【大數據之數據倉庫】選型流水記

時間  2020-05-16
標籤 大數據之數據倉庫 選型 流水 简体版
原文   原文鏈接

去年10月份放下了一手打造的緩存服務（NKV和NCR），投身到新成立的數據科學中心從事大數據存儲相關的工做，新的部門、新的項目、新的知識，腳踏實地，從零開始。php

第一款調研的對象是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（ 附上異域猛禽彪悍的性能指標）。
這裏提到的每一款產品、每個工具都是陌生的，須要重頭開始學習摸索，基本上都是摸着石頭過河。這是本系列第一篇，後續幾篇以下：

本文來自網易雲社區，經做者何李夫受權發佈。html

原文地址：【大數據之數據倉庫】選型流水記java

更多網易研發、產品、運營經驗分享請訪問網易雲社區。 算法

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程