在这个信息爆炸的时代，每天都有海量的数据在互联网上流淌，从全球社交媒体上的点赞评论到一张张宠物美食旅行的相片，从不同语言的每一句交流分享到漂洋过海的每一个包裹与惊喜，这些看似独立却又紧密相连的数据点构成了我们生活与工作的日常。面对如此庞大的“数据洪流”，今天我们探索利用最大规模的数据湖来驾驭这股“泼天”的流量。

面对暴涨的流量，必须充分利用云上的大规模与弹性，阿里云在存量规模数百 PB，业务不停机每日新增数 PB 的情况下，同时完成复杂的数据校验与业务双跑过程，保证核心数据偏差率在千分之一，项目过程“0”故障，将业界最大数据湖迁至阿里云。

百 PB 级数据湖上云的挑战

在传统的数据同步中一般只同步 ODS 数据到目的端，而数据湖上云不仅仅是数据的上云，还涉及到数据湖与数据仓库的全链路，且涉及到复杂的数据校验以及业务校验过程，是数据 IT 系统的整体上云，然而当数据量上升到百 PB 级别时，对于一家拥有庞大存量规模和复杂规则的企业来说，这些挑战变得更加严峻，上云的难度又增加了许多。例如：

• 存量规模大、规则复杂高

存量数据规模往往会达到 TB 甚至数百 PB，这中间涉及的表数量可以达到千万级。伴随如此海量的数据，企业往往在历史上还构建了数十万的数据调度任务，这些任务经过多年建设，里面包含了很多复杂的业务逻辑，随着人员流动部分任务已经缺乏多年的维护，甚至还存在了很多的非标任务，对标准化的数据上云来说是巨大的挑战。

• 需要业务双跑，数据校验难度大

数据湖上云不是静态的，不可能将所有业务暂停下来等待存量上云后再重新启动，往往伴随着业务的双跑，那么除了存量数据的迁移，还需要对增量数据进行同步迁移，那么在上云过程中又需要同时对新的分区数据进行校验，1 份数据在线上与迁移过程的两个结果需要在比较短的时间内就能完成一致性的校验，并且核心数据偏差率需要在可控范围内。

• 协同团队多，标准化程度要求高

数据湖上云往往是多个团队协同的项目，特别是业务团队，如果没有较好的产品化或者标准化的流程，项目的进度以及推进难度都会受到极大的阻碍，中间对于各类过程管理、故障发现及排除，数据不一致处理等等问题都需要项目团队去快速解决。

百 PB 级数据湖上云实践

阿里云数据湖构建（Data Lake Formation，简称 DLF）提供了百 PB 级数据湖上云与迁移的能力。通过标准化产品能力实现存量数据数百 PB，增量数据数 PB 大规模数据湖上云，解决各类小文件等性能问题，数据同步持续保持较高带宽利用率，保障项目进度。在业务双跑阶段，重点数据在 15 分钟以内可以完成校验，核心数据偏差率低于千分之一，阿里云产品、服务团队与客户紧密合作，整体确保业务 0 故障完成数据校验与割接。

一、存量与增量迁移

由于存量和增量数据都非常大，产品的易用性、性能将极大制约迁移进展。针对非标任务，如果全部手动修改也是巨大的工作量。DLF 实现以下能力：

全增量一体化同步（数据+元数据）

• 存量数据一次性迁移，增量部分自动识别，在全量同步完成后自动创建增量同步任务，用户只需要创建一个任务，提高效率。

• 元数据 Location 自动替换，无需手动修改。

• 小文件过多，数据同步变慢，带宽利用不足，通过技术优化提升同步速度。

二、双跑阶段

双跑阶段涉及到 S3、阿里云、客户自研的调度平台三方。同时针对这么大的存量与增量数据，周期任务数量达到 5W+，其中复杂，最深的任务依赖层级达到 53 层，按照要求与源端任务相比偏差不慢于 15 分钟。如果没有正确的数据校验策略，将会没有充足的时间进行数据验证。而针对数据准确性要求，核心数据偏差率要求小于千分之一，非核心数据偏差率小于千分之五。

双向双跑策略

客户自研调度平台>>DLF

在感知客户的调度任务完成后，DLF 再进行双跑，逻辑清晰简单，但由于是逐级跑，上游数据差异可能会放大到下游，影响下游数据验证的复杂度，资源消耗逐步较大，已经验证过的任务仍然会需要双跑，深层链路的产出数据较晚，不能及时进行数据验证。

DLF>>>客户自研调度平台

当 DLF 完成数据同步后，同步客户自研调度平台，开始进行双跑。这种方式源数据同步过来是准确的，能减少数据不一致的排查时间，并可以并发提高校验效率。

双跑执行流程：

• 双跑按任务的上下游关系层进行，首先进行上游任务的双跑，下游任务保持数据同步，待上游任务校验完毕后进行下层任务双跑。

• 双跑分多轮进行，每轮进行任务双跑、数据校验、问题修复、差异覆盖等过程。

• 任务双跑、数据校验和问题修复可以并行完成，每天双跑过程中同步进行数据校验，保证校验资源和网络带宽的持续占用。每天数据校验完成后进行问题修复。

• 由于部分任务可能会存在延迟一天以上的情况，因此双跑过程可能持续 3~4 天，进行数据校验和问题修复，具体双跑时间长短需要根据数据量和任务量决定。

• 一轮数据问题排查完毕后，进行数据差异覆盖，使用 S3 中的数据覆盖所有双跑过程中产生的数据。

数据校验

提供产品化的数据比对方案，针对数据校验不一致部分提供修复、重跑能力。并支持客户按表级别自定义校验模板，不同业务场景的表，均可配置不同的校验函数、精度、差异容忍率，更灵活地满足实际业务需求。

针对数据不一致，提供差异率分析等不一致信息，告知用户不同数据字段的差异率情况，方便进行排查

三、割接阶段

割接阶段，涉及之前提到的所有功能，都需要通过多次演练、进行逐个排查确认。

JindoSDK 自动路由 S3 路径访问 OSS，实现非标作业无缝高效迁移

针对割接阶段的非标的 Spark jar 任务，迁移后部分 jar 作业继续保留原 S3 路径，而实际业务数据已经从 S3 迁移至 OSS，这些任务会全部报错。如果手动进行任务改写工作量大，风险高问题。

• JindoSDK 自动路由无需依赖外部代理服务即可让 S3 路径轻松共享 JindoSDK 为 OSS 路径的优化项，避免因代理服务稳定性问题降低整个存储的可用性风险。

• 整体性能几乎无损耗，路径改写规则的校验与匹配在 FileSystem 对象初始化时完成，后续函数调用只会引入字符串替换。

• 支持 S3、COS 和 OBS 等不同云厂商的对象存储服务。

四、迁移项目管理

由于上云是一个环节多，业务逻辑复杂，涉及人员多的项目，阿里云 DLF 提供迁移项目大盘，方便各团队人员快速掌握迁移进度，及时修复卡点问题，保障迁移正常进行。

迁移项目大盘

表和目录的迁移总进度分别统计项目内所有表或目录任务的实时迁移进度。表和目录任务状态分布分别统计项目内所有表或目录任务的状态，包括未启动、双跑中、同步中、校验中和停止五种。

提供数据迁移指标与审计日志

阿里云在全球部署了超过 10 万台计算集群，完成数据湖的上云后，面对暴涨的业务高峰，可以将数据湖的规模迅速扩展至数百万核。同时，对多模态数据（结构化、半结构化和非结构化数据），阿里云基于数据湖推出了 OpenLake 解决方案，整合大数据、搜索、AI 一体化服务，构建面向 AI 时代的数据基础设施。

基于平台优质的分享内容，数据湖实时精准推荐全球用户的最新笔记，每一条点赞、评论、分享与交流都是数据时代的一次次碰撞，语言的障碍被技术打破，地理的距离因真诚而缩短。新一轮人工智能浪潮正在重塑世界，推动了数据与智能的一体化，而随着全球用户的涌入，我们也在通过技术搭建思想交流的桥梁，从学术研究到兴趣爱好，从生活技巧到专业技能，我们不仅是信息的接受者，也是创造者，传播者，泼天的流量也将汇入全球化的浪潮，推动了跨文化的交流与融合。