这是【kudu pk parquet】的第二篇,query2在kudu和parquet上的对比解析,其中kudu包含有不能下发的谓词。
3台物理机,1T规模的数据集,impala和kudu版本是我们修改后支持runtime filter的版本,结果对比如下图:
纵坐标表示耗时,矮表示性能好,耗时短,响应差近三倍。
首先,来我们来看两者的执行计划,颜色越鲜艳表示越耗时:
- parquet
![](https://i-blog.csdnimg.cn/blog_migrate/2f3dcf20d0c471bceb82e8560241fbd6.png)
- kudu
![](https://i-blog.csdnimg.cn/blog_migrate/067ab61862d617b86b984d96367cfb4d.png)
可以看到kudu左右两边各有一个鲜艳的红色框(节点),说明这两个执行节点耗时比较长,放大来看:
左边部分:
- parquet
![](https://i-blog.csdnimg.cn/blog_migrate/581013e9c73fd9f651a926293108fed9.png)
- kudu
![](https://i-blog.csdnimg.cn/blog_migrate/322a977ac1a4ff39574c07882997b878.png)
上面两个图的执行计划红色圈起来部分,parquet的扫描(“05:SCAN KUDU”)和关联(“09:HASH JOIN”)分别只要1秒钟左右,而kudu则要7秒和11秒。
大家注意到了没有,“07:SCAN KUDU”这个节点在两个引擎上返回的数据量是不一样的,parquet只返回了5条记录,kudu则返回了25条。同时这个返回结果是作为runtime filter应用于“06:SCAN KUDU”的,所以可以看到“06:SCAN KUDU”节点上返回的数据量,呈现几何级的差异(条件宽泛,所以匹配的数据量就多了)。接着,过滤出来的结果再runtime filter应用于“05:SCAN KUDU”节点。为什么“05:SCAN KUDU”节点的扫描动作会差7倍(kudu 7秒钟对比parquet 1秒钟)?
分析kudu的profile可以看到“05:SCAN KUDU”的runtime filter是在2秒钟(另外1个是在18秒后到达,无效)以后才到达的:
![](https://i-blog.csdnimg.cn/blog_migrate/b26152a872ce46d6e2e7d37ad19bca5b.png)
所以减去1秒钟的filter等待时间,对partsupp表扫描花了6秒钟时间,同样是扫描partsupp表为啥parquet只要扫描2秒钟,怎么解释?这涉及到了runtime裁剪分片,因为它们的关联键刚好是个主键
05:SCAN KUDU [kudu_1000g_2.partsupp]
runtime filters: RF000 -> kudu_1000g_2.partsupp.ps_partkey, RF004 -> ps_suppkey
mem-estimate=0B mem-reservation=0B
tuple-ids=5 row-size=24B cardinality=800000000
----------------
所以动态裁剪分片很重要,这里就不再展开,以后有机会再解析。
扫描返回的数据多,直接导致后续的关联节点“09:HASH JOIN”时间变成11秒。
前面埋伏了1个地雷,有心的读者可以想一下。
右边部分:
- parquet
![](https://i-blog.csdnimg.cn/blog_migrate/a2566d7bf88b7fa85579344aeea31c81.png)
- kudu
![](https://i-blog.csdnimg.cn/blog_migrate/5c4b450992211a1e5befa6746f7f0209.png)
上面两个图中,kudu的“00:SCAN KUDU”节点消耗了4秒钟,而parquet只需要817毫秒!
查看kudu的profile:
| | | F07:PLAN FRAGMENT [RANDOM] hosts=3 instances=3
| | | 00:SCAN KUDU [kudu_1000g_2.part]
| | | predicates: p_type LIKE '%NICKEL'
| | | kudu predicates: p_size = 22
| | | mem-estimate=0B mem-reservation=0B
| | | tuple-ids=0 row-size=75B cardinality=1264911
| | |
可以看到有个“like”的谓词,但是kudu官网说“!=”和“like”目前是不支持的:
![](https://i-blog.csdnimg.cn/blog_migrate/3ba96f0cdddddb31ff7187c60a9f3588.png)
因为kudu不支持“like”谓词的下发,所以过滤的动作需要在impala侧执行,这就需要impala把kudu上的数据全部扫描读取过来,那么这个耗时跟parquet本地过滤显然是没法比的(网络IO+序列化反序列化),近5倍的差异。
然后,左边“02:SCAN KUDU”节点的runtime filter是在4秒钟后到达:
所以partsupp全表扫了3秒钟(减去1秒钟的filter等待时间),然后应用filter,接着扫描剩下的7秒钟(11秒-4秒),也即扫描花了10秒钟时间。耗时比parquet长的原因和最前面“左边部分”的“05:SCAN KUDU”一样,也涉及到了runtime裁剪分片,因为它们的关联键也是主键:
| | 02:SCAN KUDU [kudu_1000g_2.partsupp]
| | runtime filters: RF008 -> ps_partkey
| | mem-estimate=0B mem-reservation=0B
| | tuple-ids=2 row-size=24B cardinality=800000000
| |
这里埋伏第2个地雷。
-------------------------------------------------------------------------------------------
到此,TPC-H query2在kudu和parquet上执行耗时的对比已经解析完成,接下来挖出前面埋伏的2个地雷:
- 为什么parquet上“07:SCAN KUDU”只返回5条,而kudu返回了25条?
- 在kudu执行计划中,同样是扫描partsupp表,为啥“左边部分”“05:SCAN KUDU”节点只耗时7秒钟,而“右边部分”“02:SCAN KUDU”节点则耗时11秒钟?
本文来自网易云社区,经作者何李夫授权发布。
原文地址:【kudu pk parquet】TPC-H Query2对比解析
更多网易研发、产品、运营经验分享请访问网易云社区。