从MySQL迁移到TiDB,横向扩展Hive Metastore数据库

2020-07-24 互联网

工业:知识共享

作者:胡梦宇(知乎平台工程师)

Transcreator:Caitin陈编辑器:汤姆政府高级官员

MySQL水平扩展Hive Metastore

“你知道吗?”在文言文里的意思是“你知道吗?”是中国的Quora:一个问答网站,用户社区在这里创建、回答、编辑和组织各种各样的问题。作为中国最大的知识共享平台在美国,我们有2.2亿注册用户,网站上有3000万个问题和超过1.3亿的答案。2019年8月,我们完成了项目f轮融资4.5亿美元

在知狐,我们使用MySQL作为Hive Metastore。随着Hive的数据增长,MySQL存储了大约60gb的数据,最大的表有超过2000万行数据。虽然对于一个独立的MySQL数据库来说数据量并不大,但是在Hive中执行查询或写数据会导致Metastore操作频繁。在这种情况下,Metastore的后台数据库MySQL成为了整个系统的瓶颈。我们比较了多个解,发现TiDB,一个开源的分布式软件混合事务/分析处理(HTAP)数据库是最优解决方案。多亏了TiDB的弹性可伸缩性,我们可以横向扩展元数据存储系统,而不必担心数据库容量。

去年,我们出版了帖子这显示了我们如何将查询响应时间保持在毫秒级别,尽管有超过1.3万亿行的数据。这篇文章在各种媒体平台上引起了轰动黑客新闻DZone.今天,我将与大家分享我们如何使用TiDB水平扩展Hive Metastore,以满足我们不断增长的业务需求。

我们的痛苦点

Apache蜂巢是一个建立在Apache Hadoop之上的数据仓库软件项目,提供数据查询和分析。Hive Metastore是Hive的元数据管理工具。它提供了一系列用于操作元数据的接口,其后端存储通常使用Derby或MySQL等关系数据库。除了Hive,很多计算框架都支持使用Hive Metastore作为元数据中心,在底层Hadoop生态系统中查询数据,如Presto、Spark、Flink等。

在知狐,我们使用MySQL作为Hive Metastore。随着Hive中数据的增长,MySQL中一个表就存储了超过2000万行的数据。当用户的任务在Metastore中有密集的操作时,它经常运行缓慢甚至超时。这极大地影响了任务的稳定性。如果这种情况继续下去,MySQL将不堪重负。因此,对Hive Metastore进行优化至关重要。

为了减少MySQL的数据大小和减轻Metastore的压力,我们定期删除MySQL中的元数据。但在实践中,该政策存在以下弊端:

  • 数据的增长速度远远快于删除速度。
  • 当我们删除一个有数百万个分区的大分区表的分区时,会给MySQL带来压力。我们必须控制此类查询的并发性,并且在高峰时间一次只能执行一个查询。否则,会影响Metastore中的其他操作,如选择更新操作。
  • 在知乎,删除元数据时,相应的数据也被删除了。(为了节省成本,我们在Hadoop分布式文件系统中删除了过时的数据。)此外,Hive用户有时会创建错误的表,设置错误的分区路径。这导致数据被误删除。

因此,我们开始寻找另一种解决办法。

解决方案我们比较

我们比较了多个选项,最终选择TiDB作为我们的解决方案。

MySQL分片

我们考虑使用MySQL分片来平衡集群中多个MySQL数据库的负载。然而,我们决定反对这项政策,因为它存在以下问题:

  • 为了分片MySQL,我们需要修改Metastore界面来操作MySQL。这将涉及许多高风险的变化,并将使未来的Hive升级更加复杂。
  • 我们每天将MySQL数据复制到Hive,进行数据治理和数据生命周期管理。我们使用内部数据复制平台来复制数据。如果我们使用了MySQL分片,那么我们需要更新数据复制平台的复制逻辑。

使用Federation标度Metastore

我们认为可以用联盟来扩展蜂巢Metastore。我们可以形成一个架构,由MySQL和多组Hive Metastore组成,并在Metastore前面添加一个代理,按照一定的规则分发请求。

但经过调查,我们发现这一政策也存在缺陷:

  • 为了在Hive Metastore上启用Federation,我们不需要修改Metastore,但我们必须维护一组路由组件。更重要的是,我们需要谨慎地设置路由规则。如果我们将现有的MySQL存储划分到不同的MySQL实例,划分可能是不均匀的。这将导致子集群之间的负载不平衡。
  • 与MySQL共享解决方案一样,我们需要更新数据复制平台的复制逻辑。

TiDB具有弹性可扩展性,是完美的解决方案

TiDB一个分布式SQL数据库是由PingCAP它的开源社区。它兼容MySQL,具有水平可伸缩性、强一致性和高可用性。它是OLTP和OLAP工作负载的一站式解决方案。您可以了解更多关于TiDB的架构在这里

正如您所记得的,我们的问题是当数据大小增加时,MySQL受到其独立性能的限制,不能提供良好的性能。当单个MySQL数据库形成集群时,复杂性急剧增加。如果我们能找到一个分布式的、与mysql兼容的数据库,我们就能解决这个问题。因此,TiDB是一个完美的匹配。

我们选择TiDB是因为它有以下优点:

  • TiDB与MySQL协议兼容。我们的测试表明,TiDB支持Metastore中的所有插入、删除、更新和选择。使用TiDB不会带来任何兼容性问题。因此,我们需要做的就是将MySQL数据转储到TiDB。
  • 由于它的分布式架构,TiDB在大数据集和大量并发查询方面远远优于MySQL
  • TiDB具有良好的横向可伸缩性。它支持弹性可伸缩性。无论我们选择MySQL分片还是Hive Metastore Federation,我们都可能再次遇到瓶颈。然后,我们需要再做一次分片或Hive Metastore Federation。但是TiDB解决了这个问题。
  • TiDB在知乎中被广泛使用,且相关技术相对成熟,可以控制迁移风险。

蜂巢结构

迁移到TiDB之前

在我们从MySQL迁移到TiDB之前,我们的Hive架构如下。在这个架构中,Zue是知乎内部使用的可视化查询界面。

迁移到TiDB之前的Hive架构

迁移到TiDB之前的Hive架构

迁移到TiDB后

当我们从MySQL迁移到TiDB后,Hive的架构是这样的:

迁移到TiDB后的Hive架构

迁移到TiDB后的Hive架构

您可以看到,在我们将元数据迁移到TiDB之后,架构几乎没有变化。在一个MySQL节点上的查询请求现在分布在TiDB集群中。TiDB集群越大,查询效率越高,性能提升越大。

迁移过程

我们是这样从MySQL迁移到TiDB的:

  1. 我们使用MySQL作为主数据库,TiDB作为辅助数据库,实时地将数据从MySQL复制到TiDB。

  2. 我们将Metastore节点减少为1个,避免多个Metastore节点同时写MySQL和TiDB,造成元数据不一致。

  3. 在应用程序的非高峰时间,我们从主数据库切换到辅助数据库。我们使用TiDB作为主节点,并重新启动Metastore。

  4. 我们添加了Metastore节点。

在迁移过程中,应用程序没有受到影响。现在TiDB在我们的生产环境中成功运行。

应用程序的运行状态

应用程序峰值中的操作执行时间

我们从Hive级别测试数据库,模拟应用程序峰值,同时删除和添加数百万个分区的表的分区。执行如下Hive SQL语句:

改变,更改表格“$ {table_name}”下降如果存在分区改变,更改表格“$ {table_name}”添加如果存在分区

执行时间由迁移前的45-75秒降至迁移后的10秒以下。

大型查询对数据库的影响

在Metastore层面,我们测试了一些Metastore提交的SQL语句,特别是那些会对Metastore造成很大压力的SQL语句,例如:

选择A0PART_NAMEA0PART_NAME作为NUCORDER0分区A0加入中环B0A0TBL_IDB0TBL_ID加入星展银行C0B0DB_IDC0DB_ID在哪里C0的名字“$ {database_name}”B0TBL_NAME“$ {table_name}”订单通过NUCORDER0

当Hive表的分区数非常大时,此SQL语句会给Metastore带来很大的压力。在迁移到TiDB之前,这类SQL语句在MySQL中的执行时间为30-40秒。迁移后,执行时间为6-7秒。多么显著的进步啊!

复制的时间

安全数据表(SDS)表,拥有超过1000万行数据,是Metastore中最大的表之一。数据复制平台上Metastore上SDS表的复制时间从90秒缩短到15秒。

接下来是什么

在Hive Metastore的案例中,TiDB帮助我们横向扩展元数据存储数据库,因此我们不再需要担心数据库存储容量。我们希望在未来,TiDB能够提供跨数据中心(DC)服务:通过数据副本的跨数据中心部署,TiDB可以连接在线和离线场景,使我们能够离线进行实时提取、转换、加载(ETL)任务,而不会对在线业务造成压力。这将提高离线ETL任务的实时性能。因此,我们正在开发TiBigData

这个项目是由晓光太阳,知乎的TiKV维护者。目前,它是一个孵化项目PingCAP孵化器.平cap孵化器旨在建立TiDB生态开源项目的孵化体系。有关所有项目,请参见pingcap-incubator GitHub上.您可以查看PingCAP孵化器的文档在这里

TiBigData项目为TiDB提供了Presto和Flink的只读支持。未来,我们希望在PingCAP孵化器计划的支持下,与社区共同打造TiBigData项目,努力提升TiDB的大数据能力。

准备好开始使用TiDB了吗?