固定链接 Hive Metastore Federation 在滴滴的实践

Hive Metastore Federation 在滴滴的实践

Hive Metastore Federation 在滴滴的实践

2019年3月25日 胡海洋

一、背景

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

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

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

为此，我们开始调研元数据 Federation 方案，实现元数据水平扩展能力，为 MySQL 解压，提升 Hive 稳定性。on 方案，实现元数据水平扩展能力，为 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 压力问题。

方案调研

  1. MySQL 机器查询压力大的问题主要由于 Hive 元数据结构中只存在一个库，而库中存在单表超过上亿条记录的情况。那为什么不考虑 MySQL 分库，分表等方案？

    如果采用 MySQL 分库，分表等方案，需要大量更改 Hive Metastore 接口，这样风险及成本较高，而且后期涉及 Hive 版本升级也会带来更多工作量。

  2. 基于 Hive Mestatore 层实现 Federation（waggle_dance）
    该方案实现思路主要是以 Hive DB 切分，在 Hive DB 层面将元数据分布多套 MySQL 环境存储，这样对 Hive Metastore 本身不需要做任何修改，这种方案也较好维护。

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

2.2 waggle_dance 介绍

Reference：

  1. https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=80452092
  2. 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。

Property Description
READ_ONLY 只读操作,不允许 creation of databases and and update/alters or other data manipulation 等操作
READ_AND_WRITE_ON_DATABASE_WHITELIST 允许读取库,但不允许创建新数据库操作，需要在主元存储配置数据库白名单
READ_AND_WRITE_AND_CREATE_ON_DATABASE_WHITELIST 允许读取库,创建新数据库操作，需要在主元存储配置数据库白名单
READ_AND_WRITE_AND_CREATE 允许读取库, 创建新数据库操作
  • 主 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 实现（项目官网），该库支持将相关监控信息通过 Ganglia 和 Graphite 等工具进行展示；主要对 JVM 内存，线程执行状态，Hive 元数据相关操作等监控。

FederationsAdmin 管理模块

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

三、滴滴实践

3.1 服务改造

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

  1. 我们目标是需要支持对多套 Hive Metastore 环境进行读写元数据操作，所以扩展 waggle-dance-federation.yml 文件模板支持配置多个主 Hive Metastore。
  2. MappingEventListener 增加 MULTI_PRIMARY 策略。根据多个主 Hive Metastore 模式实现对应的 Hive Database 名字->Metastore mapping 路由信息类。
  3. 修改 FederatedHMSHandler 等类相关处理逻辑（兼容 Hive 1.2.1 与 2.x 版本 Hive ThriftHiveMetastore API）。这样做的好处是在客户端保持 Hive 1.2.1 版本的情况下可以完全兼容后端多个 Hive 版本 Metastore 服务，方便后期对 Metastore 服务版本升级。
  4. 修改监控模块，由于公司内部是使用 Ganglia 工具进行监控，将 Graphite 监控改造为 Ganglia 监控并优化监控指标。
  5. 性能相关优化，为了避免每个客户端连接过程中都需要建立一个 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 环境带来的性能及服务稳定问题。

本文作者：胡海洋

您的留言将激励我们越做越好