本文由 網易雲 發布。
這篇博文主要的內容不是分析說明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，字里行間其實已經有些端倪的，只不過當時沒有引起足夠的重視：
至此，本文結束。希望大伙兒能從中吸取到一點經驗，謝謝！
網易有數
企業級大數據可視化分析平台。面向業務人員的自助式敏捷分析平台，采用PPT模式的報告制作，更加易學易用，具備強大的探索分析功能，真正幫助用戶洞察數據發現價值。
點擊這里---免費試用。
了解 網易雲 ：
網易雲官網：https://www.163yun.com/
新用戶大禮包：https://www.163yun.com/gift
網易雲社區：https://sq.163yun.com/