Microsoft Fabric utiliza un modelo de consumo basado en Capacity Units (CUs) para medir y facturar el uso de recursos computacionales. Comprender cómo diferentes artefactos y escenarios de ingesta de datos impactan en el consumo de CUs es fundamental para optimizar costos y seleccionar la herramienta más eficiente para cada caso de uso.

Este artículo presenta una comparativa práctica y detallada del consumo de CUs en Microsoft Fabric al cargar datos desde diferentes orígenes y formatos utilizando los principales artefactos disponibles en la plataforma. Los objetivos específicos son:

• Medir el consumo real de CUs en escenarios de ingesta de datos

• Comparar el rendimiento de diferentes artefactos: Notebooks (PySpark y Python), Pipelines, Copy Jobs y Dataflows Gen2

• Evaluar el impacto del tamaño de archivo en el consumo de recursos

• Analizar las diferencias entre datos estructurados (SQL Server) y ficheros

• Calcular el coste económico real de cada operación

Metodología

Para cada escenario se han capturado las siguientes métricas mediante la aplicación Microsoft Fabric Capacity Metrics:

• CUs consumidas: Total de Capacity Units utilizadas en la operación

• Duración: Tiempo de ejecución en segundos

• Coste: Coste económico calculado en base a la duración y el precio de la capacidad

Configuración de la Capacidad

Para estas pruebas se ha utilizado una capacidad F2 en modo Pay-as-you-go en la región Spain Central, con un precio de €0.323/hora según la página oficial de Microsoft Fabric - Pricing | Microsoft Azure.

Cálculo del coste:

Coste (€) = (Duración en segundos × €0.323) / 3600

Escenario 1: Ingesta de Fichero CSV

Dataset utilizado

Archivo de ventas (sales.csv)

Características:

• Ubicación: Lakehouse de Microsoft Fabric

• Nombre del archivo: sales.csv

• Tamaño del archivo: 189 MB

• Tipo: Datos de ventas en formato CSV

Operación realizada: Lectura de todos los ficheros CSV y escritura en tabla Delta sin transformaciones ni limpiezas. Operación pura de lectura y escritura para medir el consumo base.

Artefactos probados

• Notebook (PySpark)

• Notebook Python

• Pipeline

• Copy job

• Dataflow Gen2

Resultados

Revisando el informe de Microsoft Fabric Capacity Metrics:

Coste económico

El impacto económico para archivos pequeños es mínimo en términos absolutos, pero las diferencias porcentuales son significativas:

• Pipeline: €0.0035 por ejecución - El más económico por tiempo

• Notebook Python: €0.0038 por ejecución - 9% más que Pipeline

• Copy Job: €0.0042 por ejecución - 20% más que Pipeline

• Dataflow Gen2: €0.0047 por ejecución - 34% más que Pipeline

• Notebook PySpark: €0.0060 por ejecución - 71% más que Pipeline

Consumo de CUs y tiempos de ejecución

Comparativa PySpark vs Python (Pandas)

Es importante destacar la diferencia entre los dos tipos de Notebooks:

Para archivos pequeños, Python/Pandas es claramente superior en todos los aspectos medibles: CUs, tiempo, throughput y coste. El overhead de inicialización y coordinación de Spark (sesión, workers, distribución de tareas) solo se justifica con volúmenes grandes donde su capacidad de procesamiento distribuido paralelo compensa estos costes iniciales.

Escenario 2: Ingesta de fichero CSV de gran volumen

Dataset utilizado

Archivo unificado de CMS (cms_unificado.csv)

Características:

• Ubicación: Lakehouse de Microsoft Fabric

• Nombre del archivo: cms_unificado.csv

• Tamaño del archivo: 83.76 GB

• Tipo: Datos de CMS consolidados en formato CSV

Operación realizada: Lectura del fichero CSV de gran volumen y escritura en tabla Delta sin transformaciones ni limpiezas. Operación pura de lectura y escritura para medir el consumo base en escenarios de producción con grandes volúmenes.

Artefactos probados

Los mismos que en el escenario anterior:

• Notebook (PySpark)

• Notebook Python

• Pipeline (Copy data activity)

• Copy job

• Dataflow Gen2

Resultados

Revisando el informe de Microsoft Fabric Capacity Metrics:

El notebook de python no se ha podido evaluar debido al siguiente error:

❌ ERROR - Forced-process termination

Error exit code: -9 (Forced-process termination. 
This is often caused by insufficient memory causing the process to be killed. 
Please check memory usage)

Análisis del error: Pandas opera en un único nodo cargando todo el dataset en memoria RAM. Con un archivo de 83.76 GB, la memoria disponible en la capacidad F2 es insuficiente, resultando en la terminación forzada del proceso por el sistema operativo (OOM - Out Of Memory).

Coste económico

El impacto económico en archivos grandes es sustancial y debe ser considerado seriamente:

• Notebook PySpark: €0.0610 por ejecución - El más económico 💰

• Pipeline: €0.3135 por ejecución - 5.14x más caro que PySpark

• Copy Job: €0.3158 por ejecución - 5.18x más caro que PySpark

• Dataflow Gen2: €0.3748 por ejecución - 6.15x más caro que PySpark

Consumo de CUs y tiempos de ejecución

Con archivos de gran volumen, las diferencias en consumo de CUs y tiempos de ejecución se vuelven dramáticamente significativas

El Notebook PySpark consume menos de 1/8 de las CUs del Pipeline y menos de 1/25 del Dataflow Gen2. Además, completa la carga en 11 minutos, mientras que los demás artefactos tardan entre 58 y 70 minutos (alrededor de 1 hora).

Conclusiones del escenario

Notebook de Python no aplicable

El Notebook Python/Pandas no es escalable para grandes volúmenes. Su eficiencia en archivos pequeños no se traslada a escenarios con datasets grandes.

Superioridad de PySpark en grandes volúmenes de datos

El Notebook PySpark demuestra su verdadero valor en archivos grandes, invirtiendo completamente los resultados del Escenario 1:

🏆 Ventajas decisivas de PySpark:

1. Arquitectura distribuida: Distribuye el procesamiento entre múltiples workers en paralelo

2. Procesamiento lazy: Solo carga en memoria lo necesario en cada momento

3. Particionamiento automático: Divide el archivo en chunks procesables independientemente

4. Optimización nativa para Delta: Escritura optimizada a formato Delta Lake

5. Gestión eficiente de memoria: Spill to disk cuando es necesario sin fallar

El overhead de Spark en archivos pequeños (inicialización, coordinación) se convierte en una ventaja masiva en archivos grandes gracias a su capacidad de distribución y paralelización.

Análisis crítico del Dataflow Gen2 en grandes volúmenes de datos

El Dataflow Gen2 muestra un rendimiento completamente inaceptable para archivos grandes:

🚫 Consumo no apto para producción

• 24.54x más CUs que PySpark (63,980 CUs de diferencia)

• 6.15x más tiempo que PySpark (casi 70 minutos vs 11 minutos)

• €0.3138 más por ejecución (+515% de coste)

Proyección anual con carga diaria:

• Coste PySpark: €22.27/año

• Coste Dataflow Gen2: €136.80/año

• Sobrecoste: €114.53/año (para un solo archivo)

Problemas estructurales de Dataflow Gen2 con grandes volúmenes:

1. Motor no optimizado: Power Query mashup engine no está diseñado para Big Data

2. Procesamiento ineficiente: Operaciones fila por fila en lugar de vectorizadas

3. Sin paralelización efectiva: No aprovecha arquitectura distribuida

4. Alto overhead de memoria: Gestión ineficiente de grandes datasets

5. Serialización costosa: Múltiples conversiones de formato internas

⚠️ Advertencia:

Aunque Dataflow Gen2 ofrece una interfaz visual atractiva y fácil de usar, su uso en producción con archivos grandes es técnicamente inadecuado y económicamente inviable. La facilidad de uso no justifica un sobrecosto del 515% y un tiempo de ejecución 6x superior.

Consecuencias de una mala elección del artefacto

1. Saturación de capacidad: Consumo de CUs puede exceder la capacidad disponible

2. Throttling: Fabric puede ralentizar o pausar trabajos

3. Fallos en SLA: Procesos no completan en ventana de tiempo

4. Costes desorbitados: Necesidad de capacidades superiores (F4, F8...)

5. Impacto en otros procesos: Otros workloads en la misma capacidad sufren degradación

Escenario 3: Ingesta desde Azure SQL Database

Este escenario evalúa el consumo de CUs al cargar datos desde una base de datos relacional estructurada en Azure SQL Database hacia tablas Delta en Microsoft Fabric.

Operación realizada: Lectura completa de tablas desde Azure SQL Database y escritura en tablas Delta sin transformaciones. Operación de extracción pura (full load) para medir el consumo base en conexiones a bases de datos cloud.

Dataset utilizado

Se han evaluado dos tablas de diferentes tamaños para analizar el comportamiento escalable:

Tabla 1: Customer (Pequeña)

Características:

• Nombre de tabla: customer

• Número de registros: 1,679,846

• Tamaño: 679.47 MB

Tabla 2: Sales (Mediana-Grande)

Características:

• Nombre de tabla: sales

• Número de registros: 23,719,935

• Tamaño: 2,989 GB

Resultados

Revisando el informe de Microsoft Fabric Capacity Metrics:

Tabla customer

Coste económico:

• Pipeline: €0.0047 - El más económico por tiempo

• Notebook PySpark: €0.0050 - Prácticamente igual (+6%)

• Copy Job: €0.0052 - Similar (+11%)

• Dataflow Gen2: €0.0116 - 147% más caro que Pipeline

Consumo de CUs y tiempos de ejecución

Tabla sales

Coste económico:

• Notebook PySpark: €0.0082 - El más económico

• Copy Job: €0.0173 - 2.11x más caro

• Pipeline: €0.0236 - 2.88x más caro

• Dataflow Gen2: €0.0667 - 8.13x más caro

Consumo de CUs y tiempos de ejecución

La diferencia se amplifica: PySpark consume 3x menos de las CUs de Pipeline y menos de 23x del Dataflow Gen2. PySpark no solo consume menos CUs, sino que es casi 3 veces más rápido que Pipeline.

Conclusión final

La elección del artefacto correcto en Microsoft Fabric es una decisión estratégica que impacta:

• 💰 Costes operativos (diferencias del 400-700% en grandes volúmenes)

• ⚡ Tiempos de ejecución (diferencias del 500-800% en grandes volúmenes)

• 📊 Capacidad disponible (eficiencia permite capacidades más pequeñas)

• 👥 Productividad del equipo (menos tiempo esperando procesos)

Lecciones aprendidas:

1. El tamaño importa exponencialmente: Una diferencia del 9% en archivos pequeños se convierte en 500% en archivos grandes

2. El origen importa: Azure SQL es más eficiente que CSV para todos los artefactos

3. PySpark es el rey indiscutible en producción: Para cualquier volumen >1 GB, PySpark es superior en todos los aspectos medibles

4. Dataflow Gen2 no escala: Su facilidad de uso no justifica sobrecostos del 500-700% en producción

5. La formación se paga sola: Invertir en formación de PySpark se amortiza en semanas con el ahorro en CUs

La interfaz visual y facilidad de uso tienen un precio en Capacity Units. En archivos o tablas pequeñas, ese precio puede ser aceptable. En archivos o tablas grandes, ese precio es prohibitivo.

El potencial de ahorro de cientos o miles de euros anuales (dependiendo del volumen de cargas) justifica ampliamente:

• La inversión en formación del equipo

• El tiempo de migración de procesos existentes

• El establecimiento de buenas prácticas y estándares