Saltar al contenido

Delta

Menú

Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.

Guardar progreso

Delta Lake: ACID, esquema, historial y DML

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

Lectura pública
Detalles
Reto observable

Implementa una escritura Delta idempotente y demuestra con historial, claves y un segundo run que el reintento conserva el mismo estado lógico.

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
Prerrequisitos
m05
Última revisión
25 ago 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.

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.

SQLHistorial de commits
DESCRIBE HISTORY main.silver.customers;

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

¿Qué evita que un lector vea media escritura?

Profundiza

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.
Resumen

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

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.

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.

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

Profundiza

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.
Resumen

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
03
Operación

Schema enforcement y evolution

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

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.

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.

¿Por qué condicionar updated_at?

Profundiza

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.
Resumen

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
04
Diagnóstico

MERGE e idempotencia

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

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.

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.

¿mergeSchema convierte cualquier tipo incompatible?

Profundiza

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.
Resumen

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

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.

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.

¿DESCRIBE HISTORY garantiza time travel ilimitado?

Profundiza

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.
Resumen

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

Vista de lectura · sin ejecución

01_quickstart.ipynb

Delta Lake examples · commit 82ed214

notebooks/pyspark/01_quickstart.ipynb

Módulo 06

Contenido del módulo