Entendiendo el Transaction Log (_delta_log): el verdadero cerebro detrás de Delta Lake
- 3 jun
- 3 min de lectura
Introducción
En el post anterior vimos cómo los datos recorren las distintas capas de Databricks hasta terminar almacenados físicamente como archivos Parquet dentro de una Delta Table. Sin embargo, esto nos lleva a realizar una serie de preguntas muy importantes:
Si los archivos Parquet ya existen físicamente, ¿quién decide cuáles forman parte de la tabla?
¿Quién mantiene el historial de cambios?
¿Cómo sabe Delta Lake qué información es válida?
La respuesta está en uno de los componentes más importantes de toda la arquitectura:
🔥 El Transaction Log (_delta_log)
Una analogía sencilla: la bitácora de una tabla
Para entender mejor este concepto, imaginemos una bitácora. Ese cuaderno donde registramos todo lo que ocurre durante una jornada:
Fecha
Hora
Actividad realizada
Cambios efectuados
El Transaction Log cumple exactamente ese papel dentro de Delta Lake.
¿Dónde vive el Transaction Log?
Dentro de cada Delta Table existe una carpeta especial:
A simple vista parecen archivos JSON comunes. Pero en realidad contienen uno de los activos más importantes de toda la tabla.
Lo que el Transaction Log NO almacena
Aquí existe una confusión muy común, los archivos JSON del deltalog no contienen los datos de negocio.
Los datos continúan almacenándose físicamente dentro de archivos Parquet. Por lo tanto:
❌ El deltalog no reemplaza a Parquet.
❌ El deltalog no contiene todos los registros de la tabla.
Lo que realmente almacena el Transaction Log
Lo que almacena es aún más importante:
👉 El historial de cambios de la tabla.
Cada operación realizada queda registrada dentro del log. Y gracias a ello Delta Lake puede reconstruir el estado correcto de la tabla en cualquier momento.
Las capacidades que habilita el Transaction Log
Gracias a esta capa transaccional obtenemos funcionalidades como:
⏪ Time Travel: Permite consultar versiones anteriores de una tabla.
🔒 Transacciones ACID: Garantiza consistencia durante las operaciones.
⚡ Control de concurrencia: Permite que múltiples procesos trabajen sobre los mismos datos de forma segura.
📜 Historial de versiones: Mantiene trazabilidad completa sobre los cambios realizados.
¿Qué ocurre durante las operaciones más comunes?
Cada vez que ejecutamos una operación sobre una Delta Table, se genera una nueva versión dentro del Transaction Log:
📤 INSERT
Se agregan nuevos datos.
Delta Lake registra una nueva transacción.
Y se genera una nueva versión.
🔚 UPDATE
No modifica versiones anteriores.
Genera una nueva versión que representa el nuevo estado de la tabla.
❌ DELETE
Aquí ocurre algo interesante:
La eliminación inicialmente es lógica.
Los datos dejan de ser visibles para la versión actual de la tabla.
Sin embargo, los archivos físicos pueden seguir existiendo hasta que procesos posteriores los eliminen definitivamente, por ejemplo: VACUUM responsable de esa limpieza física.
⚙️ MERGE
Combina múltiples operaciones:
INSERT
UPDATE
DELETE
Y todas quedan registradas dentro del Transaction Log.
La relación entre el log y los archivos Parquet
Este es probablemente el punto más importante de todo Delta Lake:
Cada registro dentro del deltalog mantiene referencias a los archivos Parquet involucrados en cada transacción.
Cuando aparece una nueva versión:
Algunos archivos pasan a formar parte del estado actual.
Otros dejan de ser considerados válidos.
Algunos permanecen como parte del historial.
El verdadero secreto de Delta Lake
Aquí fue donde finalmente comprendí cómo funciona Delta Lake:
💡 Los archivos Parquet pueden seguir existiendo físicamente.
Pero quien realmente decide qué información debe mostrarse es el Transaction Log
👉 El deltalog actúa como la fuente de verdad de la tabla.
Conclusión
Muchas veces se piensa que Delta Lake es únicamente una colección de archivos Parquet. Sin embargo, Delta Lake combina:
📄 Archivos Parquet para almacenar los datos.
📜 Transaction Logs para gestionar versiones y transacciones.
Y es precisamente esta combinación la que permite ofrecer capacidades que históricamente asociábamos más a Data Warehouses que a Data Lakes tradicionales. Por eso, si tuviera que resumir Delta Lake en una sola frase sería:
🔥 Los datos viven en Parquet, pero quien manda es el Transaction Log.
Comentarios