MySQL到TiDB：Hive Metastore横向扩展之路

为解决HMS的性能问题，我们团队对HMS横向扩展方案做了大量的调研工作，总体下来业内在HMS的横向扩展思路上主要分为对MySQL进行拆库扩展或用高性能的分布式引擎替代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架构

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

2.2 TiDB

TiDB 是 PingCAP 公司自主设计、研发的开源分布式关系型数据库，是一款同时支持在线事务处理与在线分析处理 (Hybrid Transactional and Analytical Processing, HTAP) 的融合型分布式数据库产品，具备水平扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 5.7 协议和 MySQL 生态等重要特性。在TiDB 4.x版本中，其性能及稳定性较与之前版本得到了很大的提升并满足HMS的元数据查询性能需求。故我们对TiDB也做了相应的调研及测试。结合HMS及大数据生态，采用TiDB作为元数据存储整体的部署架构如下：

HMS on TiDB架构   

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

2.3 TiDB和Waggle Dance对比

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

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

选择TiDB引擎替代原MySQL存储引擎，由于TiDB与MySQL之间不能做双主架构，在切换过程中HMS服务须完全停服后并重新启动切换至TiDB，为保障切换过程顺利及后面若有重大问题发生能及时回滚，在切换前做了如下数据同步架构以保障切换前MySQL与TiDB数据一致以及切换后仍有MySQL兜底。

TiDB&MySQL上线前后数据同步架构

在上述架构中，切换前唯一可写入的数据源只有源数据库主库，其他所有TiDB、MySQL节点都为只读状态，当且仅当所有HMS节点停服后，MySQL源数据库从库及TiDB源数据库主库的数据同步最大时间戳与源数据库主库一致时，TiDB源数据库主库才开放可写入权限，并在修改HMS底层存储连接串后逐一拉起HMS服务。

在上述架构完成后，即可开始具体的切换流程，切换整体流程如下：

HMS切换底层存储流程

其中在保障源MySQL与TiDB数据正常同步前，需要对TiDB做以下配置：

此外在开启sentry服务状态下，需确认sentry元数据中NOTIFICATION_ID的值是否落后于HMS元数据库中NOTIFICATION_SEQUENCE表中的NEXT_EVENT_ID值，若落后需将后者替换为前者的值，否则可能会发生建表或创建分区超时异常。

以下为TiDB方案在在不同维度上的表现：

以下为上线后HMS主要API接口调用耗时情况统计：

（左右滑动，查看更多···）

4.1 在模拟TiDB回滚至MySQL过程中出现主键冲突问题

在TiDB数据增长3倍后，切换回MySQL出现主键重复异常，具体日志内容如下：

主键冲突异常日志

产生该问题的主要原因为每个 TiDB 节点在分配主键ID时，都申请一段 ID 作为缓存，用完之后再去取下一段，而不是每次分配都向存储节点申请。这意味着，TiDB的AUTO_INCREMENT自增值在单节点上能保证单调递增，但在多个节点下则可能会存在剧烈跳跃。因此，在多节点下，TiDB的AUTO_INCREMENT自增值从全局来看，并非绝对单调递增的，也即并非绝对有序的，从而导致Metastore库里的SEQUENCE_TABLE表记录的值不是对应表的最大值。

造成主键冲突的主要原因是SEQUENCE_TABLE表记录的值不为元数据中实际的最大值，若存在该情况在切换回MySQL后就有可能生成已存在的主键导致初见冲突异常，此时只需将SEQUENCE_TABLE里的记录值设置当前实际表中的最大值即可。

4.2 PARTITION_KEY_VALS的索引取舍

在使用MySQL引擎中，我们收集了部分慢查询日志，该类查询主要是查询分区表的分区，类似如下SQL：

#以下查询为查询三级分区表模板，且每级分区都有过来条件
SELECT PARTITIONS.PART_IDFROM PARTITIONS  INNER JOIN TBLS  ON PARTITIONS.TBL_ID = TBLS.TBL_ID    AND TBLS.TBL_NAME = '${TABLE_NAME}'  INNER JOIN DBS  ON TBLS.DB_ID = DBS.DB_ID    AND DBS.NAME = '${DB_NAME}'  INNER JOIN PARTITION_KEY_VALS FILTER0  ON FILTER0.PART_ID = PARTITIONS.PART_ID    AND FILTER0.INTEGER_IDX = ${INDEX1}  INNER JOIN PARTITION_KEY_VALS FILTER1  ON FILTER1.PART_ID = PARTITIONS.PART_ID    AND FILTER1.INTEGER_IDX = ${INDEX2}  INNER JOIN PARTITION_KEY_VALS FILTER2  ON FILTER2.PART_ID = PARTITIONS.PART_ID    AND FILTER2.INTEGER_IDX = ${INDEX3}WHERE FILTER0.PART_KEY_VAL = '${PART_KEY}'  AND CASE     WHEN FILTER1.PART_KEY_VAL <> '__HIVE_DEFAULT_PARTITION__' THEN CAST(FILTER1.PART_KEY_VAL AS decimal(21, 0))    ELSE NULL  END = 10  AND FILTER2.PART_KEY_VAL = '068';

SELECT "PARTITIONS"."PART_ID"FROM "PARTITIONS"  INNER JOIN "TBLS"  ON "PARTITIONS"."TBL_ID" = "TBLS"."TBL_ID"    AND "TBLS"."TBL_NAME" = 'tb1'  INNER JOIN "DBS"  ON "TBLS"."DB_ID" = "DBS"."DB_ID"    AND "DBS"."NAME" = 'db1'  INNER JOIN "PARTITION_KEY_VALS" "FILTER0"  ON "FILTER0"."PART_ID" = "PARTITIONS"."PART_ID"    AND "FILTER0"."INTEGER_IDX" = 0  INNER JOIN "PARTITION_KEY_VALS" "FILTER1"  ON "FILTER1"."PART_ID" = "PARTITIONS"."PART_ID"    AND "FILTER1"."INTEGER_IDX" = 1WHERE "FILTER0"."PART_KEY_VAL" = '2021-12-28'  AND CASE     WHEN "FILTER1"."PART_KEY_VAL" <> '__HIVE_DEFAULT_PARTITION__' THEN CAST("FILTER1"."PART_KEY_VAL" AS decimal(21, 0))    ELSE NULL  END = 10;

由于对PARTITION_KEY_VALS的PARTITION_KEY_VAL字段添加了索引做查询优化，会导致该类查询生成的执行计划中同样会使用idx_PART_KEY_VAL索引进行数据扫描，该执行计划如下：

走idx_PART_KEY_VAL索引执行计划

添加的idx_PART_KEY_VAL索引在该字段的具有相同值的数据较少时，使用该索引能检索较少的数据提升查询效率。在hive中的表一级分区基本是按天进行分区的，据统计每天天分区的增量为26w左右，如果使用idx_PART_KEY_VAL索引，按这个数值计算，查询条件为day>=2021-12-21 and day<2021-12-26的查询需要检索将近160w条数据，这显然不是一个很好的执行计划。

若执行计划不走idx_PART_KEY_VAL索引，TiDB可通过dbs、tbls检索出所有关联partition数据，在根据part_id和过滤条件扫描PARTITION_KEY_VALS数据并返回。此类执行计划扫描的数据量和需要查询的表的分区总量有关，如果该表只有少数的分区，则查询能够迅速响应，但如果查询的表有上百万的分区，则该类执行计划对于该类查询不是最优解。

不走idx_PART_KEY_VAL索引执行计划

在实际生产中元数据基本都是按天分区为主，每天增长大概有26w左右，且范围查询的使用场景较多，使用idx_PART_KEY_VAL索引查询的执行计划不太适合线上场景，故该索引需不适合添加到线上环境。

4.3 TiDB内存突增导致宕机问题

在刚上线TiDB服务初期，曾数次面临TiDB内存溢出的问题，每次出现的时间都随机不确定，出现的时候内存突增几乎在一瞬间，若期间TiDB的内存抗住了突增量，突增部分内存释放在很长时间都不会得到释放，最终对HMS服务稳定性带来抖动。

TiDB内存突增情况

通过和TiDB开发、DBA联合分析下，确认TiDB内存飙高的原因为用户在使用Dashboard功能分析慢查询引起；在分析慢查询过程中，TiDB需要加载本地所有的slow-query日志到内存，如果这些日志过大，则会造成TiDB内存突增，此外，如果在分析期间，用户点击了取消按钮，则有可能会造成TiDB的内存泄漏。针对该问题制定如下解决方案：

4.4 locate函数查询不走索引导致TiKV负异常

在HMS中存在部分通过JDO的方式去获取分区的查询，该类查询的过滤条件中用locate函数过滤PART_NAME数据，在TiDB中通过函数作用在字段中是不会触发索引查询的，所以在该类查询会加载对应表的所有数据到TiDB端计算过滤，TiKV则需不断扫描全表并传输数据到TiDB段，从而导致TiKV负载异常。

locate函数导致全表扫描

然而上述的查询条件可以通过like方式去实现，通过使用like语法，查询可以成功使用到PARTITIONS表的UNIQUEPARTITION索引过滤，进而在TiKV端进行索引过滤降低负载。

like语法走索引过滤

通过实现将locate函数查询转换为like语法查询，有效降低了TiKV端的负载情况。在HMS端完成变更后，TiKV的CPU使用率降低了将近一倍，由于在KV端进行索引过滤，相应的io使用率有所上升，但网络传输则有明显的下降，由平均1G降低到200M左右。

变更前后TiKV的负载情况

除TiKV负载有明显的降低，TiDB的整体性能也得到明显的提升，各项操作耗时呈量级降低。以下整理了TiDB增删改查的天平均耗时情况：

TiDB P999天平均耗时统计

4.5 get_all_functions优化

随着hive udf的不断增长，HMS的get_all_functions api平均耗时增长的也越来越久，平均在40-90s，而该api在hive shell中首次执行查询操作时会被调用注册所有的udf，过长的耗时会影响用户对hive引擎的使用体验，例如执行简单的show database需要等待一分钟甚至更久才能返回结果。

原get_all_functions api平均耗时

导致该api耗时严重的主要原因是HMS通过JDO方式获取所有的Function，在获取所有的udf时后台会遍历每条func去关联DBS、FUNC_RU两个表，获取性能极低。而使用directSQL的方式去获取所有udf数据，响应耗时都在1秒以内完成，性能提升相当明显。以下为directSQL的SQL实现逻辑：

select FUNCS.FUNC_NAME,  DBS.NAME,  FUNCS.CLASS_NAME,  FUNCS.OWNER_NAME,  FUNCS.OWNER_TYPE,  FUNCS.CREATE_TIME,  FUNCS.FUNC_TYPE,  FUNC_RU.RESOURCE_URI,  FUNC_RU.RESOURCE_TYPEfrom FUNCSleft join FUNC_RU on FUNCS.FUNC_ID = FUNC_RU.FUNC_IDleft join DBS on FUNCS.DB_ID = DBS.DB_ID