胡海洋：Hive Metastore Federation 在滴滴的实践

出品 | 滴滴技术
做者 | 胡海洋

前言：本文来自滴滴基础平台大数据架构离线引擎组，针对内部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/conf...
https://github.com/HotelsDotC...

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 架构流程图：

▍3.2 部署状况

为了将线上 MySQL 中的 Hive 元数据逐步分布到多套 MySQL 环境存储，须要部署一套新的 MySQL 环境（对应新的 Hive Metastore环境）。

通过内部压力测试，咱们得出结论，一个 waggle_dance 实例能够对接于一套 Hive Metastore 环境。考虑 Hive Metastore 环境横向扩展及保证服务的稳定性，部署了一套 waggle_dance 集群由 LVS+4 个 waggle_dance 实例组成。

后续会将已有 MySQL 中存储的 Hive 库，表元数据信息逐步迁移到新的 MySQL 环境，为了迁移过程当中减小对用户使用的影响，将来还须要开发 waggle-dance 按表路由等功能。

▍总结

当前方案上线已经稳定运行几个月，新的体系架构会支持横向扩展多套 MySQL 环境，从根本上解决因为一套 MySQL 环境带来的性能及服务稳定问题。

▍END
原文来源 / 滴滴云（didi-cloud）
转载请至 / 转载合做入口