分享

滴滴平台大数据架构离线引擎:Hive元数据上亿级别存储方案的实践



问题导读

1.什么是元数据 Federation 方案?
2.怎样引入 Federation 方案?
3.怎样改造现有服务?


▍背景
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 架构体系:

16a8c856eef448c2.jpg

该架构体系中用户使用的 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 架构体系:

16a8c8728c44dcc7.jpg

  • 2.2 waggle_dance 介绍

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

2.2.1 架构流程图
16a8c8862749ca2d.jpg

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

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

2.2.2 内部组件解析

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

16a8c8a21899362c.jpg

  • WaggleDance容器

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

  • YamlFederatedMetaStoreStorage 模块

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

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

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

16a8ce88dab32b40.jpg

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

16a8cf06a056486b.jpg

  • 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 环境带来的性能及服务稳定问题。



最新经典文章,欢迎关注公众号



---------------------

作者:滴滴技术
来源:掘金
原文:https://juejin.im/post/5ccffdfd51882541cd485f2c





已有(3)人评论

跳转到指定楼层
为梦狂野 发表于 2020-7-21 09:15:27
太棒了,这个技术很牛逼。部署起来难度不小
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

推荐上一条 /2 下一条