货拉拉离线大数据跨云迁移 - 数据迁移篇

数据迁移背景

正如《货拉拉离线大数据跨云迁移-综述篇》中所述，2023 年底公司正式决策启动离线大数据迁移项目。为落实公司离线大数据跨云迁移战略，我们团队负责执行离线数据的迁移任务。

面对海量数据的迁移挑战，我们需要一款高吞吐、高性能、可扩展，且支持文件一致性灵活比对的迁移工具。我们对业界常用迁移工具进行了深入调研。然而，诸如 COSDistCp、AzCopy 等方案在性能与灵活性方面均不满足我们现有业务的迁移需求。为此，我们决定依托团队自研的 Kirk 数据迁移服务，进行功能升级与优化，从而满足高并发和多样化的数据迁移需求。

数据迁移挑战

货拉拉积累了20万+张表 和近40PB Hive数据 ，迁移过程中不仅要保证数据与表 Schema 的一致性，还要确保源端的大数据产品和服务持续稳定运行。与此同时，源端数据每天都在不断新增和更新，增量和实时数据在不断变化 ，这意味着迁移无法"一次性完成"，必须在全量迁移的基础上，构建稳定高效的增量同步机制，确保目标端与源端保持最终一致。

面对如此庞大且动态的数据迁移，这不是简单的"复制粘贴"，而是一场需要兼顾数据 100% 迁移、数据一致性 100% 保障、业务全程无影响的复杂系统工程，只有提前规划、工具化、自动化，才能稳稳落地。

迁移过程中将面临如下挑战：

挑战 1：数据 100% 迁移

• 海量数据：近 40P 数据，计划 3 个月内完成，时间紧任务重
• 元数据迁移：20 万+ 张表的 Schema、分区信息、权限等需批量自动化迁移，保证结构与源端完全一致
• 高性能要求：对网络带宽、存储吞吐、迁移工具并发能力、大数据组件稳定性要求极高
• 迁移策略：需分批、分时段、并行迁移，避免对源端造成过大压力影响线上业务

挑战 2：迁移数据 100% 一致

• 全量+增量同步：历史存量数据需快速迁移，增量数据持续双写同步
• 动态一致性：源端数据不断新增/更新，需保持目标端与源端实时一致
• 结构一致性：表字段类型、分区策略、存储格式等需与源端完全一致

挑战 3：业务无影响

• 业务零感知：迁移过程中业务不能停，需保证线上服务稳定性
• 平滑切换：正式切换时可灰度、可回滚，业务无感，一旦异常可立即回滚

架构设计

1. 整体架构

Kirk 服务支持表 schema 和 Hive 数据跨云迁移。包含多个模块：

1. 库表管理模块：表 schema 一致性比对，支持自动创建和修改，用于元数据对齐。
2. 数据比对模块：Hive 元数据和数据 count 一致性比对，用于发现数据差异并生成拷贝或删除 task。
3. 任务调度模块：运行 Hive 数据拷贝和删除任务，用于源端数据同步到目标端。
4. 回溯验证模块 ：数据迁移最后一道防线，用于迁移切换完成后源端删除数据前回溯验证数据，防止数据不一致无法恢复。

2. 库表管理模块

表 schema 比对

流程说明：

• 比对元数据：包括表存储格式、表location、字段名称 、字段类型、字段说明、字段顺序等
• 大部分自动处理（小表或者非核心表）
  1. 目标端删除表并进行重建
  2. 或者执行alter语句自动添加字段
• 少部分需人工介入（大表或者核心表）
  1. 判断是否能删除重建，重建后快速生成一批高优先级拷贝任务，确保数据能快速拷贝
  2. 或者人工执行DDL修改表结构

3. 数据迁移比对模块

数据一致性保证，采用数据校验三步法：让源端与目标端"真正一致"

我们将整个校验分为三步，从粗到细，逐层过滤数据不一致问题。

为什么需要三步校验？

在分布式存储（如 HDFS、OSS、S3、COS）中，文件的元数据（大小、文件数、修改时间等）一致并不能 100% 代表文件内容真正一致。

常见的异常场景包括：

• 分区缺失：某些分区未同步过来，导致数据不全。
• 文件不一致：文件大小、修改时间不同，说明数据被更新或损坏。
• 元数据一致但内容损坏：例如网络传输中损坏、存储介质异常，导致文件无法正常读取。

因此，我们需要一个分层的校验流程，既能快速发现数据不一致问题，又能精准修复数据。

比对报告

支持库、表级别比对报告，可通过全局一致率 和 交集一致率，直观判断源端与目标端的数据一致情况：

• 全局一致率：反映整体数据的一致程度，可同时体现分区数量差异等情况。
• 交集一致率：反映源端与目标端交集部分的数据一致程度，能够直接评估交集数据的质量可靠性。

4. 任务调度模块

1. Task 获取：通过轮询 DB 方式按任务优先级获取 task。

2. 任务执行：通过 DistCp job 拷贝数据，支持两种拷贝模式。一种是先拷贝到临时目录再 rename 到正式目录（如果有数据需要先 move 到 trash），适合数据基本不变的离线表场景，避免双跑阶段影响数据验证。另一种是通过 update 比较直接拷贝到正式目录，适合数据量较大，数据存在回刷变动的实时表场景，避免大量数据重新拷贝。

   • DistCp job 正常运行完成后通过 add partition HQL 添加分区，如果运行失败支持 task 自动重试。
   • 对于源端被删除分区，也会通过 drop task 删除目标端分区。

另外，任务执行支持分时段并发控制，夜间降低并发避免影响核心链路产出。

5. 回溯验证模块

回溯验证就像数据迁移的最后一道防线，帮我们在物理删除源端数据前，做一次全面的回溯验证，确保已迁移数据无数据质量问题。

为什么需要回溯验证？

1. 链路切换完成后，将会进入迁移观察期并且源端存储桶也会进入物理删除倒计时，如果此时存在数据遗漏或迁移后数据损坏，一旦源端被清空，就无法从源端恢复。虽然迁移过程中会持续进行数据验证，但仍存在以下风险：

• 迁移后数据损坏：迁移期间，可能因为网络抖动导致文件传输损坏。
• 人为误删或覆盖：迁移完成后，目标端任务被误调起导致被覆盖或者误删除。

回溯验证的核心逻辑

由于链路切换后，目标端数据研发平台已开始运行，目标端存储桶中可能出现迁移数据 + 新增数据 + 回刷数据 混存：

1. 时间锚点：为解决"数据混存"比对难题，引入时间锚点（链路切换时间）来区分迁移数据与目标端新增数据，这样能精准锁定迁移数据清单，避免将新增数据误判为迁移异常数据，同时确保源端已迁移数据无遗漏、无质量问题。

• 使用源端和目标端链路切换时间 2024-05-18 20:00:00 来作为锚点
• 规则：
  • 该时间点之前生成的目标端数据 → 视为迁移数据，纳入回溯比对
  • 该时间点之后生成的目标端数据 → 视为目标端新增数据，记录特定 case，需人工分析
  • 该时间点之后生成的源端数据 → 视为源端重刷数据，记录特定 case，需人工分析

2. 比对逻辑：只记日志，不自动拷贝

• 迁移验证：发现异常 → 自动生成拷贝任务
• 回溯验证：发现异常 → 仅记录日志（路径、差异类型、文件 owner、时间戳等）
• 目的：为人工核验保留判断空间，避免误操作

3. 异常筛选：从日志表导出回溯明细

• 按两大维度过滤：
  1. 数据完整性：源端存在文件，但目标端缺失，需结合时间锚点判断缺失文件是在切换前还是切换后发生的
  2. 数据一致性：源端与目标端均存在文件，但文件元数据不一致（大小不同、修改时间不同、文件owner不同）
• 输出异常数据候选清单，缩小人工核查范围

4. 人工核验：通知数据 owner 确认后再处置

• 若确认是真实异常（遗漏、损坏） → 手动生成拷贝任务补齐
• 若为假阳性（统计日志偏差、正常覆盖） → 标记为"无需处理"

5. 异常代号：为了便于对异常文件进行分析，根据源端和目标端文件修改时间在 518-20 时间锚点的分布情况，归纳并列出了所有可能的情形。

   Tips：A 代表源端，B 代表目标端。518-20 是指目标端链路切换为主时间：2024-05-18 20:00:00

   • A > 518-20 集合代表源端文件最小修改时间都大于链路切换正式时间
   • A <= 518-20 集合代表源端文件最大修改时间都小于等于链路切换正式时间
   • B > 518-20 集合代表目标端文件最小修改时间都大于链路切换正式时间
   • B <= 518-20 集合代表目标端文件最大修改时间都小于等于链路切换正式时间
   • A <= 518-20 集合和 B <=518-20 集合代表源和目标端文件最大修改时间都小于等于链路切换正式时间

   此时需要比对交并差集（A 和 B 比对元数据）

迁移实施

整体数据迁移分为三大阶段，第一阶段为数据迁移开始到正式切换前一天，主要进行表 schema 迁移和存量数据迁移。第二阶段为正式切换当天（2024.5.18），保证所有数据和表元数据一致。第三阶段为正式切换之后删除原云数据之前，通过回溯比对保证迁移完整性和准确性，避免数据丢失和不一致。

1. 第一阶段 - 存量数据迁移

1.1 表 schema 迁移

Hive 数据迁移前需要先迁移表 schema。库表管理模块负责整体表 schema 迁移管理。 通过周期性或手动触发比对源端和目标端表 schema，发现目标端不存在时则创建表，目标端存在时则比对 schema 一致性。 存量数据迁移期间以在目标端创建 schema 为主，等存量数据迁移基本完成，后续以不一致 schema 修复为主。 考虑不一致 schema 对应表数据量大小以及修复复杂度因素，大部分通过自动化 add/alter column 或者 drop table 等方式修复，少部分情况需要人工介入修复。

1.2 数据迁移

数据迁移依赖数据比对和任务调度模块。通过数据比对发现数据新增和数据变动并生成拷贝任务，任务调度模块负责运行 DistCp 拷贝任务或者 drop 分区任务。 为应对千万级别分区数据快速比对，数据比对模块支持横向扩展实例。离线和实时库分属不同实例范围。在实例范围内，通过对不同存储量大小库分组，每个实例负责库列表大小基本均衡，个别比对耗时长的库需以独立实例运行。

在迁移过程中，我们也发现部分表不需要迁移，可以通过配置比对表黑名单方式实现过滤。

除文件元数据比对外，正式切换前我们也对元数据一致的数据进行几轮 count 比对，并发现少量 DistCp 拷贝导致数据损坏情况并重新生成拷贝 task 完成修复。

在双跑阶段前，通过设置 update 模式直接写正式目录提高写入效率。双跑阶段为避免数据一致性问题，通过写临时目录再 rename 方式保证数据写入原子性，rename 前需要将正式目录数据删除。

对于实时 Hive 数据，大部分由消费 Kafka 落 Hive 的 Flink 任务写入，少部分由消费 Kafka 同时读取离线 Hive 数据任务写入，这两种不同类型任务实时平台自行接管写入时间节点存在一些差别。

单纯消费 Kafka 落 Hive 数据，存量数据由 Kirk 同步，并在正式切换前两个星期，Kirk 设置同步截止分区日期，分区日期前由 Kirk 继续同步变更，日期后由实时任务自行写入，并每天通过数据比对验证工具和源端比对数据量。

消费 Kafka 读 Hive 表写 Hive 表任务，会在正式切换前几天确认离线 Hive 表数据和源端一致情况下，一样通过设置截止同步分区日期，由实时任务自行接管后续数据写入。

通过以上数据迁移服务和库表数据比对报告，我们顺利完成近 40P 存量数据迁移工作。

2. 第二阶段 - 正式切换

正式切换当天，在核心报表任务完成后，源端和目标端数据研发平台开始停服，源端存储桶禁止写入，开始进行最后的数据和表 schema 对齐工作。

通过设置比对实例分区日期范围为 2024-01-01 到切换当天，优先实现当年数据快速对齐。对齐后设置起始分区日期为 1990-01-01，实现历史数据对齐。对齐过程中通过 DB 查询实例比对报告查看库数据对齐情况并记录已对齐库。

在全量数据都对齐并且任务都完成后，停止比对实例和拷贝实例。开始拉起目标端数据研发平台进行追数工作。

3. 第三阶段 - 数据回溯验证

正式切换后增量数据质量验证没问题，不意味着数据迁移工作结束。后续源端存储桶数据会被物理删除，如果部分数据未拷贝或损坏，则无法从源端恢复。因此需要在删除数据前通过数据回溯验证，确认已迁移数据无数据质量问题。

由于目标端数据研发平台已经开始运行，此时进行数据比对逻辑会比前期存量数据迁移阶段更复杂，需要考虑已迁移数据目录被增量写入或全量覆盖等情况。

正式切换当天目标端数据研发平台开始运行时间为 2024-05-18 20:00:00，因此我们以这个时间点前后来区分目标端数据是来源于数据迁移还是目标端自行写入，从而区分出不同 case。

回溯验证模块通过以上比对逻辑梳理出各种 case 具体信息，后续通过人工确认是否需要拷贝数据。

由于前期数据迁移验证工作完备，回溯阶段未发现数据不一致或遗漏情况。

数据迁移问题

我们在数据迁移过程中遇到过很多的困难，包括迁移工具Kirk自身问题，以及Hive、YARN等基础组件的稳定性或性能问题等，但是经过整个团队不懈努力，最终克服了重重困难，确保了迁移工作的顺利完成。

迁移总结

通过自研 Kirk 系统，顺利完成 20万+表和近 40P 数据迁移，未发现数据质量和表 schema 不一致等问题，保证了整体云迁移的成功。

迁移完成后通过回溯比对，历史数据 100% 一致，也未发现数据因拷贝损坏情况。

整体数据迁移过程近半年，历经跨云迁移开始和结束，并在迁移完成后通过回溯比对来进一步保证数据迁移完整性和准确性。过程中碰到并解决了诸多问题，也调动了大数据各个相关组件负责同学一起参与性能优化和问题解决，依靠团队的力量最终顺利完成迁移工作，在此一并表示感谢。

作者简介：

1. 何洋：大数据专家，曾就职于拼多多并负责 YARN 团队。现就职于货拉拉，负责大数据安全、数据治理平台、资源调度相关工作。
2. 李光云：高级大数据工程师，数据质量平台负责人， YARN 团队核心研发。
3. 吴刚：高级大数据工程师，专注于大数据安全能力建设和治理方向。