我正在使用一组表开发 Spark SQL 分析解决方案。假设我需要 5 个表来构建我的解决方案，最后我正在创建一个输出表。 这是我的流程
dataframe1 = table1 join table2
dataframe2 = dataframe1 join table3
dataframe3 = datamframe2 + filter + agg
dataframe4 = dataframe3 join table4 join table 5
// finally
dataframe4.saveAsTable
当我保存最终数据帧时，即评估所有上述数据帧。 我的方法好吗？要么 我需要缓存/持久化中间数据帧吗？
【问题讨论】：
标签： apache-spark apache-spark-sql
这是一个非常笼统的问题，很难提供明确的答案。
根据表的大小，您可能希望对任何相对较小的表进行广播提示。 您可以通过
table_i.join(broadcast(table_j), ....)
此行为取决于以下值：
现在广播提示只有在 Spark 能够评估表的值时才会被兑现，因此您可能需要cache()。
另一种选择是通过 Spark 检查点，它可以帮助截断本地优化计划（这也允许您从检查点位置恢复作业，它类似于写入 HDFS，但有一些开销）。
如果广播几百个 Mb 表，您可能需要增加 kryo 缓冲区：
--conf spark.kryoserializer.buffer.max=1g
这还取决于您将使用哪种连接类型。 您可能希望尽早进行过滤和聚合，因为它会减少连接面。
为了适当地优化它，还有许多其他的考虑因素需要考虑。如果任何连接中连接键的幂律分布，您需要进行盐渍化并分解较小的表。
【讨论】：
在您的情况下，原则上不需要缓存或持久化为什么？
但是，由于集群上的内存驱逐可能性，可能需要在 Worker 上重新计算。您可以通过 .cache 和 .persist 应用各种设置，但 Spark 无需显式 .cache 或 .persist 即可处理内存和磁盘溢出。见https://sparkbyexamples.com/spark/spark-difference-between-cache-and-persist/
此外，使用 .cache 会影响性能。所以使用.explain。在这里看到一个很好的帖子：Spark: Explicit caching can interfere with Catalyst optimizer's ability to optimize some queries?
因此，每种情况都不同，但您的情况似乎可以像我一样回答。总而言之：没有缓存或检查点的 RDD 或 DF 每次在该 RDD 或 DF 上调用 Action 时或如果在当前 Action 内重新访问且不适用跳过阶段的情况时，都会再次重新评估。在你的情况下没有问题。否则实际上会减慢您的应用程序的速度。
【讨论】：