CDC, SCD Type 1 y SCD Type 2 con AUTO CDC

Objetivo: aprender cómo Lakeflow gestiona automáticamente INSERT, UPDATE y DELETE, y cómo mantener el estado actual o el historial completo de una entidad.

1. ¿Qué es CDC?

CDC significa Change Data Capture.

Imagina que tenemos una tabla de clientes y nos llegan estos eventos desde Kafka:

En lugar de recibir siempre una tabla completa, recibimos los cambios que han ocurrido.

Lakeflow puede aplicar estos eventos automáticamente mediante AUTO CDC, evitando que tengamos que implementar manualmente la lógica de MERGE, las versiones históricas y parte de la gestión de eventos desordenados.

2. SCD Type 1 vs SCD Type 2

La diferencia es sencilla:

• SCD Type 1: conserva únicamente el último estado.

• SCD Type 2: conserva el historial de cambios.

Vamos a visualizarlo.

Fíjate en algo fundamental: SCD Type 2 permite reconstruir cómo era el cliente en un momento anterior.

Esto resulta especialmente útil para auditorías, dimensiones históricas y análisis temporales.

3. ¿Cómo se implementa con AUTO CDC?

Supongamos que ya tienes una Streaming Table llamada bronze_customer_events, con los siguientes campos:

customer_id
city
operation       -- INSERT, UPDATE, DELETE
sequence_num    -- orden lógico de los cambios

Queremos crear una Silver que mantenga siempre el último estado del cliente.

Ejemplo SCD Type 1

from pyspark import pipelines as dp
from pyspark.sql.functions import col, expr

dp.create_streaming_table("silver_customers")

dp.create_auto_cdc_flow(
    target="silver_customers",
    source="bronze_customer_events",
    keys=["customer_id"],
    sequence_by=col("sequence_num"),
    apply_as_deletes=expr("operation = 'DELETE'"),
    except_column_list=["operation", "sequence_num"],
    stored_as_scd_type=1
)

¿Qué significa cada parámetro?

El código utiliza la API actual dp.create_auto_cdc_flow(). Databricks recomienda AUTO CDC frente al antiguo APPLY CHANGES. Databricks on AWS

4. ¿Y para SCD Type 2?

¡Prácticamente el mismo código!

Solo cambiamos:

stored_as_scd_type=2

Y Lakeflow mantiene las versiones históricas añadiendo las columnas:

• __START_AT: secuencia desde la que es válida la versión.

• __END_AT: secuencia hasta la que es válida.

Cuando __END_AT IS NULL, la versión está vigente.

Importante: el valor de sequence_by no tiene por qué ser una fecha. Puede ser un número de secuencia, un timestamp o incluso un STRUCT para desempatar eventos. Databricks on Google Cloud

5. ¿Qué pasa si los eventos llegan desordenados?

Imagina que recibimos estos cambios en este orden:

¿Debería terminar el cliente viviendo en Madrid?

No. El estado más reciente según sequence_by es Valencia (12).

AUTO CDC utiliza ese campo para ordenar lógicamente los cambios, incluso si llegan desordenados. En SCD Type 2 puede incorporar un evento tardío dentro del historial correspondiente. Databricks on AWS

Por eso es tan importante elegir correctamente sequence_by: no deberíamos utilizar ingest_time si lo que necesitamos es respetar el orden real de los cambios del origen.

6. ¿Dónde aplicaría esto en vuestra arquitectura?

Una advertencia importante: AUTO CDC necesita eventos de cambios identificables y ordenables. Si únicamente recibimos snapshots completos de una tabla, habría que estudiar AUTO CDC FROM SNAPSHOT, que compara snapshots para detectar diferencias. Databricks on AWS

7. Mini ejercicio

Qué debes recordar:

• CDC representa los cambios de una entidad.

• SCD1 conserva el estado actual.

• SCD2 conserva el historial.

• AUTO CDC automatiza la aplicación de cambios y su ordenación lógica.

En la lección 9 veremos cómo combinar Batch, Streaming, Triggered y Continuous, y cuándo merece la pena pagar por mantener un pipeline ejecutándose continuamente.