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

勿忘初心2018-11-21 15:11

欢迎访问网易云社区,了解更多网易技术产品运营经验。


这篇博文主要的内容不是分析说明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-3741impala-4252

+

看到这里,基本上问题已经比较明确了,答案有了,可是我不甘心啊,于是不管三七二十一就注册了账号,在他们的jira库上提了 bug单: impala-4719(正常情况应该是在userlist发邮件咨询,那么就当我帮他们测试了jira库的权限问题了=_=),再次确认下 是否支持。


后来又重新去阅读了kudu的官方documents,字里行间其实已经有些端倪的,只不过当时没有引起足够的重视:

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


网易有数:企业级大数据可视化分析平台。面向业务人员的自助式敏捷分析平台,采用PPT模式的报告制作,更加易学易用,具备强大的探索分析功能,真正帮助用户洞察数据发现价值。可点击这里免费试用