知乎-Hive-Metastore-实践从-MySQL-到-TiDB

作者介绍：胡梦宇，知乎数据架构平台开发工程师

背景

Apache Hive 是基于 Apache Hadoop 的一个数据仓库工具，能够将结构化的数据文件映射为一张数据库表，并且提供了 Hive SQL 进行查问和剖析，在离线数仓中被宽泛应用。
Hive Metastore 是 Hive 的元信息管理工具，它提供了操作元数据的一系列接口，其后端存储个别选用关系型数据库如 Derby、MySQL 等。当初很多除了 Hive 之外计算框架都反对以 Hive Metastore 为元数据中心来查问底层 Hadoop 生态的数据，比方 Presto、Spark、Flink 等等。
在知乎，咱们是将元信息存储在 MySQL 内的，随着业务数据的一直增长，MySQL 内曾经呈现单表数据量两千多万的状况，当用户的工作呈现 Metastore 密集操作的状况时，往往会呈现迟缓甚至超时的景象，极大影响了工作的稳定性。长此以往，MySQL 在将来的某一天肯定会不堪重负，因而优化 Hive 的元数据库势在必行。
在去年，咱们做过数据治理，Hive 表生命周期治理，定期去删除元数据，冀望可能缩小 MySQL 的数据量，缓解元数据库的压力。然而通过实际，发现该计划有以下毛病：

1. 数据的增长远比删除的要快，治标不治本；
2. 在删除超大分区表（分区数上百万）的分区时，会对 MySQL 造成肯定的压力，只能单线程去做，否则会影响其余失常的 Hive 查问，效率极其低下；
3. 在知乎，元信息删除是随同数据一起删除的（删除 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。

TiDB 是 PingCAP 开源的分布式 NewSQL 数据库，它反对程度弹性扩大、ACID 事务、规范 SQL、MySQL 语法和 MySQL 协定，具备数据强统一的高可用个性，是一个不仅适宜 OLTP 场景还适 OLAP 场景的混合数据库。

选用 TiDB 的理由如下：

1. TiDB 齐全兼容 MySQL 的协定，通过测试，TiDB 反对 Hive Metastore 对元数据库的所有增删改查操作，应用起来不存在兼容性相干的问题。因而，除了将 MySQL 的数据原样 dump 到 TiDB，简直没有其余工作须要做；
2. TiDB 因为其分布式的架构，在大数据集的体现远远优于 MySQL；
3. TiDB 的可扩展性非常优良，反对程度弹性扩大，不论是选用分库分表还是 Federation，都可能会再次遇到瓶颈，届时须要二次切分和扩容，TiDB 从根本上解决了这个问题；
4. TiDB 在知乎曾经失去了非常宽泛的利用，相干技术相对来说比拟成熟，因而迁徙危险可控。

Hive 架构

迁徙前

其中 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 以下。

1. 咱们从元数据库层面测试了一些 Metastore 提交的 SQL，尤其是那些会造成元数据库压力微小的 SQL，例如：

SELECT `A0`.`PART_NAME`,`A0`.`PART_NAME` AS `NUCORDER0` FROM `PARTITIONS` `A0

当某个 Hive 表的分区数量非常微小时，这条 SQL 会给元数据库造成相当大的累赘。迁徙前，此类 SQL 在 MySQL 运行工夫约为 30s – 40s，迁徙后，在 TiDB 运行仅需 6s – 7s，晋升相当显著。

1. 数据同步平台上的 Hive 元数据库内的 SDS 表的同步工作工夫从 90s 升高到 15s。

瞻望

在 Hive Metastore 的场景下，咱们曾经感触到了 TiDB 在大数据利用场景下的魅力。后续咱们心愿 TiDB 可能成为跨数据中心的服务，通过数据正本的跨机房部署，买通离线与在线，让离线场景可能在对在线服务无压力的状况下为数据提供实时的 ETL 能力，解决离线 ETL 工作实时性差的问题。为此，咱们正在开发 TiBigData。

目前其作为 PingCAP Incubator 的孵化我的项目。由来自知乎的 TiKV Maintainer 孙晓光发动。PingCAP Incubator 旨在梳理一套绝对残缺的 TiDB 生态开源我的项目孵化体系，将对于 TiDB 开源生态的想法与理论生产环境中的需要相关联，通过开源我的项目合作形式，独特将想法落地。力求想法我的项目化。从「我有一个想法」到「我的项目顺利毕业」，PingCAP 提供一系列的资源反对，确保所有我的项目孵化的流程都有章可循，同时联合我的项目不同特色及孵化目标，将我的项目划分为 Feature 类和 Project 类，针对性地给出孵化流程倡议。PingCAP Incubator 中的我的项目有：TiDB Dashboard、TiUP、TinyKV，TiDB Wasm 等。

残缺我的项目请查看：
https://github.com/pingcap-incubator

PingCAP Incubator 残缺文档参考：
https://github.com/pingcap/community/tree/master/incubator

目前 TiBigData 我的项目曾经为 TiDB 提供了 Presto 与 Flink 的只读反对。后续咱们心愿在 PingCAP Incubator 打算的搀扶下同社区一起建设 TiBigData 我的项目，力求为 TiDB 带来更加残缺的大数据能力。