Ngone51 commented on a change in pull request #31763:
URL: https://github.com/apache/spark/pull/31763#discussion_r589007510
##########
File path: core/src/main/scala/org/apache/spark/scheduler/MapStatus.scala
##########
@@ -52,6 +52,13 @@ private[spark] sealed trait MapStatus {
* partitionId of the task or taskContext.taskAttemptId is used.
*/
def mapId: Long
+
+ /**
+ * Extra metadata for map status. This could be used by different
ShuffleManager implementation
+ * to store information they need. For example, a Remote Shuffle Service
ShuffleManager could
+ * store shuffle server information and let reducer task know where to fetch
shuffle data.
+ */
+ def metadata: Option[Serializable]
Review comment:
hmm...what's the relationship between SPARK-33114 and SPARK-25299?
According to the JIRA description, SPARK-33114 seems to enhance the support for
custom shuffle manager while SPARK-25299 only customize the storage with the
default `SortShuffleManager`.
So if we are only talking about SPARK-33114, adding `metadata` may be a good
choice according to its own scenario. But if we bring in SPARK-25299 together
(IIUC, what this PR is doing would also benefit SPARK-25299), I personally
think we need a more general design here. For example, I'd prefer to redesign
the `location` of `MapStatus` to make it be able to support different scenarios
(e.g., Spark BlockManager, Spark external shuffle service, custom remote
storage, etc. ) mentioned in SPARK-25299. And in this way, different scenarios
would be able to reuse the existing features, e.g., decommission(which may
update mapstatus location during runtime) and reuse the existing code paths,
e.g., we don't need the extra `getAllMapOutputStatuses` and everything should
be the same as what we already did during shuffle reading.
WDYT?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
