Particionamiento y compactación en Lakehouse con Fabric

Un Lakehouse mal particionado cuesta más en consultas que todo el proceso de ingestión.

En la práctica de bConcepts vemos esto repetidas veces: equipos construyen pipelines que llegan a los datos sin pensar en cómo serán leídos. El resultado son miles de archivos pequeños, scans innecesarios e informes lentos en Power BI. En este artículo describimos, con pasos concretos y métricas accionables, cómo definir una estrategia de partición y políticas de compactación para un Lakehouse en Microsoft Fabric, incluyendo heurísticas, ejemplos numéricos y consideraciones operacionales para hacer estas decisiones reproducibles y seguras.

¿Por qué particionar un Lakehouse?

Particionar significa organizar los archivos físicos del Lakehouse en carpetas (directorios) que reflejan predicados de consulta frecuentes —por ejemplo, fecha, país o categoría de producto. La ganancia inmediata es la llamada partition pruning: cuando una query filtra por fecha, el sistema solo lee las carpetas relevantes en lugar de todos los archivos de la tabla.

Sin una partición adecuada, incluso queries simples pueden obligar a leer terabytes de datos. Imagine una tabla con 50 TB de histórico; un dashboard que filtra solo el último mes puede, sin pruning, llevar a leer 5–10 TB por ejecución. Si ese dashboard se refresca 2.000 veces al mes en DirectQuery, el coste acumulado y la latencia se vuelven inaceptables. En escenarios prácticos, hemos visto lecturas innecesarias que multiplicaban por 10 el consumo de vCore‑hours y aumentaban el tiempo de respuesta de 5 segundos a minutos.

Además del tiempo de respuesta y costes, hay impacto operacional: más archivos significan más operaciones en el catálogo, mayor probabilidad de conflictos de I/O y más complejidad en la recuperación de fallos. Particionar adecuadamente es una de las primeras decisiones de ingeniería de datos con impacto directo en la experiencia del usuario y en los costes mensuales de la plataforma.

Cómo elegir la clave de partición correcta

No existe una clave «mágica». La elección depende de dos factores principales: patrones de consulta (qué filtran las BI queries) y características del dato (cardinalidad y distribución). Empiece por analizar los informes y las queries: ¿cuáles son los filtros más comunes? ¿Fecha de evento, tienda, país, usuario, estado de procesamiento?

Algunas reglas prácticas que aplicamos en proyectos con clientes:

• Priorice columnas usadas en filtros frecuentes por informes interactivos (p.ej.: fecha de evento, región). Si el 70–90% de las consultas filtra por mes, la partición por mes reduce sustancialmente lecturas.
• Evite particiones por columnas de alta cardinalidad (p.ej.: ID del usuario) —esto genera demasiadas carpetas pequeñas y pérdidas de eficiencia. Como principio, evite particiones con más de 10k a 100k valores distintos; para números de usuarios en el orden de millones, no es buena idea.
• Considere esquemas compuestos (por ejemplo, year=/month=) para datos temporales. Este enfoque facilita operaciones de purge y mantenimiento: es simple eliminar year=2022 cuando la retención se aplica anualmente.
• Para filtros semi‑esperados (p. ej., país + categoría), evalúe usar una tabla materializada o agregada en lugar de una partición compuesta que genere muchas carpetas poco utilizadas.

Ejemplo: en un sistema de e‑commerce, los informes de negocio normalmente filtran por mes y por país. Una partición por year/month y, en complemento, columnas de filtro como country y category como columnas regulares (pero indexadas a nivel de ordenación) tiende a ofrecer el mejor compromiso. Esto evita crear más de 200 carpetas por día (si se usara día) y garantiza que la mayoría de las queries toquen pocos directorios.

Granularidad, cardinalidad e impacto en queries

La granularidad de las particiones es un trade‑off entre selectividad (cuántas carpetas se leen) y overhead de metadata/archivos. Particiones demasiado finas llevan al problema de los "small files": cientos de miles de archivos pequeños que degradan I/O y aumentan latencia. Particiones demasiado gruesas pierden selectividad y obligan a leer más datos de lo necesario.

Indicadores que monitorizamos para ajustar granularidad:

• Número de archivos por partición: si una partición tiene >10k archivos, sospeche del problema de small files. En muchos casos, nos proponemos tener como máximo 1k–2k archivos por partición, dependiendo del tamaño total de datos.
• Tamaño medio de archivo: ideal entre 128 MB y 512 MB para archivos parquet/Delta en escenarios analíticos. Valores medios por debajo de 50 MB son señal de alerta; por debajo de 20 MB es generalmente insostenible a largo plazo.
• Bytes leídos por query: evalúe cuántos GB se leen en informes críticos. Si un KPI necesita solo 50 MB de datos agregados y la query lee 50 GB, la partición (o el diseño de los datos) necesita revisión.

Una heurística útil: si el 80% de las consultas filtra por mes, adopte month‑partitions; si muchas queries filtran por hora (p.ej.: pipelines de streaming y alerting), combine particiones por día y cree índices auxiliares o tablas agregadas para escenarios de low‑latency. En el caso de datos de telemetría con 100M eventos/día, una partición diaria con compactación agresiva para archivos de ~256 MB es una configuración común.

Compactación: cuándo, cómo y con qué objetivos

Compactación (o "compaction") es el proceso de reescribir archivos pequeños en archivos más grandes y ordenados, reduciendo la cuenta de archivos y mejorando la lectura secuencial. El objetivo no es solo reducir archivos: es optimizar la lectura física y, cuando tiene sentido, mejorar la ordenación de los datos (z‑ordering) para acelerar filtrado multidimensional y reducir el volumen leído.

¿Cuándo compactar?

• Tras cargas masivas que generan muchos archivos pequeños (p.ej.: ingestiones por stream o por micro‑batches). Por ejemplo, si una ingestión diaria de 1 TB resulta en 20k archivos, es hora de compactar.
• Cuando el tamaño medio del archivo en una partición esté por debajo de 50 MB —plan de acción: reescribir hasta alcanzar 128–512 MB por archivo.
• Cuando el número de archivos por partición sea superior a 5k–10k o cuando la latencia de los informes aumente de forma consistente.

Estrategias de compactación:

• Compactación incremental (minor compaction): junta archivos pequeños dentro de una partición para reducir la cuenta de archivos sin reescribir toda la partición. Útil cuando los datos son append‑heavy y se pretende minimizar coste de reescritura.
• Compactación completa (major compaction): reescribe la partición entera para definir un nuevo layout y aplicar ordenación/Z‑order. Más costosa, pero necesaria periódicamente para reorganizar datos sobre largos periodos.
• Ordenación por columna (z‑order): cuando queries combinan filtros multidimensionales (p.ej.: fecha + user_id + product_id), ordenar por columnas con alta selectividad puede reducir mucho el volumen leído. Evalúe coste/beneficio —ordenar es costoso en CPU.

Cómo compactar con seguridad:

• Haga compactaciones idempotentes: read -> repartition/coalesce -> write (modo atomic). Pruebe en una partición pequeña antes de generalizar. Evite operaciones que introduzcan inconsistencias en el catálogo.
• Reserve ventanas de baja utilización para compactaciones pesadas, o use autoscaling para minimizar impacto sobre consultas interactivas. En Fabric, es común ejecutar compactaciones fuera del horario punta o en clusters temporales dimensionados para la tarea.
• Use políticas de retención y VACUUM (eliminar archivos obsoletos) tras operaciones de rewrite para no inflar almacenamiento. Por ejemplo, tras un major compaction, ejecutar VACUUM con retención de 7 días (o según política) para eliminar archivos antiguos y garantizar integridad de backups/retenciones).

Compactar no es magia: es la traducción del know‑how operacional en tiempo de respuesta y ahorro de costes.

Implementación práctica en Microsoft Fabric

En Microsoft Fabric disponemos de herramientas integradas para implementar las estrategias descritas: lakehouses (OneLake), notebooks Spark, pipelines y orquestación. El flujo típico que recomendamos sigue fases claras:

1. Definir esquema de particiones al crear la tabla en el Lakehouse (por ejemplo, partitioned by (year, month)). Documente esa decisión en el catálogo y en los runbooks.
2. Ingerir datos en modo append a carpetas temporales o staging para evitar archivos demasiado pequeños directamente en la partición final. Agrupe micro‑batches antes de promover a la partición final.
3. Programar un job de compactación (Spark notebook) que lea particiones objetivo y reescriba archivos con coalesce/repartition al número de archivos deseado, alineado con el target de tamaño por archivo (~256 MB).
4. Ejecutar operaciones de mantenimiento: VACUUM para Delta (o equivalente), y actualizar metadatos del catálogo. Automatice alertas cuando métricas superen thresholds.

Ejemplo de snippet técnico (escrito de forma genérica):

spark.read.format("delta").load("/oneLake/cliente/events/year=2026/month=08") .repartition(50) .write.mode("overwrite").format("delta").option("overwriteSchema", "true") .save("/oneLake/cliente/events/year=2026/month=08")

Notas prácticas:

• Elija el número de particiones finales en función del target de tamaño (p.ej.: elegir repartition(50) porque el volumen de la partición es ~12 TB y 12 TB / 50 ≈ 240 GB por archivo colectivo, luego ajustar para obtener ~256 MB por archivo).
• Use pipelines de Fabric para orquestar notebooks y monitorizar fallos —por ejemplo, compactar solo particiones con más de N archivos y con tamaño medio <50 MB.
• Registre métricas (número de archivos, tamaño medio, tiempo de compactación) en tablas meta‑operacionales para análisis histórico y tuning. Un panel simple con thresholds (archivos >5k, avg_size <50 MB, tiempo >2h) evita regresiones.

Mini‑caso práctico: comercio minorista online que reduce latencia y costes

Contexto: una empresa de comercio minorista online con 120 empleados procesa eventos de compra y navegación. Ingesta: 200 millones de eventos por mes (≈2,4 TB de parquet / mes). Antes de la intervención, cada ingestión diaria producía archivos medios de 6 MB, totalizando 400k archivos por mes para la tabla de eventos.

Problema observado:

• Informe diario de ventas (Power BI, DirectQuery) tardaba de media 90 s en cargar y se ejecutaba ~3.000 veces/mes por analistas y dashboards automatizados.
• Lectura media por ejecución: 150 GB de datos leídos, con costes de procesamiento elevados y experiencias de usuario pobres.

Intervención implementada en 4 semanas:

1. Definición de particiones por year/month/day y reconfiguración del proceso de ingestión para escribir primero en una carpeta staging. Reducimos escritura directa en las particiones finales y agregamos micro‑batches.
2. Compactación diaria de cada partición que pasó a generar archivos medios de 250 MB (utilizando notebooks Spark orquestados por pipelines de Fabric). Implementamos minor compactions continuas y un major compaction semanal para particiones activas.
3. Política de limpieza: VACUUM para eliminar archivos obsoletos y retención de 365 días en particiones antiguas; definimos alertas para particiones con avg_size <50 MB.

Resultados mensurables en producción (30 días después):

• Número de archivos mensuales reducido de 400k a 8k (–98%).
• Tamaño medio del archivo aumentó de 6 MB a 250 MB.
• Tiempo medio del informe diario cayó de 90 s a 8 s (–91%).
• Bytes leídos por ejecución cayeron de 150 GB a 12 GB (–92%).
• Consumo de vCore‑hours del cluster de consultas compartidas se redujo de 1.200 vCore‑h/mes a 300 vCore‑h/mes (–75%), después de considerar el overhead de compactación.

Impacto en el negocio: los analistas empezaron a explorar datos de forma más fluida, el SLA de refresh de dashboards mejoró y el coste mensual asociado a consultas analíticas disminuyó significativamente, justificando la automatización de la compactación. Incluso cuando se contabiliza el coste de los jobs de compactación (por ejemplo, 40 vCore‑h/mes extra), la ganancia neta fue sustancial —tanto en rendimiento como en coste.

En resumen

• Particione según patrones de consulta: priorice columnas que las BI queries usan en filtros frecuentes; para datos temporales, use year/month en lugar de día cuando sea relevante.
• Mantenga archivos lo suficientemente grandes (128–512 MB) para optimizar I/O y reducir overhead de metadata; compacte cuando avg size <50 MB o archivos por partición >5k–10k.
• Automatice compactaciones con notebooks Spark y pipelines de Fabric, monitorizando métricas de archivos y tiempo de ejecución para ajustar frecuencia y evitar regresiones.
• Balancee costes: la compactación consume compute, pero reduce lecturas repetidas y latencias, frecuentemente generando ahorros netos mensuales y mejor experiencia para usuarios.

Conclusión y próximos pasos: la estrategia técnica que describimos debe tratarse como iterativa. Empiece por mapear patrones de consulta, implemente particiones conservadoras (p.ej.: year/month), automatice compactación para particiones problemáticas y supervise las métricas operacionales. En Microsoft Fabric, la integración entre lakehouses, notebooks y pipelines facilita esta operacionalización —pero es la disciplina (programación, tracking, thresholds) la que la hace sostenible.

¿Qué particiones están causando más lecturas en su organización hoy —y qué pequeño cambio podría reducir la latencia de sus dashboards mañana?