Spark迭代/递归算法 - 打破火花谱系答案

【问题标题】：Spark iterative/recursive algorithms - Breaking spark lineageSpark迭代/递归算法 - 打破火花谱系
【发布时间】：2018-09-28 13:47:24
【问题描述】：

我有一个递归 spark 算法，它将 10 天的滑动窗口应用于数据集。

原始数据集是从按日期分区的 Hive 表中加载的。

在每次迭代中，都会对包含十天窗口的数据集应用一组复杂的操作。

最后一个日期然后被插入回原始 Hive 表中，下一个日期从 Hive 加载并联合到剩余的 9 天。

我意识到我需要打破火花谱系以防止 DAG 变得无法管理。

我相信我有两个选择：

使用第二个选项是否有任何缺点 - 我假设这是一个内存操作，因此更便宜。

【问题讨论】：

【解决方案1】：

检查指向并转换回 RDD 确实是截断沿袭的最佳/唯一方法。

许多（全部？）Spark ML Dataset/DataFrame 算法实际上是使用 RDD 实现的，但由于优化器未并行化以及迭代/递归实现的沿袭大小，公开的 API 是 DS/DF。

与 RDD 之间的转换是有成本的，但比文件系统检查点选项要小。

【讨论】：

怎么说你有一个 DF.read 循环？那么血统是如何运作的呢？ @Garren S
如果我理解您的问题，一个应用程序会循环使用许多读取调用，其中每次读取都与最后一次读取无关，血统应该不是问题，因为每次读取都是它自己的工作。如果您继续将相同的数据集转换为 RDD，然后再返回，则沿袭将被截断。
好的，明白了。阅读这个问题让我们感到好奇。这说明了这一点。周末愉快。
是否转换为 rdd 然后调用createDataFrame 将 rdd 收集到驱动程序？我只在主机上的本地数据上使用了createDataFrame，我现在正在尝试这个，它在驱动程序上因内存不足而崩溃 - 不确定它是否是这个createDataFrame 调用呢
我有类似的需要在每次迭代中截断 dag，因为我的 udf 调用随着每次迭代而不断增加。我必须避免检查点和缓存。正在转换为 rdd 并返回最佳解决方案，它会截断 dag。