-
Notifications
You must be signed in to change notification settings - Fork 28.6k
[WIP][SPARK-14408][CORE] Changed RDD.treeAggregate to use fold instead of reduce #12217
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
93e3cb3
0d05b96
7fcc10d
16e79e3
02d107a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -1061,7 +1061,7 @@ abstract class RDD[T: ClassTag]( | |
* Aggregates the elements of this RDD in a multi-level tree pattern. | ||
* | ||
* @param depth suggested depth of the tree (default: 2) | ||
* @see [[org.apache.spark.rdd.RDD#aggregate]] | ||
* @see [[org.apache.spark.rdd.RDD#aggregate]] These two methods have identical semantics. | ||
*/ | ||
def treeAggregate[U: ClassTag](zeroValue: U)( | ||
seqOp: (U, T) => U, | ||
|
@@ -1075,7 +1075,7 @@ abstract class RDD[T: ClassTag]( | |
val cleanCombOp = context.clean(combOp) | ||
val aggregatePartition = | ||
(it: Iterator[T]) => it.aggregate(zeroValue)(cleanSeqOp, cleanCombOp) | ||
var partiallyAggregated = mapPartitions(it => Iterator(aggregatePartition(it))) | ||
var partiallyAggregated: RDD[U] = mapPartitions(it => Iterator(aggregatePartition(it))) | ||
var numPartitions = partiallyAggregated.partitions.length | ||
val scale = math.max(math.ceil(math.pow(numPartitions, 1.0 / depth)).toInt, 2) | ||
// If creating an extra level doesn't help reduce | ||
|
@@ -1087,9 +1087,10 @@ abstract class RDD[T: ClassTag]( | |
val curNumPartitions = numPartitions | ||
partiallyAggregated = partiallyAggregated.mapPartitionsWithIndex { | ||
(i, iter) => iter.map((i % curNumPartitions, _)) | ||
}.reduceByKey(new HashPartitioner(curNumPartitions), cleanCombOp).values | ||
}.foldByKey(zeroValue, new HashPartitioner(curNumPartitions))(cleanCombOp).values | ||
} | ||
partiallyAggregated.reduce(cleanCombOp) | ||
val copiedZeroValue = Utils.clone(zeroValue, sc.env.closureSerializer.newInstance()) | ||
partiallyAggregated.fold(copiedZeroValue)(cleanCombOp) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's this line which makes AFTSurvivalRegression fail. Not sure why... There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @jkbradley Is it because the code uses There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I tried making one copy for each use of zeroValue at the beginning of the method, but that didn't fix the AFT test failures. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hm OK if you've got a copy for each of the 3 usages, that really can't be it. Unless the clone isn't implemented as a deep clone for the object in question somehow. Could it be due to a different order of applying the combOp in this case? that's the only other thing I can think of if this change alone is the issue. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The ordering of the combOp really shouldn't matter for AFT. I feel like it must be some esoteric closure issue. |
||
} | ||
} | ||
|
||
|
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to help ... I believe the actual Javadoc errors look ...