Saltar al contenido
Lakehouse LabLakehouse LabPreparación Databricks Data Engineer
Módulo 06 · Associate + Professional

Delta

Contenido abierto

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

Associate + Professional

Delta Lake: ACID, esquema, historial y DML

Usa el transaction log para construir tablas fiables, auditables e idempotentes.

Lectura pública
Al terminar podrás
  • Explicar snapshots y concurrencia optimista
  • Aplicar MERGE, UPDATE y DELETE correctamente
  • Diferenciar tipos de tabla, conversión, schema evolution y time travel
Ver fuentes y revisión

Metadatos editoriales

Última revisión
21 jul 2026
Nivel
Associate + Professional
Ruta relacionada
core
Dominios blueprint
Delta Lake · Data management
Estado
Revisión editorial interna
Fuentes principales
Delta Lake · Convertir a managed con SET MANAGED
Reportar un error
01
Modelo mental

Transaction log y propiedades ACID

El transaction log ordena commits y permite snapshots consistentes sobre archivos Parquet.

Objetivo
El transaction log ordena commits y permite snapshots consistentes sobre archivos Parquet.
Duración estimada
17 min aprox.
Dificultad
Associate + Professional
Prerrequisitos
m05
Reportar un error en esta lección

Cada operación escribe acciones atómicas en _delta_log; los lectores construyen un snapshot válido sin observar archivos parcialmente publicados.

La concurrencia optimista detecta conflictos al confirmar. ACID protege la tabla, pero no vuelve idempotente una lógica que inserta duplicados.

Modelo mental

Una tabla Delta es un historial ordenado de acciones sobre archivos, no un directorio cuyo contenido actual se deduce listándolo. Cada commit añade una versión al transaction log con archivos agregados, retirados y metadatos. Un lector reconstruye un snapshot consistente desde log y checkpoints, y solo lee archivos activos en esa versión. Los escritores usan concurrencia optimista: trabajan sobre un snapshot y al confirmar verifican si cambios concurrentes entran en conflicto. ACID garantiza atomicidad y aislamiento del commit, pero no conoce la clave de negocio ni impide que un pipeline append inserte el mismo pedido dos veces. Idempotencia pertenece a la lógica y debe diseñarse sobre estas garantías.

Transaction log

Secuencia versionada de acciones que define metadatos y archivos activos de una tabla Delta.

Es la fuente de verdad para snapshots, historial y concurrencia.
Concurrencia optimista

Modelo en el que escritores avanzan sin bloqueo global y validan conflictos al confirmar.

Permite paralelismo, pero exige manejar reintentos y operaciones conflictivas.
Idempotencia

Propiedad por la que repetir una operación con la misma entrada produce el mismo estado lógico.

ACID no la aporta automáticamente y es esencial para retries seguros.
SQLHistorial de commits
DESCRIBE HISTORY main.silver.customers;

Relaciona operation, user y parámetros con el incidente investigado.

Puntos clave

  • El log define el snapshot
  • Lectores y escritores pueden concurrir
  • ACID no sustituye claves idempotentes

Evita

  • Modificar archivos Delta fuera del protocolo
  • Confundir commit atómico con deduplicación

Recuerdo activo

¿Qué evita que un lector vea media escritura?

Borrador privado · solo en este navegador
02
Implementación

Tablas managed, external y SET MANAGED

Managed y external describen el ciclo de vida; una external Delta elegible puede convertirse con SET MANAGED.

Objetivo
Managed y external describen el ciclo de vida; una external Delta elegible puede convertirse con SET MANAGED.
Duración estimada
17 min aprox.
Dificultad
Associate + Professional
Prerrequisitos
m05
Reportar un error en esta lección

En una managed table, Unity Catalog administra datos y metadatos; en una external table gobierna el objeto, pero DROP TABLE no borra los archivos de la ubicación externa.

ALTER TABLE … SET MANAGED conserva nombre, historial, permisos y vistas. Exige Delta y compute compatible; antes se inventarían todos los lectores, features, optimizaciones y streams. UNSET MANAGED permite rollback dentro de la ventana documentada.

Modelo mental

Managed y external describen el control del ciclo de vida y la ubicación; no describen si una tabla es Delta, segura o accesible externamente. En una managed table de Unity Catalog, Databricks administra ubicación y archivos junto con metadatos y puede aplicar capacidades gestionadas como predictive optimization cuando corresponda. En una external table, los archivos permanecen bajo una ruta gobernada que la organización controla; DROP TABLE elimina el objeto del catálogo, pero no los bytes. Ambas necesitan privilegios y pueden usar Delta. Para una external Delta elegible, ALTER TABLE SET MANAGED convierte el objeto conservando nombre, permisos, vistas, configuración e historial; no equivale a crear una copia CTAS.

Managed table

Tabla cuyo almacenamiento de datos y metadatos gestiona Unity Catalog como una unidad de ciclo de vida.

Es la opción recomendada cuando no se necesita controlar una ubicación externa.
External table

Objeto gobernado cuyos archivos residen en una ubicación externa administrada separadamente.

Permite interoperabilidad o control cloud, pero DROP no elimina esos archivos.
SET MANAGED

Operación ALTER TABLE que convierte una external Delta elegible en managed conservando identidad, historial, permisos y vistas.

Evita la pérdida de continuidad de CTAS y ofrece redirección y rollback controlados.
SQLConvertir y verificar
DESCRIBE DETAIL main.learning.external_orders;
ALTER TABLE main.learning.external_orders SET MANAGED;
DESCRIBE EXTENDED main.learning.external_orders;
-- Rollback durante la ventana admitida:
-- ALTER TABLE main.learning.external_orders UNSET MANAGED;

Usa Serverless o DBR 17.3 LTS+; pausa OPTIMIZE y valida todos los lectores y escritores antes y después.

Puntos clave

  • Ambas pueden ser Delta
  • SET MANAGED conserva continuidad
  • La conversión exige inventario y reinicio de streams

Evita

  • Usar CTAS y perder continuidad sin necesidad
  • Convertir sin inventariar clientes por ruta ni reiniciar streams

Recuerdo activo

¿Qué conserva SET MANAGED frente a recrear por CTAS?

Borrador privado · solo en este navegador
03
Operación

Schema enforcement y evolution

DDL define objetos y DML modifica filas; MERGE expresa upsert con condiciones claras.

Objetivo
DDL define objetos y DML modifica filas; MERGE expresa upsert con condiciones claras.
Duración estimada
17 min aprox.
Dificultad
Associate + Professional
Prerrequisitos
m05
Reportar un error en esta lección

CREATE OR REPLACE redefine una tabla de forma atómica; INSERT añade, UPDATE cambia y DELETE elimina filas. MERGE combina coincidencias y no coincidencias desde una fuente.

La fuente de MERGE debe tener como máximo una fila relevante por clave o definir previamente cuál gana. Añade una condición de secuencia para impedir que un evento antiguo sobrescriba uno reciente.

Modelo mental

DDL define estructura y objetos; DML expresa cambios sobre filas. En Delta, CREATE, ALTER o REPLACE modifican metadatos y versiones; INSERT, UPDATE, DELETE y MERGE producen nuevos commits. MERGE no significa simplemente sincronizar: compara una fuente con un destino mediante una condición y aplica cláusulas a filas coincidentes o no coincidentes. Para ser determinista, la fuente debe producir como máximo una versión ganadora por clave y las reglas deben decidir cómo tratar eventos tardíos. UPDATE SET * no corrige una fuente ambigua. Antes de escribir se define clave, secuencia, semántica de borrado y comportamiento de reintento.

DDL

Lenguaje de definición que crea o modifica objetos, esquema y propiedades.

Distingue cambios estructurales de modificaciones de filas.
MERGE

Operación Delta que aplica cláusulas condicionadas según coincidencia entre una fuente y un destino.

Implementa upsert y CDC cuando clave y orden están bien definidos.
Secuencia

Valor monotónico de negocio o fuente que ordena versiones de una misma entidad.

Impide que eventos tardíos reviertan un estado más reciente.
SQLUpsert con secuencia
MERGE INTO main.silver.customers t
USING updates s ON t.customer_id = s.customer_id
WHEN MATCHED AND s.updated_at >= t.updated_at THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *;

Deduplica updates por customer_id antes del MERGE.

Puntos clave

  • CREATE OR REPLACE sustituye el objeto
  • MERGE necesita fuente determinista
  • La secuencia protege de eventos antiguos

Evita

  • Múltiples filas fuente para una clave
  • UPDATE sin condición temporal en CDC

Recuerdo activo

¿Por qué condicionar updated_at?

Borrador privado · solo en este navegador
04
Diagnóstico

MERGE e idempotencia

Schema enforcement rechaza incompatibilidades; schema evolution acepta cambios configurados de forma explícita.

Objetivo
Schema enforcement rechaza incompatibilidades; schema evolution acepta cambios configurados de forma explícita.
Duración estimada
17 min aprox.
Dificultad
Associate + Professional
Prerrequisitos
m05
Reportar un error en esta lección

Enforcement evita escribir columnas o tipos incompatibles con el contrato. Evolution puede añadir columnas durante append o merge cuando se habilita por operación o configuración soportada.

Aceptar columnas nuevas no significa aceptar cualquier cambio de tipo o semántica. Bronze puede ser más tolerante; Silver debe controlar contrato, nulos y consumidores.

Modelo mental

Schema enforcement protege la tabla frente a escrituras incompatibles; schema evolution modifica el contrato bajo una autorización explícita. Enforcement compara nombres, tipos y estructura con el esquema de destino y evita aceptar silenciosamente datos imposibles. Evolution puede añadir columnas o realizar cambios soportados cuando se habilita en la operación adecuada. No es una licencia para que una columna cambie de significado o para activar autoMerge global sin revisión. Bronze puede tolerar atributos nuevos para no perder ingestión; Silver debe decidir si son válidos, cómo se rellenan históricamente y qué consumidores se rompen. El esquema es sintaxis, mientras el contrato incluye semántica y calidad.

Schema enforcement

Validación en escritura que rechaza datos que no cumplen el esquema admitido por la tabla.

Evita corrupción silenciosa y hace visibles los cambios de productor.
Schema evolution

Cambio controlado del esquema de destino durante operaciones compatibles.

Permite adaptar columnas sin desactivar la protección general.
Column mapping

Funcionalidad Delta que identifica columnas más allá de su nombre físico y habilita ciertos cambios de metadatos.

Afecta renombres, drops y compatibilidad de clientes.
PySparkEvolución controlada
(incoming.write
  .format("delta")
  .mode("append")
  .option("mergeSchema", "true")
  .saveAsTable("main.bronze.orders"))

Registra columnas nuevas y prueba consumidores antes de propagarlas a Silver.

Puntos clave

  • Enforcement protege el contrato
  • Evolution es opt-in
  • Cambio sintáctico no garantiza compatibilidad semántica

Evita

  • Activar autoMerge global sin gobernanza
  • Cambiar STRING a INT suponiendo evolución automática

Recuerdo activo

¿mergeSchema convierte cualquier tipo incompatible?

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

History, time travel y VACUUM

Time travel consulta snapshots retenidos; VACUUM elimina archivos ya no referenciados tras un umbral.

Objetivo
Time travel consulta snapshots retenidos; VACUUM elimina archivos ya no referenciados tras un umbral.
Duración estimada
17 min aprox.
Dificultad
Associate + Professional
Prerrequisitos
m05
Reportar un error en esta lección

VERSION AS OF y TIMESTAMP AS OF permiten reproducir una lectura anterior si existen log y archivos. RESTORE crea un nuevo commit que devuelve la tabla al estado elegido.

VACUUM recupera almacenamiento, pero limita time travel y puede afectar lectores de larga duración si se reduce la retención sin criterio. History no garantiza que los archivos históricos sigan disponibles.

Modelo mental

Time travel, RESTORE y VACUUM operan sobre dimensiones distintas del historial. Time travel lee un snapshot anterior por versión o timestamp, siempre que log y archivos necesarios sigan retenidos. RESTORE crea un nuevo commit cuyo estado lógico referencia el contenido de una versión elegida; no borra versiones posteriores del historial. VACUUM elimina físicamente archivos que ya no están activos y superan el umbral seguro, reduciendo la ventana real de time travel. OPTIMIZE, en cambio, reorganiza layout y no es una limpieza de historial. La retención se diseña con recuperación, lectores concurrentes y normativa; DESCRIBE HISTORY por sí solo no garantiza que un snapshot antiguo siga materializable.

Time travel

Lectura de un snapshot histórico de Delta mediante versión o timestamp disponible.

Permite auditoría, reproducción y validación antes de una recuperación.
RESTORE

Operación que publica un nuevo commit para devolver el estado lógico a un snapshot anterior.

Recupera sin reescribir manualmente archivos ni borrar el historial posterior.
VACUUM

Eliminación física de archivos obsoletos que superan la política de retención.

Ahorra almacenamiento, pero limita recuperación y time travel reales.
SQLComparar y restaurar
SELECT count(*) FROM main.silver.orders VERSION AS OF 42;
RESTORE TABLE main.silver.orders TO VERSION AS OF 42;

Valida el snapshot antes de restaurar; RESTORE no borra el historial posterior.

Puntos clave

  • Time travel depende de retención
  • RESTORE añade un commit
  • VACUUM no es compactación

Evita

  • Usar VACUUM para compactar archivos
  • Reducir retención ignorando lectores concurrentes

Recuerdo activo

¿DESCRIBE HISTORY garantiza time travel ilimitado?

Borrador privado · solo en este navegador
5 lecciones pendientes

Vista de lectura · sin ejecución

01_quickstart.ipynb

Delta Lake examples · commit 82ed214

notebooks/pyspark/01_quickstart.ipynb