作业帮 x TiDB丨多元化海量数据业务的支撑

导读

作业帮是一家成立于 2015 年的在线教育品牌，致力于用科技手段助力教育普惠。经过近十年的积累，作业帮运用人工智能、大数据等技术，为学生、老师、家长提供学习、教育解决方案，智能硬件产品等。随着公司产品和业务场景越来越丰富，数据量越来越大，业务方对数据库的使用需求也越来越多元化。本文介绍了作业帮对 TiDB 的探索历程，以及逐渐落地多个业务场景的使用实践。

TiDB 在作业帮的探索和推广

作业帮内部最开始接触的版本是 TiDB v4.0.9。相较于 TiDB v3.x，v4.0.9 在性能、管理、易用性等方面都有了质的提升，同时 TiDB 的生态组件以及社区也都达到了非常完善的程度，可以说是一个标志性的版本。2020 年，我们正式开始调研测试 TiDB v4.0.9, 以实现团队在分布式数据库的技术储备，从而更好地服务公司的业务需求。

1. 探索期: 使用 TiDB 隔离对在线 MySQL 集群有性能影响的查询请求

研发人员需要不定时查询线上实时数据，以此来确定业务数据的情况或者对部分业务数据做汇总分析。

● 引入 TiDB 之前：业务人员是直连到 MySQL 从库查询数据，如果扫描的数据量太大经常会引起线上 MySQL 节点性能抖动甚至机器的 io/cpu 资源瓶颈。

● 引入 TiDB 之后：通过数据同步工具 DM 将 MySQL 的数据以全量+实时增量的方式同步到 TiDB 中，实现在线、离线请求的隔离性。

在这个探索阶段，一方面满足了离线查询的隔离性的要求，另一方面也熟悉了 TiDB 及其生态组件的特性以及使用方法。

2、推广期：内部分享+主动出击

经过半年左右时间的使用，在对 TiDB 有一定了解的基础上，我们开始在公司内部进行 TiDB 相关的技术分享，向研发人员介绍 TiDB 的一些特性和在大数据量场景下的优势，并主动接触各个业务线去寻找合适的使用场景。研发人员也陆续将一些业务 内部使用的报表服务 接入到离线 TiDB 集群中。

在线业务落地从 0-1

在各个团队使用和熟悉 TiDB 一段时间后，我们开始针对已有业务的痛点或者未来新业务的规划，逐渐将视野转移到 TiDB。通过配合业务一起测试验证，开始正式将在线业务迁移到 TiDB 中。

1、报表平台使用 TiDB 突破存储&性能瓶颈

作业帮的报表服务每天要导入大量来自各个业务线的文件数据，来实现最终的数据大盘展示。随着业务线越来越多以及 MySQL 单实例主机的磁盘限制，报表服务平台逐渐显现出存储受限以及数据展示响应慢，甚至无法响应等问题。

我们通过 DM 将数据同步到 TiDB 中，经过业务验证，TiDB 对 SQL 达到了高度兼容性。同时，对比使用 MySQL 的耗时，TiDB 减少 80% 的时间，效果远超预期。随着 DM 同步稳定性的提高，报表平台也将一些直连线上 MySQL 的报表服务改成使用 TiDB 作为数据源。

经过改造，报表服务最终架构如下:

2、业务流水数据

业务流水数据业务的主要特点是每日写入数据量特别大，而且需要保存时间比较长。在公司的多个业务线中，只要是发展到一定阶段，使用 MySQL 存储的数据最终都会遇到存储瓶颈。此时 TiDB 便是非常好的一种解决方案。

在线业务落地从1-N

得益于 DM 同步数据的可靠性以及后面 TiDB-5.x 版本的兼容性、稳定性，作业帮有些业务逐渐将性能采集数据、用户访问记录、业务日志等业务也迁移到 TiDB。同时，在人工智能爆发的背景下，越来越多的探索性业务天然需要存储海量的数据，TiDB 自然成为首选方案。当然，线上还有很多核心业务不会轻易更换数据存储方案，那么对历史数据的归档使用 TiDB 也是目前的标准方案。

从 TiDB 4.0 版本开始，TiDB 加入了 TiFlash 列存引擎，并且在之后的版本中不断增强。如果业务有任何复杂查询需求，直接就可以在 TiDB 集群里通过增加 TiFlash 节点解决一些比较复杂的查询。

总结以及未来展望

现在，TiDB 在作业帮内部使用中已经可以独当一面了。目前，作业帮已经部署了几十套 TiDB 集群，总体数据量规模超过百 TB。在这些集群中，大部分采用的是 TiDB 5.4 版本，有一半已经升级到 6.5 版本。如果大家还在用 v3.x 版本的话，建议可以采用一些比较保险的方法测试升级到新的版本。作业帮从 v4.0.9 版本一路不断升级上来，整体感受是越来越稳定，让人比较安心，升级过程也非常丝滑，业务几乎没有任何感知。

最近有看到消息说杭州银行已经在核心账务系统上线 TiDB 6.5.6 版本，到 2024 年我们应该也会全部升级到这个版本。

最后，也说一下对 TiDB 的希望：

1. 希望 TiDB 能有不依赖于 CDC 的主备集群方案，一方面可以做异地机房的灾备，另一方面可以作为升级回滚的方案，避免升级之后出现业务不兼容的情况；
2. 探索使用资源管控方案 (Resource Control)。对于 MySQL 分库分表的业务，无法将多个分集群同步到同一个 TiDB 集群，会出现库名冲突的情况；
3. SQL 限流或者拦截功能：对于资源消耗异常高的 SQL，可以自动进行降级处理，避免将集群资源耗尽，集群雪崩。