不止于替换 HBase：宝付支付借力 OceanBase，构建面向未来的“TP+AP+KV+AI”统一数据基座

作者：杨泽，宝付支付数据团队负责人

随着数字化转型升级进入关键期，数据库已从被动的存储仓库，转变为主动赋能业务的智能数据中枢。以现代金融行业为例，业务对数据库提出了更高要求：既要满足事务，又要实时分析，同时安全、高效、弹性、智能地处理多模数据，并支撑实时决策与业务创新。这意味着，符合要求的数据库需在 TP、AP、KV、AI 方向均具备出色的数据处理能力。

作为在银行、消费金融、零售、跨境等行业深耕多年的一站式综合支付解决方案商，宝付支付产品种类丰富，且深谙技术创新与业务稳健的关系，不断引进先进技术维护和保障公司业务稳步运行，全方位为商户资金安全和交易安全保驾护航。

近年来，宝付支付的原数据库方案已不能满足业务需求，故而寻求技术升级。本文分享宝付支付在 KV 场景使用 OBKV 替换 HBase 的技术实践。

出于架构痛点，寻求支持 TP+AP+KV+AI 的数据库

宝付支付所属集团——漫道集团采用基于 MySQL 的集中式架构，由于近年来业务高速增长（2023 年初交易量约 3000 万笔/日，2024 年 12 月已突破 9000 万笔/日）带来的海量数据（TB 级），系统压力陡增。

最直观的压力便是成本压力，每年存储采购预算高达数千万元。同时，为了保障部分业务系统的高可用性，需在 A/B 两个机房部署完全对等的 MySQL 双活架构集群（如各 100 台服务器），导致硬件与运维成本成倍增长。

同时在双活架构下，业务层仅关注“订单不丢、实时写入”，但不关心数据最终落在哪个机房、哪个分库。这给数据团队带来巨大挑战：无法准确追踪数据源，难以构建统一的数据视图，ETL 与实时同步逻辑异常复杂。

在业务种类多样的情况下，长期使用 MySQL 还会导致架构越来越复杂，使运维压力极大。集团内部运行着十余套大数据集群和超过 1000 个 MySQL 实例，分别服务于支付、风控、征信、BI 等不同场景，对数据库有不同的需求。

• 支付交易系统：要求高并发、低延迟的事务处理能力。
• 风控系统：依赖实时数据分析与毫秒级决策。
• 征信用户画像业务：需要高性能 KV 存储与快速点查。
• BI 系统：依赖大规模离线分析计算。

多套异构系统并行，导致开发、监控、备份、扩容等运维工作极其繁重。

除 MySQL 外，我们使用 HBase 存储海量日志与宽表，其虽具备高吞吐写入能力，但在事务支持、复杂查询、实时分析、KV 混合负载等方面存在明显短板，已无法满足新一代业务需求。

基于上述挑战，我们开始评估新一代分布式数据库方案。文章开头提到现代金融行业的业务对数据库提出了多种要求。宝付支付作为金融行业的一员也不例外，根据对 TP、AP、KV、AI 方向的需求，我们首先想到了 OceanBase，核心原因在于其原生支持 HTAP（混合事务/分析处理）+ KV + AI 的一体化架构。

• TP 能力：满足支付交易系统的高并发、强一致性要求。
• AP 能力：支撑风控与 BI 的实时分析需求。
• KV 接口：为征信等场景提供低延迟点查。
• AI 能力：内置向量化引擎与 AI 原生能力，为后续智能风控、实时推荐等 AI 应用奠定基础。

为控制风险，我们采取“由边缘到核心”的渐进式改造路径：先在非关键系统验证 OceanBase 稳定性，逐步迁移风控、征信等中台系统；最终目标是将核心支付交易系统平滑切换至 OceanBase，用一套数据库承载全场景需求。

从边缘到核心：OBKV-HBase 替换 HBase

在启动 OceanBase 引入计划后，我们先在离线与分析业务进行试点，后将多个 MySQL 业务迁移至 OceanBase。当 OBKV 功能较为完善时，又完成了从 HBase 到 OBKV-HBase 的升级，实现了一套引擎支持多场景业务的目标。

HBase 难以应对业务复杂度与实时性要求

尽管 HBase 在海量数据存储场景中曾发挥重要作用，但随着业务复杂度提升与实时性要求增强，其在架构、运维及成本等方面的问题日益凸显。主要体现在以下六个方面。

• 离线链路冗长：当前数据流转路径为从 MySQL 流转至 Hive，再导入 HBase，流程环节多，数据延迟显著，且 Hive 层的数据修正不够灵活。
• 实时链路依赖过重：直接读写 HBase 严重依赖 Zookeeper 与 HDFS，中间件耦合度高，链路稳定性风险集中。
• 运维问题：跨机房场景下，集群切换与数据同步操作繁琐，故障时难快速隔离或切换。
• 成本控制：为满足高可用要求，需部署完整的 HBase 主备集群，硬件与存储资源近乎翻倍，成本太大。
• 多机房网络问题：机房网络切割的时候，专线网络异常的时候，对业务都有影响。
• SQL 查询依赖 Phoenix：原生不支持标准 SQL，需借助 Phoenix 等组件实现查询，引入额外维护负担，且使用体验与性能往往不及直接 SQL 友好。

使用 OBKV 替换 HBase，为统一技术栈奠定基础

OBKV 是构建在 OceanBase 分布式存储引擎之上的 NoSQL 产品系列，目前支持 OBKV-Table、OBKV-HBase、OBKV-Redis 三种产品形态，其原生继承了 OceanBase 的高性能、事务、分布式、多租户、高可靠的基础能力。此外，OceanBase 的工具体系（比如 OCP、OMS、CDC 等）也原生支持 OBKV，运维 OBKV 的各个产品形态和运维 OceanBase 的 SQL 集群完全一样。OBKV 可以帮助企业统一技术栈，在满足业务对多模 NoSQL 数据库诉求的同时，降低企业在数据库运维上的复杂度。

基于我们目前正在使用的 OBKV-HBase，总结其与 HBase 的使用区别如下。

• 完全集成 OceanBase 分布式存储能力：OBKV 不仅有 OceanBase 强大的内核能力，也继承了 OceanBase 丰富的生态工具能力。
• 极简运维：DBA 如果同时有 SQL 以及 NoSQL 数据库的诉求，可以只运维一个数据库。
• 统一查询：可以用 OBKV 做简单快速的 DML，同时可以用 SQL 对同一份数据做并发的复杂查询。
• 成本更低：HBase 独用资源，OceanBase 是复用现有资源。
• 监控更方便：方便对应用现有运行环境添加监控。

OBKV-HBase 不仅解决了传统 HBase 在运维复杂、资源孤岛、工具缺失等方面的痛点，更通过与 OceanBase 深度融合，可以实现“一套引擎、多模服务、统一运维、资源共享”的现代化数据基础设施目标。

引入 OceanBase 的三个阶段，确保技术转型平稳可控

在数据库架构升级过程中，我们分三个阶段逐步引入 OceanBase，确保技术转型平稳可控。

第一阶段：初步探索与能力评估（2023 年）

2023 年底，团队开始接触 OceanBase 及其 OBKV-HBase 产品。当时 OBKV 文档尚不完善，关键功能缺失，尤其缺乏 bulkload（批量导入）能力，无法高效导入离线数据，初期判断暂不具备支撑核心业务的能力。因此，该阶段以技术调研为主，未投入生产使用。

第二阶段：归档与分析场景试点（2024 年）

2024 年，团队转向更匹配当前能力的场景，启动 OceanBase 在离线与分析业务的试点，将数据归档、BI 聚合宽表、AP 分析类业务迁移至 OceanBase。我们不仅验证了 OceanBase 在高吞吐写入、复杂查询、资源隔离等方面的稳定性与性能表现，还积累了集群部署、SQL 优化、运维监控等关键经验，为后续全面推广奠定基础。

第三阶段：逐步替换与扩展（2025 年起）

随着 OceanBase 功能持续完善（特别是 OBKV-HBase 的成熟），团队启动规模化替换计划。

• 关系型业务：逐步将业务管理系统、商户管理系统、BI 系统等原 MySQL 应用迁移至 OceanBase SQL 模式；
• NoSQL 业务：使用 OBKV-HBase 替代原有 HBase，例如将“绑卡/解卡操作日志”等高频 KV 场景迁移至 OBKV-HBase；
• 实现 TP、AP、KV 多负载统一承载，推动技术栈收敛与运维简化。

五步平滑迁移：工具使用、方案设计与注意事项

在从 HBase 到 OBKV-HBase 的数据迁移过程中，我们在实践中总结出五个关键步骤。

Step1：目标端准备

在正式启动从 HBase 到 OBKV-HBase 的数据迁移前，需在 OceanBase 端完成充分的环境与配置准备。

• 硬件配置：为避免因磁盘性能不足导致集群不稳定，建议使用高性能磁盘，但建议初期不要过度分配资源，以便预留弹性空间，用于后续扩缩容及负载均衡调整。
• 存储规划：单个 OBServer 节点的磁盘容量应大于单个日志流的数据量。若单表数据量极大，而节点磁盘不足，可能在扩容或副本迁移时触发空间不足错误。
• 租户规划：建议为 OBKV 创建独立租户，隔离资源。
• 建好分区表。

注意事项

• 实测表明，自动 Range 分区优于手工预设 Hash 分区。自动分区支持分区裁剪，对范围扫描类查询性能更优；手工 Hash 分区在范围查询时需扫描所有分区，显著增加延迟与资源消耗。
• 需正确创建 Table Group：HBase 表名对应 OBKV-HBase 的 tablegroup 名字。
• 注意命名规范：HBase 列簇 family 在 OBKV-HBase 形式对应表 tablegroup$family。
• 注意 K 大小写：使用 DBeaver 等工具导出建表语句时，关键字（如 K）可能被转为小写（如 k），导致语法错误。同时需显式设置最大版本数（Max Versions）和数据过期时间（TTL）（多个版本多行）。

Step2：数据迁移

在完成目标端环境准备后，我们分阶段实施历史数据迁移与增量数据同步，确保业务平滑切换至 OBKV-HBase。

历史数据迁移

为高效迁移海量历史数据（单表达数十 TB），我们同时使用了 DataX 与 OMS，但需特别注意两者在数据格式上的关键差异：

• DataX 导入的数据 Q 值是带列簇，T 值是正数。
• 用 OMS 导入的 Q 值是不带列簇，T 值是负数。

增量数据同步

为确保切换期间数据零丢失，我们采用“OMS 增量同步 + 业务双写”双保险机制：

• HBase 开启复制，通过 OMS 增量同步。
• 通过业务程序双写保证数据实时同步。
• 逐步将流量从 HBase 切换到 OceanBase。

Step3：数据校验

由于 OBKV-HBase 属于 NoSQL 场景，OMS 在当前版本中尚未提供 KV 类型数据的全量一致性校验功能，我们结合业务实际，设计了一套多维度、可落地的数据校验方案，确保迁移后数据准确无误。

1. 行数校验：精确统计表行数。

HBase 端：使用 HBase 的 RowCounter 工具统计原表行数。命令：org.apache.hadoop.hbase.mapreduce.RowCounter 'table'。

OceanBase 端：使用 count 统计，获取行数并与 HBase 结果比对。

2. 三方数据对比：借助 Doris 实现内容级校验。

由于 OMS 暂时不支持进行 KV 场景下的全量校验，我们引入 Doris 作为临时比对中间层：

• 通过 DataX 将 HBase 数据同步至 OceanBase 和 Doris。
• 对比 HBase、OceanBase、Doris 三方的数据一致性。

3. 对关键业务字段进行抽样对比。

Step4：数据访问支持

在完成数据迁移与校验后，业务系统需通过标准接口访问 OBKV-HBase。我们发现 OBKV-HBase 不仅兼容 HBase 协议，还扩展了多项高级查询与操作能力，显著提升了开发效率与系统灵活性。

查询操作（Select）

• Filter：支持定义基于 AND 及 OR 构建的复杂的过滤条件，下压给 OBKV 服务端来做过滤。
• Limit：限制返回满足条件数据的条数。
• IN 等语法糖：IN 本质上是一种 Filter，提供对应接口方便业务编码。
• 简单聚合能力：提供 Sum/Min/Max/Avg/Count 的聚合语义接口，下压给 OBKV 服务端来做简单聚合。
• OrderBy：只支持基于主键以及索引序。
• 迭代器访问方式：提供类似迭代器的流式 Query 接口，适用于大批量结果集的流式获取以及处理场景，比如翻页场景。

数据操作

• Insert：支持单行/多行数据插入。
• Update：支持单行/多行数据更新，支持带 Filter 的条件更新。
• Delete：提供基于主键做数据的删除，支持单行/多行数据删除。
• Upsert（insertOrUpdate）：此接口的语义是，如果有对应记录存在，执行 Update 操作，如果不存在，执行 Insert 操作，此接口也支持单行/多行操作。

Step5：业务压测

为确保 OBKV-HBase 能够满足高并发生产环境要求，我们使用真实业务压测 OBKV 性能，达到 42w QPS，延迟仅为 1ms 左右，超出预期。

压测方法：

• 业务直接连接 OBServer 压测 OBKV 性能。
• 对比前期通过 ODP 压测的性能差异。
• 详细测试数据

我们部署 10 个 Pod 模拟业务客户端，分别通过 OCP 统一调度和通过 ODP 的方式进行多轮压测任务。如下分别是 OceanBase 数据库、OCP 模式、ODP 模式压测的数据记录。

OceanBase 数据库压测数据如下图所示。

OCP 模式压测数据如下图所示。

ODP 模式压测数据如下图所示。

需要说明的是，前期通过 ODP 压测，性能不佳，QPS 不到 2k，具体原因分析见后续问题总结。经过优化，直连 OBServer 压测 OBKV，QPS 达到 42W，延迟 1ms 左右，完全满足业务需求。

直连 OBServer 的测试结果让我们对 OceanBase 的性能有了充分的信心，为后续业务的正式切换奠定了基础。

OBKV 上线经验与问题总结：运维配置、数据校验

在 OBKV-HBase 的测试与上线过程中，我们积累了一系列关于监控集成、硬件配置、租户隔离及 CDC 同步等方面的实践经验，总结如下，供大家参考。

运维配置相关

1. 监控配置

为避免重复建设监控平台，我们将 OBKV 相关指标接入公司统一的自研监控系统：

• ODP 的 Prometheus 参数可直接使用默认配置，无需额外调整；
• 如需修改 ODP 监控参数，可通过 sys 租户登录集群，执行以下命令：

show proxyconfig like "%prometheus%";
alter proxyconfig set xxx = xxx;

2. 硬件配置

• 建议使用高性能磁盘，以保障高吞吐写入需求。
• 初期资源不要划太多，避免将单台服务器的全部 CPU/内存资源划给租户，以便预留弹性空间用于后续扩缩容及负载均衡。
• 单个节点的磁盘要大于日志流的大小，当单表很大时且未合理分区，其对应的日志流可能超过单节点磁盘容量，同时在集群扩容（如从 3-3-3 架构扩展至 6-6-6）时，副本迁移会因日志流到节点磁盘迁移失败而失败。

3. 租户配置

建议为 OBKV 创建独立租户，避免与 TP/AP 类 SQL 业务共享资源。

4. CDC 配置

在使用 OMS 或 CDC 进行数据同步时，需特别注意 HBase 动态列模型与 CDC 日志格式的兼容性问题。HBase 表的列是动态的（不同 Row 可含不同列），而 OceanBase 的 clog（提交日志）在记录变更时有两种模式。

• 全列模式（full）：记录整行所有列的值。
• 非全列模式：仅记录被更新的字段。

若源端写入为非全列，而目标端 CDC 期望全列日志，可能导致同步解析失败或数据不一致。

解决方法是启用 CDC 的脏数据跳过开关 skip_dirty_data=1，允许跳过全列校验，修改后重启实例生效：ALTER BINLOG INSTANCE y6op8d9rk1 SET EXTRA_OBCDC_CFG ='skip_dirty_data=1'。

5. 前缀检索用 setRowPrefixFilter

在早期调研阶段，我们比较担忧 OBKV-HBase 是否支持基于 RowKey 前缀的高效查询。经过深入查阅文档与测试验证，确认 OBKV-HBase 完全兼容 HBase 1.2+ 的原生 API，其中包括关键的前缀检索功能。可通过 Scan.setRowPrefixFilter(byte[] prefix) 方法实现高效的前缀扫描（Prefix Scan），具体如下图所示。

该接口会自动构造起始键（startRow）和终止键（stopRow），仅扫描匹配指定前缀的 RowKey 范围，避免全表扫描，显著提升查询效率。

数据校验问题

在从 HBase 迁移至 OBKV-HBase 的过程中，我们在数据校验过程中也遇到了 3 个关键问题。

问题 1：上下游数据条数校对问题

问题描述

使用 DataX 和 OMS 两种工具分别迁移同一张 HBase 表后，OBKV 中的数据行数均少于 HBase 源端，初步校验无法对齐。

原因分析

HBase 的数据模型特性导致 count 结果存在歧义。

• Region 分裂重叠：分裂过程中可能短暂产生重复 RowKey。
• 未提交数据/写入失败残留：部分写入未完成但日志已落盘。
• 多版本（Multi-Version）：同一 RowKey 多次写入生成多个时间戳版本，默认全部保留。
• TTL（Time-To-Live）未生效：过期数据尚未被清理，仍计入统计。

在上述场景下，HBase 的 RowCounter 统计的是所有版本 + 所有可见记录，而 OBKV 默认仅保留最新版本（若未显式配置），导致数量差异。

解决办法

• 统一迁移工具：避免混合使用 DataX 与 OMS，防止因时间戳、列格式处理逻辑不同引入偏差。
• 放弃基于快照（Snapshot）或 HFile 的 BulkLoad 方式，改用 queryType=scan 的流式读取，确保仅同步当前可见、已提交的最新版本数据。
• 开发专门的数据校验工具，对比源端和目标端的数据。

结果验证

通过调整迁移工具和校验方法，最终实现了 HBase 和 OBKV 数据的完全一致。

注意事项

• 建表语句大小写敏感：通过 DBeaver 等工具导出的建表语句中，K 关键字可能为小写（如 k = 'value'），需手动修正为大写，否则解析失败。
• 注意设置最大版本号和过期属性（多个版本多行）。

问题 2：20002 错误码

问题描述

• 客户端等待服务端一直没有回包，超时报错 20002，默认超时设置为 1.5 秒。
• 每次应用重启后，第一笔查询耗时比较高，后面查询耗时基本正常。

原因分析

根本原因是 scan.setCaching 参数配置不合理。

• scan.setCaching 参数用于限制每次 RPC 请求返回数据的行数。在 next() 迭代的过程中，底层通过多次 RPC 来拉取剩余数据。
• 不设置 scan.setCaching 参数时，默认一次 RPC 拉完一整个分区的数据，在等数据返回的过程中卡住，导致 RT 较高。

解决办法

将 scan.setCaching 参数的值设置为 100，控制每次 RPC 请求返回的最大行数：scan.setCaching(100);。设置后，第一次查询耗时降到了 300ms 左右，后续查询性能也得到显著提升。

问题 3：代理压测性能不佳

问题描述

通过 ODP 压测 OBKV-HBase，发现性能瓶颈明显，QPS 不到 2k。

原因分析

根本原因是 ODP 元数据缓存机制与数据库大小写敏感配置不匹配。

• OceanBase 集群启用了表名大小写敏感模式（lower_case_table_names = 0）。
• 而 ODP 默认行为在处理元数据请求时，未正确识别大小写敏感上下文，导致其无法有效缓存表结构信息。

每次查询均触发完整的元数据解析流程（包括向 sys 租户查询表定义），无法命中本地缓存。高频元数据查询成为性能瓶颈，严重拖累整体吞吐能力。

优化方案

• 通过设置 ODP 参数开启 ODP 表名小写兼容模式，在 sys 租户下执行：alter proxyconfig set pc_enable_lower_case_table_names=True。
• 再次压测结果：QPS 稳定在 1.2w 左右，性能提升 6 倍。

“一库多模、统一平台”，将大规模引入 OceanBase

通过近两年对 OceanBase 及其 OBKV-HBase 能力的深入实践，宝付支付成功完成了从传统 HBase 架构向新一代分布式数据库平台的平滑演进，取得了显著的技术与业务成效。

• 实现降本：HBase 独用资源转为 OceanBase 复用资源，不仅释放了数台服务器资源，还实现了 NoSQL 与 SQL 负载的统一承载，使硬件投入与运维成本大幅降低。
• 提升效率：QPS 提升到 42W，延迟降低到 1ms 左右，完全满足高并发支付场景的严苛 SLA 要求。
• 增强可用性：告别 MySQL 主从 + 异地备库等复杂架构，统一为 OceanBase 多副本强一致架构。系统具备自动故障切换（RTO < 8s）、数据零丢失（RPO = 0）能力，整体健壮性显著提升。
• 统一监控：方便对应用现有运行环境添加监控，大幅提升可观测性和监控易用性。

不仅如此，对于集团架构而言，也具有重大意义和价值。

其一，完成数据库架构全面升级。从 HBase 到 OceanBase，从“多套异构数据库”走向“一库多模、统一平台”，我们实现了数据库架构的全面升级，技术栈大幅收敛。

其二，夯实业务创新底座。高性能、高可用的数据服务为实时风控、智能 BI 等新场景的业务创新提供了更强大的数据支撑能力。

其三，奠定智能数据架构基础。为未来 AI 原生计算、HTAP 融合分析、跨地域多活等演进方向预留充分扩展空间。

其四，沉淀宝贵实践经验。形成涵盖迁移方案、数据校验、性能调优、故障排查的完整方法论，可复用于后续系统改造。

本次 OBKV-HBase 成功落地，离不开 OceanBase 团队在过去两年中提供的专业、及时、深度的技术支持，特别是老纪及其研发、技术支持团队。无论是早期功能定制、性能瓶颈攻关，还是生产上线保障，OceanBase 团队始终与我们并肩作战，为项目顺利推进提供了坚实保障。在此，谨代表宝付支付技术团队，向 OceanBase 团队在迁移过程中提供的技术支持致以诚挚感谢！

另外，基于当前 OceanBase 在宝付支付的成功落地经验，我们已将 OceanBase 纳入集团未来数据架构的核心，聚焦 AI 项目赋能、汇聚库建设、多活架构尝试、零售支付场景四大业务方向大规模引入。

1. AI 项目赋能：实现一体化 SQL+AI。

为响应公司对智能化转型的战略要求，我们将 AI 能力深度集成至数据库引擎层，推动从“被动查询”向“主动智能服务”升级。

• 原生支持 AI 混合计算：利用 OceanBase 内置的向量化执行引擎与 AI 函数能力，实现“SQL + AI”的混合计算。
• 探索智能化查询优化和数据处理。
• 提升数据分析和决策支持能力。

2. 汇聚库建设：实现一体化 TP+AP。

当前集团存在 1000+ MySQL 实例及多套异构数据系统，导致跨库分析、实时统计、经营报表等场景面临巨大挑战，OceanBase 的 HTAP 一体化架构为此提供了根本性解决方案。我们将逐步把核心业务库、汇聚库、宽表等迁移至 OceanBase 并扩大线上使用规模，使用一套集群同时承载 TP 写入与 AP 分析，构建统一的数据平台，简化数据链路，提升数据治理和数据服务能力。

3. 多活架构尝试，实现系统稳定。

苦于 MySQL 双活架构带来的问题，我们将尝试业务多活要求，满足高可用业务需求。依托 OceanBase 原生分布式多副本与 Paxos 协议能力，构建轻量级、高可用、跨机房、跨地域的多活架构，提升系统容灾能力和业务连续性。

4. 零售支付场景深化。

随着内部零售支付业务越来越多，我们将在其他零售支付业务场景推广使用 OceanBase。并持续优化 OceanBase 压测记录，完善性能基线。我们计划基于真实业务负载开展常态化压测，建立 QPS、延迟、资源消耗等关键指标的基准模型。

此外，探索更多 OceanBase 在支付行业的应用场景，充分发挥 OceanBase 的 HTAP 与多模能力。

数据库的升级不仅是技术的迭代，更是业务持续创新与稳健运行的基石。