浪尖以案例聊聊spark 3.0 sql的动态分区裁剪

浪尖聊大数据

共 1943字,需浏览 4分钟

 · 2021-06-22

麻烦大家给浪尖投个票,主要是目前公共号名称太单一了,以后的分享的知识会扩充到数据智能,用户画像等领域。

本文主要讲讲,spark 3.0之后引入的动态分区裁剪机制,这个会大大提升应用的性能,尤其是在bi等场景下,存在大量的where条件操作。

动态分区裁剪比谓词下推更复杂点,因为他会整合维表的过滤条件,生成filterset,然后用于事实表的过滤,从而减少join。当然,假设数据源能直接下推执行就更好了,下推到数据源处,是需要有索引和预计算类似的内容。

1.静态数据集分区谓词下推执行
下面sql 是为例
SELECT * FROM Sales WHERE day_of_week = ‘Mon’
该语句执行有两种可能:
1) .全表扫描,然后过滤。
2) .先过滤再扫描。
假如表按照day_of_week字段分区,那sql应该是将filter下推,先过滤,然后在scan。
这就是传统数据库存在索引及预计算的时候所说的谓词下推执行。
2.动态分区裁剪场景
Spark 3.0的分区裁剪的场景主要是基于谓词下推执行filter(动态生成),然后应用于事实表和维表join的场景。
如果存在分区表和维表上的filter,则通过添加dynamic-partition-pruning filter来实现对另一张表的动态分区修剪。
有下面一个简单的sql,完成的功能是事实表(sales)和维表(Date)的join:
SELECT * FROM Sales JOIN Date WHERE Date.day_of_week = ‘Mon’;
假如不存在任何下推执行的优化,执行过程就应该如下图:
上图就是不存在任何谓词下推执行优化的计算过程,全量扫描事实表sales和维表date表,然后完成join,生成的表基础上进行filter操作,然后再scan计算,显然这样做很浪费性能。
假如维表支持下推执行,那么就可以先进行维表的filter操作,减少维表Date的数据量加载,然后在进行事实表sales的scan和维表date的scan,最后进行join操作。
想一想,由于where条件的filter是维表Date的,spark读取事实表的时候也是需要使用扫描的全表数据来和维表Date实现join,这就大大增加了计算量。
假如能进一步优化,通过维表date的filter,生成一个新的事实表的salesFilterSet,应用到事实表sales,那么就可以大大减少join计算性能消耗。也即是这个样子:
这个就叫做动态分区裁剪。下面的例子会更详细点:
表t1和t2进行join,为了减少参加join计算的数据量,就为t1表计算(上图右侧sql)生成了一个filter数据集,然后再扫描之后过滤。当然,这个就要权衡一下,filter数据集生成的子查询及保存的性能消耗,与对数据过滤对join的性能优化的对比了,这就要讲到spark sql的优化模型了。
spark sql 是如何实现sql优化操作的呢?
一张图可以概括:
现在sql解析的过程中完成sql语法优化,然后再根据统计代价模型来进行动态执行优化。
逻辑执行计划的优化都是静态的,物理计划的选择可以基于统计代价模型来计算动态选择。
下图是一个基于分区ID的join实现。维表的数据是没有分区的,事实表的数据是分区的。假如没有动态分区裁剪,那么完成的执行过程就如图所示。事实表和维表都需要全表扫描,然后对维表执行filter操作,最后再进行join操作。
假如对维表的filter操作,进行一些计算然后可以生成事实表的filter set,那么就可以减少维表和事实表join的数据量了。就如前面的t1和t2的join例子一样。
当然,上面的例子要考虑计算和保存事实表的filter set集合的开销是否远小于其减少join数据量的增益,否则就得不偿失了。
还有一种join大家都比较熟悉,那就是Broadcast Hash Join。
这种主要是重用广播的结果,来实现filter功能。这个的理解要基于BroadcastExchangeExec。后面出文章详细聊吧。
至于效果码,可以关注浪尖微信公众号:bigdatatip。然后输入 :dpp  获取完整的ppt。
推荐阅读:
Flink 消息聚合处理方案
不可不知的spark shuffle
从 PageRank Example 谈 Spark 应用程序调优
浪尖的星球马上突破1000~

浏览 30
点赞
评论
收藏
分享

手机扫一扫分享

举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

举报