冷数据归档（历史库），成本与性能如何兼得？| OceanBase应用实践

随着数据量的迅猛增长，企业和组织在数据库管理方面遭遇的挑战愈发凸显。数据库性能逐渐下滑、存储成本节节攀升，以及数据运维复杂性的增加，这些挑战使得DBA和开发者在数据管理上面临更大的压力。

为了应对这些挑战，对数据生命周期实施更为细致的管理变得至关重要。这包括从在线处理到近线存储，再到归档整理，直至数据销毁的整个生命周期管理。在这一系列阶段中，近线阶段和归档阶段的历史库管理显得尤为重要。本文将深入探讨如何对历史库进行现代化架构升级，并重点聚焦于OceanBase如何帮助企业优化数据库历史库管理。

一、构建满足现代需求的数据库

历史数据存储在近线和归档阶段都发挥着重要作用。在归档阶段，可采用数据库或离线文件的形式。而对于仍需进行少量查询的归档数据，则通常选择历史库方案。历史库方案实际上是实现冷热数据分离的策略，通过减轻在线库负担来提升其性能。历史库的冷数据通常具有低频访问的特点，所以可以选择磁盘空间较大、CPU 配置较低的机型，以实现成本节约的目的。

历史库的引入给数据库管理系统带来了新的挑战，我们对此的理解主要来自于用户对数据管理解决方案的迫切期待。在与用户的交流中，我们发现许多用户迫切需要一种能够有效处理大规模历史数据的解决方案，同时希望在降低成本的同时不影响性能和数据可用性。这些反馈深刻地影响了我们对历史库的理解。因此，我们期望历史库能够具备以下特点：

○ 大容量的存储空间，支持大量数据的存储和在线库数据高效持续导入。

○ 具备良好的可扩展性，能够处理不断增加的数据量而无需调整存储架构。

○ 提供更低的存储成本，以更少的磁盘空间和更经济的存储介质存储更多数据。

○ 提供一定的查询能力，支持高效的少量事务型查询，同时也能够支持高效的分析型查询。

○ 对应用和在线库保持相同的访问接口，降低应用复杂度。

当面对这些需求时，OceanBase 成为一种天然的选择。其具备良好的单机分布式扩展能力和 HTAP 混合负载处理能力，使其能够高效地支持业务系统的在线库和历史库场景。更为重要的是，OceanBase 在满足业务需求的同时，能够至少降低一半的存储成本。据部分客户反馈，将业务历史库从其他数据库迁移至 OceanBase 后，存储成本可降低 80%左右，这也是许多用户在历史库场景选择 OceanBase 的主要原因之一。

1718801657

图 1：OceanBase 历史库产品架构

随着历史库产品架构的设计，我们进一步思考历史库的存储架构问题。

首先，关于历史库的数据库架构是否需要与在线库保持一致的问题，我们认为不需要。在线库可能出于数据规模和性能的需要，采取分库分表等架构，但历史库的性能要求通常较低。分库分表架构对数据库的部署运维、备份恢复都带来额外的成本。特别是采用 OceanBase 作为历史库时，单表轻松承载几十 TB 的数据规模，即使数据规模很大也可以采用分区表。

其次，关于历史库是否应该支持数据更新的问题，技术上是可行的，历史库可以支持更新，也可以设定为只读。然而，从历史库整体成本的角度考虑，我们建议尽量采用只读历史库的方案。只读历史库随机读写更少，可以使用更廉价的存储硬件，如 SATA 盘而不是 SSD。此外，只读历史库也降低了历史库自身的备份成本，只需要维护一份备份副本。

最后，对于数据归档应尽可能减少对在线库的影响的问题，这是非常重要的。在线库是企业业务持续稳定运行的关键，在数据规模较大的场景下，大批量数据的读取、计算、删除会给在线库造成压力，因此数据归档过程必须能够保障在线库的稳定性。

二、OceanBase 数据归档的核心能力

（一）冷热数据分离，提升在线库性能

通常情况下，一部分业务数据在一段时间后就很少被访问或者不再被访问（我们称之为“冷”数据）。解决思路是将访问频率较低的“冷”数据归档到历史库中，而在线库则只保留最近某一段时间的数据。

传统的数据归档方式常常需要耗费大量的时间和人力，并且存在操作错误、数据丢失等风险。此外，手动归档操作的繁琐性也限制了数据管理的效率和工作的灵活性。面对这些问题，ODC 从 4.2.0 版本引入了数据归档功能，旨在解决数据管理中的难题，提高工作效率和数据安全性。下面，我们将使用 ODC 的数据归档功能来实现这一冷热数据分离的过程：

（二）新建「数据归档」工单

在 ODC 中，点击「工单」-> 「新建工单」-> 「数据归档」，进入数据归档工单的创建页，填写工单详情。这里我们配置了 tb_order 表从在线库到历史库的归档任务，勾选了归档完成后清理源端已归档数据。注意这里使用了变量 archive_date，其值设置为当前时间往前偏移 1 年，通过在过滤条件中引用变量的方式，可以实现每次执行归档任务都归档 1 年前的数据。

1718801804

图 2：新建数据归档任务

ODC 数据归档支持多种执行调度策略，可以立即执行、指定时间执行，也可以周期执行。还支持配置结构同步、数据插入策略和限流策略。结构同步时可根据需要选择是否同步分区和索引，因为历史库可能会和在线库有不同的分区设计，历史库和在线库的查询需求也不一样也可以通过更少的索引进一步降低存储成本。

1718801857

图 3：数据归档任务设置

点击新建任务，会显示归档 SQL 的预览，进一步确认需要归档的数据范围。

1718801891

图 4：数据归档 SQL 预览

可以看到，通过 ODC 数据归档任务，只需简单配置，就可以成功地将冷数据从在线库归档到了历史库，实现了在线库的冷热数据分离。那么我们完成这个过程就足够么，如果我们因为业务变动或误操作，需要将已归档到历史库的数据恢复到在线库又该如何处理呢？新建一个反向归档任务不可谓不行，但我们既要花费精力重新配置新任务，又要担心配置错误引入问题。ODC 已经为用户考虑到了这一点，提供了一键回滚功能。我们以刚才的任务为例，现在需要将已经归档的数据回滚到在线库，我们仅需要在执行记录页，点击数据归档任务记录后的回滚按钮，即可发起归档回滚任务。

1718801937

图 5：数据归档执行过程

（三）过期数据清理，降低存储成本

ODC 的数据归档功能来实现在线库的冷热数据分离，将冷数据迁移到历史库，以达到降低成本、提高效率的目的。然而，你可能会问，历史库难道不需要成本吗？地主家也没有余粮啊。

实际上，一旦业务的冷数据进入历史库，它并不一定需要永久保留。在经过一段时间后，部分冷数据可能会处于“过期”状态，完全不会再被使用，比如日志型数据。如果能及时清理掉这些过期数据，那么我们的存储成本会进一步降低。为了解决这个问题，ODC 提供了数据清理功能定期清理数据库中的过期数据，从而进一步优化存储资源的利用。

（四）新建「数据清理」工单

在 ODC 中，点击「工单」-> 「新建工单」-> 「数据清理」，进入数据清理工单的创建页，看到这个页面是不是非常熟悉，数据清理工单的配置与数据归档工单基本一致，这里我们不再赘述，直接创建一个周期性清理的工单。ODC 数据清理也支持联动历史库做清理前的数据校验。

1718801997

图 6：新建数据清理任务

（五）端到端的数据归档链路

截止 ODC v4.3.0 版本，ODC 数据归档支持以下链路：

○ OceanBase MySQL 在线库到 OceanBase MySQL 历史库。

○ OceanBase Oracle 在线库到 OceanBase Oracle 历史库。

○ MySQL 在线库到 MySQL 历史库。

○ MySQL 在线库到 OceanBase MySQL 历史库。

ODC 的产品形态包括：

○ 私有云 WEB 版，私有云版本既可以连接 OceanBase 社区版、企业版，也支持连接 OB Cloud 云数据库。

○ OB Cloud 云服务，ODC 数据归档能力同时也在 OB Cloud 云控制台提供，购买 OB Cloud 云数据库的用户可以直接使用。

三、OceanBase 数据归档的核心技术

为了实现数据归档过程的稳定、快速、准确、适合大规模数据场景，ODC 数据归档引入了多维度限流、分片并行、数据校验、断点恢复等技术。以下为数据归档的技术架构，主要包含三个组件：

○ Worker（任务执行器，负责执行任务的具体逻辑）

○ MetaDB（用于存储任务的元数据信息，采用 OceanBase 来保证高可用）

○ ODC Console（用户操作的入口，用于任务的发布与管理）。

1718802126

图 7：数据归档技术架构

（一）多维度限流机制，保障在线库稳定运行

ODC 数据归档采用了主动限流和被动限流的双重策略，以最大程度保障在线库的性能稳定性。

主动限流涵盖了流量限制和行数限制，针对读操作和写操作进行计算和限制。流量限制的目的是避免过大的流量对网卡造成过载或过快的速度导致 CPU 和 IO 资源耗尽。数据行数限制的目的是防止产生过多的 RPS，可能会对 DRC 产生影响。

被动限流是在任务执行过程中，ODC 持续监控数据源的 CPU 和内存占用情况。当 CPU 和内存达到预设的阈值时，会让任务执行器进入休眠状态，直到监控指标满足任务执行标准后再继续执行。这种策略可以有效控制资源的使用，确保任务执行在合适的条件下进行。

（二）分片并行，实现高性能归档

数据规模越来越大，数据归档过程需要尽可能高效。为了提升数据归档性能，我们在对目标表进行处理时采用了基于主键的分片策略。这样可以将需要归档的数据拆分成多个较小的子任务，并交由多个线程并发处理。通过并行处理，我们能够更高效地完成数据归档操作。

（三）先校验再删除，确保历史数据可信

数据库是一致性的最终保障，即便是历史库，也必须保障历史数据的有效性和完整性。当前 ODC 的数据归档任务在清理在线库数据时还提供了一层一致性校验保障，在删除数据前，ODC 会拉取在线库和历史库的数据进行对比，只有满足一致性策略的数据才会被允许删除，确保不会出现数据丢失的风险。当前数据一致性校验策略是通过全量字段等值比较，只有当在线库和历史库数据完全一致时，ODC 才会允许并删除在线库的数据。类似于数据迁移，数据删除也会进行防导爆控制，以保证系统的稳定性。

（四）断点恢复，满足大数据规模场景诉求

在大数据规模场景，当任务出现意外停机时或需要手动中止任务时，重新开始任务的成本通常难以接受，所以必须能够满足大规模数据量场景下归档可靠性。

ODC 数据归档提供了断点恢复能力，它可以从最近的断点记录处快速恢复任务。实现原理基于归档表的分片处理，每个子任务都会保留一个滑动窗口，每个事务行组在生成后都会被放到滑动窗口中，由于子任务的数据读取线程是单线程，所以这些事务行组在滑动窗口的顺序是和生成的顺序一致；每个事务行组在消费完成之后，会被标记成功，此时如果滑动窗口最开头的任务是完成的，那么会进行一次窗口“移动”，直到滑动窗口最前面的任务是未完成的状态。每次随着窗口移动，移出去的那个事务行组的最后一行就成为了一个断点。对于每一个运行中的子任务，它的断点信息都会被定期汇报到数据库中。当这个任务由于某种原因退出时，其他节点可以继续跑这个任务，在重跑任务时会从数据库中获取到每个子任务的断点信息，从断点的位置开始继续运行。对于子任务生成线程，也有类似的断点续传机制。

四、真实应用场景下的历史库案例

目前已有超过 100 家用户通过 OceanBase 进行历史库架构升级，包括支付宝、携程、怪兽充电、网商银行等客户，取得了显著成效。

支付宝通过 OceanBase 进行历史库架构升级，实现 PB 级数据归档和横向无限扩展，整体存储成本下降 1/3，总体数据存储成本减少 80%。截至目前，支付宝已建立了 20 多个历史库集群，涵盖交易、支付、充值、会员、账务等几乎所有核心业务，总数据量达到 95 PB，每月新增 3 PB。其中，最大的交易支付集群组数据量达 15 PB，每日数据增量可达 50 TB。这项历史库升级为支付宝带来了显著收益：

○ 成本显著降低：历史库采用成本更低的 SATA 盘来搭建 OceanBase 数据库集群，单位空间磁盘成本降低到线上机器的 30%。同时，使用更高压缩比的 zstd 压缩算法，总体成本下降 80%。如果线上数据库是 MySQL、Oracle 等传统数据库，成本降低更为显著，因为 OceanBase 的数据编码、压缩及 LSM-Tree 存储架构使存储成本仅为传统数据库的三分之一。

○ 弹性伸缩降低运维成本：历史库采用 OceanBase 三副本架构，每个 zone 中有多个 OBServer，通过分区将数据分散到多个 unit。OceanBase 具备业务无感知的弹性伸缩能力，可以通过扩容节点增加容量和性能。这意味着历史库不再受限于磁盘大小，少数集群即可涵盖所有业务历史库，降低了运维成本。

○ 数据强一致和快速故障修复：数据迁移相当于数据归档及逻辑备份，对于需要审计和历史数据查询的金融业务来说，数据一致性至关重要。OceanBase 底层使用 Paxos 一致性算法，当单台 OBServer 宕机时，可以在 30 秒内快速恢复并保证数据强一致，减少对线上查询及归档任务的影响。

此外，网商银行通过 OceanBase 历史库方案节省超过 1000 万的硬件成本。携程通过 OceanBase 历史库方案，相比之前使用 MySQL 的方案降低 85% 的存储成本。怪兽充电将历史库迁移到 OceanBase 后，存储成本下降 71%。