Como o Meta Migrou Seu Sistema de Ingestão de Dados em Escala de Petabytes Sem Perder Dados

O Desafio: Migrar um Sistema de Ingestão de Dados em Hiperescala

O grafo social do Meta é alimentado por uma das maiores implantações de MySQL do mundo. Todos os dias, o sistema de ingestão de dados coleta incrementalmente vários petabytes de dados do grafo social para o data warehouse, alimentando análises, relatórios e treinamento de modelos de machine learning. Com o crescimento da empresa, o sistema legado — baseado em pipelines gerenciados pelos clientes — tornou-se instável sob requisitos cada vez mais rigorosos de tempo de entrega de dados.

A equipe precisava migrar dezenas de milhares de jobs de ingestão para um novo serviço de data warehouse auto-gerenciado, mais simples, que pudesse operar eficientemente em hiperescala. A migração tinha que ser perfeita: sem perda de dados, sem regressão de latência e sem picos de uso de recursos.

Restrições principais:

• Tolerância zero para problemas de qualidade de dados (contagem de linhas e checksum devem coincidir)
• Nenhuma regressão de latência de entrega permitida
• O uso de computação e armazenamento não pode aumentar
• Rollback deve ser rápido e seguro

Isso não é um exercício teórico — é um manual testado em batalha de um dos ambientes de produção mais exigentes do planeta.

A Solução: Um Ciclo de Vida de Migração em Três Fases

Para garantir a integridade dos dados e a confiabilidade operacional, o Meta estabeleceu um ciclo de vida de migração claro com três fases:

Fase 1: A Fase Shadow

Cada job foi executado primeiro em um ambiente de pré-produção como um "job shadow". O job shadow consumia a mesma fonte de dados que o job de produção, mas escrevia em uma tabela shadow separada. Isso expunha o novo sistema ao comportamento real de produção, enquanto fornecia um espaço isolado para inspecionar resultados e implantar correções.

Monitoramento crítico: A contagem de linhas e o checksum eram continuamente comparados entre o job de produção e o job shadow. Qualquer discrepância desencadeava uma investigação imediata.

# Exemplo simplificado: comparando contagem de linhas e checksum entre tabelas de produção e shadow

def validar_qualidade_dados(tabela_prod, tabela_shadow):
    """
    Compara contagem de linhas e checksum entre tabelas de produção e shadow.
    Retorna True se ambos coincidirem, caso contrário registra as discrepâncias para depuração.
    """
    contagem_prod = obter_contagem_linhas(tabela_prod)
    contagem_shadow = obter_contagem_linhas(tabela_shadow)
    
    checksum_prod = obter_checksum(tabela_prod)
    checksum_shadow = obter_checksum(tabela_shadow)
    
    if contagem_prod != contagem_shadow:
        registrar_discrepancia("Contagem de linhas", tabela_prod, tabela_shadow, contagem_prod, contagem_shadow)
        return False
    
    if checksum_prod != checksum_shadow:
        registrar_discrepancia("Checksum", tabela_prod, tabela_shadow, checksum_prod, checksum_shadow)
        return False
    
    return True

Fase 2: A Fase Shadow Reversa

Assim que o job shadow funcionava de forma confiável, os papéis eram invertidos: os dados do job shadow eram escritos na tabela de produção, e os dados do job de produção original eram escritos na tabela shadow. Isso trazia dois benefícios principais:

• Sinais contínuos de qualidade de dados continuando a comparar as saídas
• Rollback instantâneo se discrepâncias fossem detectadas, sem precisar recriar o job antigo

Fase 3: Limpeza da Migração

Depois que ambos os jobs funcionavam na configuração shadow reversa sem problemas, o job shadow do sistema antigo era removido. O novo sistema assumia completamente.

Ferramentas Personalizadas de Análise de Qualidade de Dados

O Meta construiu um conjunto abrangente de ferramentas de depuração. Para cada partição de tabela shadow entregue, o sistema lia a partição de tabela de produção correspondente e comparava a contagem de linhas e o checksum. Discrepâncias eram registradas no Scuba (sistema de gerenciamento de dados em tempo real do Meta). A cada hora, a ferramenta lia os logs, executava consultas para identificar linhas de exemplo que causavam discrepâncias e registrava informações detalhadas de depuração de volta no Scuba.

Esta mesma ferramenta ainda está em uso após a migração como parte do processo de validação de releases.

Gerenciando Rollout e Rollback

Como ambos os sistemas usavam change data capture (CDC), dados problemáticos podiam se propagar para novos dados gerados. Para reduzir o risco, o Meta focou em:

1. Sinais precoces antes que dados problemáticos chegassem aos consumidores
2. Parar o sangramento rapidamente durante o rollback

Sinais precoces: Após o rollout, o sistema acionava o backfill tanto nos jobs de produção quanto nos shadow. Se os resultados coincidissem, a migração era bem-sucedida. Caso contrário, o job era revertido imediatamente — antes que os consumidores de dados fossem impactados.

Parando a propagação de dados ruins: Durante a fase shadow reversa, se uma partição específica tivesse problemas de qualidade, ela era marcada nos metadados. Para partições delta, novos dados paravam de chegar e um alerta era enviado. Para partições alvo, o sistema selecionava uma partição mais antiga e a mesclava com mais deltas. O rollback podia então consultar os metadados para encontrar todas as partições ruins e corrigi-las com backfill.

Executando em Escala: Automação e Lotes

Com dezenas de milhares de jobs de ingestão para migrar, a migração manual era impossível. O Meta construiu:

• Ferramentas de migração externas que monitoravam continuamente os sinais de status dos jobs e promoviam/rebaixavam automaticamente os jobs entre os estágios do ciclo de vida
• Dashboards de nível de sistema e de job para acompanhar o progresso e depurar

Como a capacidade de migração era limitada, os jobs foram migrados em lotes. Os jobs foram categorizados por throughput, prioridade e casos especiais. As equipes evitaram criar jobs shadow com problemas conhecidos para evitar dumps completos desnecessários (que são lentos e caros). Eles também reutilizaram partições de snapshot entregues pelo sistema antigo como snapshots iniciais para reduzir a carga de dump completo.

Para um mergulho mais profundo em estratégias de rollout progressivo para mudanças em produção, confira nosso guia sobre Progressive Rollouts in Vercel Flags.

Limitações e Cuidados

Embora a abordagem do Meta seja robusta, é importante entender suas restrições:

• Alta sobrecarga operacional: Executar sistemas duais (shadow + produção) requer recursos significativos de computação e armazenamento. Nem toda organização pode arcar com a duplicação da infraestrutura durante a migração.
• Design específico para CDC: As estratégias de rollback dependem fortemente de metadados CDC. Se seu sistema não usa CDC, você precisará adaptar a abordagem.
• Ferramentas complexas: Construir a ferramenta personalizada de análise de qualidade de dados e o orquestrador automatizado de migração não é trivial. Equipes menores podem precisar usar soluções open source existentes como Apache Airflow ou dbt para validação semelhante.
• Dependência de lotes: A estratégia de lotes pressupõe que você pode priorizar jobs. Se todos os jobs têm a mesma prioridade, você pode enfrentar contenção pela capacidade shadow limitada.

Próximos Passos para Aprendizado

Se você está planejando uma migração semelhante, aqui está um caminho de aprendizado recomendado:

1. Entenda seu pipeline CDC: Leia sobre padrões de change data capture em seu data warehouse (ex: Snowflake Streams, BigQuery Change Tracking).
2. Construa um framework de testes shadow: Comece com um único job e valide contagens de linhas e checksums antes de escalar.
3. Automatize o ciclo de vida: Implemente uma máquina de estados para os estágios de migração (shadow → shadow reverso → limpeza) com critérios de promoção automatizados.
4. Pratique simulações de rollback: Teste seu procedimento de rollback em um ambiente de staging antes de ir para produção.

Para um estudo de caso relacionado sobre gerenciamento de complexidade em sistemas distribuídos, veja Deconstructing Complexity: A Multi-Agent Architecture for Intelligent Advertising.

Conclusão

A migração do sistema de ingestão de dados do Meta é uma aula magistral em migração de sistemas em larga escala. Os principais aprendizados são:

• Estabeleça um ciclo de vida de migração claro com critérios de sucesso definidos em cada estágio
• Use testes shadow para validar a correção sem impactar a produção
• Implemente shadow reverso para sinais contínuos de qualidade e rollback instantâneo
• Automatize tudo — monitoramento, promoção e rollback — ao lidar com dezenas de milhares de jobs
• Lote estrategicamente para evitar desperdiçar recursos em jobs com problemas conhecidos

Este manual não é apenas para sistemas do tamanho do Meta. Qualquer equipe migrando um pipeline de dados crítico pode adotar esses princípios, adaptados à sua escala e ferramentas. A filosofia subjacente — validar cedo, reverter rápido, automatizar implacavelmente — é universal.

Fonte: Meta Engineering Blog - Migrating Data Ingestion Systems at Meta Scale