本文由 網易雲 發布。
這篇博文主要的內容不是分析說明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庫的許可權問題了=_=），再次確認下 是否支援。
至此，本文結束。希望大夥兒能從中吸取到一點經驗，謝謝！
網易有數
企業級大資料視覺化分析平台。面向業務人員的自助式敏捷分析平台，採用ppt模式的報告製作，更加易學易用，具備強大的探索分析功能，真正幫助使用者洞察資料發現價值。
點選這裡---免費試用。
了解 網易雲 ：
網易雲官網：
新使用者大禮包：gift
網易雲社群：
大資料之資料倉儲分層
資料分層是一套行之有效的資料組織和管理方法，使得資料體系更有序。1 清晰資料結構 每乙個資料分層都有它的作用域和職責，在使用表的時候能更方便的定位和理解。2 減少重複開發 規範資料分層，開發一些通用的中間層資料，能夠減少極大的重複計算。3 統一資料口徑 通過資料分層，提供統一的資料出口，統一對外輸出...
大資料開發之資料倉儲理論
二 數倉和資料庫的區別 三 數倉的資料 四 數倉的分層 五 數倉建模 六 數倉調優 七 資料維護 資料倉儲，是為企業所有級別的決策制定過程，提供所有型別資料支援的戰略集合。它出於分析性報告和決策支援目的而建立。為需要業務智慧型的企業，提供指導業務流程改進 監視時間 成本 質量以及控制。概括來看，數倉...
大資料資料倉儲 場景
2015 10 24 朱潔hadoop技術學習 傳統oltp olap之分 資料倉儲裡面有oltp olap之分，oltp是傳統關係型資料庫的主要應用，其主要面向基本的 日常的事務處理，例如銀行交易。olap是資料倉儲系統的主要應用，支援複雜的分析操作，側重決策支援，並且提供直觀易懂的查詢結果。大資...