Migrating Data Ingestion Systems at Meta Scale

在 Meta 规模下迁移数据摄取系统 - Meta 工程团队

跳至内容

[](https://engineering.fb.com/ "Meta 工程团队")

在本站搜索

• [开源](https://engineering.fb.com/2026/05/12/data-infrastructure/migrating-data-ingestion-systems-at-meta-scale/# "开源")
• [开源](https://engineering.fb.com/category/open-source/ "开源")
• [Meta 开源项目](https://opensource.fb.com/ "Meta 开源项目")

• [平台](https://engineering.fb.com/2026/05/12/data-infrastructure/migrating-data-ingestion-systems-at-meta-scale/# "平台")
• [Android](https://engineering.fb.com/category/android/ "Android")
• [iOS](https://engineering.fb.com/category/ios/ "iOS")
• [Web](https://engineering.fb.com/category/web/ "Web")

• [基础设施系统](https://engineering.fb.com/2026/05/12/data-infrastructure/migrating-data-ingestion-systems-at-meta-scale/# "基础设施系统")
• [核心基础设施](https://engineering.fb.com/category/core-infra/ "核心基础设施")
• [数据基础设施](https://engineering.fb.com/category/data-infrastructure/ "数据基础设施")
• [开发基础设施](https://engineering.fb.com/category/developer-tools/ "开发基础设施")
• [生产工程](https://engineering.fb.com/category/production-engineering/ "生产工程")
• [安全与隐私](https://engineering.fb.com/category/security/ "安全与隐私")
• [研究出版物](https://research.facebook.com/publications/research-areas/systems-infrastructure/ "研究出版物")

• [物理基础设施](https://engineering.fb.com/2026/05/12/data-infrastructure/migrating-data-ingestion-systems-at-meta-scale/# "物理基础设施")
• [连接性](https://engineering.fb.com/category/connectivity/ "连接性")
• [数据中心工程](https://engineering.fb.com/category/data-center-engineering/ "数据中心工程")
• [网络与流量](https://engineering.fb.com/category/networking-traffic/ "网络与流量")
• [研究出版物](https://research.facebook.com/publications/research-areas/networking-connectivity/ "研究出版物")

• [视频工程与 AR/VR](https://engineering.fb.com/2026/05/12/data-infrastructure/migrating-data-ingestion-systems-at-meta-scale/# "视频工程与 AR/VR")
• [视频工程](https://engineering.fb.com/category/video-engineering/ "视频工程")
• [虚拟现实](https://engineering.fb.com/category/virtual-reality/ "虚拟现实")
• [研究出版物](https://research.facebook.com/publications/research-areas/augmented-reality-virtual-reality/ "研究出版物")

• [人工智能](https://engineering.fb.com/2026/05/12/data-infrastructure/migrating-data-ingestion-systems-at-meta-scale/# "人工智能")
• [机器学习应用](https://engineering.fb.com/category/ml-applications/ "机器学习应用")
• [AI 研究](https://engineering.fb.com/category/ai-research/ "AI 研究")
• [研究出版物](https://ai.facebook.com/results/?content_types%5B0%5D=publication "研究出版物")

• [观看视频](https://engineering.fb.com/videos "观看视频")

发布于 2026年5月12日 | 数据基础设施

在 Meta 规模下迁移数据摄取系统

作者：[Zihao Tao](https://engineering.fb.com/author/zihao-tao/ "Zihao Tao 的文章"), [Mohan Perumal Swamy](https://engineering.fb.com/author/mohan-perumal-swamy/ "Mohan Perumal Swamy 的文章"), [Grace Gong](https://engineering.fb.com/author/grace-gong/ "Grace Gong 的文章"), [Ailyn Tong](https://engineering.fb.com/author/ailyn-tong/ "Ailyn Tong 的文章"), [Peishan Wang](https://engineering.fb.com/author/peishan-wang/ "Peishan Wang 的文章"), [Nilay Kapadia](https://engineering.fb.com/author/nilay-kapadia/ "Nilay Kapadia 的文章"), [Md Mustafijur Rahman Faysal](https://engineering.fb.com/author/md-mustafijur-rahman-faysal/ "Md Mustafijur Rahman Faysal 的文章"), [Saurav Sen](https://engineering.fb.com/author/saurav-sen/ "Saurav Sen 的文章"), [Jameel Mohamed](https://engineering.fb.com/author/jameel-mohamed/ "Jameel Mohamed 的文章")

• Meta 的数据摄取系统是工程团队获取社交图谱实时快照的核心工具，近期已进行全面升级以提升其大规模可靠性。
• 从遗留系统迁移到新架构涉及整个数据摄取系统的全面迁移。
• 我们分享了实现成功大规模系统迁移的解决方案与策略，以及影响架构决策的关键因素。

在 Meta，我们的社交图谱由全球规模最大的MySQL 部署之一驱动。我们的数据摄入系统每日从 MySQL 增量抓取数拍字节的社交图谱数据至数据仓库，为公司各团队提供分析、报告及下游数据产品支持，助力从日常决策到机器学习模型训练与产品开发的各类任务。

我们近期对数据摄入系统架构进行了全面重构，显著提升其效率与可靠性。新架构摒弃了早期由客户自管的管道（该方案在小规模下运行良好），转而采用更简洁的自管理数据仓库服务，同时在超大规模场景下保持高效运行。

我们已成功完成 100% 工作负载迁移并彻底弃用旧系统。然而，如此规模的数据摄入系统迁移是一项重大挑战。以下关键解决方案与策略确保了此次迁移的成功。

迁移挑战

随着业务规模持续扩大，旧版数据摄入系统在日益严格的数据落地时效要求下开始出现不稳定迹象。我们亟需迁移至新系统，但同时也意识到这不仅关乎如何确保每个作业无缝迁移，更需解决大规模迁移本身的挑战。

确保无缝过渡

实现无缝迁移意味着我们需要有效追踪数千个作业的迁移生命周期，并建立稳健的发布与回滚控制机制，以应对迁移过程中可能出现的问题。

迁移生命周期

我们的首要步骤是建立清晰的迁移作业生命周期，确保全流程数据完整性和运营可靠性。

迁移生命周期。

每个作业需在进入下一阶段前通过以下验证：

• 无数据质量问题：旧系统与新系统交付的数据完全一致。通过比对行数与校验和（checksum）确保双系统数据完全一致。
• 无数据落地延迟退化：新系统交付的数据落地延迟应有所改善，或至少与旧系统持平。
• 无资源利用率退化：新系统运行作业的计算与存储使用量应有所优化，或至少与旧系统相当。
• 对关键表迁移，我们与服务依赖方共同定义并确认了额外迁移标准。

#### 阶段 1：影子阶段

在生命周期首步，我们在预生产环境部署影子作业，通过新系统交付数据。影子作业使用与生产作业相同的源数据，但将结果写入名为影子表的独立表。此设计能暴露真实生产数据与行为下的问题，同时提供隔离环境快速验证结果与部署修复。

我们持续监控生产作业与影子作业的行数及校验和差异。一旦发现差异，立即定位根因并修复预生产环境，验证差异消除后方可推进。

此阶段同步测量影子作业的计算与存储配额，确保生产环境资源充足。

若影子作业满足上述标准，将迁移至生产环境，确认其在生产环境稳定运行后进入下一阶段。

#### 阶段 2：反向影子阶段

当生产作业与影子作业在生产环境均稳定运行后，启动反向影子阶段。此阶段影子作业的数据写入生产表（即影子作业成为新生产作业），而生产作业的数据则写入影子表（原生产作业转为影子作业）。

该方案带来两大核心优势：其一，迁移后仍能持续通过双系统输出比对获取数据质量信号；其二，若检测到差异可快速回滚，无需重建或重新配置旧系统作业。

#### 阶段 3：迁移清理

我们持续比对双作业交付的数据。若无差异，将移除当前运行在旧系统的影子作业，新系统接管生产作业继续交付数据，标志着迁移完成。

自定义数据质量分析工具链

我们还构建了全面的调试工具集，帮助团队成员高效定位并解决迁移过程中可能出现的问题。

我们开发了一套数据质量分析工具，确保跨作业的边缘情况能够被有效捕获和处理。对于每个落地的影子表分区，系统会读取对应的目标表分区，对比行数和校验和。任何不匹配的情况都会被记录到Scuba——Meta用于实时分析的数据管理系统中。每小时，数据质量分析工具会读取Scuba中的日志，运行查询定位导致不匹配的示例行，并将详细调试信息记录回Scuba。这一流程使团队成员能够快速定位问题根本原因，并判断问题是否已被识别且正在处理。

该数据质量分析工具在迁移后仍作为发布验证流程的一部分持续使用。

灰度发布与回滚处理

我们的遗留系统和新数据摄取系统均采用变更数据捕获（CDC）技术，将数据增量摄取至目标表。每个数据摄取作业均包含三类内部表：用于存储源数据库全量转储的内部表（full dump）、用于捕获源数据库变更的内部表（delta），以及被数据消费者使用的最终目标表。所有作业实体信息（包括表名和表结构）均由中央管理服务保存和管理。

CDC流程的数据流向。

作为CDC流程，系统生成的数据会被再次用于生成新数据。这意味着若先前落地的数据存在异常，问题数据将传递至新落地数据。若迁移后出现异常，需执行回滚以修复落地数据，防止问题扩散。

为降低风险，我们聚焦于两种解决方案：

1. 在问题数据影响数据消费者前获取早期预警
2. 回滚过程中快速阻断问题扩散

#### 灰度发布后的早期预警

我们未等待数据消费者发现异常数据，而是通过早期预警判断迁移是否成功。如前所述，迁移进入反向影子阶段后，影子作业的数据写入生产表，使影子作业成为新生产作业；同时生产作业的数据写入影子表，原生产作业转为影子作业。

为获取早期预警，我们同时触发生产作业和影子作业的回填（backfill）。若回填结果一致，表明迁移成功；若结果不一致，则立即回滚，确保数据消费者不受影响。

#### 回滚中快速阻断错误数据传播

如前所述，CDC流程的特性是问题数据可能传播至新生成数据。快速阻断错误数据传播不仅能提升迁移健壮性，还能增强迁移完成后的系统可靠性。

在反向影子阶段，若检测到特定分区存在数据质量问题，该分区的元数据将被标记为"数据质量异常"。若该分区为增量分区（delta），则新数据落地将停止，并向团队成员发送告警；若该分区为目标分区，系统则会选取较旧的分区，与更多增量数据合并。

CDC流程中防止错误数据传播的机制。

通过此方式，我们能快速阻断错误数据传播。对于回滚操作，可快速查询元数据定位所有标记为数据质量异常的分区，并通过回填修复。

大规模迁移的执行方案

在成功迁移小批量作业后，我们确信能够执行全量迁移。执行过程中主要面临两大挑战：

1. 如何自动化监控和迁移大量作业（作业规模庞大进一步加剧了该挑战）
2. 如何在有限资源下进行有效的影子测试

自动化工具监控

面对需迁移的数万条数据摄取作业，我们开发了自动化工具链，实现全流程自动化并最小化操作摩擦。

在如此大规模作业集上执行影子测试并处理边缘情况，需要强大的自动化能力和全面验证以确保可靠性与正确性。

基于明确的迁移作业生命周期和晋升标准，系统持续向Scuba发送作业状态信号，包含生命周期晋升标准相关数据及作业当前迁移阶段信息。我们构建了外部迁移工具，持续监控各作业信号，并根据是否满足（或不再满足）迁移标准，自动在迁移生命周期各阶段间晋升或降级作业。同时，我们开发了系统级和作业级仪表盘，使工程师能快速追踪整体迁移进度，同时监控和调试单个作业。

有限资源下的迁移规划

由于迁移容量受限，无法同时运行所有影子作业。因此我们采用分批次迁移策略。迁移效率高度依赖于每批次作业的选择策略。

我们根据吞吐量、优先级和特殊场景等因素对作业进行分类。工程团队确保在创建批量作业前环境已准备就绪。例如，他们制定了筛选标准，排除仍处于修复中的已知问题作业，从而减少因重复问题产生的干扰。作业还根据业务需求进行优先级排序，同时提前通知依赖该服务的团队。

在问题未解决前，我们避免创建存在已知问题的新影子作业。一旦发现问题，会将可能受影响的作业从迁移列表中移除并暂停处理，直至问题修复完成。

如前所述，由于系统采用 CDC 设计，新作业的首次快照通过全量转储落地，这通常速度慢且成本高。若在落地快照中发现数据质量问题，我们会触发另一次全量转储，待底层问题修复后落地修正后的快照。因此，在已知问题未解决时创建影子作业会导致大量不必要的全量转储操作，既发生在作业创建时，也发生在数据质量修复阶段。通过避免创建此类作业，我们大幅减少了额外的全量转储工作量，提升了迁移效率。同时，我们还开发了创新方案，例如复用旧系统交付的快照分区作为初始快照，以降低全量转储负载。

致谢

_我们感谢所有为 Meta 该项目成功做出贡献的团队成员和管理层。_