某公司在大数据元数据服务横向扩展道路上的探索历程，由实际面临的问题出发，对当前主流的横向扩展方案进行了调研及对比测试。

1.问题背景

Hive Metastore存储着数据仓库中所依赖的所有元数据，计算引擎（Hive、Spark、Presto/Trino）在查询时需要访问Metastore才能能在海量数据中准确访问到需要访问的具体数据。

公司的Hive Metastore使用的是MySQL存储引擎，但随着业务发展，数据爆炸式增长，存储的元数据也相应的增长到亿级别，包括：

（1）PARTITION_PARAMS：8亿

（2）PARTITION_KEY_VALS：3.5亿

（3）PARTITIONS：1.5亿

在如此大量的数据基数下，团队经常面临机器资源的性能瓶颈，往往用户多并发的去查询某些大分区表（50w+分区），机器资源的使用率就会被打满，从而导致元数据查询超时，严重时甚至整个Metastore集群不可用，此时恢复手段只能暂时停服所有Metastore节点，直到MySQL机器负载降下来后在逐步恢复服务。

为此，针对当前MySQL方案存在的严重性能瓶颈，Hive Metastore急需一套完善的横向扩展方案来解决当前燃眉之急。

2.方案选型

基于当前业界的生产实践，Hive Metastore的横向扩展思路上主要分为两种：

（1）对MySQL进行拆库扩展

（2）用高性能的分布式引擎替代MySQL。

在第一种思路上做的比较成熟的方案有Hotels.com公司开源的Waggle Dance，实现了一个跨集群的Hive Metastore代理网关，他允许用户同时访问多个集群的数据，这些集群可以部署在不同的平台上，特别是云平台。

第二种思路当前主流的做法是用分布式存储引擎TiDB替换传统的MySQL引擎，在Hive社区中有不少公司对hive 2.x接入TiDB做了大量的测试并应用到生产中。

2.1.Waggle Dance代理层

Waggle-dance向用户提供统一的入口，将来自Metastore客户端的请求路由到底层对应的Metastore服务，同时向用户隐藏了底层的Metastore分布，从而在逻辑层面整合了多个Metastore的Hive库表信息。

Waggle-dance实现了Metastore的Thrift API，客户端无需改动，对用户来说，Waggle-dance就是一个Metastore。

其整体架构如下：

从Waggle-dance的架构中最突出的特性是其采用了多个不同的MySQL实例分担了原单MySQL实例的压力，除此之外其还有如下优势：

（1）用户侧可以沿用Metastore客户端的用法，配置多台Waggle-dance的连接，在当前Waggle-dance连接服务不可用的时候切换到其他的Waggle-dance服务上。

（2）Waggle-dance只需几秒即可启动，加上其无状态服务的特性，使得Waggle-dance具备高效的动态伸缩性，可以在业务高峰期快速上线新的服务节点分散压力，在低峰期下线部分服务节点释放资源。

（3）Waggle-dance作为一个网关服务，除了路由功能外，还支持后续的定制化开发和差异化部署，平台可根据需要添加诸如鉴权、防火墙过滤等功能。

2.2.TiDB替换MySQL

TiDB 是 PingCAP 公司自主设计、研发的开源分布式关系型数据库，是一款同时支持在线事务处理与在线分析处理 (Hybrid Transactional and Analytical Processing, HTAP) 的融合型分布式数据库产品，具备水平扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 5.7 协议和 MySQL 生态等重要特性。

结合HMS及大数据生态，采用TiDB作为元数据存储整体的部署架构如下：

由于TiDB本身具有水平扩展能力，扩展后能均衡查询压力，该特性就是我们解决Hive Metastore查询性能瓶颈的大杀器。除此外该架构还有如下优势：

（1）用户无需任何改动；HMS侧面没有任何改动，只是其依赖的底层存储发生变化。

（2）不破坏数据的完整性，无需将数据拆分多个实例来分担压力，对HMS来说其就是一个完整、独立的数据库。

（3）除引入TiDB作为存储引擎外，不需要额外的其他服务支撑整个架构的运行。

2.3.方案对比

前面内容对Waggle-dance方案和TiDB方案做了简单的介绍及优势总结，以下列举了这两个方案在多个维度的对比：

3.方案选择

通过上述多个维度的对比，TiDB方案在性能表现、水平扩展、运维复杂度及机器成本上都优于waggle-dance方案，故线上选择了TiDB进行上线应用。