到底要不要引入hive｜Java 開發實戰

最近接手了一個比較古老的項目，用到了hbase/hive/hadoop等相關技術，考慮到技術的更新疊代，但還是對之前的一些設計方案比較感興趣，故探讨一下。 曆史 Hive 由 2009 年 3 月引入淘寶作為資料平台的海量資料分析基礎架構, 引入的原因有如下 幾點: (1) 不是所有使用者都懂計算機程式設計, 特别是 MapReduce 的分布式程式, 并且資料平 台的使用者大多數會 SQL, Hive 則提供了由 SQL 解析成 MapReduce 作業的功能, 用 戶隻需要掌握 SQL 即可上手, 學習曲線較為平滑.

(2) Hive SQL 表意精簡, 大幅度地減少開發量, 提高資料分析的生産效率. 例如, 之前統計網站 UV 的代碼至少需要 Mapper, Reducer, JobDriver 三個類共計數百 行 Java 代碼, 使用 Hive 隻需要一行 SQL.

(3) Hive 具有查詢優化引擎, 結合了一部分傳統資料庫的優化理論以及針對 MapReduce 分布式程式的一些優化理念. MapReduce 原生程式達到 Hive 同等的效 率，需要編寫大量的優化代碼.

(4) Hive提供中繼資料服務, 而原生MapReduce以及Pig都不提供. 中繼資料有助于數 據血緣分析,資料生命周期定義,資料共享以及權限控制等資料倉庫的基礎功能. 經過兩年的發展, Hive 已經成為淘寶資料平台的主要離線資料分析基礎架構. 在橫向 上誕生了極限存儲,DIP,Web IDE 等項目, 同時影響了天網排程系統,資料同步工具 (DataX, DbSync),資料平台生命周期分析系統的發展曆程；在縱向上, Hive 産生的結 果資料已經成為量子統計,資料魔方,搜尋,BI 業務的主要資料來源，并且一淘,淘寶商城, 支付寶,B2B,阿裡金融集團子公司也開始使用 Hive 作為他們的資料分析工具, 提取他們 所需要的資料.

問題

随着 Hive 在淘寶的深度使用, 有一些問題逐漸暴露出來:

(1) 根據 Hive 教育訓練的結果回報, 集團内有一些數字化營運, PD 員工開始使用 Hive. 這部分使用者的特征是對資料的商業價值敏感度及對資料化産品的認識度都相對于開 發人員更高, 但他們往往不會 SQL 語言, 更容易接受可視化操作.

(2) Hive 使用的 SQL 語言不利于圖形化操作.市面上出現的一些成熟的 SQL 圖形化操 作工具都可以有效地解決 Join 操作的圖形化，但都無法較好地解決如何實作子查 詢以及 aggregation 操作的圖形化.

(3) SQL是一種描述型語言, 開發SQL的使用者必須把他所需要的結果關系Schema化分 為多個子 Schema, 全部想清楚才能編寫 SQL 程式. SQL 不符合人類循序漸進的思 維方式, 初次使用 Hive 的使用者經常回報不知如何下手取資料.

(4) Hive由于SQL表意的局限性, 有一些分析程式不得不使用原生MapReduce編寫. 但原生的MapReduce 無法友善地共享 Hive 的資料, 因為 MapReduce 無法擷取Hive 的中繼資料資訊.

(5) 資料分析是一道複雜的過程, 查詢資料庫往往是其中的一個步驟，是以衆多資料庫 系統都可以将其 SQL 嵌入到其它程式設計語言中, 作為資料化産品的一個組成部分.淘 寶有一些使用者曾嘗試在 Python/Java 語言中嵌入 Hive SQL, 但都以失敗告終.

(6) Hive 是 Facebook 公司主導的開源項目, 代碼品質存在一定的問題. 研發人員普 遍反映 Hive 代碼結構紊亂, 添加一個新功能經常需要涉及 Hive 所有的核心類. 并且由于 Facebook 的生産環境和淘寶的環境有較大的差異, 是以采納社群的 patch 經常需要數個月的穩定期. 在這段穩定期, 給使用者體驗帶來了負面影響.

(7) Hive 沒有關注錯誤提示資訊的友好性. 對于一些簡單的錯誤, 使用者都沒有辦法自 我判斷, 需要報告給研發人員.

因為以上幾個原因, Hive 在淘寶的發展受到制約. 從使用者看, Hive 無法順利地挖掘 潛在的使用者群, 而這些使用者确實需要資料; 從開發上看, Hive 進展緩慢, 開發人員疲于 解答和解決各類 Hive 錯誤

作為一個程式員，迅速搭建環境，和快速本地測試的技能是比不可少的。

Kudu項目的初衷是在hive的批量處理和hbase的随機讀寫之間找一個平衡點。

kudu的批量處理性能優于hbase，随機讀寫優于hive。

hive的一般用于建構資料倉庫，kudu一般用于做近實時的查詢分析。

hive一般要配合impala或者presto或者kylin等做互動式查詢

kudu一般配合impala做互動式查詢，也可以配合其他的做資料查詢。

hbase一般可以配合apache Phoenix提供查詢功能。

使用hive、kudu、hbase還要看需求：

如果是建立資料倉庫，做T+1天的BI系統，還是要選擇Hive。

如果希望資料是分鐘級别的延時，希望盡量快的看到結果，而且是結構資料，選kudu是沒錯的。

如果需求是大量快速的寫，經常單條的讀，那必須是hbase，kudu和hive都不行。

它們三個各有所長，沒有誰能取代誰，一般在企業中也都是互相配合使用來應對多種需求場景