Power BI Dataflows vs Datamart: diferencias clave

¿Qué problema resuelven Dataflows y Datamarts?

En entornos Power BI sin arquitectura centralizada, cada informe tiene sus propias transformaciones en Power Query. Cuando la lógica cambia (una métrica redefinida, una fuente migrada), hay que actualizar N informes. Dataflows y Datamarts existen para evitar esto: centralizar la preparación de datos en un único punto.

¿Qué son los Dataflows de Power BI?

Un Dataflow es esencialmente Power Query en la nube: defines transformaciones (ETL) que se ejecutan en el servicio de Power BI y almacenan el resultado en Azure Data Lake Storage. Los informes y modelos semánticos consumen los Dataflows como fuente de datos ya preparados, en lugar de conectarse directamente a los sistemas fuente.

Características clave de los Dataflows

• Transformaciones en lenguaje M (Power Query), sin necesidad de SQL ni Python
• Ejecución programada independiente del refresco de los informes
• Soporte para Dataflows de primera y segunda generación (Gen2 con mayor rendimiento)
• Compatibilidad con directquery incremental para grandes volúmenes
• Reutilizables: múltiples informes pueden usar el mismo Dataflow como fuente

¿Qué son los Datamarts de Power BI?

Un Datamart de Power BI es un almacén de datos relacional gestionado (basado en Azure SQL Database internamente) con un modelo semántico incluido. Permite a equipos de negocio crear y consultar datos relacionales con SQL sin necesitar un DBA ni provisionar infraestructura de base de datos.

Características clave de los Datamarts

• Base de datos SQL relacional gestionada automáticamente por Microsoft
• Incluye un modelo semántico listo para conectar informes Power BI
• Permite consultas SQL directas desde Power BI Desktop o herramientas externas
• Pensado para escenarios donde el equipo prefiere SQL sobre M (Power Query)
• Disponible en licencias Premium Per User (PPU) o Premium

Comparativa directa: Dataflows vs Datamarts

¿Cuándo usar Dataflows?

• Tu equipo domina Power Query y quiere reutilizar transformaciones en múltiples informes
• Necesitas un pipeline de preparación de datos que se ejecute antes de que los informes se refresquen
• Tienes fuentes heterogéneas que requieren limpieza y normalización antes de modelar
• Quieres reducir el tiempo de carga en los informes sacando las transformaciones del modelo

¿Cuándo usar Datamarts?

• El equipo prefiere SQL sobre M para definir la lógica de negocio
• Necesitas un punto centralizado de datos relacionales sin provisionar un data warehouse externo
• Quieres que los usuarios de negocio puedan consultar datos directamente con SQL
• El volumen de datos es moderado y no justifica Synapse Analytics o Snowflake

¿Qué limitaciones tener en cuenta?

Los Dataflows tienen limitaciones en la gestión de dependencias entre entidades y pueden ser lentos con volúmenes muy grandes sin Dataflows Gen2. Los Datamarts tienen límites de almacenamiento (actualmente 100 GB por Datamart) y no son adecuados para empresas con necesidades de data warehouse complejas o multi-tenant.

¿Cuánto cuestan? Licencias y costes reales

El coste de Dataflows y Datamarts en Power BI no es inmediatamente obvio porque depende de la licencia del workspace, no de una suscripcion independiente. Entender que licencia necesitas para cada herramienta evita sorpresas cuando el proyecto ya esta en marcha.

Para una empresa de 50 usuarios analíticos, la diferencia de coste entre usar solo Dataflows Gen1 (Power BI Pro) y anadir Datamarts (PPU) es de aproximadamente 10 USD por usuario al mes, es decir, unos 500 USD mensuales adicionales para el equipo completo. A cambio, el equipo gana una capa relacional SQL gestionada sin necesitar Synapse ni Snowflake. Para muchas empresas medianas, ese coste incremental es justificable si evita pagar una licencia de Snowflake o provisionar y mantener un Azure SQL Database separado.

Para poner en perspectiva el coste del Dataflows Gen2 frente a alternativas: Snowflake en su tier Standard para 100 usuarios con un volumen moderado de consultas puede costar entre 2.000 y 5.000 USD mensuales dependiendo del crédito de compute. Dataflows Gen2 con Fabric en capacidad F4 (~524 USD/mes) puede ser competitivo para equipos que ya tienen licencias Microsoft, aunque con menos funcionalidad que Snowflake en integraciones avanzadas. Los precios son orientativos y sujetos a cambio; contrasta siempre con la calculadora oficial de Microsoft.

Migración práctica: de Excel a Datamart de Power BI en 5 pasos

El caso más frecuente que encontramos en empresas medianas es este: los datos de ventas viven en un Excel compartido en SharePoint, varios analistas lo descargan, lo modifican con sus propias macros y los informes de Power BI parten de versiones distintas del mismo fichero. El resultado es desincronizacion, errores y reuniones para conciliar números. Mover ese Excel a un Datamart de Power BI resuelve el problema en menos tiempo del que parece.

Esto lo viví muchas veces antes de fundar MERIDIAN: distintos sistemas, o distintas copias de un mismo Excel, usando nombres diferentes para el mismo concepto, con duplicados y formatos incompatibles, hasta que nadie sabía ya cuál era la versión fiable. La solución nunca fue prohibir el Excel, sino construir una única fuente de verdad de la que ese Excel, y todo lo demás, pudiera alimentarse.

1. 1Crear el Datamart en Power BI Service. En el workspace con licencia PPU o Premium, selecciona Nueva > Datamart. Power BI provisiona automáticamente una base de datos Azure SQL gestionada. No necesitas configurar servidor, usuario ni password: Microsoft gestiona toda la infraestructura.
2. 2Conectar el Excel de SharePoint como fuente en el editor del Datamart. El editor del Datamart incluye un Power Query integrado. Selecciona SharePoint Online como conector, navega hasta el fichero Excel y carga las hojas que necesitas. Si el Excel tiene varias hojas (ventas, clientes, productos), puedes cargar todas en el mismo paso.
3. 3Definir transformaciones básicas en Power Query. Establece los tipos de datos correctos (fechas como Date, importes como Decimal, IDs como Text), renombra columnas con nombres claros y consistentes, elimina filas vacias o de encabezado duplicadas. Este paso es crítico: los tipos de datos mal definidos generan errores silenciosos en los informes.
4. 4Crear relaciones entre tablas dentro del Datamart. Una vez cargadas las tablas de ventas, clientes y productos, define las relaciones en el editor de relaciones del Datamart (similar al modelo de datos de Power BI Desktop). Esto convierte las tablas planas del Excel en un modelo relacional que soporta análisis cruzados sin duplicar datos.
5. 5Publicar el modelo semántico y conectar los informes. Una vez el Datamart esta listo, Power BI genera automáticamente un modelo semántico (dataset) que los informes pueden usar como fuente via DirectQuery. Todos los informes del equipo apuntan ahora al mismo modelo centralizado. Cuando el Excel fuente se actualiza en SharePoint, el Datamart se refresca según la programación configurada y todos los informes reflejan los datos actualizados.

Dos limitaciones a tener en cuenta en este proceso. Primero, si el Excel tiene más de 1 millon de filas, el conector de SharePoint puede ser lento o dar errores; en ese caso conviene mover primero los datos a una tabla de SQL Server o Azure SQL antes de cargar en el Datamart. Segundo, si el Excel no tiene una estructura tabular consistente (celdas combinadas, totales intercalados, encabezados en varias filas), el tiempo de limpieza en Power Query puede ser mayor que el de la implementación del Datamart en si.