Spark Scala Checkpointing 数据集在操作后显示 .isCheckpointed = false 但目录已写入

Spark Scala Checkpointing Data Set showing .isCheckpointed = false after Action but directories written

似乎有一些关于此的帖子,但 none 似乎回答了我的理解。

DataBricks 上的以下代码 运行:

spark.sparkContext.setCheckpointDir("/dbfs/FileStore/checkpoint/cp1/loc7")
val checkpointDir = spark.sparkContext.getCheckpointDir.get
val ds = spark.range(10).repartition(2)
ds.cache()
ds.checkpoint()
ds.count()
ds.rdd.isCheckpointed  

添加了某种改进:

...
val ds2 = ds.checkpoint(eager=true)
println(ds2.queryExecution.toRdd.toDebugString)
...

returns:

(2) MapPartitionsRDD[307] at toRdd at command-1835760423149753:13 []
 |  MapPartitionsRDD[305] at checkpoint at command-1835760423149753:12 []
 |  ReliableCheckpointRDD[306] at checkpoint at command-1835760423149753:12 []
 checkpointDir: String = dbfs:/dbfs/FileStore/checkpoint/cp1/loc10/86cc77b5-27c3-4049-9136-503ddcab0fa9
 ds: org.apache.spark.sql.Dataset[Long] = [id: bigint]
 ds2: org.apache.spark.sql.Dataset[Long] = [id: bigint]
 res53: Boolean = false

问题一:

ds.rdd.isCheckpointedds2.rdd.isCheckpointed 两者 return False 即使有 count 我有一个非懒惰的情况。为什么,特别是 ../loc 7 和 10 是用(部分)文件编写的?我们还可以看到 ReliableCheckPoint!

没有很好地解释整个概念。试图解决这个问题。

问题 2 - 次要问题:

最新版本的 Spark 2.4 是否真的需要缓存? ds 上的一个新分支,如果没有缓存,会导致重新计算还是现在更好?不使用检查点数据似乎很奇怪,或者我们可以说 Spark 真的不知道什么更好?

从 High Performance Spark 得到的混合印象是不推荐使用检查点,但话又说回来。

TL;DR:您没有检查实际设置了检查点的对象:

ds2.queryExecution.toRdd.dependencies(0).rdd.isCheckpointed
// Boolean = true

ds.rdd.isCheckpointed or ds2.rdd.isCheckpointed both return False

这是预期的行为。被检查点的对象不是您引用的转换后的 RDD(这是转换为外部表示所需的额外转换的结果),而是内部 RDD 对象(实际上,正如您在上面看到的,它甚至不是最新的内部 RDD,但它的父级)。

此外,在第一种情况下,您只是使用了错误的 Dataset 对象 - 正如 Dataset.checkpoint returns a new Dataset

中所述

even though with count I have a non-lazy situation

这没有多大意义。默认 checkpoint 实现 is eager, therefore it force evaluates. Even if it wasn't for that, 强制计算。

Is the cache really necessary or not with latest version

如您在链接源中所见,Dataset.checkpoint 在内部使用 RDD.checkpoint,因此适用相同的规则。但是,您已经执行了一个单独的操作来强制检查点,因此额外的缓存,尤其是考虑到 Dataset 持久性的成本,可能是一种矫枉过正。

当然,如果有疑问,您可以考虑在特定上下文中进行基准测试。