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

TiDB_Robot for PingCAP · 2020年07月10日 · 444 次阅读

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

背景

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

2.我们从元数据库层面测试了一些 Metastore 提交的 SQL,尤其是那些会造成元数据库压力巨大的 SQL,例如:

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

当某个 Hive 表的分区数量十分巨大时,这条 SQL 会给元数据库造成相当大的负担。迁移前,此类 SQL 在 MySQL 运行时间约为 30s - 40s,迁移后,在 TiDB 运行仅需 6s - 7s,提升相当明显。

3.数据同步平台上的 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 带来更加完整的大数据能力。

更多原创文章干货分享,请关注公众号
  • 加微信实战群请加微信(注明:实战群):gocnio
暂无回复。
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册