Entendiendo cómo Delta Lake almacena realmente los datos en Databricks
- 28 may
- 2 min de lectura
Introducción
Para realmente entender qué es Delta Lake y por qué cambió completamente la manera moderna de trabajar con datos…
Primero necesitamos entender cómo interactúan las distintas capas de Databricks. Porque honestamente, este fue uno de los puntos donde finalmente muchas piezas empezaron a conectar para mí...
La arquitectura moderna de Databricks
Antes de hablar directamente de Delta Lake, veamos cómo se conectan sus capas principales:
1️⃣ Workspace⬇️2️⃣ Unity Catalog⬇️3️⃣ Runtime (Apache Spark + Delta Lake)⬇️4️⃣ Infraestructura Multi-Cloud
Cada capa cumple una responsabilidad distinta dentro de la plataforma
👉 ¿Cómo se almacenan realmente los datos en Delta Lake?
Porque aunque muchas veces trabajamos simplemente con tablas y queries…
Por debajo ocurren MUCHAS más cosas.
El Inicio: Un usuario escribe datos
Imaginemos un caso sencillo.
Un usuario desea almacenar información dentro de Databricks utilizando:
🐍 PySpark
📄 Spark SQL
Por ejemplo:
No profundizaremos aún en el código de cada uno (por el momento), sino, lo importante aquí es entender el flujo general.
Los Datos Originales
Inicialmente la información puede existir como:
📄 CSV
🧾 JSON
🗂️ XML
Entre muchos otros formatos
Es decir, archivos completamente normales.
El papel de Unity Catalog
Cuando ejecutamos el proceso, la información comienza a atravesar distintas capas.
La primera capa importante aquí es:
🔐 Unity Catalog
Y aquí ocurre algo MUY importante:
👉 Unity Catalog NO almacena físicamente los datos.
Lo que hace es gobernarlos. Por ejemplo, define estructuras organizadas como:
Aquí es donde nace el concepto de:
📦 Delta Table
La llegada al Runtime
Después de pasar por Unity Catalog, la información llega al Runtime. Y aquí aparece el protagonista principal:
⚡ Apache Spark
Spark toma los datos y realiza el procesamiento distribuido. Durante ese procesamiento, los datos terminan escribiéndose como:
📄 Archivos Parquet
Y este fue uno de los puntos donde finalmente todo empezó a tener sentido para mí.
Porque sí…
👉 Una Delta Table realmente almacena archivos Parquet por debajo.
Lo que ocurre con el archivo original
Imaginemos este archivo: clientes.csv
Después del procesamiento, ya no existe como “tabla”.
Ahora se convierte en múltiples archivos parquet optimizados:
part-0000.parquet
part-0001.parquet
part-0002.parquet
¿Dónde viven físicamente esos archivos?
Aunque en Databricks nosotros trabajemos con:
📊 tablas
📂 catálogos
📄 queries
La realidad es que los archivos viven físicamente en infraestructura cloud.
Por ejemplo:
s3://bucket-data/ventas/part-0000.parquet
o
abfss://contenedor/ventas/
La gran abstracción de Databricks
Y aquí aparece una de las cosas más interesantes de toda la plataforma.
👉 Nosotros trabajamos con conceptos organizados y simples.
Mientras por debajo realmente existen:
☁️ buckets
📄 archivos parquet
⚡ procesamiento distribuido
📂 rutas cloud
🔀 múltiples archivos físicos
Databricks abstrae gran parte de esa complejidad.
Pero aún falta la pieza más importante…
Hasta este punto ya tenemos:
✅ archivos parquet
✅ almacenamiento cloud
✅ tablas Delta
Pero todavía falta resolver algo crítico:
👉 ¿Cómo sabe Delta Lake qué archivos son válidos?
👉 ¿Cómo maneja versiones?
👉 ¿Cómo controla transacciones exitosas?
Y ahí aparece el verdadero corazón de Delta Lake:
🔥 deltalog
Pero eso lo veremos en el siguiente post...
Comentarios