Saltar al contenido
Lakehouse LabLakehouse LabPreparación Databricks Data Engineer
Módulo 16 · Professional

CDC

Contenido abierto

Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.

Professional

Change Data Feed, CDC, AUTO CDC y SCD

Procesa inserciones, actualizaciones y borrados respetando clave, secuencia y retención.

Lectura pública
Al terminar podrás
  • Consumir Change Data Feed
  • Modelar CDC con AUTO CDC y reconocer APPLY CHANGES
  • Elegir SCD tipo 1 o 2
Ver fuentes y revisión

Metadatos editoriales

Última revisión
21 jul 2026
Nivel
Professional
Ruta relacionada
streaming
Dominios blueprint
CDC · Change Data Feed
Estado
Revisión editorial interna
Fuentes principales
Delta Change Data Feed · Databricks · AUTO CDC APIs · Databricks
Reportar un error
01
Modelo mental

CDC, CDF y sus diferencias

Delta Change Data Feed expone cambios confirmados de una tabla junto con su tipo, versión y timestamp de commit para consumo incremental.

Objetivo
Delta Change Data Feed expone cambios confirmados de una tabla junto con su tipo, versión y timestamp de commit para consumo incremental.
Duración estimada
17 min aprox.
Dificultad
Professional
Prerrequisitos
m15
Reportar un error en esta lección

Al habilitar `delta.enableChangeDataFeed`, las versiones futuras pueden leerse con `readChangeFeed=true`. La salida incluye `_change_type`, `_commit_version` y `_commit_timestamp`; los updates generan imágenes previa y posterior. CDF no reconstruye cambios anteriores a su activación.

El historial disponible depende de la retención de la tabla y de `VACUUM`. Un consumidor que permanezca caído más allá del horizonte puede no recuperar versiones antiguas. Por eso el SLA de recuperación debe relacionar retención, máxima indisponibilidad y una alternativa de snapshot.

Modelo mental

Change Data Feed convierte el historial transaccional de una tabla en una interfaz incremental de cambios por fila. En lugar de comparar snapshots completos, el consumidor solicita versiones y recibe inserts, deletes y, para updates, imágenes anteriores y posteriores junto con versión y timestamp de commit. La frontera importante es el commit Delta: todos los cambios de una transacción comparten versión, aunque su orden de filas dentro de ella no sea una secuencia de negocio. CDF facilita replicación, auditoría y ETL incremental, pero no constituye una copia permanente e independiente del historial; su disponibilidad depende de la retención de la tabla y de las políticas aplicables. En 2026 Databricks distingue el change data feed automático, calculado al leer mediante row lineage cuando es compatible, y el legado materializado durante escrituras. Ambos se consumen con las APIs documentadas, pero sus prerrequisitos y costes operativos deben comprobarse.

Change Data Feed

Interfaz que expone cambios de filas confirmados entre versiones de una tabla con metadatos de tipo y commit.

Permite procesamiento incremental sin escanear y comparar snapshots completos en cada ejecución.
Commit version

Número monotónico que identifica una transacción Delta dentro del historial de una tabla.

Sirve como frontera reproducible para checkpoints y replays, pero no sustituye la secuencia de negocio de la fuente.
Preimage/Postimage

Valores anterior y posterior que CDF puede emitir para una fila actualizada.

Distinguirlos evita duplicar entidades y permite elegir entre auditoría completa y aplicación del estado vigente.
PySparkLectura incremental de Change Data Feed
spark.sql("""
ALTER TABLE main.bronze.customers
SET TBLPROPERTIES (delta.enableChangeDataFeed = true)
""")

changes = (
    spark.readStream
      .option("readChangeFeed", "true")
      .table("main.bronze.customers")
      .where("_change_type IN ('insert', 'update_postimage', 'delete')")
)

En un stream nuevo se puede fijar `startingVersion`; al reanudar, el checkpoint conserva la posición.

Puntos clave

  • CDF se habilita antes de los cambios que se quieren capturar.
  • `update_preimage` y `update_postimage` representan dos vistas del mismo update.
  • La versión de commit ordena cambios Delta; el timestamp ayuda a auditoría, pero no sustituye la secuencia de origen.

Evita

  • Esperar que habilitar CDF genere retroactivamente cambios de versiones anteriores.
  • Consumir preimages y postimages como dos actualizaciones independientes y duplicar efectos.

Recuerdo activo

¿Qué tipos de cambio suelen conservarse para materializar el estado actual?

Borrador privado · solo en este navegador
02
Implementación

Change types y versiones de commit

Un feed CDC solo es determinista si define claves, una secuencia total por clave y semántica explícita para deletes y valores nulos.

Objetivo
Un feed CDC solo es determinista si define claves, una secuencia total por clave y semántica explícita para deletes y valores nulos.
Duración estimada
17 min aprox.
Dificultad
Professional
Prerrequisitos
m15
Reportar un error en esta lección

La hora de llegada no es una secuencia fiable: un update antiguo puede llegar después de uno nuevo. `SEQUENCE BY` debe usar un LSN, número de versión u otra columna monotónica del origen. Si hay empates, un `struct` con campos de desempate produce un orden lexicográfico estable.

El pipeline también debe decidir si un `NULL` borra el valor o significa 'campo no enviado', y cómo identificar borrados. La clave no debe cambiar silenciosamente; una modificación de clave suele modelarse como delete de la antigua e insert de la nueva.

Modelo mental

Un feed CDC describe transiciones, no filas independientes. Para reconstruir una entidad se necesita una clave estable, una operación y una secuencia total por clave. El timestamp de llegada no suele bastar: dos actualizaciones pueden atravesar particiones o reintentos y aparecer fuera de orden. La secuencia debe provenir del log de origen —LSN, SCN, versión o una estructura compuesta— y resolver empates de forma determinista. Deletes deben representarse explícitamente, y los nulls requieren semántica: pueden significar establecer null o simplemente campo ausente en una actualización parcial. Antes de aplicar cambios se valida el contrato, se deduplican reenvíos y se conserva el raw feed. Una clave mutable se trata como delete más insert o mediante una identidad inmutable separada. Este modelo permite demostrar el estado final ante replay y es requisito conceptual tanto para un `MERGE` manual como para AUTO CDC.

Secuencia total por clave

Orden determinista que permite comparar cualquier par de cambios de la misma entidad, incluidos empates.

Hace que el estado reconstruido sea idéntico en ejecución normal, reintento y replay.
Tombstone

Evento que representa la eliminación lógica de una clave sin depender de que la fila desaparezca físicamente del feed.

Permite propagar deletes y cerrar historia en vez de dejar entidades obsoletas downstream.
Actualización parcial

Cambio que especifica solo algunos atributos y deja el resto sin modificar.

Obliga a distinguir null de campo ausente para no borrar datos accidentalmente al aplicar CDC.
SQLOrden compuesto para CDC
SELECT
  customer_id,
  operation,
  sequence_number,
  event_ts,
  named_struct(
    'sequence_number', sequence_number,
    'event_ts', event_ts
  ) AS cdc_sequence
FROM STREAM(main.bronze.customer_cdc);

El primer campo del struct debe representar el orden autoritativo del origen; el timestamp solo desempata si su calidad está garantizada.

Puntos clave

  • La secuencia se evalúa por clave y debe resolver eventos fuera de orden.
  • `APPLY AS DELETE WHEN` convierte una condición del feed en eliminación lógica del target.
  • `IGNORE NULL UPDATES` solo es correcto cuando los nulos significan ausencia de cambio.

Evita

  • Ordenar por `current_timestamp()` y permitir que el evento más tardío en llegar sobrescriba al más nuevo del origen.
  • Activar `IGNORE NULL UPDATES` cuando un nulo representa realmente una eliminación de atributo.

Recuerdo activo

¿Por qué un timestamp de ingesta no es un buen `SEQUENCE BY`?

Borrador privado · solo en este navegador
03
Operación

Keys y sequence_by

AUTO CDC es el nombre actual de las APIs de pipelines que reemplazan a APPLY CHANGES y automatizan orden, deduplicación, deletes y SCD.

Objetivo
AUTO CDC es el nombre actual de las APIs de pipelines que reemplazan a APPLY CHANGES y automatizan orden, deduplicación, deletes y SCD.
Duración estimada
17 min aprox.
Dificultad
Professional
Prerrequisitos
m15
Reportar un error en esta lección

En SQL se declara una streaming table target y un flow `AUTO CDC INTO`. En Python se usa la API equivalente de Spark Declarative Pipelines en Lakeflow. La fuente debe ser streaming y la clave, secuencia y reglas de borrado quedan en la definición declarativa.

`APPLY CHANGES` sigue disponible por compatibilidad y comparte sintaxis, pero Databricks recomienda AUTO CDC. En documentación, código nuevo y respuestas de diseño debe aparecer el nombre actual; mencionar APPLY CHANGES solo aclara una configuración anterior o una migración.

Modelo mental

AUTO CDC es la API actual de Lakeflow pipelines para convertir un feed de cambios en una tabla SCD sin implementar manualmente orden, deduplicación y aplicación. Reemplaza el nombre anterior `APPLY CHANGES`; las APIs antiguas siguen disponibles, pero la documentación recomienda `AUTO CDC`. En Python se declara una streaming table destino y se crea un flow con `dp.create_auto_cdc_flow`; en SQL se usa `AUTO CDC INTO`. El autor aporta claves, `sequence_by`, reglas de delete, tratamiento de nulls, columnas y tipo SCD. El servicio se ocupa de eventos fuera de orden dentro de su semántica, pero no inventa un contrato correcto: una secuencia ambigua o clave inestable sigue produciendo un modelo defectuoso. También conviene distinguir Lakeflow pipelines, que extiende el framework declarativo con capacidades administradas, del proyecto Apache Spark Declarative Pipelines; AUTO CDC es una capacidad Databricks de Lakeflow, no una API portátil del núcleo Apache.

AUTO CDC

API administrada de Lakeflow pipelines que aplica un change feed ordenado a una tabla SCD tipo 1 o 2.

Reduce lógica manual propensa a errores y es la terminología actual recomendada por Databricks.
sequence_by

Expresión escalar o estructurada que establece el orden de cambios para cada clave del flujo.

Gobierna la resolución de eventos tardíos y la construcción correcta de estado e intervalos.
apply_as_deletes

Condición que identifica qué registros del feed representan eliminaciones de la entidad destino.

Sin ella, un tombstone podría tratarse como upsert y dejar datos que el origen ya eliminó.
SQLAUTO CDC SCD tipo 1
CREATE OR REFRESH STREAMING TABLE main.silver.customers_current;

CREATE FLOW customers_cdc_flow AS AUTO CDC INTO
  main.silver.customers_current
FROM STREAM(main.bronze.customer_cdc)
KEYS (customer_id)
APPLY AS DELETE WHEN operation = 'DELETE'
SEQUENCE BY struct(sequence_number, event_ts)
COLUMNS * EXCEPT (operation, sequence_number)
STORED AS SCD TYPE 1;

`APPLY CHANGES INTO` es la denominación anterior. Para implementaciones nuevas usa `AUTO CDC INTO`.

Puntos clave

  • AUTO CDC sustituye a APPLY CHANGES con la misma finalidad y sintaxis equivalente.
  • El target de un flow AUTO CDC es una streaming table.
  • La declaración no elimina la necesidad de validar claves, secuencia, deletes y retención.

Evita

  • Copiar ejemplos antiguos y presentar APPLY CHANGES como la API recomendada actual.
  • Omitir `SEQUENCE BY` autoritativo y asumir que el pipeline puede inferir el orden correcto.

Recuerdo activo

¿Cuál es la relación entre AUTO CDC y APPLY CHANGES?

Borrador privado · solo en este navegador
04
Diagnóstico

AUTO CDC y el alias anterior APPLY CHANGES

SCD tipo 1 conserva el valor vigente; SCD tipo 2 crea intervalos de validez para responder cómo era una dimensión en un momento pasado.

Objetivo
SCD tipo 1 conserva el valor vigente; SCD tipo 2 crea intervalos de validez para responder cómo era una dimensión en un momento pasado.
Duración estimada
17 min aprox.
Dificultad
Professional
Prerrequisitos
m15
Reportar un error en esta lección

Tipo 1 sobrescribe atributos y es apropiado para correcciones donde la historia no aporta valor. Tipo 2 conserva versiones con columnas de inicio y fin administradas por el pipeline. Consultas de hechos históricos pueden unir el event time del hecho con el intervalo de la dimensión.

Guardar historia multiplica filas y exige decidir qué columnas disparan una nueva versión. `TRACK HISTORY ON` puede limitar ese conjunto en AUTO CDC. Campos operativos como `ingested_at` no deberían crear una versión de negocio cada vez que cambia.

Modelo mental

SCD tipo 1 y tipo 2 responden preguntas distintas. Tipo 1 representa la mejor versión vigente de cada clave y sobrescribe atributos; es compacto y sencillo, pero no puede responder qué valor se conocía antes. Tipo 2 conserva una fila por periodo de validez, normalmente con fronteras técnicas de inicio y fin, y permite consultas temporales. No todo cambio merece historia: corregir un typo técnico puede no requerir una nueva versión, mientras que dirección, segmento o consentimiento sí pueden afectar hechos y auditoría. La secuencia del CDC define cuándo comienza cada versión, no el instante en que Databricks la procesó. Deletes pueden cerrar el intervalo activo o retirar la fila vigente según el tipo. El modelador debe separar business effective time de system processing time; una SCD2 estándar basada en secuencia no es automáticamente bitemporal ni conserva cuándo se descubrió una corrección.

SCD tipo 1

Modelo que mantiene una única fila vigente por clave y reemplaza atributos con el cambio más reciente.

Es apropiado cuando solo importa el estado actual y minimiza coste y complejidad.
SCD tipo 2

Modelo que conserva múltiples versiones por clave con intervalos de validez no solapados.

Permite análisis as-of y auditoría de atributos cuyo valor histórico afecta decisiones.
Intervalo de validez

Rango temporal durante el cual una versión de dimensión se considera efectiva.

Es la base para joins temporales correctos y para detectar huecos o solapamientos de historia.
SQLAUTO CDC SCD tipo 2 selectivo
CREATE OR REFRESH STREAMING TABLE main.silver.customers_history;

CREATE FLOW customers_history_flow AS AUTO CDC INTO
  main.silver.customers_history
FROM STREAM(main.bronze.customer_cdc)
KEYS (customer_id)
APPLY AS DELETE WHEN operation = 'DELETE'
SEQUENCE BY sequence_number
COLUMNS * EXCEPT (operation)
STORED AS SCD TYPE 2
TRACK HISTORY ON (name, segment, country);

Verifica los nombres de las columnas de control que expone el target antes de diseñar consultas point-in-time.

Puntos clave

  • SCD 1 responde 'cuál es el valor actual'; SCD 2 responde también 'cuál era entonces'.
  • La secuencia determina intervalos; no debe confundirse con la fecha de carga.
  • El conjunto de columnas históricas controla ruido y coste de almacenamiento.

Evita

  • Usar SCD 2 para cada atributo técnico y generar versiones sin valor analítico.
  • Sobrescribir con SCD 1 cuando auditoría o reporting histórico necesitan el valor vigente al producirse el hecho.

Recuerdo activo

¿Qué problema evita `TRACK HISTORY ON` en un target SCD 2?

Borrador privado · solo en este navegador
05
Decisión de diseño

SCD 1, SCD 2 y borrados

AUTO CDC FROM SNAPSHOT procesa snapshots ordenados cuando la fuente no ofrece un log de cambios, pero necesita una versión fiable y cobertura completa.

Objetivo
AUTO CDC FROM SNAPSHOT procesa snapshots ordenados cuando la fuente no ofrece un log de cambios, pero necesita una versión fiable y cobertura completa.
Duración estimada
17 min aprox.
Dificultad
Professional
Prerrequisitos
m15
Reportar un error en esta lección

Algunas bases entregan una extracción completa diaria. Comparar snapshots permite inferir inserts, updates y deletes, y las APIs AUTO CDC FROM SNAPSHOT automatizan esa materialización. Cada snapshot debe tener una versión estrictamente creciente y representar el conjunto completo esperado.

Una extracción parcial confundida con snapshot completo produciría borrados masivos. Antes de publicar se validan conteos, particiones y marcadores de finalización. Si el origen sí ofrece CDC continuo, AUTO CDC normal evita comparar toda la dimensión y reduce latencia.

Modelo mental

AUTO CDC FROM SNAPSHOT resuelve fuentes que no exponen log de cambios: compara snapshots completos consecutivos, deriva inserts, updates y deletes sintéticos y aplica la misma lógica SCD. No recupera transiciones que ocurrieron y se revirtieron entre dos capturas; solo conoce las diferencias observables entre estados. La API actual está disponible en la interfaz Python de Lakeflow pipelines y necesita snapshots en orden ascendente mediante una versión fiable. Un snapshot debe ser completo y coherente para su versión; si llega truncado, el comparador puede interpretar miles de ausencias como deletes legítimos. Por ello, la adquisición publica primero un manifest con conteos, checksum, tiempo de extracción y estado completo. Los snapshots fuera de orden se ignoran según la semántica documentada, así que la versión no puede derivarse de una hora de llegada susceptible a retrasos.

Snapshot completo

Imagen coherente de todas las claves en alcance para una versión concreta de la fuente.

Las ausencias se interpretan como deletes, por lo que incompletitud puede causar pérdida masiva downstream.
Versión de snapshot

Identificador monotónico y estable que ordena las imágenes por su secuencia de extracción lógica.

Permite comparar pares correctos y evita aplicar una entrega retrasada como si fuera el estado más nuevo.
Cambio sintético

Insert, update o delete inferido al comparar dos snapshots, no emitido directamente por el sistema origen.

Aporta incrementalidad, pero no puede revelar transiciones intermedias invisibles entre capturas.
PythonContrato mínimo de un snapshot
snapshot_manifest = {
    "snapshot_version": 2026072101,
    "source_table": "crm.customers",
    "expected_rows": 12_450_230,
    "completed": True,
    "landing_path": "/Volumes/main/landing/customers/2026-07-21/",
}

assert snapshot_manifest["completed"]
assert snapshot_manifest["expected_rows"] > 0

La función que entrega snapshots a AUTO CDC debe ordenar versiones y devolver `None` cuando no haya una nueva disponible.

Puntos clave

  • Snapshot CDC sirve cuando no existe un feed de cambios fiable.
  • La versión del snapshot debe ordenar entregas y no reutilizarse.
  • La completitud se comprueba antes de interpretar ausencias como deletes.

Evita

  • Interpretar una partición ausente por fallo de extracción como eliminación de todos sus clientes.
  • Procesar snapshots fuera de orden y reabrir una versión antigua como si fuera nueva.

Recuerdo activo

¿Qué validación evita deletes falsos al comparar snapshots?

Borrador privado · solo en este navegador
5 lecciones pendientes

Vista de lectura · sin ejecución

change-data-feed.ipynb

Delta Lake examples · commit 82ed214

notebooks/pyspark/change-data-feed.ipynb