【大数据之数据仓库】kudu性能测试报告分析

雨中漫步_012

这篇博文主要的内容不是分析说明kudu的性能指标情况，而是分析为什么kudu的scan性能会这么龊！当初
对外宣传可是加了各种 逆天黑科技的呀：列独立存储、bloom filter、压缩、原地修改、b+tree、mvcc ... ...



这里先贴个kudu和parquet小部分的TPCDS测试结果对比图吧：



没有对比就没有伤害，有了对比就有了乐趣。纵坐标是耗时，单位是秒，代表kudu的黄色柱子太高了，
说人话就是kudu耗时太 长，性能太差！



老大：为什么kudu性能会这么差？ 本人：我不清楚 ... ...



当时真的不知道原因，前前后后忙着测试，急着获取测试指标，还来不及分析，何况还是两个陌生的大系
统：impala和kudu，很 是尴尬



等到TPCDS测试用例全部跑完以后，有一个空档期，就花了几天时间来找原因，阅读资料、翻文档、go
ogle来google去，过程这 里不再叙述，下面着重描述下原因吧。



我们知道impala有个交互式的管理工具impala-shell，它有个profile命令，在每次执行完sql以后执行它，可
以获取到这个sql的执 行计划及每个点的耗时统计。因为测试kudu和parquet，计算引擎都用的是impala，
所以是不是可以从这里面获取些信息？



所以我就拿了上图中对比比较明显的query7和query40做试验，分别对kudu和parquet执行了一遍，搜集
了它们各自的profile，总 共有4个文件，然后拿来分析。可能你不信，profile的结果实在是太大了，1个文
件接近1万行，你还有信心分析么？（query40的 profile见底下附件）当时我是一脸懵逼样，没办法，原
因总得找，所以硬着头皮从头到尾的阅读。无意间，手贱，点开了以前经常 用来比对代码的beyond co
mpare，把执行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，字里行间其实已经有些端倪的，只不过当时没有引起足够
的重视：





至此，本文结束。希望大伙儿能从中吸取到一点经验，谢谢！

qqq911

感谢分享·~

Miss_love

感谢分享