0
2
0
0
专栏/.../

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

 是我的海  发表于  2024-01-29
原创

作业帮是一家成立于 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 及其生态组件的特性以及使用方法。

image

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

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

image

二、在线业务落地从 0-1

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

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

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

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

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

image

2、业务流水数据

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

三、在线业务落地从 1-N

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

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

image

#四、总结以及未来展望

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

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

最后,也说一下对 TiDB 的希望:

希望 TiDB 能有不依赖于 CDC 的主备集群方案, 一方面可以做异地机房的灾备,另一方面可以作为升级回滚的方案,避免升级之后出现业务不兼容的情况;

探索使用资管管控方案 (Resource Control)。 对于 MySQL 分库分表的业务,无法将多个分集群同步到同一个 TiDB 集群,会出现库名冲突的情况;

SQL 限流或者拦截功能: 对于资源消耗异常高的 SQL,可以自动进行降级处理,避免将集群资源耗尽,集群雪崩。

0
2
0
0

版权声明:本文为 TiDB 社区用户原创文章,遵循 CC BY-NC-SA 4.0 版权协议,转载请附上原文出处链接和本声明。

评论
暂无评论