胡海洋：Hive Metastore Federation 在滴滴的实践_文化 & 方法_滴滴开源

AIGC在金融场景是如何落地的？了解详情 



 写点什么

本文来自滴滴基础平台大数据架构离线引擎组，针对内部 hive 元数据上亿级别存储方案的实践；该架构体系从根本上提高了 hive 元数据服务的稳定性及扩展性问题。

背景

Apache Hive 是基于 Apache Hadoop 之上构建的数据仓库，提供了简单易用的类 SQL 查询语言，适合对大规模数据进行存储、查询操作，被广泛使用。

Hive 元数据 Metadata 包含用 Hive 创建的 Database、Table、Partition 等的元信息。此类元信息一般存储在关系型数据库中，如 Derby、MySQL 等。

在滴滴，我们是将元数据存储在 MySQL 里，随着业务的不断增长，Hive 元数据越来越庞大，出现单表存储超过上亿条记录的情况，这种情况下会导致 MySQL 查询压力过大，而且在高峰期间，经常导致机器 CPU 使用率达到 100%，影响服务稳定性。

为此，我们开始调研元数据 Federation 方案，实现元数据水平扩展能力，为 MySQL 解压，提升 Hive 稳定性。

Federation 方案介绍

2.1 Hive 架构体系演变

引入 Federation 之前的 Hive 架构体系：

该架构体系中用户使用的 Hive 客户端或者 Hivesever2 服务、Spark 引擎、Presto 引擎等都是访问统一 Hive Metastore 服务获取 Hive 元数据。

Hive Metastore 服务主要是使用 LVS + 多个 Hive Metastore 实例组成。所有的 Hive Metastore 实例共享一套主从 MySQL 环境作为 Hive 元数据存储 DB。

前期工作

为了缓解 Hive 元数据存储 DB（MySQL）查询压力，我们做了很多元数据治理工作，包括长时间无用的库、表、分区清理等。元数据访问限制包括查询分区表分区限制等功能，但这些并没有从根本上解决 MySQL 压力问题。

方案调研

MySQL 机器查询压力大的问题主要由于 Hive 元数据结构中只存在一个库，库中存在单表超过上亿条记录的情况。那为什么不考虑 MySQL 分库，分表等方案？如果采用 MySQL 分库，分表等方案，需要大量更改 Hive Metastore 接口，这样风险及成本较高，而且后期涉及 Hive 版本升级也会带来更多工作量。
基于 Hive Metastore 层实现 Federation（waggle_dance），实现思路主要是以 Hive DB 切分，在 Hive DB 层面将元数据分布多套 MySQL 环境存储，这样对 Hive Metastore 本身不需要做任何修改，这种方案也较好维护。

基于 Hive Metastore Federation 实现后的 Hive 架构体系：

2.2 waggle_dance 介绍

Reference：

https:// cwiki.apache. org/confluence/pages/viewpage.action?pageId=80452092
https:// github. com/HotelsDotCom/waggle-dance

waggle-dance 是由 Hotels.com 公司开源的一个项目，该项目主要是联合多个 Hive Metastore 数据查询的服务，实现了一个统一的路由接口解决多套 Hive Metastore 环境间的元数据共享问题。

2.2.1 架构流程图

从架构图来看， waggle_dance 服务其实是承担 Router 路由的角色，后端配置多个 Hive Metastore 环境，接收客户端的元数据请求，通过 DB 与 Hive Metastore 路由关系将请求具体转发到相应的 Hive Metastore 环境执行操作。

这些操作对于客户端来说完全透明，对于客户端只是访问一套 Hive Metastore 的环境。

2.2.2 内部组件解析

waggle_dance 基于 Spring-boot 框架实现，主要包括如下几个模块：

WaggleDance 容器

服务启动类，主要初始化容器 Spring boot，加载 Listener，每个关键的类通过注解方式加载，初始化。

YamlFederatedMetaStoreStorage 模块

维护需要依赖 Hive Metastore 环境的配置信息及 Hive Database 名字到 Hive Metastore 服务之间的路由信息。

当前支持配置一个主 Hive Metastore 及多个从 Hive Metastore 策略。

主 Hive Metastore 与从 Hive Metastore 配置主要区分的属性 access-control-type。

主 Hive Metastore 定义属性 access-control-type：对当前环境的 Hive 元数据操作支持以上 4 种策略。
从 Hive Metastore 定义属性 access-control-type：对当前环境的 Hive 元数据操作只支持 READ_ONLY 只读策略。

文件配置管理模块

WaggleDanceConfiguration: ThriftServer 服务属性配置
GraphiteConfiguration： Graphite 监控属性配置

ThriftServer 模块

实现 ThriftServer 服务，基于 Hive ThriftHiveMetastore API 对外提供 RPC 服务。接口包括 create_database、drop_database、create_table 以及汇总信息查询如 get_all_databases、set_ugi 等操作。

这样可以做到完全兼容 Hive 客户端，Hivesever2 等服务请求协议，最终通过路由解析至对应的 Hive Metastore 建立连接并调用同名方法执行操作。

几个需要注意的地方：

接口的操作是区分只读和读写等策略，会根据路配置文件中定义的 Hive Metastore 的 access-control-type 属性决定。
对于那些无法通过库名来路由的接口，都是转发至主 Hive Metastore 环境执行操作。

Monitor 模块

MonitoringConfiguration、MonitoredAspect：服务监控逻辑，主要采用 Java 监控类库 Metrics 实现（项目官网 http://metrics.dropwizard.io/ ），该库支持将相关监控信息通过 Ganglia 和 Graphite 等工具进行展示，主要对 JVM 内存，线程执行状态，Hive 元数据相关操作等监控。

FederationsAdmin 管理模块

FederationsAdminController：restful 接口实现，供管理员使用，可动态完成对 Federation Metastore 注册、注销及 Hive Database 名字与 Metastore 路由信息修改。

滴滴实践

3.1 服务改造

当前 waggle_dance 功能不能完全满足我们的使用要求，需要进行扩展。改进点如下：

目标是需要支持对多套 Hive Metastore 环境进行读写元数据操作，所以扩展 waggle-dance-federation.yml 文件模板支持配置多个主 Hive Metastore。
MappingEventListener 增加 MULTI_PRIMARY 策略。根据多个主 Hive Metastore 模式实现对应的 Hive Database 名字->Metastore mapping 路由信息类。
修改 FederatedHMSHandler 等类相关处理逻辑（兼容 Hive 1.2.1 与 2.x 版本 Hive ThriftHiveMetastore API）。这样做的好处是在客户端保持 Hive 1.2.1 版本的情况下可以完全兼容后端多个 Hive 版本 Metastore 服务，方便后期对 Metastore 服务版本升级。
修改监控模块，由于公司内部是使用 Ganglia 工具进行监控，将 Graphite 改造为 Ganglia 并优化监控指标。
相关性能优化，为了避免每个客户端连接过程中都需要建立一个 Database->Metastore mapping 路由信息耗费的内存操作，每个 waggle_dance 实例启动的时候缓存一个 Hive Database->Metastore mapping 路由信息，该信息会被每个客户端连接请求的线程共用。
对于 Database->Metastore mapping 路由信息的维护，每个 waggle_dance 实例会定期请求后端多套 Hive Metastore 服务进行数据更新。

改造后 waggle_dance 架构流程图：