某邮储银行数据归集系统在 HTAP 场景下的选型与实践

导语：面对 HTAP 能力的需求与云原生时代的趋势，以及国产化的浪潮，某邮储银行携手 OceanBase 打造了云原生时代下的国产分布式数据库场景实践体验。以下内容整理自某邮储银行运维方 DBA 的自述。

业务痛点

我们有一套针对业务内部的运营数据归集系统，各地的服务网点都将各类生产数据、经营数据及运营数据进行上报，还有前端用户埋点数据、各子系统生产数据表单汇集，数据源的格式多样，数据聚合程度不一，计算方式复杂多样。目前，我们采用两种方式进行数据采集。

• 人工上报：通过员工自行制表、填表将数据上报至系统中的固定页面，进行运算。

• 机器抓取：一些老系统或无法提供接口，就需要通过 RPA 自动化机器人抓取数据，这是整个基础数据的来源。抓取数据后汇总，并用 Java 在程序中进行计算，将数据沉淀至报表，以供前台实时读取。

面对每天的数据增长，而且内部运营系统的数据不能直接完成实时分析，需要将其汇总成特定格式进行转换计算，做成战略面板，提供顶层决策分析能力。我们使用的数据库系统是 MySQL，在大众印象中，MySQL 侧重于 OLTP(联机事务处理)，在 OLAP（在线分析处理）方面的性能如高可用、备份等方面表现较弱，这些痛点在我们使用 MySQL 的过程中也确实感受到了。而随着我们业务并发量的提高和数据量的增长，既要求较强的 OLTP 能力，又需要 OLAP 能力的支撑，且软硬件及服务成本不断升高。面对传统关系型数据库的许多技术难题，比如海量数据下 sacle in or out（弹性扩展）的算力不足、不能原生解决单点故障和全链路高可用、OLTP+OLAP 场景无法实现一体化，我们决定探索 HTAP（混合事务分析处理）数据库，实现降本增效的目标。

产品调研

在决定探索 HTAP 数据库后，我们最先了解到的是 OceanBase。因为公司有一个项目正在使用阿里云的 PolarDB，但 PolarDB 必须在云端部署，而我们的业务需求是本地部署，所以，OceanBase 成为我们的首个研究目标。OceanBase 兼容 MySQL 的特性很吸引我们，而最终选择 OceanBase 是出于以下几个因素。

• 因素 1：稳定可靠。 OceanBase 十二年稳定可靠的产品力和在支付宝全核心场景替换 MySQL 的实践，以及应用于众多行业多个大型客户核心场景，为我们在业务场景中使用它建立了信心。

• 因素 2：AP 性能优秀。 在类似的 OLAP 场景中，我们曾经使用过 GBase、PostgreSQL、Greenplum，在复杂的 SQL 查询方面速度较慢，并且当用户量大的时候再连接这些数据库，都会出现各种各样的问题，也有可能是我们自身资源不足的导致的。我们在测试 OceanBase 的性能时，采用现有环境即 2 核 40C80 线程、256GB 内存的环境，测试了 TPS 和 QPS， 以下是在 3000 并发量下 Sysbench 的读写混合测试结果。这个测试结果完全满足了业务要求。

SQL statistics:    queries performed:        read:                            2405494        write:                           687284        other:                           343642        total:                           3436420    transactions:                        171821 (2859.31 per sec.)    queries:                             3436420 (57186.17 per sec.)    ignored errors:                      0      (0.00 per sec.)    reconnects:                          0      (0.00 per sec.)
General statistics:    total time:                          60.0903s    total number of events:              171821
Latency (ms):         min:                                   29.15         avg:                                  104.83         max:                                  414.93         95th percentile:                      155.80         sum:                             18012703.78
Threads fairness:    events (avg/stddev):           572.7367/30.91    execution time (avg/stddev):   60.0423/0.02

因素 3：运维简单。 目前的业务需求需要在 AP 与 TP 之间找到一个平衡点，如果 AP 场景和 TP 场景使用不同的数据库，势必会增加技术栈的深度，增大运维难度，而业务对于两种使用场景并不是强依赖的关系。使用混合型的 HTAP 产品，无疑是最好的选择，也是一种良好的探索与尝试。OceanBase 运维简单，只需一套 OCP 工具就能搞定。且系统告警提供了丰富的扩展功能，可以与现有监控对接。运维人员每天只是关注重要数值，观察有没有报警，运维管理比较轻松。

因素 4：国产化趋势。 我们无法预料 MySQL 在未来是否会被限制，也无法确定是否所有系统都会逐渐成 Linux，但可以肯定的是要防患于未然。因此，研究完全国产自研且开源的数据库是一条出路，未来如果真要替换全部系统，至少到那时我们已经有一定的技术积累和沉淀，能够应对引进软件限制的问题。

因素 5：适用业务且容错。 OceanBase 主打 HTAP，具有高可用和容灾能力，非常适用于我们的业务。同时，我们要应用数据库的系统不完全是生产系统，而是一个后台的报表，它处于核心系统与边缘系统之间，有一定的容错性，因此，决定先在这个报表环境中尝试使用 OceanBase。

因素 6：及时响应。 OceanBase 开源后社区活动与响应都很积极，虽然有些生态还在完善，但是能感觉到 OceanBase 开源的产品力在显著提高。

场景实践

决定使用 OceanBase 后，我们开始了环境部署，表 1 列出部署参数。

图 1 OceanBase 三节点部署架构

上文提到，随着业务数据量的增大，我们原本使用的 MySQL 不符合业务要求，部署 OceanBase 后，我们开始重构系统和底层数据底座，经历了以下四个阶段。

第一，POC 阶段。 “如果有什么问题或者和 MySQL 不一致，你们就直接报错，我们看如何解决”，这是我当时对 OceanBase 的研发支持人员说的话，但我惊喜地发现，OceanBase 能够与我们使用的 MySQL 5.7.18 版本良好兼容，可以轻松实现零成本迁移。在此过程中，我们遇到了两个问题，一是 SQLSTATE[0A000]: Feature not supported: 1235 while parameter _ob_enable_prepared_statement is disabled, prepared statement not supported，通过参数调整，轻松搞定；二是应用数据的迁移人员在使用 Navicat 进行迁移的时候，出现了一些结构化语句不兼容的问题，我们惊喜地发现 Navicat16.1 版本开始，有了 OceanBase 的专用驱动连接，使用后兼容性问题完美解决。

第二，数据迁移阶段。 我们使用了 OceanBase 迁移服务（OceanBase Migration Service，OMS）完成了 MySQL 数据的在线无缝迁移。

第三，数据库侧改造阶段。 我们的应用测试基本不用改造，就将 MySQL 的分区数据、表结构等迁移到了 OceanBase，并且一切运行正常，查询性能和查询效率都超出预期。同时，对于开发人员来说，他们无需投入学习成本，在 OB 上操作与此前在 mysql 上无异。

第四，实际上线阶段。 在该阶段，我们暂停了业务写入，等待系统迁移完成，并在新业务流量写入 OceanBase 集群后，观察业务波动。割接后近一个月的试用，系统运行稳定，分析数据处理时间缩短到了原来的 1/3，达到了我们的使用预期。

业务收获

以上就是我们应用 OceanBase 的实践过程。从业务角度看，在此次的数据库实践中，我们有五点收获。

• 原生的高可用体系： OceanBase 基于 PAXOS 协议高可用，避免单点故障，RPO=0。

• 无感知的 DDL： OceanBase DDL 无感知，可以加快业务迭代效率。

• 完善的管理平台： OCP 平台集成了部署、监控、诊断等功能，大大降低了运维与开发成本。

• 线上扩展能力： 后期业务数据体系可以通过横向增加机器资源实现 scale in or out。

• 赋能 HTAP 能力： 数据读写与实时统计分析场景用一个数据产品解决。

当然，对于 OceanBase，我们也有三个期望与建议。

• 希望 OCP 实现集成性能测试。

• 使用 SATA 硬盘实际测试出的 TPS 是官网的 1/2，建议使用 SSD 作为硬盘存储。

• 期望 OceanBase 能在更多场景替换 MySQ，并不断完善其三地五中心等高级能力。

不得不说，随着国产化浪潮和云原生趋势的推动，企业对数据产品的要求日趋增高。面对老牌数据产品的能力，或许勇于尝试一些优秀的新型产品才能找到良好的解决方案。此次对 OceanBase 的探索，让我们解决了以往在高可用、线性扩展、存储成本等方面遇到的难题，并且，在拥有了 HTAP 能力的同时还能持续降低业务成本。