Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.
Guardar progresoDelta Lake: ACID, esquema, historial y DML
Usa el transaction log para construir tablas fiables, auditables e idempotentes.
01Modelo mentalTransaction log y propiedades ACID
El transaction log ordena commits y permite snapshots consistentes sobre archivos Parquet.
+
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.
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.
Secuencia versionada de acciones que define metadatos y archivos activos de una tabla Delta.
Es la fuente de verdad para snapshots, historial y concurrencia.Modelo en el que escritores avanzan sin bloqueo global y validan conflictos al confirmar.
Permite paralelismo, pero exige manejar reintentos y operaciones conflictivas.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
02ImplementaciónTablas managed, external y SET MANAGED
Managed y external describen el ciclo de vida; una external Delta elegible puede convertirse con SET MANAGED.
+
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.
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.
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.Objeto gobernado cuyos archivos residen en una ubicación externa administrada separadamente.
Permite interoperabilidad o control cloud, pero DROP no elimina esos archivos.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
03OperaciónSchema enforcement y evolution
DDL define objetos y DML modifica filas; MERGE expresa upsert con condiciones claras.
+
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.
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.
Lenguaje de definición que crea o modifica objetos, esquema y propiedades.
Distingue cambios estructurales de modificaciones de filas.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.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
04DiagnósticoMERGE e idempotencia
Schema enforcement rechaza incompatibilidades; schema evolution acepta cambios configurados de forma explícita.
+
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.
(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.
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.Cambio controlado del esquema de destino durante operaciones compatibles.
Permite adaptar columnas sin desactivar la protección general.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
05Decisión de diseñoHistory, time travel y VACUUM
Time travel consulta snapshots retenidos; VACUUM elimina archivos ya no referenciados tras un umbral.
+
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.
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.
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.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.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