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

没有比照就没有伤害，有了比照就有了乐趣。纵坐标是耗时，单位是秒，代表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）比对了下，一点点往下拉，在执行方案这一 段，竟然真发现了宝！

两者扫描磁盘获取的结果集也不一样了！！难怪在比拟测试过程中，kudu集群跑query的时分会有大量的磁盘IO和网络传输开支， 而parquet负荷比拟低！你看懂了么？

为什么kudu没有runtime filter？于是去kudu的jira库搜索，好吧，没找到！那试试impala的jira库呢，还真找到了，Matthew Jacobs是cloudera公司impala/kudu的开发工程师，找到他的两个jira单：

看到这里，根本上问题曾经比拟明白了，答案有了，可是我不甘心啊，于是不论三七二十一就注册了账号，在他们的jira库上提了 bug单： impala-4719（正常状况应该是在userlist发邮件咨询，那么就当我帮他们测试了jira库的权限问题了=_=），再次确认下 能否支持。

后来又重新去阅读了kudu的官方documents，字里行间其实曾经有些端倪的，只不过当时没有惹起足够的注重：

至此，本文完毕。希望大伙儿能从中汲取到一点经历，谢谢！