Imagina que tienes una tabla con diez millones de clientes y quieres mantenerla sincronizada en tu data warehouse. El enfoque ingenuo es copiar los diez millones de filas todas las noches. Funciona — hasta que deja de funcionar. A medida que los datos crecen, esa copia total tarda cada vez más, pesa cada vez más sobre la base de datos de origen, y desperdicia recursos moviendo millones de filas que no cambiaron nada. Hay una forma mucho mejor: capturar solo lo que cambió. Se llama Change Data Capture, o CDC.
El CDC es una de esas técnicas que parecen un detalle técnico pero que, en la práctica, deciden si tu arquitectura de datos escala o se estrangula. Entender el problema que resuelve y las formas de implementarlo es esencial para quien construye pipelines que tienen que acompañar datos que crecen — es decir, prácticamente todos.
El problema de la copia total
Recargar todo en cada actualización es simple de programar y, con pocos datos, perfectamente aceptable. El problema es que no escala. Si de los diez millones de clientes solo mil cambiaron desde ayer, copiar los diez millones es hacer diez mil veces más trabajo del necesario. Ese desperdicio se traduce en ventanas de actualización que se estiran hasta la madrugada, en bases de datos de origen sobrecargadas en el peor momento, y en costos de procesamiento que suben sin que el valor suba con ellos.
Hay además un problema más sutil: la copia total solo te da el estado actual, no la historia. Si un cliente cambió de dirección tres veces desde la última copia, tú solo ves la última — perdiste los cambios intermedios. Para muchos análisis eso no importa; para otros, la historia de los cambios es precisamente lo que interesa. El CDC, al capturar cada alteración, preserva esa historia que la copia total tira.
La idea central: seguir los cambios, no el estado
El CDC invierte la lógica. En vez de preguntar "¿cómo está todo ahora?" y copiar el resultado entero, pregunta "¿qué cambió desde la última vez?" y mueve solo esos cambios — las inserciones, las actualizaciones y las eliminaciones. Como el número de cambios en un período es típicamente una fracción minúscula del total, el volumen a mover es pequeño, la actualización es rápida, y el origen casi no siente el peso. Es la diferencia entre mudarse de casa todos los días y solo traer lo que es nuevo.
Las formas de capturar los cambios
- Por marca temporal: si cada fila tiene un campo "última alteración", basta pedir las que cambiaron desde la última ejecución. Simple, pero depende de que la columna exista y se actualice siempre — y no atrapa eliminaciones.
- Por comparación: comparar el estado actual con una copia anterior para detectar diferencias. Funciona siempre, pero es pesado, lo que contradice en parte el objetivo.
- A partir del log de la base de datos: la forma más poderosa. Las bases de datos registran internamente cada cambio en un log de transacciones; el CDC basado en log lee ese registro y reconstruye los cambios sin siquiera tocar las tablas — mínimo impacto en el origen, atrapa todo (incluyendo eliminaciones), casi en tiempo real.
Por qué el CDC basado en log es el estándar de oro
Leer el log de transacciones es elegante porque aprovecha algo que la base de datos ya hace de todos modos para garantizar su propia consistencia. No hace falta añadir columnas, no hace falta sobrecargar el origen con comparaciones, y no se escapa ningún cambio — ni siquiera las eliminaciones, que las otras técnicas suelen perder. A cambio de esta potencia, exige más configuración y acceso a mecanismos internos de la base de datos, lo que lo hace más complejo de montar. Es el estándar para volúmenes grandes y requisitos de baja latencia, pero para casos simples los enfoques más ligeros bastan.
Un caso concreto
Una empresa tenía un pipeline nocturno que copiaba varias tablas grandes por entero al data warehouse. Al inicio, corría en veinte minutos. A medida que los datos crecieron a lo largo de dos años, esa ventana se estiró a más de tres horas — y empezó a colisionar con el inicio del día de trabajo, momento en que la base de datos de origen ya estaba siendo usada para operaciones y no aguantaba la carga extra. Los informes matinales se retrasaban, y el equipo vivía apagando el fuego de una actualización que ya no cabía en la noche. La solución no fue comprar hardware más grande — fue cambiar a CDC basado en log. En vez de copiar todo, el pipeline pasó a mover solo los cambios de cada tabla, que eran una pequeña fracción del total. La ventana de actualización cayó de tres horas a pocos minutos, la base de datos de origen dejó de sentir el peso, y los informes volvieron a estar listos mucho antes del inicio del día. El mismo hardware, una técnica diferente, un problema resuelto de forma duradera.
Cuándo no vale la pena la complejidad
El CDC brilla con volúmenes grandes y necesidad de frescura. Pero si tienes tablas pequeñas que caben en una copia total rápida, añadir CDC es complejidad sin retorno — la copia total simple es más fácil de construir y mantener. Como casi todo en ingeniería de datos, la técnica correcta depende del problema: usar CDC "porque es moderno", sin la escala que lo justifica, es resolver un problema que no tienes a costa de complicar lo que ya funcionaba.
En la práctica
Si tus ventanas de actualización se están estirando y el origen sufre con copias totales cada vez más pesadas, el CDC es probablemente la respuesta que estás evitando. Empieza por identificar las tablas más grandes y más costosas de recargar, y evalúa mover solo lo que cambia en esas. La mayoría de los problemas de "la actualización ya no cabe en la noche" se resuelven así. ¿Tus tablas grandes se están copiando por entero todas las noches, cuando solo una fracción de ellas cambia?
