根据Spark文档,只有RDD操作可以触发Spark作业,并且在对其调用操作时会对延迟进行转换评估。
我看到with
转换函数立即应用,它在SparkUI中显示为作业触发器。为什么呢?
答案 0 :(得分:7)
sortBy
使用sortByKey
实现,RangePartitioner
依赖于sortBy
(JVM)或分区函数(Python)。当您调用sortByKey
/ RDD
分区器(分区功能)时,需要急切地初始化分区器并对输入RDD进行采样以计算分区边界。你看到的工作对应于这个过程。
仅当您对新创建的beforeShowDay
或其后代执行操作时,才会执行实际排序。
答案 1 :(得分:1)
根据Spark文档,只有该操作在Spark中触发作业,在对其调用操作时会对延迟进行转换。
一般来说,你是对的,但正如你刚才所经历的那样,很少有例外情况,sortBy
就在其中(zipWithIndex
)。
事实上,它在Spark的JIRA中有报道,并以Will not Fix解决方案结束。请参阅the documentation。
您可以看到在启用DAGScheduler
日志记录的情况下运行的作业(稍后在Web UI中):
scala> sc.parallelize(0 to 8).sortBy(identity)
INFO DAGScheduler: Got job 1 (sortBy at <console>:25) with 8 output partitions
INFO DAGScheduler: Final stage: ResultStage 1 (sortBy at <console>:25)
INFO DAGScheduler: Parents of final stage: List()
INFO DAGScheduler: Missing parents: List()
DEBUG DAGScheduler: submitStage(ResultStage 1)
DEBUG DAGScheduler: missing: List()
INFO DAGScheduler: Submitting ResultStage 1 (MapPartitionsRDD[4] at sortBy at <console>:25), which has no missing parents
DEBUG DAGScheduler: submitMissingTasks(ResultStage 1)
INFO DAGScheduler: Submitting 8 missing tasks from ResultStage 1 (MapPartitionsRDD[4] at sortBy at <console>:25)
DEBUG DAGScheduler: New pending partitions: Set(0, 1, 5, 2, 6, 3, 7, 4)
INFO DAGScheduler: ResultStage 1 (sortBy at <console>:25) finished in 0.013 s
DEBUG DAGScheduler: After removal of stage 1, remaining stages = 0
INFO DAGScheduler: Job 1 finished: sortBy at <console>:25, took 0.019755 s
res1: org.apache.spark.rdd.RDD[Int] = MapPartitionsRDD[6] at sortBy at <console>:25