我正在研究以数据砖为基础进行认证考试,而他们的实践考试(请参阅> https://databricks-prod-cloudfront.cloud.databricks.com/public/793177bc53e528530b06c78a4fa0e086/0/6221173/100020/latest.html)要求我们接受以下陈述为真实事实:
“显式缓存可能通过干扰来降低应用程序性能 借助Catalyst优化器优化某些查询的能力”
即使我已经读了很多关于催化剂的文章,并且对细节有很好的理解,但我还是错了这个问题。因此,我想增强我对该主题的了解,并转到源头,该源头解释了该主张的背后原因和原因。
任何人都可以提供有关此方面的指导吗?具体来说,为什么会这样呢?以及如何确保在缓存数据集时不会真正妨碍优化器并使情况变得更糟? /谢谢!
答案 0 :(得分:3)
让我们用一个简单的例子来证明这一点:
// Some data
val df = spark.range(100)
df.join(df, Seq("id")).filter('id <20).explain(true)
在这里,催化剂计划将通过在联接之前在每个数据帧上执行过滤器来优化此联接,以减少将被拖曳的数据量。
== Optimized Logical Plan ==
Project [id#0L]
+- Join Inner, (id#0L = id#69L)
:- Filter (id#0L < 20)
: +- Range (0, 100, step=1, splits=Some(4))
+- Filter (id#69L < 20)
+- Range (0, 100, step=1, splits=Some(4))
如果我们在连接后缓存查询,查询将不会像在这里看到的那样优化:
df.join(df, Seq("id")).cache.filter('id <20).explain(true)
== Optimized Logical Plan ==
Filter (id#0L < 20)
+- InMemoryRelation [id#0L], true, 10000, StorageLevel(disk, memory, deserialized, 1 replicas)
+- *Project [id#0L]
+- *BroadcastHashJoin [id#0L], [id#74L], Inner, BuildRight
:- *Range (0, 100, step=1, splits=4)
+- BroadcastExchange HashedRelationBroadcastMode(List(input[0, bigint, false]))
+- *Range (0, 100, step=1, splits=4)
过滤器在最后完成...
为什么这样?因为cache
在磁盘上写入了数据帧。因此,每个后续查询都将使用此缓存/写在磁盘DataFrame上的数据,因此它将仅在缓存之后优化查询的一部分。我们可以使用相同的示例进行检查!
df.join(df, Seq("id")).cache.join(df, Seq("id")).filter('id <20).explain(true)
== Optimized Logical Plan ==
Project [id#0L]
+- Join Inner, (id#0L = id#92L)
:- Filter (id#0L < 20)
: +- InMemoryRelation [id#0L], true, 10000, StorageLevel(disk, memory, deserialized, 1 replicas)
: +- *Project [id#0L]
: +- *BroadcastHashJoin [id#0L], [id#74L], Inner, BuildRight
: :- *Range (0, 100, step=1, splits=4)
: +- BroadcastExchange HashedRelationBroadcastMode(List(input[0, bigint, false]))
: +- *Range (0, 100, step=1, splits=4)
+- Filter (id#92L < 20)
+- Range (0, 100, step=1, splits=Some(4))
该过滤器在第二个连接之前完成,但在第一个连接之后完成,因为已缓存。
知道自己在做什么!您可以简单地比较催化剂计划,看看Spark缺少哪些优化。