Cómo Meta Migró Su Sistema de Ingestión de Datos a Escala de Petabytes Sin Perder Datos

El Desafío: Migrar un Sistema de Ingestión de Datos en Hiperescala

El grafo social de Meta está impulsado por una de las implementaciones de MySQL más grandes del mundo. Todos los días, el sistema de ingestión de datos recolecta incrementalmente varios petabytes de datos del grafo social hacia el data warehouse para alimentar análisis, reportes y entrenamiento de modelos de machine learning. A medida que la empresa crecía, el sistema heredado —basado en pipelines gestionados por los clientes— se volvió inestable bajo requisitos cada vez más estrictos de tiempo de entrega de datos.

El equipo necesitaba migrar decenas de miles de jobs de ingestión a un nuevo servicio de data warehouse autogestionado, más simple, que pudiera operar eficientemente en hiperescala. La migración tenía que ser perfecta: sin pérdida de datos, sin regresión de latencia y sin picos en el uso de recursos.

Restricciones clave:

• Tolerancia cero a problemas de calidad de datos (recuento de filas y checksum deben coincidir)
• No se permite ninguna regresión en la latencia de entrega
• El uso de cómputo y almacenamiento no debe aumentar
• El rollback debe ser rápido y seguro

Esto no es un ejercicio teórico — es un manual probado en batalla de uno de los entornos de producción más exigentes del planeta.

La Solución: Un Ciclo de Vida de Migración en Tres Fases

Para garantizar la integridad de los datos y la confiabilidad operacional, Meta estableció un ciclo de vida de migración claro con tres fases:

Fase 1: La Fase Sombra (Shadow)

Cada job se ejecutó primero en un entorno de preproducción como un "job sombra". El job sombra consumía la misma fuente de datos que el job de producción, pero escribía en una tabla sombra separada. Esto exponía el nuevo sistema al comportamiento real de producción, mientras proporcionaba un espacio aislado para inspeccionar resultados e implementar correcciones.

Monitoreo crítico: El recuento de filas y el checksum se comparaban continuamente entre el job de producción y el job sombra. Cualquier discrepancia desencadenaba una investigación inmediata.

# Ejemplo simplificado: comparando recuento de filas y checksum entre tablas de producción y sombra

def validar_calidad_datos(tabla_prod, tabla_sombra):
    """
    Compara el recuento de filas y el checksum entre las tablas de producción y sombra.
    Devuelve True si ambos coinciden, de lo contrario registra las discrepancias para depuración.
    """
    recuento_prod = obtener_recuento_filas(tabla_prod)
    recuento_sombra = obtener_recuento_filas(tabla_sombra)
    
    checksum_prod = obtener_checksum(tabla_prod)
    checksum_sombra = obtener_checksum(tabla_sombra)
    
    if recuento_prod != recuento_sombra:
        registrar_discrepancia("Recuento de filas", tabla_prod, tabla_sombra, recuento_prod, recuento_sombra)
        return False
    
    if checksum_prod != checksum_sombra:
        registrar_discrepancia("Checksum", tabla_prod, tabla_sombra, checksum_prod, checksum_sombra)
        return False
    
    return True

Fase 2: La Fase Sombra Inversa

Una vez que el job sombra funcionaba de manera confiable, los roles se invertían: los datos del job sombra se escribían en la tabla de producción, y los datos del job de producción original se escribían en la tabla sombra. Esto traía dos beneficios clave:

• Señales continuas de calidad de datos al seguir comparando las salidas
• Rollback instantáneo si se detectaban discrepancias, sin necesidad de recrear el job antiguo

Fase 3: Limpieza de la Migración

Después de que ambos jobs funcionaran en la configuración de sombra inversa sin problemas, el job sombra del sistema antiguo se eliminaba. El nuevo sistema tomaba el control por completo.

Herramientas Personalizadas de Análisis de Calidad de Datos

Meta construyó un conjunto integral de herramientas de depuración. Para cada partición de tabla sombra entregada, el sistema leía la partición de tabla de producción correspondiente y comparaba el recuento de filas y el checksum. Las discrepancias se registraban en Scuba (el sistema de gestión de datos en tiempo real de Meta). Cada hora, la herramienta leía los logs, ejecutaba consultas para identificar filas de ejemplo que causaban discrepancias y registraba información detallada de depuración de vuelta en Scuba.

Esta misma herramienta todavía se usa después de la migración como parte del proceso de validación de releases.

Manejando Rollout y Rollback

Debido a que ambos sistemas usaban change data capture (CDC), los datos problemáticos podían propagarse a los nuevos datos generados. Para reducir el riesgo, Meta se enfocó en:

1. Señales tempranas antes de que los datos problemáticos llegaran a los consumidores
2. Detener el sangrado rápidamente durante el rollback

Señales tempranas: Después del rollout, el sistema activaba el backfill tanto en los jobs de producción como en los sombra. Si los resultados coincidían, la migración era exitosa. Si no, el job se revertía inmediatamente — antes de que los consumidores de datos se vieran afectados.

Deteniendo la propagación de datos malos: Durante la fase de sombra inversa, si una partición específica tenía problemas de calidad, se marcaba en los metadatos. Para particiones delta, los nuevos datos dejaban de llegar y se enviaba una alerta. Para particiones destino, el sistema seleccionaba una partición más antigua y la fusionaba con más deltas. El rollback podía entonces consultar los metadatos para encontrar todas las particiones malas y corregirlas con backfill.

Ejecutando a Escala: Automatización y Lotes

Con decenas de miles de jobs de ingestión para migrar, la migración manual era imposible. Meta construyó:

• Herramientas de migración externas que monitoreaban continuamente las señales de estado de los jobs y promovían/relegaban automáticamente los jobs entre las etapas del ciclo de vida
• Dashboards a nivel de sistema y de job para rastrear el progreso y depurar

Debido a que la capacidad de migración era limitada, los jobs se migraron en lotes. Los jobs se categorizaron por throughput, prioridad y casos especiales. Los equipos evitaron crear jobs sombra con problemas conocidos para evitar dumps completos innecesarios (que son lentos y costosos). También reutilizaron particiones de snapshot entregadas por el sistema antiguo como snapshots iniciales para reducir la carga de dump completo.

Para una inmersión más profunda en estrategias de rollout progresivo para cambios en producción, echa un vistazo a nuestra guía sobre Progressive Rollouts in Vercel Flags.

Limitaciones y Precauciones

Aunque el enfoque de Meta es robusto, es importante entender sus limitaciones:

• Alta sobrecarga operativa: Ejecutar sistemas duales (sombra + producción) requiere recursos significativos de cómputo y almacenamiento. No todas las organizaciones pueden permitirse duplicar su infraestructura durante la migración.
• Diseño específico para CDC: Las estrategias de rollback dependen en gran medida de los metadatos CDC. Si tu sistema no usa CDC, necesitarás adaptar el enfoque.
• Herramientas complejas: Construir la herramienta personalizada de análisis de calidad de datos y el orquestador automatizado de migración no es trivial. Los equipos más pequeños pueden necesitar usar soluciones open source existentes como Apache Airflow o dbt para validación similar.
• Dependencia de lotes: La estrategia de lotes asume que puedes priorizar jobs. Si todos los jobs tienen la misma prioridad, puedes enfrentar contención por la capacidad de sombra limitada.

Próximos Pasos para Aprender

Si estás planeando una migración similar, aquí tienes una ruta de aprendizaje recomendada:

1. Entiende tu pipeline CDC: Lee sobre patrones de change data capture en tu data warehouse (ej: Snowflake Streams, BigQuery Change Tracking).
2. Construye un framework de pruebas sombra: Comienza con un solo job y valida recuentos de filas y checksums antes de escalar.
3. Automatiza el ciclo de vida: Implementa una máquina de estados para las etapas de migración (sombra → sombra inversa → limpieza) con criterios de promoción automatizados.
4. Practica simulaciones de rollback: Prueba tu procedimiento de rollback en un entorno de staging antes de ir a producción.

Para un caso de estudio relacionado sobre gestión de complejidad en sistemas distribuidos, mira Deconstructing Complexity: A Multi-Agent Architecture for Intelligent Advertising.

Conclusión

La migración del sistema de ingestión de datos de Meta es una clase magistral en migración de sistemas a gran escala. Las principales lecciones son:

• Establece un ciclo de vida de migración claro con criterios de éxito definidos en cada etapa
• Usa pruebas sombra para validar la corrección sin impactar la producción
• Implementa sombra inversa para señales continuas de calidad y rollback instantáneo
• Automatiza todo — monitoreo, promoción y rollback — al lidiar con decenas de miles de jobs
• Agrupa en lotes estratégicamente para evitar desperdiciar recursos en jobs con problemas conocidos

Este manual no es solo para sistemas del tamaño de Meta. Cualquier equipo que migre un pipeline de datos crítico puede adoptar estos principios, adaptados a su escala y herramientas. La filosofía subyacente — validar temprano, revertir rápido, automatizar sin piedad — es universal.

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