Entendiendo Delta Lake: la capa que da orden y confiabilidad al Data Lake
- 12 may
- 3 Min. de lectura
Introducción
Después de revisar Apache Spark dentro de la capa Runtime de Databricks, llegamos a otro de los componentes más importantes de toda la arquitectura Lakehouse: Delta Lake. Y honestamente, este fue uno de los conceptos que más me costó entender al inicio 😅. Sin embargo, al revisar documentación oficial y comprender cómo funciona realmente por debajo, todo empezó a tener mucho más sentido.
Delta Lake no reemplaza al Data Lake
Lo primero que hay que entender es algo fundamental:
Delta Lake NO reemplaza al Data Lake tradicional.
Se construye SOBRE él.
Además, Databricks utiliza servicios cloud como:
☁️ Amazon S3
☁️ Azure Data Lake Storage (ADLS)
☁️ Google Cloud Storage (GCS)
Estos servicios funcionan como Data Lakes tradicionales. Es decir:
📦 Almacenan enormes cantidades de datos y archivos de distintos tipos.
Entonces… ¿qué hace Delta Lake?
Aquí aparece el verdadero valor de Delta Lake:
👉 Agrega una capa adicional de almacenamiento y administración SOBRE el Data Lake tradicional.
Gracias a esto, incorpora capacidades similares a las de un Data Warehouse.
Los dos componentes clave de Delta Lake
Dentro de Delta Lake aparecen dos conceptos fundamentales:
📦 Delta Tables
📝 Transaction Log (_delta_log)
Una analogía sencilla para entenderlo
🌊 Data Lake
Imagina un enorme almacén de reciclaje completamente desordenado.
Todo mezclado:
📄 Papel
🍾 Vidrio
🧴 Plástico
🌱 Material orgánico
Y muchos otros elementos.
🪵Delta Lake
Ahora imagina una capa que llega y dice:
👉 “Vamos a organizar todo esto”.
Empieza a estructurar ese almacén en secciones organizadas y controladas.
¿Qué son las Delta Tables?
Las Delta Tables representan esas secciones organizadas dentro del almacén. Aquí empiezan a aparecer capacidades muy importantes como:
✅ Versionamiento
⏪ Time Travel
🔒 Transacciones ACID
🧩 Schema Enforcement
🔄 Schema Evolution
¿Qué es el Transaction Log (_delta_log)?
El _delta_log funciona como un cuaderno de registro. Ahí queda almacenado:
➕ Qué datos ingresaron
➖ Qué datos fueron eliminados
🔄 Qué datos cambiaron
👤 Quién realizó la operación
⏰ Cuándo ocurrió
Cada modificación genera una nueva versión registrada.
Delta Lake y el formato Parquet
Las Delta Tables almacenan físicamente sus datos utilizando:
👉 Archivos Parquet.
Un formato columnar optimizado para lectura analítica, y aquí vuelve a aparecer Apache Spark⚡.
Spark es quien procesa, transforma y escribe esos archivos Parquet dentro de las Delta Tables.
El verdadero corazón de Delta Lake
Aunque Parquet es importante, el verdadero valor está en el Transaction Log.
El _delta_log mantiene archivos .json con información sobre:
📌 Operaciones realizadas
📌 Versiones
📌 Timestamps
📌 Archivos válidos para cada transacción
Aquí es donde entran las transacciones ACID
Este fue el punto donde finalmente entendí el verdadero propósito de Delta Lake.
👉 Las transacciones ACID.
Si ocurre un error durante una operación:
La transacción no se registra correctamente en el log
Y aunque existan archivos Parquet físicamente…
❌ Delta Lake no los considera válidos dentro de la tabla.
Entonces… ¿qué aporta realmente Delta Lake?
Delta Lake no es simplemente almacenamiento.
🔥 Es una capa que aporta:
✅ Orden
✅ Confiabilidad
✅ Gobernanza
Sobre el caos natural de un Data Lake tradicional.
Lo que viene después (En próximos posts mas detallados 👀)
Y sí… todavía queda muchísimo por profundizar:
⚡ OPTIMIZE
🧹 VACUUM
⏪ Time Travel
🗜️ Compaction
🧩 Schema Evolution
📍 Z-Ordering
Pero eso quedará para próximos artículos 👀🔥. Por ahora:
🪵 DELTA LAKE ✅
Comentarios