El movimiento de datos a escala de hyperscaler, especialmente entre sistemas transaccionales (OLTP) como Apache Cassandra y analíticos (OLAP) como Apache Iceberg, presenta desafíos fundamentales de consistencia, eficiencia y resiliencia. La evolución de Casspactor a un motor unificado en Netflix aborda el problema de la divergencia de la verdad y la rigidez arquitectónica en pipelines de datos críticos. Históricamente, la integración de sistemas dispares a menudo resulta en soluciones ad-hoc que, con el tiempo, acumulan deuda técnica, dependencias circulares y puntos únicos de fallo. Este artículo detalla cómo Netflix refactorizó un componente crítico de su infraestructura de datos para superar estas limitaciones, adoptando un enfoque más modular y basado en principios de computación distribuida.
El problema central que resuelve esta nueva arquitectura es la gestión de metadatos y la transformación de datos a gran escala. Casspactor, el sistema anterior, dependía de múltiples fuentes de metadatos, lo que llevaba a inconsistencias y fallos. Además, su diseño monolítico no podía adaptarse a la complejidad creciente de los modelos de datos de alto nivel (Key Value, Time Series) construidos sobre Cassandra. La solución se centra en establecer una única fuente de verdad para los metadatos de backup y en proporcionar un framework extensible para transformaciones de datos conscientes del modelo, utilizando Apache Spark como motor de procesamiento.
Arquitectura del Sistema
La nueva arquitectura se construye sobre una base de Apache Cassandra Analytics, utilizando una capa de "Cassandra Analytics Wrapper" que interactúa directamente con los backups almacenados en Amazon S3. Esta capa es responsable de la lectura de los archivos SSTable y sus metadatos asociados, traduciéndolos en Apache Spark DataFrames estándar. Esta decisión es crucial porque desacopla la lógica de lectura de bajo nivel de la lógica de transformación de datos de alto nivel, eliminando la necesidad de múltiples sistemas de metadatos externos y haciendo de S3 la fuente de verdad.
Sobre esta capa fundamental, se implementa un modelo de "Connector Factory" que permite a las abstracciones de datos específicas (Key Value, Time Series) construir sus propios conectores optimizados. Estos conectores utilizan UDFs (User Defined Functions) y transformaciones de Java para procesar los Spark DataFrames genéricos, aplicando lógica de negocio consciente del modelo de datos sin necesidad de pasos de post-procesamiento complejos o tablas intermedias. Esto contrasta con Casspactor, que movía tablas de Cassandra "tal cual", requiriendo lógica de reconstrucción de datos externa y costosa. La nueva arquitectura también maneja particiones sesgadas de manera eficiente al mover la compactación y el procesamiento de mutaciones al nivel del Executor de Spark, minimizando el data shuffling y evitando errores de Out-Of-Memory. La integración con el framework interno "Move Data" y la plataforma de orquestación de flujos de trabajo Maestro, junto con el patrón Decider, permite una gestión dinámica de los conectores y una estrategia de fallback robusta durante la migración.
Flujo de Movimiento de Datos con el Nuevo Motor
- 1 Inicio Job DM Usuario inicia un trabajo de movimiento de datos vía Data Bridge API/UI.
- 2 Maestro Workflow Plataforma de orquestación invoca el Decider Step.
- 3 Connector Controller Determina qué conector usar (legacy Casspactor o nuevo Move Data).
- 4 Cassandra Analytics Wrapper Lee SSTables y metadatos directamente de Amazon S3.
- 5 Spark Engine Procesa datos, realiza compactación/mutación en Executors, genera DataFrames.
- 6 Connector Factory Conectores específicos de modelo de datos (KV, TS) transforman DataFrames.
- 7 Escritura Iceberg Datos transformados se escriben directamente en tablas Apache Iceberg.
| Capa | Tecnología | Justificación |
|---|---|---|
| storage | Apache Cassandra | Base de datos OLTP fuente para el movimiento de datos. |
| storage | Amazon S3 | Almacén de objetos para backups de Cassandra, ahora como fuente de verdad para metadatos. |
| data-processing | Apache Spark | Motor de procesamiento distribuido para transformaciones de datos y compactación. Procesamiento de mutaciones y compactación en el nivel del Executor para manejar particiones sesgadas. |
| storage | Apache Iceberg | Formato de tabla de alto rendimiento para el destino de datos analíticos. |
| orchestration | Maestro | Plataforma de orquestación de flujos de trabajo, implementa el patrón Decider para la migración. |
Trade-offs
Ganancias
- ▲ Consistencia de metadatos
- ▲ Manejo de particiones sesgadas
- ▲ Reducción de tablas intermedias
- ▲ Conciencia del modelo de datos
- ▲ Funcionalidad de Time Travel
- ▲ Reducción de dependencias
- ▲▲ Reducción de costos (almacenamiento y cómputo)
- ▲ Rendimiento (tiempo de ejecución)
Costes
Fundamentos Teóricos
El desafío de mantener la consistencia de metadatos en sistemas distribuidos es un problema clásico en la ciencia de la computación, abordado por principios como el de la "única fuente de verdad" (Single Source of Truth). La divergencia de metadatos observada en Casspactor es un ejemplo de las dificultades inherentes a la coordinación de estados entre múltiples sistemas distribuidos, un problema que el teorema CAP (Consistency, Availability, Partition tolerance) de Eric Brewer (2000) y sus extensiones como PACELC (Latency, Consistency, Availability, Partition tolerance, Else Latency, Consistency) de Daniel Abadi (2012) buscan caracterizar. La decisión de consolidar la fuente de metadatos en S3 y leer directamente de los backups refleja un patrón de diseño para mejorar la consistencia y la resiliencia.
La estrategia de "shadow testing" y validación de datos (C=M) para la migración se alinea con los principios de verificación formal y pruebas de regresión en sistemas complejos. La necesidad de manejar "unknown unknowns" y las sutiles discrepancias entre sistemas es un recordatorio de la dificultad de lograr la equivalencia funcional en entornos distribuidos, incluso cuando las especificaciones parecen idénticas. La utilización de Apache Spark DataFrames como interfaz universal para las transformaciones de datos se basa en los principios de procesamiento de datos en paralelo y la abstracción de la complejidad del cómputo distribuido, como se describe en trabajos fundamentales sobre MapReduce (Dean & Ghemawat, 2004) y sus sucesores.