在大數據領域，數據管理與存儲至關重要，Hive MetaStore（HMS）作為 Hive 數據倉庫的核心組件，承擔著元數據管理的關鍵職責。隨著數據規模不斷膨脹，其性能與穩定性面臨挑戰。本文將深入剖析 HMS 的實現機制，結合 Hive Client、MetaCat 等相關內容展開探討，分析各項操作流程，同時針對 HMS 及 MetaCat 提出優化方案，并闡述與 Spark 的關聯等內容，助力讀者全面掌握 HMS 技術要點。

HMS

相關類圖如下：

上圖顏色分類

• 綠色部分是 hive 的

• 橙色部分是 thrift 框架自動生成的代碼

• 白色部分是 JDK 的

右邊是 hive meta-store client，兼容了這個客戶端協議的框架，如 spark，會通過 hive meta-store 協議連接過來?
左邊是服務端的實現，主要繼承自ThriftHiveMetastore.Iface，這個類包含了很多操作，CURD庫、表，函數的等等

HMSHandler實現了這個接口，然后調用RawStre去一個具體數據源來獲取信息，或者創建信息?
RowStore的實現類ObjectStore則調用了javax.jdo去連接一個真實的數據庫，完成此操作

jdo 是?ORM?的實現，比 JDBC 更高層一些，這里會有一些表的連接操作，然后會轉為更底層的 SQL?
hive 使用的 ORM 框架為?DataNucleus
幾個包

• org.apache.thrift.protocol 這個是底層 thrift RPC 相關類，會做序列化操作

• org.apache.hadoop.hive.metastore.api，這是Iface里面庫、表會引用到這些RPC類，這些類的一些數據結構定義又引用了更下沉的thrift類

• org.apache.hadoop.hive.metastore.model，將數據中的數據讀取封裝成對象，再將這個對象轉為thrift RPC中的對象

另外 HMS 也有直接使用SQL 鏈接數據庫
ObjectStore引用了MetaStoreDirectSql，這個類中就包含了很多 sql 語句，不通過 ORM 框架，直接訪問
可能是 hive 層做的一些優化

Hive Client

自定義hiveserver設計
相關類圖

上圖顏色分類

• 藍色部分是 自動生成的代碼

• 深灰色是 client實現

• 淺灰色是 服務端邏輯

• 綠色部分是 service 層邏輯

服務端和客戶端 都實現了 Iface 邏輯，也就是 thrift RPC 協議
服務端有不同的傳輸實現類，binary 和 http
業務邏輯調用綠色部分，再委托給 SessionManager獲取一個session
然后執行具體的 sql 任務

MetaCat-相關操作

架構如如下：

大致分類

• metacat-controller，CURD 元數據的操作

• partition-controller，分區操作，mysql 不支持這樣的操作

• tag-controller，可以給表打標簽

• 其他，如創建 meta-cat試圖等，mysql不支持

查詢 catalog

結果

查詢 數據庫

結果

查詢表

結果

mysql 插件的配置信息：

給 tomcat 增加幾個 -D 參數

• -Dmetacat.usermetadata.config.location=/usermetadata.properties的具體路徑

• -Dmetacat.plugin.config.location=catalog的具體路徑

?HMS 優化

相關類如下：

顏色分類

• 灰色部分，HMS相關，其中深灰色是自動生成的代碼

• 紅色部分，web controller 相關的代碼

• 綠色部分，service 相關邏輯

• 藍色部分，操作 HMS 相關的類

• 黃色部分，外部依賴

Iface 是最核心類，metacat 繼承了這個類，相當于是實現了 HMS 的server端RPC協議
其中一般操作是直接調用了 controller 的類，所以 RPC 和 http 的邏輯實際是統一的
有一些特殊的 controller，如 Tag、metadata、Search，這些會調用外部類
如搜索會直接調用 ES，tag 和 metadata 會調用 MySQL，所以需要一個外部的 ES，MySQL 來支持這些功能

藍色部分是操作 HMS 相關的類，分為表、庫、partition 三個類
這里有兩種情況

• 淺色部分的實現類，直接調用了 Hive metastore client 來實現的

• 深藍色部分，繞過了Hice Client，直接鏈接了底層的數據庫，通過SQL 來交互的

所以 metacat 對HMS 的優化，可以理解為

• 將ORM操作，轉為了直接的 JDBC操作

• 將ORM生成的多表關聯，改為了很多單表查詢，再加載到內存中做管理，減輕了 數據庫端的計算壓力

• 本質上相當于對 SQL 做優化

Spark和HMS

相關類圖如下

灰色的是 spark v1 體系的類
黃色部分是 外部catalog 相關類
v1 中包含了兩個 catalog

• InMemoryCatalog

• HiveExternalCatalog

HiveExternalCatalog 調用了 IMetaStoreClient 實現類
也就是通過 hive MS client 向服務端發起了 RPC 請求實現 catalog 查找的

這里使用了多版本機制

MetaCat 一些優化-對HMS做的優化SQL

這里不通過 HMS，而是通過 JDBC，直接連底層的數據源
DirectSqlDatabase 的主要 SQL 如下：

DirectSqlGetPartition 的主要 SQL 如下：

DirectSqlSavePartition 的主要 SQL 如下：

DirectSqlTable 的主要 SQL 如下：

ThriftHiveMetastore 相關函數

ThriftHiveMetastore.Iface 的所有函數

org.apache.hadoop.hive.metastore.api 包下的所有類

org.apache.hadoop.hive.metastore.api 包下的類

參考

• Metacat: Making Big Data Discoverable and Meaningful at Netflix

• Netflix Metacat: Origin, Architecture, Features & More

• Data Catalog and crawlers in AWS Glue

相關文章

• Hive論文

往期推薦

• Data Ingestion: Architectural Patterns

• Data engineering at Meta

• The Life of a Read/Write Query for Apache Iceberg Tables

• Compaction in Apache Iceberg

• Spark原理-解析過程和Catalog

• Janino簡單使用

• Oracle的CDC工具OpenLogReplicator編譯

• OpenLogReplicator的一些改動

• Spark-Streaming 原理

• Parquet?for?Spark