【kudu pk parquet】TPC-H Query2对比解析

这是【kudu pk parquet】的第二篇，query2在kudu和parquet上的对比解析，其中kudu包含有不能下发的谓词。

3台物理机，1T规模的数据集，impala和kudu版本是咱们修改后支持runtime filter的版本，结果对好比下图：

 

纵坐标表示耗时，矮表示性能好，耗时短，响应差近三倍。

首先，来咱们来看二者的执行计划，颜色越鲜艳表示越耗时：

• parquet

 

• kudu

 

能够看到kudu左右两边各有一个鲜艳的红色框（节点），说明这两个执行节点耗时比较长，放大来看：

左边部分：

• parquet

 

• kudu

上面两个图的执行计划红色圈起来部分，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秒后到达，无效）之后才到达的：

 

因此减去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

 

• kudu

 

上面两个图中，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”目前是不支持的：

由于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个地雷：

1. 为何parquet上“07：SCAN KUDU”只返回5条，而kudu返回了25条？
2. 在kudu执行计划中，一样是扫描partsupp表，为啥“左边部分”“05：SCAN KUDU”节点只耗时7秒钟，而“右边部分”“02：SCAN KUDU”节点则耗时11秒钟？

本文来自网易云社区，经做者何李夫受权发布。

原文地址：【kudu pk parquet】TPC-H Query2对比解析

更多网易研发、产品、运营经验分享请访问网易云社区。