本篇内容为「OceanBase 布道师计划」优秀文章之一，作者 宝贝笑了。作者在文章中分享了客如云智享版基于 OB Cloud 的报表分区化改造实践。
客如云成立于 2021 年，专注于为餐饮、零售等行业提供前沿的数智化、开放化、生态化 SaaS 解决方案，已累计服务餐饮商家 181 万家，覆盖 C 端消费者超过 1 亿人。
一、概述
（一）背景
在过去 2-3 年中，客如云的 KPOS 产品取得了令人瞩目的成绩，商户基数和订单量都实现了数倍增长，这一业绩印证了我们产品的市场吸引力和业务模式的成功。然而，随着越来越多的大型连锁商户（KA 商户）加入客如云商家平台，我们面临了前所未有的挑战。特别是为 KA 商户提供数据报表服务时，我们发现原有的解决方案在处理大型报表和跨越长时间范围的查询场景时存在性能瓶颈。
顺应业务增长的需求，技术团队迅速反应，深入剖析了数据库面临的性能挑战，并采取了一系列切实有效的技术优化措施，确保即使在数据量剧增的情况下也能保持流畅的查询体验。我们的优化措施主要集中在以下几个方面：
👉 数据库性能：我们对数据库架构进行了全面优化，包括引入并行技术、优化索引、以及实施适当的数据拆分策略、查询逻辑优化等，减少了数据库负载，并提高了查询效率和系统的扩展能力。
👉 异步处理：对于数据量巨大的报表，我们采用异步生成并通过后台任务队列处理，允许用户在报表准备就绪后再查看，极大提升了前端体验。
👉 报表预生成：我们实现了对常用报表的预生成和定期更新机制，确保用户可以快速获取最常查看的报表数据。
经过技术层面的努力优化，我们的报表系统现已能够稳定支持日单量近千万的业务需求。但我们团队意识到，随着业务不断发展壮大，技术挑战也会不断涌现，因此我们将持续投资技术创新和性能提升，为 KA 商户提供无与伦比的服务体验。
业务层面临的问题，也对运维团队提出了前所未有的挑战。在技术运维方面，我们面临两个主要的瓶颈：数据库服务器的扩容受限，以及大表变更困难。
数据库服务器的扩容问题表现在两个方面：物理资源已到达上限和扩容过程中的服务断连风险。由于现有硬件资源的限制，对数据库服务器进行垂直扩展（增强单个服务器的性能）已到达瓶颈，而水平扩展（增加更多服务器）也受到了当前数据库部署架构的限制。
随着数据量的飞速增加，数据库中出现了大量的大表。大表的变更，无论是结构调整还是数据迁移，都变得异常复杂和耗时。每次变更都需要在保持高可用性和最小化影响的前提下进行，对运维团队的技能和资源配置提出了巨大挑战。变更操作通常涉及详细的计划，以及在执行期间实施详尽的监控以确保对商户无感操作。
（二）现状
1、业务情况
应用链接数据库情况如下图所示：
高峰期数据库 QPS\TPS 如下图所示：
2、数据库部署架构
集群为双机房部署，分别在张家口 A 及 B 区，主可用区位于 A 区，提供可读可写能力，备可用区位于 B 区，仅提供查询能力；读写应用一般配置主地址，只读应用配置只读地址。
3、业务查询性能
智享版报表库 70% 的流量还是业务写，QPS 和 TPS 都比较高，少部分商户查询都是 AP 场景。点查基本上没有问题，对于范围查询一般会查询一天、一周、一月的数据，通常一周内的数据查询没有性能问题，对于大 KA 查询一月的数据就会比较慢，通常要 5-10s。
4、目前存在的问题
OceanBase 3.2 版本目前存在的问题有以下两点：
👉 部分 SQL 执行计划走偏；
👉 大表索引变更速度非常慢。
（三）技术目标
1、性能方面
目前最大查询时间周期为一个月，并且在 1000 家门店内耗时 5 秒以内，我们的目标是将查询时间缩短至 2 秒以内。
2、稳定性方面
目前我们使用的单台顶配 104 核 CPU 的服务器，其最高使用率为 50% 左右。即使商户数量翻倍，我们希望数据库的 CPU 使用率也不超过 65%。
（四）分区化改造
为什么选择分区化改造？当前智享版报表的存储层现状是 OceanBase 1:1:1 104 核 600GB，最大的表已经超过 300GB，都是单表。
分区化改造的目的是为了提高查询性能，并且能够更好地支撑大型 KA 商户的需求。以下是为何要进行分区化改造的原因：
1、提升查询效率
对于单表查询来说，随着数据量的增加，查询的性能可能会下降。而通过分区化改造，可以将数据分散存储在多个分区中，每个分区只包含部分数据，从而减小查询的数据量，提高查询效率。
2、优化资源利用
分区化改造可以将数据分布在多个分区中，使查询可以在分区级别上进行并行处理，从而充分利用多核 CPU 和其它硬件资源，提高系统的整体性能。
3、支持增量数据处理
对于大型 KA 商户，数据的更新频率可能很高，而分区化改造可以支持增量数据的处理。通过将数据按照时间或其他规则进行分区，可以方便地实现增量数据的导入和查询，减少全表扫描的开销。
4、优化维护和备份
分区化改造可以将数据按照逻辑或物理上的规则进行分区，使得维护和备份变得更加灵活和高效。例如，可以对热点数据进行单独的维护和备份，而对于历史数据可以进行压缩存储或归档，从而节省存储空间和维护成本。同时分区化改造后对于大表 DDL 速度也能明显提升 30% 以上。
综上所述，通过对门店进行分区化改造，可以提升查询性能，优化资源利用，支持增量数据处理，以及优化维护和备份。这样可以更好地满足大型 KA 商户的需求，并提升系统的整体性能和稳定性。
（五）关于技术术语
更多术语请访问：
https://www.oceanbase.com/docs/enterprise-oceanbase-database-cn-10000000000943758
二、方案选择
（一） 部署方案选择
部署方案通常有三种，多机房部署、双机房部署、单机房部署。
1、多机房部署
OB Cloud 云数据库多机房部署指将三个节点部署在三个不同可用区，实现跨可用区容灾。
每个节点均为全能型副本，其中一个主副本提供读写服务，两个备副本提供只读服务。当主副本发生故障时，备副本将会升为主副本继续提供读写服务。
对性能和多机房可用性有着更高要求的客户建议选择多机房部署方案。
2、双机房部署
OB Cloud 云数据库双机房部署：
👉 将两个节点部署在两个可用区，其中一个节点作为主副本提供读写服务，另外一个备节点可以提供只读服务。
👉 在第三个可用区部署一个日志节点，该节点仅用于日志同步，不包含数据副本，不对外提供读写服务，并且日志节点对用户不可见。
双机房部署仍具备机房级容灾能力，与多机房部署相比，在性价比上有较大提升。
3、单机房部署
OB Cloud 云数据库单机房部署将所有节点位于同一可用区，具备主机级别故障容灾能力。此外单机房部署还具备如下优点：
👉 两个全能型副本同时提供读写能力，为您提供更高性能的数据库读写服务。
👉 单机房部署的写请求无需进行跨机房同步，同机房内写请求的数据同步可以降低时延。
单机房部署的日志节点对用户不可见。
4、三种部署方案的区别
说明：双机房(2F1L) 副本方案中的日志副本对用户不可见，因此购买了 3 节点，实际上系统中仅 2 个节点可见。
（二）节点分布选择
节点分布一般是 1-1-1、2-2-2、3-3-3，总节点数一般是 3 的倍数。
结合上一节的知识，如果节点分布是 1-1-1，那么服务器数量就为 3 台，2-2-2 服务器数量为 6 台，3-3-3 为 9 台。
上文中讲到客如云智享版报表当前的部署方案是双机房 1-1-1，单节点配置为 104C600G，高峰期主节点 CPU 使用率为 43% 。
那么接下来新的分区集群需要综合考虑负载、性能、存储、成本、扩展性等方面因素来选择适合的部署方案及节点分布，初期可选的方案主要是如下两种：
1、3-3-3 双机房 30C180G
双机房(可用区)部署，每个可用区 3 台机器，单台机器是30C180GB，总共 9 个节点，主可用区位于 A、B 两个可用区，C 可用区为日志型副本。
2、2-2-2 多机房 30C180G
三机房(可用区)部署，每个可用区 2 台机器，单台机器是 30C180GB，总共 6 个节点，主可用区位于 A、B 二个可用区，A、B、C 都为全能型副本。
（三）主可用区选择
主可用区一般有三种选择：
1、主可用区分布在 3 个可用区
主副本均匀分布在所有机器上，适合批处理场景，希望尽快跑完，不关注某一个 SQL 的执行时间，期望让整体任务尽快完成。
2、主可用区分布在 2 个可用区
主副本均匀分布到 Zone1 和 Zone2，Zone3 均是从副本，适合城市容灾方案，将业务汇聚到距离较近的城市，距离较远的城市只承担从副本的角色（只读）。
3、主可用区分布在1个可用区
主副本只在 Zone1 存在，Zone2 和 Zone3 均是从副本只读，适合对延迟敏感的业务，业务量不大，不超过一台机器的处理能力，可以尽量避免跨服务器访问，从而降低时延。
最终客如云智享版报表选择了折中方案，将主可用区分布在了 2 个可用区，由 4 台 30C 的机器来承担写入。
（四）分区数选择
选择分区数时需要考虑多方面的因素：
1、数据量
大型表通常需要分区以提升管理和查询性能。如果你预计表将存储大量数据，更多的分区可以帮助减少单个分区的大小，提升查询响应速度和数据管理效率。不过，太多的分区也可能增加管理的复杂性和开销。
2、数据增长
评估数据随时间的增长情况。如果数据量将迅速增长，规划更多的分区可以为未来的数据增长留出空间，减少以后重新分区的需要。通常可根据 2-3 年的业务数据增长量来评估机器数量，进而来定义分区数量。
3、查询模式
考虑应用程序主要的查询模式和使用的分区键。如果查询通常在特定的分区键范围内进行，优化这些分区的数量和大小可以提高性能。
4、资源利用与性能
分区可以帮助更有效地使用服务器资源，例如，CPU 和 IO 操作可以在多个分区间并行执行。需要考虑服务器的资源情况和应用程序的性能需求，以选择合适的分区数。
5、分区键选择
在 OceanBase 系统中，选择合适的分区键至关重要，可以大幅度影响整个数据库表的性能和扩展性。下面是选择分区键时应考虑的一些关键因素：
🚩 查询性能：
分区键应该根据最常见的查询方式来选择。如果某个键经常用于 WHERE 从句中，那么使用这个键作为分区键可以提升查询性能。
🚩 数据分布：
选择能够均匀分布数据的分区键可以避免数据热点，并最大化分区间的负载平衡。
🚩 数据增长：
分区键也可以基于数据增长的模式选择，例如，如果数据增长是顺序的，则时间戳或某种顺序递增的键可能是一个好选择。
🚩 维护性和扩展性
使用分区键可以简化数据管理，例如数据归档和清理。另外，分区键选择应当支持未来的表水平扩展。
🚩 业务逻辑
分区键通常与业务逻辑紧密相关，如业务线、地区、用户 ID 等，这样能够更高效地实现针对特定业务的操作。
🚩 写操作
如果系统存在大量的写操作，则选择可以均匀分配这些操作的分区键，以优化写入性能并减少单个分区上的写入压力。
🚩 事务和并发
分区可以增加数据库的并发度，所以在预期较高并发量的表上使用合适的分区键，可以有效减轻锁竞争。
具体选择哪个列作为分区键没有硬性规定，它依赖于你的具体应用场景。但是通常情况下，以下列可能是不错的分区键候选：
👉 时间戳或日期字段：对于日志或历史数据，时间是一个自然的分区维度。这也方便数据归档和分片。
👉 业务属性：如客户 ID、地区代码或者产品种类等，可以根据业务需求进行数据的快速访问和维护。
👉 唯一属性：UUID、用户 ID 等在数据库中能均匀分布的唯一标识。
在选择分区键后，应该对其进行测试以验证是否能达到预期的性能和扩展目标。可以通过对比测试不同的分区键对查询速度、写入吞吐量以及系统的管理维护等方面的影响来做出选择。
三、方案上线
（一）参数调优
根据实际的业务场景进行参数适当调整，可降低 CPU 的负载。
（二）数据迁移
数据迁移使用 OMS 迁移工具，支持的源端数据库类型如下：
（三）数据双写
为进一步保证业务的稳定性，满足三板斧要求，同时让整个切换过程更平滑，因此选择了数据双写。数据双写主要是通过应用层实现在数据库的源库及目标库同时写入，通过事务来保持数据一致性，同时通过后台数据核对任务来保证数据库源端和目标端的数据一致性。
（四）分阶段切换及回滚
整个上线切换包含多个阶段，主要包含预发查询切流、线上查询切流、预发写切流、线上写切流等。
阶段 1：业务读功能验证
新老库采用 OMS 数据同步工具保持实时同步(延迟为秒级)，线上报表应用读数据切换到新库。如遇 SQL 问题可在 1 分钟内回切到老库（业务代码中已进行了 SQL 异常埋点，SQL 问题可第一时间感知）。
⚠ 风险：低，可 1 分钟内回切老库，且可按机器灰度。
阶段 2：数据生产写功能验证
在阶段 1 的基础上，关闭 OMS 数据同步，线上报表读数据切换到老库，数据生产采用双写，验证新库数据写入性能和正确性。（写主链路在老库，新库为弱依赖，新库写入失败不会影响老库）。
⚠ 风险：低，可 1 分钟内新库写断流，新库写入失败不会影响老库，但双写会加重应用负载，需提前应用扩容。
阶段 3：业务读切换到新库
在阶段 2 的基础上，线上报表读数据分批切换到新库。老库不提供读。
⚠ 风险：低，可 1 分钟内查询回切老库，且可按机器灰度。
阶段 4：数据生产写切换到新库
在阶段 3 的基础上，写入主链路切换至新库，双写旧库备份（写主链路在新库，新库为强依赖，新库写入失败会影响老库）。
⚠ 风险：较高，老库只做备份用，新库写入或查询失败会影响业务，但支持 5 分钟内回切。
阶段 5：老库断流
数据生产改为只写新库，旧库写入断流。
⚠ 风险：最高，老库一旦断流后，无法再切回，新库有问题只能解决问题。
四、收益
1、执行性能提升明显
汇总 SQL 耗时 3.31s，改造前 9.27s；多门店 IN 汇总耗时 1.9s，改造前 3.2s（第一次请求 3.2，改造前 9.2s）。
2、索引走偏问题明显好转
新分区库索引默认都是分区键+其他+时间的方式建 Local 索引，相比老库，新分区库执行计划走偏下降 80% 以上。
3、大表索引变更速度明显提升
分区表后，增加索引默认是分区并行执行，相比单表速度提升 50% 以上，但需注意对实例负载的影响。
五、遇到的问题
1、迁移数据时 OMS 增量阶段写入慢
业务中存在正常 DELETE 操作，OMS 在解析 SQL 时会将一条 SQL 拆分为多条，导致增量阶段耗时比较久。
2、SQL 中不带分区键的情况
在老库中，SQL 中没有强制要求必须带分区键，但是在新库中却是必须，通过 SQL 超时工具，及时发现 SQL 超时情况，推进业务解决。
3、代码中指定索引
由于 OB Cloud 数据库中存在索引走偏的情况，在老库中部分查询场景 SQL 代码中指定了索引，因此在新分区实例尽量不更改索引名，否则可能导致全表扫描。
4、自定义报表 Join 问题
自定义报表使用了 NESTED-LOOP JOIN，而在大表时执行速度会非常慢。使用了 NESTED-LOOP JOIN，且索引走偏 ，解决办法：添加 Hint，/*+ use_hash(wide_promo wo)*/ 使用 Hash Join。
由于表都是按门店分区的，SQL 中查询通常会指定品牌下多个门店，导致 SQL 执行需要路由到多个节点来执行，增加跨机开销（RT 平均耗时为单机耗时三倍）。
📕 解决方案：增加表组，将一组表下同一分区主副本迁移到一个节点上，减少跨机执行，RT 整体维持在单机执行同一级别。
六、后期扩容
1、水平扩容
扩容基本步骤：
👉 为每个 Zone 添加新的物理机器；
👉 在每台新添加的机器上启动 OBServer 服务；
👉 在每台新添加的机器上执行 alter system add server 命令，将 OBServer 服务添加到集群中。
👉 执行 alter resource pooll <pool name>unit num =<bigger number>命令，扩充资源池中的 unit 个数。
👉 OceanBase 自动执行“rebalance”过程，将部分数据从旧的 Unit 在线复制到新的 Unit 上，此过程可能会花费一定时间，具体时间取决于数据量。
👉 每个分区的数据复制完成后，OceanBase 自动将服务切换到新的 Unit 上，并删除旧 Unit 中分区上的数据。
2、垂直扩容（节点规格升配）
扩容基本步骤：
👉 为每个 Zone 增加 2 台 62C 的物理机器。
👉 在每台新添加的机器上启动 OBServer 服务。
👉 在每台新添加的机器上执行 alter system add server 命令，将 OBServer 服务添加到集群中。
👉 迁移 Unit 到新的机器上，迁移完成后直接替换老的机器（一个 Zone 一个 Zone 操作，中间会有切主动作，在执行迁移任务的节点不会有主副本提供服务）。
3、可用区打散
扩容基本步骤：
👉 执行命令将主可用区分布到三个Zone（zone1,zone2,zone3），ALTER TENANT
primary_zone='zone1,zone2,zone3';
👉 OceanBase 自动执行“rebalance”过程，将主副本迁移到三个 Zone（可以阿里云控制台白屏操作，例：原主可用区位 A、B 两个可用区，现将主可用区打散到 A、B、C 三个可用区，会根据均衡规则将 A、B 可用区上的部分主副本切到 C 可用区，对于需要切主的这部分副本会有瞬时的抖动）。
4、对比
七、总结
随着分区化改造的上线，客如云智享版报表的大部分查询性能问题得到了有效缓解。分区化集群提供了持续的线性扩展方案，能够满足未来 3-5 年内业务快速增长的需求。然而，目前仍有部分大客户的查询需求无法完全满足。因此，未来我们需要继续优化，并在 OceanBase 4.x 的主要版本及业务层面上探索更多的创新与成果。
评委有话说
资深 IT 媒体人、《老鱼笔记》主理人老鱼：文章介绍了客如云智享版报表分区化改造的背景、现状、技术目标及方案选择等，通过分区化改造提升了查询性能、优化了资源利用，详细阐述了改造过程中的参数调优、数据迁移等关键环节。此外，文章还总结了改造的收益及遇到的问题，并展望了后期扩容方案。
墨天轮社区负责人章芋文：文章提供了一个深入的实践案例，展示了客如云智享版报表在面对业务增长和数据量激增时，如何通过 OceanBase 数据库的分区化改造来提升性能和稳定性。作者详细阐述了改造的背景、目标、技术方案选择、实施过程以及所遇到的挑战和解决方案，体现了对数据库性能优化和分布式系统管理的深刻理解。文章中对于分区化改造的策略选择、参数调优、数据迁移和双写策略的讨论，特别强调了在实际操作中对细节的关注和技术团队对复杂问题的应对能力。此外，还分享了改造后的性能提升和未来扩容计划，为同行业者在处理类似问题时提供了宝贵的参考和启示。
CSDN 资讯主编、《新程序员》特约专栏记者屠敏：文章提供了一个深入的实践案例，展示了客如云智享版报表在面对业务增长和数据量激增时，如何通过 OceanBase 数据库的分区化改造来提升性能和稳定性。作者详细阐述了改造的背景、目标、技术方案选择、实施过程以及所遇到的挑战和解决方案，体现了对数据库性能优化和分布式系统管理的深刻理解。文章中对于分区化改造的策略选择、参数调优、数据迁移和双写策略的讨论，特别强调了在实际操作中对细节的关注和技术团队对复杂问题的应对能力。此外，还分享了改造后的性能提升和未来扩容计划，为同行业者在处理类似问题时提供了宝贵的参考和启示。
OceanBase 开源生态总监、OceanBase 开源社区负责人封仲淹：详细的介绍了客如云从原来的 MySQL 体系升级到 OceanBase 体系，整体内容比较丰满，流程和详实，并穿插了大量用户优化的经验，让用户阅读能够收获更多的多机房、扩缩容、 性能优化等实战经验。全文介绍客如云智享版报表分区化改造实践，包括背景、现状、技术目标、方案选择、方案上线、收益、遇到的问题、后期扩容和总结等内容。
2025 OceanBase 布道师计划
期待你的分享 ❤❤❤
