在大数据领域，数据管理与存储至关重要，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