Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.
Guardar progresoLección 2 de 5
Implementación declarativa
La implementación combina append de pedidos y AUTO CDC de clientes sin mezclar estados ni presentar el nombre anterior APPLY CHANGES como API nueva.
30 min aprox.
02ImplementaciónImplementación declarativa
La implementación combina append de pedidos y AUTO CDC de clientes sin mezclar estados ni presentar el nombre anterior APPLY CHANGES como API nueva.
+
Implementación declarativa
La implementación combina append de pedidos y AUTO CDC de clientes sin mezclar estados ni presentar el nombre anterior APPLY CHANGES como API nueva.
Pedidos se ingieren en bronze y se validan en silver con lectura streaming. Clientes llegan como operaciones con `source_lsn`; AUTO CDC materializa el estado actual SCD 1 o el historial SCD 2. La streaming table target se declara antes del flow y las columnas operativas se excluyen.
Gold une pedidos con clientes según la necesidad temporal. Si se necesita el cliente actual, SCD 1 basta; si la segmentación al momento del pedido importa, se usa SCD 2 y un join por intervalo. Esa decisión cambia corrección, coste y complejidad.
CREATE OR REFRESH STREAMING TABLE main.silver.customers_current;
CREATE FLOW customers_current_cdc AS AUTO CDC INTO
main.silver.customers_current
FROM STREAM(main.bronze.customers_cdc)
KEYS (customer_id)
APPLY AS DELETE WHEN operation = 'DELETE'
SEQUENCE BY source_lsn
COLUMNS * EXCEPT (operation)
STORED AS SCD TYPE 1;Valida que `source_lsn` sea monotónico por clave y que su tipo tenga un orden total estable.
¿Qué resuelve AUTO CDC frente a un append simple del feed?
Profundiza
Combinar append y CDC exige mantener semánticas separadas hasta una frontera común. Los pedidos append-only representan hechos nuevos y entran mediante un flow incremental; los clientes representan estado mutable y llegan como cambios que AUTO CDC ordena y aplica a una streaming table. `AUTO CDC` es la opción vigente recomendada por Databricks; `APPLY CHANGES` mantiene la misma sintaxis, sigue disponible y puede aparecer en preguntas Professional o código legado. Reconocer la equivalencia nominal no autoriza a mezclar los estados: cada flow conserva progreso, keys y secuencia propios. El enriquecimiento puede usar una materialized view que combine hechos y dimensión vigente o una estrategia temporal para SCD2. El proyecto evita un join stream-stream innecesario si solo requiere snapshot de dimensión y documenta qué versión del cliente se asigna a un pedido.
Modelo en el que cada registro aceptado representa un hecho adicional y no reemplaza implícitamente otra fila con la misma clave.
Es apropiado para eventos inmutables y evita introducir estado de upsert innecesario.Modelo en el que registros codifican transiciones de entidades y deben aplicarse por clave, secuencia, operación y política de historia.
Evita tratar updates y deletes como hechos independientes que duplicarían o dejarían obsoleto el estado.Término anterior aún visible y soportado, como APPLY CHANGES, cuyo reemplazo recomendado actual es AUTO CDC con sintaxis equivalente.
Permite responder exámenes y mantener código existente sin enseñar una API antigua como primera opción.Resumen
Puntos clave
- AUTO CDC es la API actual; APPLY CHANGES es la denominación anterior.
- Append y CDC usan flows/targets diferentes y convergen en consumo.
- El join dimensional se alinea con SCD 1 actual o SCD 2 point-in-time según requisito.
Evita
- Hacer append de updates CDC y dejar múltiples estados vigentes por cliente.
- Elegir SCD 1 cuando reporting necesita la dimensión histórica al momento del pedido.