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

Transaction log y propiedades ACID

Contenido abierto

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

Lección 1 de 5

Transaction log y propiedades ACID

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

Duración
17 min aprox.
Objetivo
El transaction log ordena commits y permite snapshots consistentes sobre archivos Parquet.
Siguiente paso
Continuar con la siguiente lección
Ver detalles del módulo

Delta Lake: ACID, esquema, historial y DML

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

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.

Mostrar prerrequisitos
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
5 lecciones pendientes

Vista de lectura · sin ejecución

01_quickstart.ipynb

Delta Lake examples · commit 82ed214

notebooks/pyspark/01_quickstart.ipynb