Gestión y límites de costes en OneLake: Guía técnica de optimización
OneLake es el pilar central de Microsoft Fabric, pero su simplicidad operativa oculta un riesgo financiero si no se gestiona con criterio técnico. Al ser un repositorio único basado en Azure Data Lake Storage (ADLS) Gen2, el almacenamiento sigue un modelo de pago por uso que parece insignificante al principio, pero que escala de forma lineal y agresiva en proyectos de gran volumen. Como consultor, he visto cómo despliegues mal planificados multiplican su factura mensual simplemente por ignorar cómo Delta Lake gestiona las versiones de los archivos.
A diferencia de la capacidad de cómputo (CU), que se puede pausar o escalar, el almacenamiento en OneLake es persistente. Pagas por cada GB que reside en el lago las 24 horas del día. Si tu estrategia de ingesta no incluye procesos de purga y optimización, estarás pagando por datos que nadie consulta y por versiones de tablas que el motor de Power BI ya no utiliza. En este artículo desglosamos la estructura de costes real y cómo aplicar políticas de limpieza para mantener el ROI del proyecto bajo control.
Es fundamental entender que OneLake no es solo un disco duro en la nube; es un ecosistema que interactúa con múltiples motores. Cada vez que realizas un proceso de ETL en un Notebook o una carga en el Warehouse, se generan metadatos y archivos log que, si no se supervisan, pueden suponer hasta el 30% del almacenamiento total de un Lakehouse desoptimizado.
La estructura de precios: Más allá del GB mensual
El coste de OneLake se factura basándose en el almacenamiento de datos persistentes y, en menor medida, en las transacciones de lectura y escritura (operaciones API). Microsoft aplica una tarifa plana por GB/mes similar a la de ADLS Gen2 con redundancia local (LRS). En la mayoría de las regiones, esto ronda los 0,023 USD por GB al mes. Si bien parece barato, la trampa reside en la redundancia de datos innecesaria.
En un entorno empresarial típico, solemos dividir el almacenamiento en tres capas: Bronze (crudo), Silver (limpio) y Gold (negocio). Si duplicas físicamente los datos en cada capa en lugar de usar referencias o transformaciones eficientes, estás triplicando el coste de almacenamiento de la misma información. Para mitigar esto, resulta vital entender la OneLake y el ecosistema de Microsoft Fabric: Novedades y su impacto técnico real para aprovechar la arquitectura de copia única (Single Copy).
Transacciones y salida de datos
Aunque el almacenamiento es el coste principal, las operaciones de lectura/escritura y la transferencia de datos (egress) fuera de la región de Azure también suman. En implementaciones multicloud, el uso de Shortcuts en OneLake: Virtualización de datos multicloud en Microsoft Fabric es la mejor forma de evitar pagar por almacenamiento duplicado, pero hay que vigilar el coste de salida de datos que pueda cobrar el proveedor de origen (AWS o GCP).
El problema de las versiones: Por qué pagas por datos borrados
OneLake utiliza el formato Delta Lake de forma nativa. Una de las características estrella de Delta es el Time Travel, que permite consultar versiones anteriores de los datos. Sin embargo, para que esto funcione, el sistema no borra físicamente los archivos Parquet antiguos cuando haces un UPDATE o un DELETE. Simplemente los marca como obsoletos en el log y crea archivos nuevos.
Si actualizas diariamente una tabla de 100 GB sin realizar tareas de mantenimiento, al cabo de diez días podrías estar ocupando 1 TB de espacio, aunque tu tabla actual solo reporte 100 GB de datos vivos. Este es el error más común en la gestión de costes de Fabric.
La solución: El comando VACUUM
Para liberar este espacio, debemos ejecutar el comando VACUUM. Este proceso elimina físicamente los archivos que ya no están referenciados en el log de transacciones y que superan el periodo de retención configurado (por defecto, 7 días). En mis proyectos, ajusto este periodo dependiendo de la criticidad del histórico.
# Ejemplo de optimización y purga en un Notebook de Fabric
from delta.tables import *
# Referenciamos la tabla de Ventas en el Lakehouse
deltaTable = DeltaTable.forPath(spark, "Files/Tables/FactVentas")
# Eliminamos archivos obsoletos de más de 3 días (72 horas)
# Nota: dryRun=False ejecuta el borrado real
deltaTable.vacuum(72)
# Consolidamos archivos pequeños para mejorar rendimiento y lectura
deltaTable.optimize().executeCompaction()Identificación de datos obsoletos en el Warehouse
Si trabajas con el Synapse Data Warehouse en lugar de Lakehouses, la gestión del almacenamiento es algo más opaca pero igualmente crítica. El Warehouse también escribe en formato Delta detrás de escena. Es fundamental monitorizar las tablas de staging que a menudo se olvidan tras cargar la tabla de hechos definitiva.
Para auditar el tamaño de nuestras tablas y detectar crecimientos anómalos, podemos recurrir a las vistas de sistema. Aunque Fabric simplifica mucho, como consultores debemos mantener el hábito de medir antes de optimizar.
-- Consulta para identificar el espacio ocupado por tablas en el Warehouse
-- Ayuda a detectar tablas de staging que no se han purgado
SELECT
s.name AS Esquema,
t.name AS Tabla,
p.rows AS NumeroFilas,
CAST((SUM(a.total_pages) * 8) / 1024.0 AS DECIMAL(18,2)) AS TamañoMB
FROM
sys.tables t
INNER JOIN
sys.schemas s ON t.schema_id = s.schema_id
INNER JOIN
sys.indexes i ON t.object_id = i.object_id
INNER JOIN
sys.partitions p ON i.object_id = p.object_id AND i.index_id = p.index_id
INNER JOIN
sys.allocation_units a ON p.partition_id = a.container_id
WHERE
t.is_ms_shipped = 0
GROUP BY
s.name, t.name, p.rows
ORDER BY
TamañoMB DESC;Comparativa: Estrategias de almacenamiento y su impacto económico
La elección de la técnica de ingesta determina el coste a largo plazo. No siempre la opción más rápida es la más económica.
| Técnica | Impacto en Coste GB | Rendimiento Lectura | Recomendación de uso |
|---|---|---|---|
| Copia física (ETL Tradicional) | Alto (Duplicidad) | Excelente | Tablas Gold con alto volumen de consultas DAX. |
| Shortcuts (Virtualización) | Casi nulo | Depende del origen | Evitar duplicar datos que ya residen en ADLS o S3. |
| Mirroring (Reflejo SQL) | Medio | Muy alto | Para bases de datos operacionales sin pipelines complejos. |
| Tablas externas | Bajo | Moderado | Datos históricos de poco uso o archivos legacy. |
El uso de Mirroring es una novedad potente que permite tener una réplica de SQL Server en Fabric casi en tiempo real. Si te interesa cómo gestionar este flujo, revisa Mirroring de SQL Server en Fabric: Gateway y Gestión de Cambios.
V-Order y compresión: ¿Ahorro o gasto?
Microsoft Fabric introduce una optimización propietaria llamada V-Order. Se aplica a los archivos Parquet para que el motor de Power BI pueda leerlos con una velocidad extrema (Direct Lake). A nivel de almacenamiento, V-Order suele generar archivos ligeramente más pequeños o de tamaño similar a un Parquet estándar gracias a una mejor ordenación de los datos, lo que favorece los algoritmos de compresión.
Sin embargo, el «coste» de V-Order no es de almacenamiento, sino de cómputo. Aplicar V-Order durante la escritura consume más CUs de tu capacidad. Mi recomendación es activarlo siempre en tablas de la capa Gold, donde el rendimiento de las consultas justifica el gasto de computación, pero desactivarlo en capas Bronze de paso intermedio para ahorrar recursos.
Para entender mejor cómo encajan estos costes en el presupuesto global de la empresa, es útil consultar la Estimación de costes en Fabric: Pago por uso vs Capacidades reservadas.
Errores frecuentes en la gestión de OneLake
- No configurar el ciclo de vida de los datos: Mantener datos de telemetría o logs de hace 3 años en OneLake como si fueran datos calientes.
- Ignorar el crecimiento de los metadatos: Cada operación en una tabla Delta genera un archivo JSON en la carpeta
_delta_log. En tablas con miles de particiones y actualizaciones frecuentes, estos logs pueden sumar gigabytes. - Duplicar datos para desarrollo: Crear copias enteras del lago para que los desarrolladores hagan pruebas en lugar de usar Seguridad granular en OneLake: Implementación de Data Access Roles en Fabric sobre los mismos datos.
- Cargas incrementales mal diseñadas: Procesos que reescriben particiones enteras cuando solo ha cambiado una fila, disparando el número de archivos obsoletos.
Conclusión y Checklist de optimización
El almacenamiento en OneLake es barato comparado con el cómputo, pero es acumulativo. Un descuido en la política de retención puede convertir una solución eficiente en una carga financiera. La clave no es dejar de almacenar, sino almacenar con propósito y limpiar con automatización.
Checklist para el administrador de Fabric:
- Programar VACUUM: Configurar un Notebook semanal que ejecute la limpieza de todas las tablas Delta del Lakehouse.
- Auditar Shortcuts: Revisar trimestralmente qué datos se están copiando físicamente y cuáles podrían ser virtualizados mediante Shortcuts.
- Monitorizar la Capacity Metrics App: Revisar la pestaña de Storage para identificar qué Workspace está consumiendo más recursos.
- Definir retención en staging: Asegurar que los archivos temporales de los pipelines de Data Factory se eliminen tras el éxito de la carga.
- Optimizar particiones: Evitar el problema de los «small files» (miles de archivos de pocos KB) que penalizan el rendimiento y complican la gestión del storage.
Preguntas frecuentes
¿El comando VACUUM rompe el Direct Lake de Power BI?
No, siempre que mantengas un periodo de retención razonable (mínimo 24-48 horas). El motor de Power BI solo necesita la versión actual de los archivos. El riesgo es si intentas leer una versión antigua de la tabla mediante Time Travel que ya haya sido purgada.
¿Se paga por los datos almacenados en los Shortcuts?
No pagas almacenamiento a Microsoft Fabric por los datos que ves a través de un Shortcut. Pagas el almacenamiento en el origen (por ejemplo, tu propia cuenta de ADLS Gen2 o S3). Fabric solo te cobrará por los metadatos mínimos y el cómputo para procesarlos.
¿Cómo puedo limitar el crecimiento de OneLake por usuario?
Actualmente no existen cuotas de disco por usuario como en un sistema de archivos tradicional. La gestión se realiza a nivel de Workspace. La mejor forma de limitarlo es mediante el gobierno de datos, asignando la creación de Workspaces solo a perfiles responsables y monitorizando el uso con la aplicación de métricas de capacidad.
¿Influye el formato de compresión en el coste?
Sí, OneLake utiliza compresión Snappy por defecto en Parquet. Cambiar a algoritmos más agresivos como GZIP puede reducir el tamaño en disco (menos coste de storage) pero aumentará significativamente el uso de CPU durante la lectura y escritura (más coste de cómputo). Snappy suele ser el equilibrio óptimo para BI.
