Las tablas de un Lakehouse en Microsoft Fabric se basan en Delta Lake, una capa de almacenamiento que añade semántica relacional sobre archivos almacenados en un lago de datos.

Dicho de forma sencilla: los datos siguen estando en archivos, normalmente en formato Parquet, pero por encima se añade una capa que permite trabajar con ellos como si estuviéramos mucho más cerca de una base de datos.

Esto significa que puedes tener operaciones de inserción, actualización, borrado, control de versiones, soporte transaccional y compatibilidad tanto con datos batch como con streaming. Todo ello sin perder la flexibilidad del almacenamiento en archivos.

Cómo funciona una tabla Delta

Una tabla Delta no deja de ser una abstracción sobre archivos físicos.

Por cada tabla, Fabric guarda:

  • los archivos de datos en formato Parquet
  • una carpeta _delta_log con el registro de transacciones

Ese registro es la pieza clave. Es el que permite saber qué cambios ha habido, qué versión de los datos existe en cada momento y cómo mantener consistencia incluso cuando varias operaciones ocurren al mismo tiempo.

Por eso, aunque desde fuera veamos una tabla, por debajo seguimos trabajando con archivos… pero con una capa de inteligencia encima.

Qué ventajas aporta Delta Lake

Aquí está realmente el valor.

Las tablas Delta permiten trabajar con datos como si estuviéramos en un sistema relacional:

  • consultar
  • insertar
  • actualizar
  • eliminar

Además, ofrecen compatibilidad con transacciones ACID, lo que garantiza atomicidad, coherencia, aislamiento y durabilidad. Es decir, un comportamiento mucho más robusto que el de un simple conjunto de archivos sueltos.

A esto se suma el control de versiones y el viaje en el tiempo, que permite recuperar estados anteriores de los datos. Y también la compatibilidad con datos de streaming, algo especialmente interesante cuando el dato no llega por lotes, sino de forma continua.

Todo esto convierte a Delta Lake en una de las piezas más potentes del Lakehouse.

Creación de tablas Delta

En Fabric, una tabla Delta puede crearse de varias formas.

La más habitual es partir de un DataFrame en Spark y guardarlo en formato Delta. En ese momento se crea tanto la definición de la tabla en el metastore como los archivos de datos subyacentes.

También se pueden crear tablas directamente con Spark SQL o definir primero los metadatos y cargar los datos después. Es decir, no siempre necesitas partir de datos ya cargados. Puedes definir la estructura y poblarla más tarde.

Y además existe una tercera posibilidad: guardar datos en formato Delta sin registrar una tabla en el metastore. Esto resulta útil cuando quieres conservar resultados intermedios o trabajar directamente a nivel de archivos.

Tablas administradas y tablas externas

Aquí conviene hacer una distinción importante.

Una tabla administrada es aquella en la que Fabric gestiona tanto la definición como los archivos de datos. Si eliminas la tabla, también desaparecen los archivos asociados.

En cambio, una tabla externa mantiene la definición en el metastore, pero los datos viven en otra ubicación. Si eliminas la tabla, los archivos permanecen.

Esto da bastante flexibilidad, porque no siempre quieres que el ciclo de vida lógico de la tabla arrastre también el físico de los datos.

Optimización de tablas Delta

Trabajar con Spark y Parquet tiene una ventaja enorme en escalabilidad, pero también trae un problema conocido: el de los archivos pequeños.

Cada actualización, inserción o borrado puede generar nuevos archivos, y con el tiempo eso puede afectar seriamente al rendimiento.

Para mitigar esto, Delta Lake incorpora varias estrategias de optimización.

Una de ellas es OptimizeWrite, que intenta escribir menos archivos y más grandes desde el propio proceso de escritura.

Otra es OPTIMIZE, una operación de mantenimiento que compacta archivos pequeños en otros más grandes, mejorando compresión, distribución y tiempos de lectura.

Y dentro de este terreno también aparece V-Order, una optimización específica de Fabric para mejorar especialmente las lecturas. Tiene un pequeño coste adicional al escribir, pero puede acelerar mucho las consultas posteriores.

VACUUM y mantenimiento

Otro aspecto importante es el mantenimiento del histórico.

Cada vez que actualizas o borras datos, los archivos antiguos no desaparecen inmediatamente. Se mantienen para permitir el viaje en el tiempo. Esto está muy bien… hasta que el volumen empieza a crecer.

Aquí entra el comando VACUUM, que elimina archivos de datos antiguos que ya no se necesitan según un periodo de retención definido.

Esto ayuda a reducir almacenamiento, pero tiene una consecuencia directa: si eliminas esos archivos, ya no podrás viajar en el tiempo más allá de ese umbral.

Por tanto, no es solo una operación técnica. Es una decisión que afecta a rendimiento, coste y capacidad de recuperación histórica.

Particiones en tablas Delta

Otra técnica habitual para mejorar rendimiento es la partición.

Consiste en dividir físicamente los datos en carpetas según el valor de una columna, por ejemplo año o categoría. Así, cuando consultas solo una parte de los datos, Spark puede saltarse particiones enteras que no necesita leer.

Esto puede ir muy bien cuando tienes mucho volumen y una lógica clara de consulta. Pero no siempre ayuda.

Si el volumen es pequeño o la columna elegida tiene demasiada cardinalidad, el resultado puede ser justo el contrario: más archivos, más fragmentación y peor rendimiento.

Así que aquí no hay receta universal. Hay que pensar cómo se van a consultar realmente esos datos.

Uso de tablas Delta con Spark

Una vez creadas, las tablas Delta pueden consultarse y modificarse de distintas formas.

La más común es usar Spark SQL, ya sea incrustado dentro de PySpark o directamente con celdas SQL en un notebook. Esto permite trabajar con una sintaxis muy familiar para muchos perfiles.

También puedes usar la API de Delta Lake directamente cuando quieres operar sobre archivos Delta sin depender de una tabla registrada en catálogo.

Es decir, puedes trabajar en modo más relacional o más cercano al almacenamiento, según lo que necesites.

Viaje en el tiempo y control de versiones

Una de las funcionalidades más interesantes de Delta Lake es el viaje en el tiempo.

Como todas las transacciones quedan registradas, puedes consultar el historial de cambios y recuperar una versión anterior de los datos, ya sea por número de versión o por marca temporal.

Esto es especialmente útil para:

  • auditoría
  • recuperación ante errores
  • validación de cambios
  • análisis comparativos

No es solo una curiosidad técnica. En muchos escenarios, es una funcionalidad tremendamente valiosa.

Streaming con tablas Delta

Hasta aquí podríamos pensar en tablas Delta como una evolución del almacenamiento batch. Pero hay más.

Delta Lake también puede trabajar con datos de streaming mediante Spark Structured Streaming. Esto significa que una tabla Delta puede actuar como origen o como destino de un flujo continuo de datos.

Por ejemplo, puedes capturar datos de sensores, logs o eventos en tiempo real y escribirlos directamente en una tabla Delta. O, al revés, leer una tabla Delta como fuente de streaming para alimentar análisis casi en tiempo real.

Esto conecta muy bien con escenarios modernos donde no todo llega en cargas periódicas, sino que el dato está en movimiento constante.

Transformación de datos en streaming

Cuando trabajas con streaming, Spark permite tratar esos datos con la misma lógica de DataFrames que usarías en batch.

Puedes:

  • filtrar filas
  • agregar columnas
  • limpiar registros
  • calcular métricas

Y después escribir el resultado en otra tabla Delta, normalmente acompañada de un checkpoint que permite recuperar el estado del procesamiento si algo falla.

Esto es importante porque en streaming no basta con transformar. También hay que garantizar continuidad y tolerancia a fallos.

Conclusión

Delta Lake es una de esas piezas que, cuando la entiendes bien, hace que muchas cosas en Fabric empiecen a tener más sentido.

No es solo un formato ni una simple tabla. Es la capa que permite que el Lakehouse se comporte de una forma mucho más cercana a un sistema analítico serio: con transacciones, control de versiones, soporte para streaming y capacidad real de mantenimiento y optimización.