本文由 網易雲 釋出。
這篇博文主要的内容不是分析說明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/