Hadoop 生態(tài)里，為什么 Hive 活下來了？

大家好，我是夢想家Alex ~ 我們都知道 Hadoop 生態(tài)圈非常龐大，但為什么Hive能活下來呢，今天這篇文章將為你解密！


作者 | Einat Orr 博士
譯者 | Sambodhi
策劃 | Tina

Apache Hive 能在下一輪“淘汰”中幸存下來嗎？

Apache Hive 在 2010 年作為 Hadoop 生態(tài)系統(tǒng)的一部分嶄露頭角，當時 Hadoop 是一種新穎而創(chuàng)新的大數(shù)據(jù)分析方法。Hive 的功能就是實現(xiàn) Hadoop 的 SQL 接口。它的架構包括兩個主要服務：一是查詢引擎：負責執(zhí)行 SQL 語句；二是元存儲：負責在 HDFS 中將數(shù)據(jù)收集虛擬化為表。


HDFS 上的 Hive 的主要組成部分，包括用戶界面、驅(qū)動程序和元存儲。
Hadoop 背后的概念是革命的。分布式文件系統(tǒng)（HDFS）中存儲大量的數(shù)據(jù)集，運行于商業(yè)硬件集群之上。并行執(zhí)行計算作業(yè)時使用 MapReduce 的數(shù)據(jù)。這類任務的分配由 Yarn 管理。主接口是一種編程語言，最初是 Java 或 Scala。

這些組件在 Apache 基金會下開源，可以免費使用。這套技術已經(jīng)成為幾年來大規(guī)模分析的標準。

但是，這個技術棧已經(jīng)逐漸被一些新技術淘汰……

HDFS 被對象存儲所取代，由 AWS S3 主導。MapReduce 已經(jīng)被 Spark 所取代，Spark 也逐漸減少了對 Hadoop 的依賴性。Yarn 正在被像 Kubernetes 這樣的技術取代。此外，Hive 的查詢引擎組件在性能和采用方面已經(jīng)被 Presto/Trino 超越。

雖然有這些改變，但大多數(shù)以數(shù)據(jù)湖為特色的組織仍然將活躍的 Hive Metastore 部署作為其架構的一部分。與 Hadoop 的同類產(chǎn)品相比，你可能會想，“Hive Metastore 有什么特別之處？

”要回答這個問題，讓我們深入了解一下 Hive Metastore 目前提供了什么功能，以及正在出現(xiàn)什么技術來取代它。

Hive Metastore 做了什么？
在將新數(shù)據(jù)存入對象存儲中時，我們會在 Hive Metastore 中注冊一個元存儲 API，該 API 來自于任何數(shù)據(jù)應用或編排工具。此生命性階段將一組對象從對象存儲重映射到 Hive 公開的表。部分注冊包含指定文件中保存的表的模式，以及描述這些列的元數(shù)據(jù)。以這種方式使用 Hive Metastore 有四個主要好處：虛擬化、可發(fā)現(xiàn)性、模式演化、性能。讓我們來詳細討論一下。

1. 虛擬化
數(shù)據(jù)分析師使用 SQL 通常不關心對象存儲的細節(jié)和其訪問模式。他們只是想要得到他們的表。

當其他 Hadoop 組件被取代時，Hive Metastore 將扮演不可替代的角色。每種新技術的引入都確保了對 Hive Metastore 的支持，從而避免了依賴于 Hive 中定義的表對象的關鍵分析工作流。

2. 可發(fā)現(xiàn)性
當公開新數(shù)據(jù)并更新數(shù)據(jù)時，Hive Metastore 會變成包含在對象存儲中的所有集合的目錄。如果維護得當，就可以發(fā)現(xiàn)可供查詢的數(shù)據(jù)集。

另外，補充性信息可以保存在元存儲中，以便提供關于數(shù)據(jù)的有用信息，比如其更新頻率，誰擁有它，等等。

3. 模式演化
管理數(shù)據(jù)集所面臨的挑戰(zhàn)之一就是其可變性。在描述其屬性的現(xiàn)有列時，記錄可以隨時間而改變。也有可能是屬性集本身會隨時間改變，從而導致表的模式發(fā)生改變。

上述的注冊過程為每一個屬于表的附加數(shù)據(jù)文件提供了模式的記錄。這就是說，如果模式在某一時刻發(fā)生了變化，那么它將被記錄到 Hive Metastore 中。在訪問數(shù)據(jù)時，可以使用合適的模式進行訪問。

這也為驗證一個模式提供了一個很好的基礎，如果它不應該被改變，并對它發(fā)出警報。Hive 保存著創(chuàng)建此類測試的信息。

4. 性能
因為 Hive Metastore 將表映射到了底層對象上，所以它可以基于對象存儲支持的主鍵來表示分區(qū)。當分區(qū)均衡且數(shù)量合理時，分區(qū)的粒度可以由用戶設置，這種映射可以提高查詢性能。

這通常被稱為“分區(qū)修剪”（partition pruning），它允許查詢引擎識別哪些數(shù)據(jù)文件可以被跳過。

Hive 會在下一次革命中幸存嗎？
目前還沒有直接取代元存儲的候選者，但如果現(xiàn)有的一些趨勢占據(jù)上風并發(fā)揮好作用，那么它可能會被淘汰。

讓我們來看看領先的繼任者們。

開放表格式
Iceberg、Hudi 和 Delta Lake 是這個類別中的三個參與者。每一個都是為了滿足不同的需求而創(chuàng)建的，但是隨著時間的推移，它們?nèi)繀R聚在一起，涵蓋了一系列的特性。這些特性允許：

可變性（Hudi、Delta）

訪問大表的效率（Iceberg）

模式實施和演化（Delta）

由于 Hive Metastore 是一個所有應用程序都支持的通用接口，因此使用開放表格式的組織仍然依賴 Hive 來進行虛擬化，以及 / 或用于格式未涵蓋的其他用例。

數(shù)據(jù)目錄
在過去的一年多時間里，我們目睹了由數(shù)據(jù)工程領域的領導者發(fā)布的 10 多個開源發(fā)現(xiàn)工具的閃電戰(zhàn)，這表明了對組織級數(shù)據(jù)目錄的需求。這些新來者加入了其他現(xiàn)有的商業(yè)數(shù)據(jù)目錄產(chǎn)品，如 Allation。

目錄支持對象存儲與目前使用的大多數(shù)數(shù)據(jù)庫的映射。如有可能，許多發(fā)現(xiàn)工具將利用已經(jīng)在 Hive Metastore 中的數(shù)據(jù)，否則就會進入對象存儲。毫不奇怪，隨著時間的推移，這些工具很有可能取代 Hive Metastore 的編目功能。

可觀察性工具
可觀察性工具的主要目的是在運行中監(jiān)控數(shù)據(jù)管道的質(zhì)量和數(shù)據(jù)本身。一些工具專注于前者（如 Databand），而另一些工具側(cè)重于后者（Great Expectations 或 Monte Carlo）。如果可觀察性工具在整個數(shù)據(jù)生命周期內(nèi)實施，它可以動態(tài)地更新數(shù)據(jù)目錄，并將 Hive Metastore 替換為目錄。

結語
許多技術已經(jīng)開始在改進 Hive 的功能方面有所突破。但是現(xiàn)在還沒有任何一種技術足夠成熟，也沒有就成功去除 Hive Metastore 的組合達成共識。這并不意味著它應該或?qū)⒗^續(xù)成為數(shù)據(jù)架構的一部分。實際上，它在可用性和性能方面都存在著明顯的不足。值得關注的是 Hive Metastore：

難以安裝和維護。

非云原生架構，使得管理服務的實施變得復雜。

因依賴關系型數(shù)據(jù)庫而受到可擴展性限制。

綜合這些因素，我們可以預測 Hive Metastore 不會在下一個數(shù)據(jù)架構的演進中幸存下來。這種情況不會自動發(fā)生——它需要來自社區(qū)內(nèi)部的力量。愿你與我們攜手共創(chuàng)美好未來！

作者：Einat Orr 博士


歡迎關注：大數(shù)據(jù)夢想家