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.
- Explicar snapshots y concurrencia optimista
- Aplicar MERGE, UPDATE y DELETE correctamente
- Diferenciar tipos de tabla, conversión, schema evolution y time travel
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.
- Objetivo
- El transaction log ordena commits y permite snapshots consistentes sobre archivos Parquet.
- Duración estimada
- 17 min aprox.
- Dificultad
- Associate + Professional
- Prerrequisitos
- m05
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.
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.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 navegador02Implementació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.
- 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
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.
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.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 navegador03Operació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.
- 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
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.
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.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 navegador04Diagnó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.
- 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
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.
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.(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 navegador05Decisió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.
- 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
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.
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.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