电话咨询

0571-89852485

工作日 9:30-18:00

在线咨询

架构师咨询

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

2018-07-10     作者:何李夫
本篇文章仅限本站分享,如需转载,请联系网易获取授权。
欢迎技术交流和讨论:bigdata@service.netease.com

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

立即下载

猛犸技术白皮书

提交以下信息,即可立即下载猛犸技术白皮书

格式不正确
格式不正确
格式不正确
请输入正确的验证码
请选择职位