本文由 網易雲 發布。

這篇博文主要的內容不是分析說明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，字裏行間其實已經有些端倪的，只不過當時沒有引起足夠的重視：

至此，本文結束。希望大夥兒能從中吸取到一點經驗，謝謝！

了解 網易雲 ：
網易雲官網：https://www.163yun.com/
新用戶大禮包：https://www.163yun.com/gift
網易雲社區：https://sq.163yun.com/

【大數據之數據倉庫】kudu性能測試報告分析