我正在尝试对3个DataFrame进行一系列转换。每次转换后,我想保留DF并将其保存到文本文件中。我正在做的步骤如下。
Step0:
创建DF1
创建DF2
创建DF3
创建DF4
(没有坚持没有保存)
步骤1:
通过连接DF1和DF2来创建RESULT-DF1
坚持它到磁盘和内存
将其保存到文本文件
步骤2:
通过连接RESULT-DF1和DF3来创建RESULT-DF2
坚持它到磁盘和内存
将其保存到文本文件
步骤3:
通过连接RESULT-DF2和DF4来创建RESULT-DF3
坚持它到磁盘和内存
将其保存到文本文件
观察:
在步骤1中创建的任务数为601
在Step2创建的任务数量是1004(没有跳过任何内容)
在Step3创建的任务数量为1400(跳过400个任务)
作为不同的方法,我将上述步骤分为三个不同的运行。即;
后来的方法运行得更快。
我的问题是:
在第一种方法中,我在遗漏方面遗漏了什么?
为什么Step2运行不仅仅使用Step1的结果而不重做所有任务,即使在持久化之后(只有601个任务而不是1004个)?
在实施这样一系列转型工作流程时,有哪些关于最佳实践的好读物?
答案 0 :(得分:0)
由于没有提供代码,我将假设您每次执行的连接操作都不同(在不同的属性和数据上)。即使您已缓存数据帧,Spark也需要将每个连接解析为多个阶段和任务。 Catalyst优化器负责为您的查询创建逻辑(初始和优化)和物理计划。每当必须根据您的查询和相应的数据集计算新计划时,给定此执行顺序(每次连接后数据框可能变得更小或更大)。
鉴于每次连接后任务从数据框增加到数据框,您的数据集可能会变得更大和/或您对多个属性执行连接操作。但是,在第二种方法中,我无法理解你的意思。
如需进一步阅读,我建议如下: https://databricks.com/blog/2015/04/13/deep-dive-into-spark-sqls-catalyst-optimizer.html
答案 1 :(得分:0)
在您的情况下,请考虑Spark SQL查询优化器的工作原理。 Catalyst优化器目前遇到挑战的一个案例是查询计划非常大。这些查询计划往往是迭代算法的结果,如图算法或机器学习算法。一个简单的解决方法是在每次迭代结束时将数据转换为RDD并返回DataFrame / Dataset。
我遇到了与上述内容完全相同的问题。这种解决方法确实有帮助。
〜埃里克