去年10月份放下了一手打造的緩存服務（NKV和NCR），投身到新成立的數據科學中心從事大數據存儲相關的工作，新的部門、新的項目、新的知識，腳踏實地，從零開始。
第一款調研的對象是cloudera公司剛開源的kudu產品，可以將其理解為是hadoop系統中的hdfs，一個存儲引擎，但是和hdfs的不同之處是它支持update操作，這點非常重要！
可能是因為剛開源的緣故，文檔中很多的的使用方式、操作步驟的描述都和cloudera manager（簡稱CM）緊緊的耦合在一起，所以一開始的時候，根本不清楚怎樣獨立部署kudu集群以及怎樣是最佳部署方式。無奈，只好先從cloudera manager管理平台安裝部署，然后等到熟悉以后再將其剝離出來，事實上后來剝離的kudu和impala的配置文件的配置參數就直接參考這里的。部署CM&CDH就花了九牛二虎之力，過程就不再細說，都是淚。
就像高富帥擇偶一樣，大公司cloudera出來的產品，對操作系統也是百般的挑剔，又要有絕對的話語權（root權限），所以一周又一周的要求sa幫忙續命（騷瑞啊，真的不是在耍你們，向sa們致以誠摯的敬意）。成功完成集群安裝部署，面臨着怎么來測試，用什么工具的尷尬，大家都沒經驗。
一開始，我們選擇了ycsb來進行測試，有兩種方式：一種是通過JDBC驅動的方式，另一種是通過kudu bind的方式。前者測試並定位了幾天才發現是驅動的問題，無法解決只好作罷；而后者，基本的load/insert/read/update都能正確執行，但唯獨scan一直有異常，網絡流量、資源消耗都不太正常，如果沒有仔細監控則很容易被忽略（scan指標很好），翻了所有的公開資料、搜索了kudu的jira庫、聯系了國內唯一的kudu committer，依然無果，偶然收到todd（kudu負責人）的回復郵件，說是kudu客戶端java驅動包本身缺陷導致，好吧，kudu的scan性能指標缺失。詳情請參考：《
【大數據之數據倉庫】kudu客戶端java驅動缺陷》。這里同時附上
加速kudu insert性能的博文以饗各位大拿！
這個時候，我們開始轉向tpcds，因為我們急切的關注kudu對於sql的覆蓋率問題。但是，網上搜索了一圈，沒有一個項目或者博文有介紹如何使用tpcds測試kudu或者impala的性能指標（這里為什么引出了impala？因為kudu本身只是一個存儲引擎，而impala是其最佳配套的計算引擎，沒有計算引擎無法談sql覆蓋率）。還好，有一根救命稻草impala-tpcds-kit，這是cloudera公司開源的用於測試impala on hdfs（parquet）的測試工具，但是，它只包含了10張表（tpcds總共有24張表），也僅僅測試了19個query（tpcds總共有99個query）。這里可以分為前后兩個階段：前一個階段是直接跑這19個query，分別在6台機器和20台機器兩個不同的集群上以不同的參數配置（調整kudu和impala的參數）、在不同的數據集下（1T、3T、10T），對比測試parquet和kudu的指標；后一個階段則是重新測試，補充上剩余的14張表，以及重寫自動化測試的腳本，重新分別在6台機器和20台機器兩個不同的集群上在不同的數據集下（1T、10T），對比測試parquet和kudu的指標。load數據的過程實在太漫長了，以至於測試10T數據集的時候，一輪就得花一個禮拜，都是insert into xxx select * from yyy惹的禍，幾輪測試下來的耗時可想而知，有更好的辦法么？
測試結果：sql覆蓋率上，因為都是impala計算引擎（kudu pk parquet），所以兩者都一樣，但是性能指標上，kudu的指標比parquet明顯差很多！為什么kudu性能指標這么差？對一個不了解的系統或者說暫時還不能hold住的系統，分析其性能指標差的原因，個人覺得有難度，而且還涉及到兩套大系統impala和kudu！各位捫心自問，換作是你，你會怎么來分析？沒有對比就沒有傷害，花了好幾天時間在這個問題上，中間省略三萬字，無意中使用了beyond compare工具對parquet和kudu的執行結果profile進行了逐行比對，終於發現了問題所在：kudu支持有限的謂詞下推功能（runtime filter） ！詳情請參考：《
【大數據之數據倉庫】kudu性能測試報告分析》。
對比意味着進步、對比意味着收獲！調研到這里，已經獲得了一手測試結果，並且發現了兩個大問題：一個是kudu的客戶端java驅動包scan存在缺陷，而測試impala過程中沒有被影響到是因為impala采用的是C++的驅動，理論上這個缺陷影響不大，因為基本上不會有用戶直接拿kudu的java驅動來接入；另一個是kudu的謂詞下推功能不完善，不支持runtime filter，導致query性能比較弱，這個就讓人難以接受了。
第二款調研的對象是pivotal公司的greenplum產品，有別於上面cloudera公司的impala和kudu，它是血統純正的MPP架構的數據庫，2015年10月開源，你可以簡單的把它理解為一個數據庫。從一開始大家對greenplum是持排斥態度的，認為它的存儲和計算合體不符合潮流、認為它的擴展性有問題、認為它只支持P級規模的數據集，但事實上，國內已經有很多大公司采購它來建設自己的數據倉庫，度娘下能找到一大堆，隔壁廠（阿里雲）的
ApsaraDB HybridDB就是基於greenplum，另外雲巨頭Amazon在2013年上市的
redshift采用的是基於postgresql的類似greenplum的架構實現（誰讓greenplum2015年才開源）、惠普基於DBMS架構的
【
大數據之數據倉庫】基准測試之TPCDS》。
第三款、第四款 ... ... 這里不再一一介紹了，這里埋個雷，大伙兒知道為啥沒有選擇
HAWQ么？請參考《
【大數據之數據倉庫】HAWQ versus GreenPlum》
文章看到這里，你一定以為是差不多要收尾了，因為測試結果已經出來了！NO NO NO！一開始面臨測試工具尷尬的時候，我們發現好多博文中提到大數據基准測試是用tpch做的，那tpch和tpcds的差異在哪里呢？有說是tpcds的sql包含了過多的聚合和關聯操作，說實話我不是很清楚，但我確定的是：tpcds的sql比tpch的復雜，業界貌似除了greenplum沒有哪個產品敢拍胸脯成功闖關99個sql的。於是，我又愉快的用tpch從頭到尾對kudu、parquet和greenplum做了對比測試，當然，所有的測試腳本都是重新寫的，不過有了前面測試tpcds的經驗，測試tpch就順利多了，基本上沒有遇到坑。詳情請參考：《
【大數據之數據倉庫】基准測試之TPCH》。
數據倉庫產品：通用性好（高sql覆蓋率），必定是MPP架構的精品數據庫；而通用性一般的，有應用場景傾斜，可以認為是定制化產品，比如parquet/carbon data/clickhouse（
附上異域猛禽彪悍的性能指標）。
這里提到的每一款產品、每一個工具都是陌生的，需要重頭開始學習摸索，基本上都是摸着石頭過河。這是本系列第一篇，后續幾篇如下：
本文來自網易雲社區，經作者何李夫授權發布。
原文地址：【大數據之數據倉庫】選型流水記
更多網易研發、產品、運營經驗分享請訪問網易雲社區。