本篇教程探讨了大数据技术 kudu性能测试报告分析，希望阅读本篇文章以后大家有所收获，帮助大家对大数据技术的理解更加深入。

<

这篇文章主要的内容不是分析说明kudu的性能指标情况，而是分析为什么kudu的scan性能会这么龊！当初对外宣传可是加了各种 逆天黑科技的呀：列独立存储、bloom filter、压缩、原地修改、b+tree、mvcc ... ...
 
这里先贴个kudu和parquet小部分的TPCDS测试结果对比图吧：

没有对比就没有伤害，有了对比就有了乐趣。纵坐标是耗时，单位是秒，代表kudu的黄色柱子太高了，说人话就是kudu耗时太 长，性能太差！
 
老大：为什么kudu性能会这么差？ 本人：我不清楚 ... ...
 
当时真的不知道原因，前前后后忙着测试，急着获取测试指标，还来不及分析，何况还是两个陌生的大系统：impala和kudu，很 是尴尬:(
 
等到TPCDS测试用例全部跑完以后，有一个空档期，就花了几天时间来找原因，阅读资料、翻文档、google来google去，过程这 里不再叙述，下面着重描述下原因吧。
 
我们知道impala有个交互式的管理工具impala-shell，它有个profile命令，在每次执行完sql以后执行它，可以获取到这个sql的执 行计划及每个点的耗时统计。因为测试kudu和parquet，计算引擎都用的是impala，所以是不是可以从这里面获取些信息？
 
所以我就拿了上图中对比比较明显的query7和query40做试验，分别对kudu和parquet执行了一遍，搜集了它们各自的profile，总 共有4个文件，然后拿来分析。可能你不信，profile的结果实在是太大了，1个文件接近1万行，你还有信心分析么？（query40的 profile见底下附件）当时我是一脸懵逼样，没办法，原因总得找，所以硬着头皮从头到尾的阅读。无意间，手贱，点开了以前经常 用来比对代码的beyond compare，把执行query40的两个profile（kudu和parquet）比对了下，一点点往下拉，在执行计划这一 段，居然真发现了宝！
 

 
parquet有runtime filter，而kudu没有，接着往下拉，对应的磁盘scan部分：
 

 
两者扫描磁盘获取的结果集也不一样了！！难怪在比较测试过程中，kudu集群跑query的时候会有大量的磁盘IO和网络传输开销， 而parquet负荷比较低！你看懂了么？
 
为什么kudu没有runtime filter？于是去kudu的jira库搜索，好吧，没找到！那试试impala的jira库呢，还真找到了，Matthew Jacobs是cloudera公司impala/kudu的开发工程师，找到他的两个jira单：impala-3741和impala-4252
 

+

看到这里，基本上问题已经比较明确了，答案有了，可是我不甘心啊，于是不管三七二十一就注册了账号，在他们的jira库上提了 bug单：impala-4719（正常情况应该是在userlist发邮件咨询，那么就当我帮他们测试了jira库的权限问题了=_=），再次确认下 是否支持。
 
后来又重新去阅读了kudu的官方documents，字里行间其实已经有些端倪的，只不过当时没有引起足够的重视：

 
   

本文由职坐标整理发布，学习更多的大数据技术相关知识，请关注职坐标大技术云计算大技术技术频道！