阿凡达

未来可期

285篇博客

最新博客

最新资源下载

编辑推荐

网易数帆开源API网关与容器云项目，让云原生生产落地“多快好网易汪源：统一负载与多云环境的“开放姿态”，才是云原生网易数帆如何用 Kubernetes“原语”搞定云原生中间件快手打新挤爆券商系统，网易数帆推出券商稳定性保障方案探索智慧校园新模式，网易有数在教育行业的实践分享金融行业大数据治理之路——数据模型篇

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

阿凡达2018-07-10 12:57

这是【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秒钟？

本文来自网易实践者社区，经作者何李夫授权发布。

推荐博客