Saltar al contenido
Lakehouse LabLakehouse LabPreparación Databricks Data Engineer
Módulo 22 · Lección

Implementación declarativa

Contenido abierto

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

Lecció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.

Duración
30 min aprox.
Objetivo
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.
Siguiente paso
Continuar con la siguiente lección
Ver detalles del módulo

Proyecto de pipeline declarativo

Construye una cadena declarativa con calidad, CDC, orquestación y operación documentada.

Al terminar podrás
  • Entregar datasets incrementales fiables
  • Probar dependencias y reglas
  • Operar fallos y backfills
Ver fuentes y revisión

Metadatos editoriales

Última revisión
21 jul 2026
Nivel
Professional
Ruta relacionada
pipelines
Dominios blueprint
Production pipelines
Estado
Revisión editorial interna
Fuentes principales
Best practices for Spark Declarative Pipelines · Databricks · AUTO CDC APIs · Databricks
Reportar un error
02
Implementación

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.

Mostrar prerrequisitos
Dificultad
Professional
Prerrequisitos
m21
Reportar un error en esta lección

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.

Modelo mental

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.

Semántica append

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.
Semántica CDC

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.
Nombre legado

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.
SQLClientes actuales con AUTO CDC
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.

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.

Recuerdo activo

¿Qué resuelve AUTO CDC frente a un append simple del feed?

Borrador privado · solo en este navegador
5 lecciones pendientes

Fuente revisada · vista externa

Databricks Free Declarative Pipelines

Databricks Free Declarative Pipelines · commit a515370

docs/3-2-building-bronze-sql.md

Lectura en GitHub

Este notebook se abre desde su fuente revisada

El repositorio no permite republicar su contenido dentro de Lakehouse Lab. Conservamos la misma experiencia lateral, la ruta exacta y el commit auditado, y dejamos la lectura en GitHub para respetar la autoría.

Autor
andkret
Licencia
No verificada
Formato
project
Ver notebook en GitHub