OceanBase 在作业帮业务的应用实践

作者｜刘强，就职于作业帮基础架构 DBA 团队，负责分布式数据库的探索和使用，协同研发团队在公司内部推进分布式数据库在业务上的落地。

核心业务架构的几大痛点

作业帮成立于 2015 年，致力于用科技手段助力教育普惠，运用人工智能、大数据等技术，为学生、老师、家长提供学习、教育解决方案，智能硬件产品等。

在业务初期，作业帮使用阿里云 ECS 自建 MySQL，同时最大程度利用自建 DBasS 平台完成初期业务的快速扩张，为业务提供稳定的 OLTP 能力，但随着业务数据量飞速上涨，该数据架构逐渐呈现亟需解决的技术痛点。

痛点 1：应用分布式改造。

众所周知，当单个 MySQL 集群性能无法满足业务读取需求时，通常采用分布式改造的方式，使用分库分表方案解决 MySQL 单点性能瓶颈。但应用改造带来了不小的改造成本，每一次数据架构扩容都需要业务与 DBA 团队做大量变更,这种业务成本换取核心业务稳定性的方案不足以支撑业务的飞速发展。

痛点 2：节点无法按需扩缩容。

基于目前的 MySQL 分布式方案，为满足业务扩展需求，作业帮从刚开始的单个 MySQL 集群扩容至现在的 8 个 MySQL 分片集群，带来大量的资源浪费，同时，数据均衡问题也对作业帮产生困扰。

痛点 3：数据架构满足不了业务需求。

当前架构仅能满足部分 OLTP 类场景的核心业务需求，MySQL 无法支持数据实时分析需求，掣肘了业务发展。因此，作业帮需要一个既能支撑 OLTP 业务也能承接 OLAP 业务且保证二者资源隔离的解决方案。

痛点 4：数据存储策略无法敏捷调整。

MySQL 分布式架构冗余、笨重，导致系统在应对多变的数据合规需求时无法及时响应，做不到“数据随着业务走，业务随着合规走”。如何在保证数据强一致的基础上迅速调整存储策略，也是作业帮需要解决的技术问题。

核心业务 HTAP 多元化能力支撑及架构升级

基于上述面临的架构痛点，DBA 团队与业务架构团队对多种数据产品进行了深入的技术调研。

其中，原生分布式数据库 OceanBase 4.x 版本的功能特性可以针对上述痛点澄源正本，具体而言，表现在原生分布式架构、HTAP 能力、多租户与数据高压缩，以及完善的生态体系。

1. 原生分布式架构，数据强一致，灵活扩缩容。

OceanBase 原生分布式架构提供了平滑扩展的能力，解决了业务分布式改造和按需扩容的问题。同时，由于 Paxos 协议和全量数据校验，真正实现数据强一致、零丢失，如出现故障，可在 8 秒内恢复业务。在业务 POC 阶段，作业帮对 OceanBase 进行扩缩容与节点容灾测试，从三个 Zone 的 1-1-1 架构，升级到 2-2-2 架构，数据分片均衡期间业务运行稳定。

2. 一套引擎支撑 HTAP 混合负载业务。

OceanBase 的行列混存与一套引擎支持 OLAP + OLTP 的混合负载架构能够满足事务处理需求的同时秒级响应分析、跑批等需求。在 HTAP 场景中，为了确保资源隔离，有多种方式，如 AP 类查询大队列、租户内 SQL 资源绑定、只读副本等，作业帮在产品测试阶段选取了典型的百万数据规模的 10-20 并发聚合类查询场景，测试结果显示 OceanBase 不仅能做到毫秒级响应（性能高于 MySQL 数十倍），而且对核心 TP 业务毫无影响。

3. 多租户与高压缩比，避免资源浪费，降本超六成

作业帮通过 OceanBase 一套集群的多个租户承接线上 8 个 MySQL 集群的所有请求，由于租户规格可设置，作业帮的资源得到极致利用，且租户间互相隔离。同时，OceanBase 存储引擎提供的数据高压缩能力使存储成本极大地降低，在同等三副本情况下（MySQL 单个集群一主二从；OceanBase 三副本），MySQL 900GB 数据在 OceanBase 中仅 170GB，存储成本节约超六成。多租户规格同等业务需求下，OceanBase 的资源使用不到 MySQL 的 1/5（单个租户规格最小仅 3C12G 一个 Zone，MySQL 节点独占资源 32C256G）。

4. 完善的生态体系

OceanBase 提供了丰富的生态工具，除自研的 OMS、ODC、OCP 等运维管理平台外，还兼容 400+ 上下游生态工具。

使用上述工具，作业帮实现了实时迁移、迁移同步任务一体化，以及可视化的集群生命周期管理、开发管理和全链路诊断，为数据架构升级提供了一个可回滚、可监控、可灰度的解决方案。

综上，作业帮决定将 OceanBase 作为架构升级的核心数据库产品，制定上线方案并实施。

应用 OceanBase HTAP 解决方案及业务收益

下图是 OceanBase 上线后的架构体系，目前业务写流量通过分库分表方式写入 MySQL 集群，再使用 OMS 将全量数据及增量数据的实时同步到下游的 OceanBase 集群中，并写入各个 MySQL 集群租户，同步过程中同时进行数据校验。

作业帮利用 OceanBase 的 HTAP 能力，使查询分析的业务得以前置，无需等待 T+1 数据，直接于在线库实现实时营销决策等分析需求。在保证线上核心业务稳定性的同时，也解决了业务痛点。后续业务流量逐步灰度到 OceanBase 或回滚到 MySQL 集群中。

自业务应用 OceanBase 以来，获得了不小的架构收益和可贵的业务实践。

首先，存储成本降低超六成，实时分析性能提升 4 倍以上，硬件成本相比 MySQL 降低 77.8%。

其次，由于一套引擎支持 OLTP 业务和 OLAP 业务，使 OceanBase 稳定支撑核心业务的同时完成实时分析需求。Auto DOP 更是 AP 性能的提升利器，经测试，在千万以内的数据量级场景下，复杂的 AP 类 SQL 响应时间可以提升数倍，秒级内完成数据分析(两次测试结果中，第一个结果从 4.6 秒提升至 0.8 秒，第二个结果从 1.8 秒提升至 0.24 秒）。在资源充足的时候，如果对性能有更高诉求可尝试使用 DBLink 功能，可以实现租户间跨库查询诉求，打破数据隔离。

最后，完善、便捷的生态体系不仅释放了业务人员与运维人员的大量工作，还节约了运维与开发成本。

此处也分享一下 OMS 的使用经验：

• OMS 同步数据一个并发可以支撑 1000 左右，具体还需要结合单条记录大小，如果单条记录包含 lob 类字段，那么该值较小。另外一个并发一般设置 1G 内存，当并发数太多而内存太小时 RPS 会降低很多（Full GC）。

• 一般一条同步链路的资源需求是 4C/8G ，如果一个机器的内存资源超过 80%，同步链路则会创建失败，建议调大内存机器。

• 可以在 OMS 具体同步任务详情中查询 RPS 监控指标，观察数据同步速度。

OceanBase 支撑核心业务架构

目前，OceanBase 的应用方案已经平稳落地，未来作业帮将扩大 OceanBase 应用范围，并在该方案中投入更多精力。

• 尝试探索落地多 Region 下的容灾架构体系，做到数据合规的同时满足数据聚合需求，进一步尝试 OceanBase 主备库方案。

• 逐步将 MySQL 的核心流量灰度到 OceanBase 中，承接全部的业务流量，完全解决分库分表架构带来的技术痛点，OMS 作为下游工具通过数据订阅方式将数据传输到数据湖中，完成数据链路闭环。

• 进一步引入 ODC，打造开发与 DBA 团队的一体化效能数据开发平台，调研 OceanBase 行级回收站能力，为业务的稳定性和数据容错性提供更多保障。