知乎 Hive Metastore 实践：从 MySQL 到 TiDB _MySQL

文章插图
作者 | 胡梦宇，知乎数据架构平台开发工程师
责编 | 屠敏
头图 | CSDN 下载自东方 IC
出品 | CSDN（ID：CSDNnews）

文章插图
背景
ApacheHive 是基于 Apache Hadoop 的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并且提供了 Hive SQL 进行查询和分析，在离线数仓中被广泛使用。
HiveMetastore 是 Hive 的元信息管理工具，它提供了操作元数据的一系列接口，其后端存储一般选用关系型数据库如 Derby、 MySQL 等。现在很多除了Hive 之外计算框架都支持以 Hive Metastore 为元数据中心来查询底层 Hadoop 生态的数据，比如 Presto、Spark、Flink 等等。
在知乎，我们是将元信息存储在 MySQL 内的，随着业务数据的不断增长，MySQL 内已经出现单表数据量两千多万的情况，当用户的任务出现 Metastore 密集操作的情况时，往往会出现缓慢甚至超时的现象，极大影响了任务的稳定性。长此以往，MySQL 在未来的某一天一定会不堪重负，因此优化 Hive 的元数据库势在必行。
在去年，我们做过数据治理，Hive 表生命周期管理，定期去删除元数据，期望能够减少 MySQL 的数据量，缓解元数据库的压力。但是经过实践，发现该方案有以下缺点：

数据的增长远比删除的要快，治标不治本；
在删除超大分区表（分区数上百万）的分区时，会对 MySQL 造成一定的压力，只能单线程去做，否则会影响其他正常的 Hive 查询，效率极其低下；
在知乎，元信息删除是伴随数据一起删除的（删除HDFS 过期数据，节约成本），Hive 的用户可能存在建表不规范的情况，将分区路径挂错，导致误删数据。

因此，我们需要寻找新的技术方案来解决这个问题。

文章插图
技术选型
? 已有方案
业内目前有两种方案可供借鉴：
1. 对 MySQL 进行分库分表处理，将一台 MySQL 的压力分摊到 MySQL 集群；
2. 对 Hive Metastore 进行 Federation，采用多套 Hive Metastore + MySQL 的架构，在 Metastore 前方设置代理，按照一定的规则，对请求进行分发。
但是经过调研，我们发现两种方案都有一定的缺陷：
1. 对 MySQL 进行分库分表，首先面临的直接问题就是需要修改 Metastore 操作 MySQL 的接口，涉及到大量高风险的改动，后续对 Hive 的升级也会更加复杂；
2. 对 Hive Metastore 进行 Federation，尽管不需要对 Metastore 进行任何改动，但是需要额外维护一套路由组件，并且对路由规则的设置需要仔细考虑，切分现有的 MySQL 存储到不同的 MySQL 上，并且可能存在切分不均匀，导致各个子集群的负载不均衡的情况；
3. 我们每天都会同步一份 MySQL 的数据到 Hive，用作数据治理，生命周期管理等，同步是利用内部的数据同步平台，如果采用上面两种方案，数据同步平台也需要对同步逻辑做额外的处理。
? 最终方案
其实问题主要在于，当数据量增加时，MySQL 受限于单机性能，很难有较好的表现，而将单台 MySQL 扩展为集群，复杂度将会呈几何倍上升。如果能够找到一款兼容 MySQL 协议的分布式数据库，就能完美解决这个问题。因此，我们选择了TiDB(https://github.com/pingcap/tidb).
TiDB 是 PingCAP 开源的分布式 NewSQL 数据库，它支持水平弹性扩展、ACID 事务、标准 SQL、MySQL 语法和 MySQL 协议，具有数据强一致的高可用特性，是一个不仅适合 OLTP 场景还适 OLAP 场景的混合数据库。
选用 TiDB 的理由如下：

TiDB 完全兼容 MySQL 的协议，经过测试，TiDB 支持 Hive Metastore 对元数据库的所有增删改查操作，使用起来不存在兼容性相关的问题。因此，除了将MySQL 的数据原样 dump 到 TiDB，几乎没有其他工作需要做；
TiDB 由于其分布式的架构，在大数据集的表现远远优于 MySQL；
TiDB 的可扩展性十分优秀，支持水平弹性扩展，不管是选用分库分表还是 Federation，都可能会再次遇到瓶颈，届时需要二次切分和扩容，TiDB 从根本上解决了这个问题；
TiDB 在知乎已经得到了十分广泛的应用，相关技术相对来说比较成熟，因此迁移风险可控。