前言

2023年底，货拉拉正式启动了货运离线大数据跨云迁移项目。经过五个月的协同奋战，项目在2024年5月顺利完成离线全链路——涵盖任务、数据、服务及基础设施——的跨云切换。期间，有十多个部门深度参与。如今距离迁移完成已逾一年，回望整个过程，依然能感受到当时的紧张氛围。项目推进中遇到的难点与挑战不少，最终都依靠多方协作一一化解，为后续系统的稳定运行奠定了坚实基础。

业界迁移上云或跨云的项目并不少见，但专门聚焦大数据场景、且将实施细节公开分享的案例确实不多。因此，我们决定将这次离线大数据迁移的完整过程整理出来，希望能为同行提供切实可行的参考与思路。本文先从整体视角介绍方案设计与实施流程，后续还会对数据迁移的技术细节、数据验证方法体系等核心内容进行深度拆解。

背景介绍

1. 大数据跨云架构

货拉拉的大数据IT架构采用“多云 + 云上自建”路线。从一开始，核心大数据服务就只依赖云商的基础设施层（IaaS），前期研发投入虽大，但好处是可控性强、可深度优化，且未来迁移或复制更为灵活。

• • 2020年以前：在线服务与大数据服务均部署在同一朵云上。
• • 2020年以后：将离线大数据服务迁至专用离线云，正式进入多云阶段。多云架构是当前中大型互联网公司的主流IT架构，优势显著：与云商议价空间更大，不同云商的技术优势也能互为补充。
• • 2024年5月后：将大数据离线服务从原有离线云迁移至新云。

2. 离线大数据规模

2.1 离线存储

本次迁移涉及公司货运业务近10年积累的约40PB数据存储，以及4万多个数据计算任务。这一体量在货运行业中处于领先地位。

2.2 离线计算

货拉拉的离线大数据集群规模接近上千个节点。除核心集群外，还有Presto混合引擎集群、业务专用计算集群、分布式调度服务节点，以及GPU/CPU异构计算资源池。整体架构呈现多层级、组件异构的特点。迁移过程中，如何协调好与在线服务集群（对低延迟交互要求高）、实时计算集群（依赖流式数据）之间的跨网络域数据交换，成为严峻挑战。跨集群的数据传输与网络权限设计，每一步都需要精细把控。

迁移方案设计

设计云迁移方案时，技术保障要求极高，核心目标是：迁移前后数据绝对准确，产出准时，业务停机时间尽可能短，且不影响业务正常运行。基于过往经验，结合本次迁移的复杂程度，我们重新设计了一套“可验证、可回滚”的数据迁移方案。

• 可验证：

1. 性能验证：前期POC阶段，对新环境的存储与计算性能进行充分测试；链路双跑阶段，在新云环境中尽可能多地运行可双跑的任务，持续跟踪新链路的性能指标。
2. 数据验证：新旧环境的大数据库表和文件可实现比对，验证数据质量。

• 可回滚：采用主备链路双跑方案。一旦主备切换出现问题，可切回主链路，确保有退路可循。

整体方案可简化如下：

1. 基础设施搭建：完成新云环境的网络规划、基础组件适配、大数据集群交付等工作。
2. 数据迁移：启动存量数据迁移、元数据迁移、离线链路任务迁移等事项。
3. 链路双跑、数据验证：新云链路启动离线计算链路抽数（MySQL等 -> Hive）任务，每天验证数据链路结果。
4. 链路切换、资源下线：数据质量验收通过后，新云链路切换为主链路，旧云链路变为备链路（具备可回滚条件）。待新云环境运行稳定、历史数据无质量问题后，再下线旧云链路及相关资源。

迁移方案实施

方案设计完成后，项目于2023年12月正式启动“搬家”。整个过程困难重重，但总算有惊无险。限于篇幅，这里列举几个典型难题及对应解决方案：

1. 网络怎么隔离

本次大数据网络架构需处理“旧离线云—新离线云—在线云”三朵云之间的跨云数据交互。不同云集群需按“组件端口粒度”进行网络隔离，同时确保隔离策略不影响现有业务网络。这套隔离策略在大数据场景下首次实施，技术挑战不小：

• 拓扑梳理与粒度细化：梳理了四套集群、30多个组件、IDP大数据离线调度平台以及线上服务的调用关系，形成完整调用拓扑图，并将所有链路信息细化到端口级别，为后续网络配置与迁移规划提供精准依据。
• 主备链路网络隔离：采用网络白名单机制，实现主备双跑链路的隔离管控，仅允许主环境的数据同步到备环境。
• 备链路与在线云隔离策略：采用网络黑名单机制，构建新云与在线云的隔离，防止链路双跑期间，新链路数据意外推送至在线业务。
• 切换前网络验证：链路切换前，临时开启新云与在线云的隔离策略，验证双跑期间无法双跑的任务（如Hive to HBase、Hive to MySQL等场景）。
• 切换后网络配置：链路切换后，停用新云与在线云的网络隔离策略，保留新云与旧云的策略；同时新增旧云与在线云的网络隔离策略，防止备链路数据污染主链路与线上。

2. 海量数据怎么迁移

40PB的数据且每天都在变化，如何快速搬到新环境并保证数据准确？大数据迁移绝非简单的“文件复制粘贴”，而是一场系统工程。迁移过程中的数据质量是重中之重——只有当两侧链路的元数据、Hive表数据、任务代码都一致后，才能开始双跑和验数工作。针对数据迁移与一致性保障，我们做了以下工作：

1. 打造高吞吐、可扩展的数据迁移工具：调研发现，Hadoop DistCP等工具仅能进行简单数据搬迁，无法校验大数据库表结果的一致性。而且，大数据场景下存在十亿级别的小文件，如何在并行迁移的同时持续打满跨云专线、提升迁移效率，也是难题。因此，我们自研了一套高吞吐、高性能、可扩展的数据迁移工具，利用上千台机器规模的大数据集群共同进行数据搬迁与比对。该工具支持Hive表级别、分区级别、文件级别的数据比对，以及Hive元数据比对与同步，从根本上解决了海量数据迁移时元数据、表、文件的一致性问题。

• 高吞吐：从无法打满跨云带宽，到持续打满100Gb带宽。
• 高性能：每日多轮全量文件元数据比对，每两日一轮的数据行数比对。
• 2500万+全量分区数据行数比对耗时：从18日缩短至2日。
• 14亿全量文件元数据比对耗时：从5小时缩短至1.5小时。

1. 数据一致性保障：

• 数据一致性：实现每日500TB以上数据（包括未拷贝分区和不一致分区）的及时拷贝；通过比对报告（库级、表级），可准确掌握同步结果。
• 表元数据一致性：通过表schema的自动化差异比对，针对表末尾加字段、表字段乱序等场景，自动生成DDL语句。再结合是否为核心链路表、表大小等信息，判断后自动同步。
• 代码一致性：为保证计算任务代码、数据、元数据一致，数据平台研发了自动同步功能。用户在主环境修改的数据和计算任务，可自动同步到备环境，大幅减少双跑期间用户维护代码的复杂度，确保主备环境代码一致。

3. 数据如何验证

存量数据迁移完成（每日仍在迁移增量数据），抽数任务全部开启后，新环境开始“蓄水”。此时进入链路双跑期，新链路的数据每天调度产出，数据验证的考验也随之而来：如何验证涉及公司近20个部门、数万张Hive表的数据与主环境是否一致？

1. 自研自动化数据比对能力：我们研发上线了平台化的数据校验工具，支持定时任务、批量比对等核心功能，将用户的验数时间缩短90%以上。例如，某个部门仅需1人花费几天时间，就完成了近1500张重点数仓表的精准验证。在数据验证上，我们总结了一套“先粗验、再精验”的方案：

• 粗验：仅对比迁移前后两侧数据表及分区的行数。行数一致后，判定为满足精准验数的基础条件。
• 精验：精确比对表字段，可指定字段联合比对。针对订单金额等数据场景，还支持设置“数据误差比对”。因为数据应用层有大量报表类库表，其单量、金额等指标容易因上游抽数的微小时间差导致join不上，通过设置合理的误差容忍区间，即可科学评估结果准确性。

1. 数据比对分优先级层层推进：按照数据基建层、数据应用层的顺序验数。每天定时产出库表验数报告，验数小组负责定位、解决、跟踪数据不一致问题，直至所有问题闭环。

4. 主备链路怎么切换

万事俱备，只欠东风。在顺利完成链路双跑和数据验证后，进入最关键的环节——主备链路切换。虽然双跑机制支持快速回滚，但我们的目标仍是力争一次切换成功。因为一旦切换失败，不仅可能导致项目延期，更会带来数据延迟、线上数据异常等难以承受的后果。

为确保切换过程万无一失，我们详细制定了链路切换的SOP（标准作业程序），并成立专门的“链路切换重点保障小组”，为整个主备切换流程保驾护航。以下是切换SOP的简略大纲：

思考与总结

经过全体项目组成员的努力，我们最终顺利完成了切换，新环境链路的数据正常、准确地产出，打赢了这场旷日持久的攻坚战。项目结束后，我们也在复盘：如果再做一次，哪些事能做得更好，哪些经验能用到后续类似项目中？

1. 持续迭代优化迁移方案：方案的完整性与适配性是迁移成功的核心前提。本次迁移的大数据链路和基础设施已积累近十年，难免会遇到线上调用、非常规依赖、无归属的代码或任务等意外情况。因此，需全面覆盖各类潜在风险点，通过多轮方案打磨，将风险降至最低。
2. 自动化能力至关重要：

• 数据迁移工具：极大提升了数据迁移效率。未来可应用于大数据灾备场景，进一步扩大灾备场景范围（如增加元数据灾备能力）。
• 资源交付自动化：云上基础设施和大数据集群可自动搭建交付，大幅缩短基础设施搭建时间。
• 数据自动比对工具：相比手动验数节省约20多人月的人力成本，用少量资源就完成了全公司重点表数据及任务代码的验证。
• 云上技术选型经验：大数据团队积累了成熟的成本测算、云产品性能测试、云产品稳定性保障能力对比等流程。面对新云环境，能快速完成性能POC（概念验证）。