【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对比解析

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