项目背景
某保险公司是国内领先的综合性保险集团, 其FF系统是客户一级核心系统，底层使用的是传统Oracle数据库，随着业务飞速发展，单库单表的集中式数据库已经无法满足业务的容量诉求，分布式架构改造迫在眉睫。客户高层在新的财年大胆决策，决定将底层存储由原来集中式数据库Oracle迁移到分布式数据库OceanBase，以获得分布式弹性扩缩容能力和跨机房高可用容灾能力。 同时客户要求对FF系统做一次大的改造，底层数据模型也需要做相应调整，旧的Oracle 和 新的OceanBase数据库在schemal上发生变化（比如原来的单表拆分成多张维度表），老数据需要按新模型进行复杂ETL转换才能生成新模型数据。我们平常使用数据平迁工具OMS不能实现此功能，需要一种新的数据迁移方案来满足客户不停机重构系统并平滑切换的要求。
数据迁移方案
因为数据模型发生了转换，数据迁移分成两个部分：存量数据 和 增量数据。 以ds=T时间为界，T之前的存量数据，可以在MC（MaxComputer）里面进行转换然后导入到OB，难点在于存量数据转换期间，业务不能停机，这个期间产生的增量数据，要如何同步到新的FF库里面。经过和研发团队讨论，我们制定了一套存量+增量消息同步的数据迁移方案。
第一步骤：存量数据迁移
客户在Oracle 上面的FF数据库，定期同步到MC（MaxComputer），ds=T 天之前的数据，在数据湖里面按照新的FF业务模型对存量FF数据进行转换，再通过DataX 导入到OceanBase 新的FF数据库中。
第二步骤：增量数据迁移
存量数据迁移之前，我们借助OMS工具 建立了一条Oracle FF数据库到OceanBase FF 镜像库之间的数据迁移链路，OceanBase FF 镜像库和Oracle FF数据库准实时同步，数据完全一致。 FF镜像数据库和重构后的新FF数据库放在OceanBase同一个租户下面，方便应用开发存储过程程序进行新老数据对账。同时在FF镜像库下面，我们还借助OMS 数据同步的功能，将业务新增、修改、删除等数据变化过程，同步到kafka 消息队列。 kafka 客户端应用程序读取消息队列，将存量截止日ds=T之后的数据，存入到OB的FF增量轨迹表中。同时，通过业务定时任务，将FF增量轨迹数据分片转换成新FF模型，更新到新FF数据库中。
存量数据和增量数据切换时机，以ds=T时间为准。
OMS迁移链路规划原则
因为FF 系统数据量巨大（存储空间10T+），同时有大对象（LOB）数据，创建一条数据迁移链路难以在有限时间内完成数据迁移，所以有必要对数据迁移任务进行拆分，以提高数据迁移效率和速度，避免oracle 源端增量日志因存储空间不足导致日志被过早清理的风险。OMS迁移链路拆分遵循以下原则：
- 不同数据类型
- 无LOB类型数据
无LOB数据类型的表的迁移，单位迁移批次的大小较小且稳定，内存需求可控，并发度可适度加大以提高迁移速度。所以，对该部分数据可使用较高的并发度和预读批次单链路或多链路迁移。
- LOB类型数据
数据表行 LOB 类型空间占用较大，每一批次的数据拉取大小会在原始行的基础上有显著增加。相比无LOB数据类型，对OMS端内存需求有数倍的需求。因此，优化的策略是单独对LOB类型的表建立新的链路，采用较小的并发，较低的批次，防范JVM OOM的风险；同时，为了提高整体迁移的速度可以多链路并行。
- 冷热数据分离
一般的业务库数据中，数据具有自己的生命周期，数据的高频访问具有冷热特点。比如，流水表历史数据，日志表历史数据除了在审计回查场景之外，访问很少甚至不访问，但是通常这部分数据都会比较大，数据迁移的开销会比较高，造成数据迁移时间的延长。针对该部分数据，我们可以预先对这部分数据进行归档备份，然后采用静态迁移或者 OMS 全量迁移单独迁移。
- 大库多链路并发迁移
单台OMS可以支持多个迁移任务，但是共享数据网络出口。鉴于大库数据的持续拉取，可以将大库的迁移分散至不同OMS节点，减少大数据网络流量的争用。
第三步骤：应用双写验证、系统切换
当增量数据追齐，应用数据校验一致之后，应用开启双写模式
第一阶段：主写FF数据库，异步调用API回写新FF数据库，通过定时任务，对增量数据进行校验，如果发现不一致，以FF镜像库数据为准，数据补偿（API) 修正新FF数据库，并检查应用代码，修复缺陷，直到两边数据一致。
第二阶段：主写新FF数据库，异步调用API回写老的FF数据库，通过定时任务，对增量数据进行校验，如果发现不一致，以新FF数据库数据为准，数据补偿（API) 修正老FF数据库，保留回滚老FF数据库的能力。
通过第一阶段长时间的双写和数据校验，确认新FF应用程序可靠并且数据一致后，进入到第二阶段，系统最终切换到OceanBase 新FF库，并具备随时回滚的能力。
