把這個拿出來的目的, 是想得到更多的反饋意見, 請郵件至[email protected]

[size=large]歷史[/size]
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 作為他們的資料分析工具, 提取他們
所需要的資料.

[size=large]問題[/size]
隨著 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 錯誤

詳情見附件pdf