HTAP 一体化能力支撑核心业务架构升级

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

1. 应用分布式改造
   1. 众所周知，当单个 MySQL 集群性能无法满足业务读取需求时，通常采用分布式改造的方式，使用分库分表方案解决 MySQL 单点性能瓶颈。但应用改造带来了不小的改造成本，每一次数据架构扩容都需要业务与 DBA 团队做大量变更,这种业务成本换取核心业务稳定性的方案不足以支撑业务的飞速发展。
2. 节点无法按需扩缩容
   1. 基于目前的 MySQL 分布式方案，为满足业务扩展需求，作业帮从刚开始的单个 MySQL 集群扩容至现在的 8 个 MySQL 分片集群，带来大量的资源浪费，同时，数据均衡问题也对作业帮产生困扰。
3. 数据架构满足不了业务需求
   1. 当前架构仅能满足部分 OLTP 类场景的核心业务需求，MySQL 无法支持数据实时分析需求，掣肘了业务发展。因此，作业帮需要一个既能支撑 OLTP 业务也能承接 OLAP 业务且保证二者资源隔离的解决方案。
4. 数据存储策略无法敏捷调整
   1. MySQL 分布式架构冗余、笨重，导致系统在应对多变的数据合规需求时无法及时响应，做不到“数据随着业务走，业务随着合规走”。如何在保证数据强一致的基础上迅速调整存储策略，也是作业帮需要解决的技术问题。

1. 原生分布式架构，数据强一致，灵活扩缩容
   1. OceanBase 原生分布式架构提供了平滑扩展的能力，解决了业务分布式改造和按需扩容的问题。同时，由于 Paxos 协议和全量数据校验，真正实现数据强一致、零丢失，如出现故障，可在 8 秒内恢复业务。在业务 POC 阶段，作业帮对 OceanBase 进行扩缩容与节点容灾测试，从三个 Zone 的 1-1-1 架构，升级到 2-2-2 架构，数据分片均衡期间业务运行稳定。
2. 一套引擎支撑 HTAP 混合负载业务
   1. OceanBase 的行列混存与一套引擎支持 OLAP + OLTP 的混合负载架构能够满足事务处理需求的同时秒级响应分析、跑批等需求。在 HTAP 场景中，为了确保资源隔离，有多种方式，如 AP 类查询大队列、租户内 SQL 资源绑定、只读副本等。
3. 多租户与高压缩比
   1. 作业帮通过 OceanBase 一套集群的多个租户承接线上 8 个 MySQL 集群的所有请求，由于租户规格可设置，作业帮的资源得到极致利用，且租户间互相隔离。同时，OceanBase 存储引擎提供的数据高压缩能力，在同等三副本情况下（MySQL 单个集群一主二从；OceanBase 三副本），使存储成本极大地降低。
4. 完善的生态体系
   1. OceanBase 提供丰富的生态工具，除自研的 OMS、ODC、OCP 等运维管理平台外，还兼容 400+ 上下游生态工具。使用上述工具，作业帮实现了实时迁移、迁移同步任务一体化，以及可视化的集群生命周期管理、开发管理和全链路诊断，为数据架构升级提供了一个可回滚、可监控、可灰度的解决方案。

1. 显著降本增效
   1. 首先，存储成本降低超六成，实时分析性能提升 4 倍以上，硬件成本相比 MySQL 降低 77.8%。
      1. MySQL 900GB 数据在 OceanBase 中仅 170GB，存储成本节约超六成。多租户规格同等业务需求下，OceanBase 的资源使用不到 MySQL 的 1/5（单个租户规格最小仅 3C12G 一个 Zone，MySQL 节点独占资源 32C256G）。
2. 复杂的 AP 类 SQL 响应时间提升数倍
   1. 查询分析业务得以前置，无需等待 T+1 数据，直接于在线库实现实时营销决策等分析需求。在保证线上核心业务稳定性的同时，也解决了业务痛点。
      1. Auto DOP 更是 AP 性能的提升利器，经测试，在千万以内的数据量级场景下，复杂的 AP 类 SQL 响应时间可以提升数倍，秒级内完成数据分析（两次测试结果中，第一个结果从 4.6 秒提升至 0.8 秒，第二个结果从 1.8 秒提升至 0.24 秒）
         1. 作业帮在产品测试阶段选取了典型的百万数据规模的 10-20 并发聚合类查询场景，测试结果显示 OceanBase 不仅能做到毫秒级响应（性能高于 MySQL 数十倍），而且对核心 TP 业务毫无影响。