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

文章插图
其中，Zue是知乎内部使用的可视化查询界面。
? 迁移后

文章插图
在 Hive 的元数据库迁移到 TiDB 了以后，架构几乎没有任何变化，只不过查询的压力由单台 MySQL 节点分摊到了整个 TiDB 集群，集群越大，查询效率越高，性能提升越明显。

文章插图
迁移流程
1. 将 TiDB 作为 MySQL 的从库，实时同步数据；
2. Metastore 缩容至 1 个，防止多个 Metastore 分别向 MySQL 及 TiDB 写入，导致元数据不一致；
3. 选取业务低峰期，主从切换，将主切为TiDB，重启 Metastore ；
4. Metastore 扩容。
此迁移过程对业务几乎无感，成功上线。

文章插图
运行概况
1. 我们从 Hive 层面对数据库进行了测试，模拟业务高峰期，多并发对百万分区级别的表增删分区，所执行的 Hive SQL 如下：
ALTER TABLE '${table_name}' DROP IF EXISTS PARTITION(...);ALTER TABLE '${table_name}' ADD IF NOT EXISTS PARTITION(...);花费时间从 45s-75s 降低到了 10s 以下。
2. 我们从元数据库层面测试了一些 Metastore 提交的 SQL，尤其是那些会造成元数据库压力巨大的 SQL，例如：

SELECT `A0`.`PART_NAME`,`A0`.`PART_NAME` AS `NUCORDER0` FROM `PARTITIONS` `A0` LEFT OUTER JOIN `TBLS` `B0` ON `A0`.`TBL_ID` = `B0`.`TBL_ID` LEFT OUTER JOIN `DBS` `C0` ON `B0`.`DB_ID` = `C0`.`DB_ID` WHERE `C0`.`NAME` = '${database_name}' AND `B0`.`TBL_NAME` = '${table_name}' ORDER BY `NUCORDER0`

当某个 Hive 表的分区数量十分巨大时，这条 SQL 会给元数据库造成相当大的负担。迁移前，此类 SQL 在 MySQL 运行时间约为 30s - 40s，迁移后，在TiDB 运行仅需 6s - 7s，提升相当明显。
3. 数据同步平台上的Hive 元数据库内的 SDS 表的同步任务时间从 90s 降低到 15s 。

文章插图
展望
在 Hive Metastore 的场景下，我们已经感受到了 TiDB 在大数据应用场景下的魅力。后续我们希望 TiDB 能够成为跨数据中心的服务，通过数据副本的跨机房部署，打通离线与在线，让离线场景能够在对在线服务无压力的情况下为数据提供实时的ETL 能力，解决离线 ETL 任务实时性差的问题。为此，我们正在开发 TiBigData(https://github.com/pingcap-incubator/TiBigData) 。
目前其作为PingCAP incubator 的孵化项目。由来自知乎的 TiKV Maintainer 孙晓光发起。PingCAP Incubator 旨在梳理一套相对完整的TiDB 生态开源项目孵化体系，将关于 TiDB 开源生态的想法与实际生产环境中的需求相关联，通过开源项目协作方式，共同将想法落地。力求想法项目化。从「我有一个想法」到「项目顺利毕业」，PingCAP提供一系列的资源支持，确保所有项目孵化的流程都有章可循，同时结合项目不同特征及孵化目的，将项目划分为 Feature 类和 Project 类，针对性地给出孵化流程建议。PingCAPIncubator 中的项目有：TiDB Dashboard、TiUP、TinyKV，TiDB wasm 等。