CDC (Captura de Datos de Cambio)

Definición

CDC (Change Data Capture, o Captura de Datos de Cambio) es la técnica de ingeniería de datos que identifica y rastrea cada modificación que ocurre en una base de datos de origen — inserciones de nuevos registros, actualizaciones de registros existentes y eliminaciones — y propaga esos cambios a sistemas de destino de forma incremental, sin necesidad de copiar la tabla completa en cada ciclo. CDC resuelve uno de los problemas fundamentales de los pipelines de datos: cómo mantener un sistema de destino sincronizado con un sistema de origen que cambia constantemente, sin impactar el rendimiento de producción ni introducir latencias de horas.

La forma más eficiente y precisa de implementar CDC es a través de la lectura de los transaction logs de la base de datos. Cada motor relacional mantiene un log de todas las transacciones que se ejecutan — Postgres lo llama WAL (Write-Ahead Log), MySQL lo llama binlog, SQL Server tiene CDC nativo, Oracle utiliza redo logs. CDC basado en transaction log captura cada operación de datos en el orden exacto en que ocurrió, con microsegundos de latencia, sin ejecutar ninguna consulta adicional sobre las tablas de producción. Esta arquitectura hace de CDC la base del patrón ELT moderno a escala, donde la replicación incremental desde sistemas OLTP hacia data warehouses analíticos debe ser continua, precisa y no invasiva.

Cómo se implementa

La implementación de CDC basado en transaction log requiere habilitar la funcionalidad de replicación lógica en la base de datos fuente y configurar una herramienta que consuma ese log y propague los cambios al destino. El proceso estándar sigue cuatro fases: carga histórica inicial (snapshot completo de la tabla), activación del seguimiento del transaction log desde el punto de partida del snapshot, captura continua de cambios incrementales, y escritura de esos cambios en el destino (data warehouse, data lake, cola de mensajes).

Ejemplo práctico

Considere una empresa de software de gestión de distribución con sede en Monterrey, México, que opera con una base de datos PostgreSQL en AWS RDS para su plataforma de pedidos. La tabla orders acumula 80,000 nuevos registros por día y recibe actualizaciones de estado a lo largo de toda la jornada operativa (pendiente → confirmado → en tránsito → entregado). El equipo de datos necesita que el data warehouse en Snowflake refleje el estado actualizado de todos los pedidos para que los reportes de operaciones estén al día sin esperar al cierre del día.

Sin CDC, el enfoque previo era un job nocturno que copiaba toda la tabla orders — 12 millones de registros — desde Postgres hacia Snowflake. El job tardaba 4 horas, impactaba el rendimiento de la base de datos de producción durante la madrugada y los reportes del día siguiente tenían datos con 12-36 horas de antigüedad. Con CDC activado a través de Fivetran, solo los registros que cambiaron en los últimos minutos se replican: en un ciclo de 5 minutos se transfieren típicamente 400-600 cambios en lugar de 12 millones de registros. La latencia de los datos pasó de 12-36 horas a 5-10 minutos, y la carga sobre la base de datos de producción es prácticamente imperceptible. El costo mensual de Fivetran para ese conector en ese volumen es de aproximadamente $280-$420 USD, frente a las horas de ingeniería que se dedicaban a mantener el job nocturno.

Análisis en profundidad

La ventaja técnica fundamental de CDC basado en transaction log frente a los enfoques alternativos — escaneos completos de tabla, timestamp-based polling — reside en tres propiedades que no son intercambiables. Primera: captura completa, incluyendo eliminaciones. Un escaneo de tabla que compara dos snapshots puede detectar inserciones y actualizaciones, pero si un registro desaparece entre un snapshot y el siguiente, no hay forma de saber si fue eliminado o si simplemente no aparece en la muestra. CDC lee la operación DELETE directamente del log y puede propagar esa eliminación al destino con precisión. Segunda: latencia de segundos. El log es escrito por el motor de base de datos en tiempo real con cada transacción; una herramienta CDC que consume ese log puede propagar cambios en segundos, frente a los ciclos de minutos u horas de los jobs batch. Tercera: impacto cero en producción. CDC no ejecuta consultas SELECT sobre las tablas de producción, no adquiere locks, no compite por recursos con las operaciones de la aplicación — lee el log de forma asíncrona como un proceso secundario.

El ecosistema de herramientas CDC se divide en tres categorías con perfiles de uso diferenciados. Debezium es el estándar open-source de facto: lee logs de Postgres, MySQL, SQL Server, Oracle, MongoDB y Cassandra, y publica los eventos en Kafka o en otros message brokers. Debezium es la opción preferida para equipos con capacidad técnica para operar Kafka y que necesitan máxima flexibilidad — puede enrutar cambios a múltiples destinos, aplicar transformaciones en el log, y escalar horizontalmente. Fivetran y Airbyte representan la categoría de conectores gestionados: configuración sin código, CDC activado de forma transparente para las fuentes que lo soportan, y destino directo al warehouse sin necesidad de Kafka. Fivetran prioriza fiabilidad y soporte; Airbyte prioriza precio y cobertura de conectores open-source. AWS DMS y GCP Datastream son las opciones nativas de cada nube: ventaja para equipos que quieren reducir la superficie de herramientas de terceros y que ya operan en esos ecosistemas.

En el contexto de LATAM, CDC tiene implicaciones prácticas adicionales relacionadas con los patrones de conectividad y los costos de infraestructura. Muchas empresas medianas en México, Colombia y Brasil operan sus bases de datos de producción en instancias on-premise o en data centers privados, no en la nube pública. En esos entornos, Debezium desplegado localmente — conectando al log de la base de datos en la misma red — es frecuentemente la única opción viable, ya que herramientas como Fivetran requieren que la base de datos sea accesible desde internet o a través de SSH tunnels con IPs de salida específicas. Esta limitación de red es uno de los factores que más condiciona la elección de herramienta CDC en empresas latinoamericanas que no han completado su migración a la nube.

CDC introduce complejidades operativas que no existen en los jobs batch tradicionales y que los equipos deben anticipar antes de adoptar la arquitectura. La primera es la gestión del lag del log: si la herramienta CDC no consume el transaction log con suficiente rapidez, el log puede crecer hasta ocupar el espacio de disco disponible, lo que puede causar que el motor de base de datos detenga operaciones para proteger la integridad del log. En Postgres, el parámetro wal_keep_size y los replication slots requieren monitoreo activo. La segunda complejidad es la gestión de cambios de esquema: si se añade o renombra una columna en la tabla fuente sin coordinación con la herramienta CDC, la replicación puede detenerse o propagar datos incorrectos. Los equipos que usan CDC deben establecer procesos de coordinación entre los cambios de schema en producción y los procesos de replicación downstream.

La relación entre CDC y la arquitectura ELT moderna es de dependencia estructural: CDC es el mecanismo por el cual el paso Extract del ELT puede ocurrir de forma continua y a baja latencia en lugar de en batches diarios. Cuando una empresa adopta un stack moderno — Fivetran o Airbyte para la extracción, Snowflake o BigQuery como warehouse, dbt para las transformaciones — CDC es el componente que determina la frescura de los datos disponibles para análisis. Un pipeline ELT sin CDC tiene datos con antigüedad de horas o días; con CDC, los datos en el warehouse pueden tener minutos de antigüedad. Para casos de uso operacionales — alertas de margen, detección de anomalías de ingresos, monitoreo de churn en tiempo real — esa diferencia de latencia determina si el warehouse puede ser fuente de decisiones operacionales o solo de reportes retrospectivos.

Errores frecuentes

• ✗

  Activar CDC sin monitorear el crecimiento del transaction log. En Postgres, los replication slots retienen el WAL hasta que el consumidor confirma que ha procesado los cambios. Si la herramienta CDC se detiene por cualquier motivo — mantenimiento, error de red, cambio de esquema no coordinado — el WAL puede acumularse sin límite y llenar el disco de la base de datos de producción, causando una interrupción del servicio. Antes de activar CDC, se debe configurar alertas sobre el tamaño del WAL y sobre el lag de los replication slots activos.

• ✗

  Asumir que CDC captura cambios de tablas sin clave primaria. CDC basado en transaction log requiere que las tablas tengan clave primaria definida para poder identificar unívocamente cada registro y determinar si un evento es una inserción, actualización o eliminación de un registro específico. Las tablas sin primary key solo pueden replicarse en modo append-only (INSERT únicos), lo que significa que las actualizaciones y eliminaciones se propagan como eventos adicionales que el destino no puede resolver correctamente. Antes de activar CDC sobre una tabla, se debe verificar que tiene clave primaria y que esa clave es estable.

• ✗

  Confundir latencia de captura con latencia de disponibilidad para análisis. CDC puede capturar un cambio en la base de datos fuente en segundos, pero ese cambio no está disponible para análisis en el warehouse hasta que se completan tres pasos adicionales: la escritura del evento en el destino (segundos a minutos), la transformación dbt que consume esos datos crudos para producir los modelos analíticos (minutos a horas, dependiendo de la frecuencia de los jobs dbt), y la actualización del caché de la capa semántica o la herramienta de BI (si aplica). La latencia extremo a extremo — desde el cambio en producción hasta el dato visible en el dashboard — es la suma de todos esos pasos, no solo de la captura CDC.

Cómo lo rastrea Fairview

Fairview se conecta a las fuentes de datos operacionales a través de los conectores de replicación más comunes — Fivetran, Airbyte y conectores nativos de Snowflake — que utilizan CDC bajo la superficie para mantener los datos del warehouse sincronizados con las plataformas de origen. Una vez que los datos ingresan al warehouse a través de CDC, Fairview aplica sus modelos de transformación para construir las métricas de operating intelligence: MRR, churn, márgenes de contribución, métricas de pipeline de ventas, y KPIs de eficiencia operacional. La arquitectura basada en CDC permite que el Operating Dashboard de Fairview refleje el estado real del negocio con minutos de antigüedad, no horas — lo que convierte los datos del warehouse en una fuente válida para decisiones operacionales en tiempo real, no solo para reportes de fin de mes.

Preguntas frecuentes