Dataflows en Fabric

Este contenido fue traducido mediante IA y no ha sido revisado por un editor humano. Las imágenes y los gráficos permanecen en su idioma original.

Conclusiones clave

• Usa Dataflows en lugar de Power Query en modelos semánticos cuando quieras transformaciones de Power Query reutilizables y gobernadas fuera de los modelos semánticos individuales, especialmente cuando, de lo contrario, la misma lógica de transformación se duplicaría y podría divergir con el tiempo.
• Gen1 funciona en Workspaces Pro pero capacidades útiles como la actualización incremental, las entidades calculadas/vinculadas y DirectQuery requieren capacidad Premium o PPU. Gen2 requiere una capacidad de Fabric, pero te ofrece mejor automatización del ciclo de vida, más reutilización entre la variedad de destinos a los que puedes escribir (Lakehouse, SharePoint, etc.) y una mejor experiencia de usuario con guardado automático y validación en segundo plano.
• Los Dataflows son una buena opción para la ingesta de bajo código, la transformación y la escritura en diversos destinos de almacenamiento de datos en el caso de Gen2. Los notebooks suelen ser más rentables desde una perspectiva de CU y siguen ganando en requisitos a gran escala o personalizados (p. ej., lógica compleja de Spark, bibliotecas, pruebas), a costa de una mayor carga de ingeniería. Data Wrangler en notebooks ofrece una interfaz gráfica similar a la de Power Query para seleccionar fragmentos de código para transformaciones comunes, y Copilot para ayudarte a escribir código.

Este resumen lo elabora el autor, no la IA.

En este artículo, hablaremos brevemente de qué son los Dataflows, en qué se diferencian Gen1 y Gen2, qué actualizaciones nuevas son interesantes y qué ventajas tienen los Dataflows frente a Power Query en modelos semánticos de importación y notebooks de Fabric.

Introducción a los Dataflows

Los Dataflows son elementos reutilizables de transformación de datos low-code en Power BI (Dataflow Gen1) y Microsoft Fabric (Dataflow Gen2). Se conectan a Data sources, realizan transformaciones definidas en Power Query M y guardan las tablas resultantes. Piensa en ellos como la capa de Power Query trasladada fuera de un modelo semántico de importación, para que las transformaciones de Power Query se puedan reutilizar y gobernar de forma independiente del modelo semántico.

Algunos casos de uso comunes de los Dataflows incluyen:

• Centralizar transformaciones de datos repetidas, desacoplándolas de los modelos semánticos.
• Mover datos desde una variedad de orígenes hacia una variedad de destinos en Fabric y Azure.
• Exponer datos de un origen con el que los usuarios no deberían interactuar directamente, o simplemente en un formato más adecuado para el usuario.

En la práctica, los Dataflows se sitúan en un punto intermedio ideal entre Power Query incrustado en modelos semánticos individuales (rápido de crear, pero difícil de reutilizar y gobernar) y los pipelines completos de ingeniería de datos o notebooks (más flexibles, pero con más sobrecarga).

El siguiente diagrama te ayuda a entender dónde encajan los Dataflows en la “visión global” de Fabric y Power BI.

Gen1 y Gen2

Los Dataflows existen desde hace tiempo. Desde la introducción de Microsoft Fabric, existen 2 generaciones en paralelo: Dataflow Gen1 (“Gen1”) y Dataflow Gen2 (“Gen2”). Gen2 es exclusivo de Fabric y es el sucesor de Gen1, ampliando la funcionalidad de distintas formas. Siguen solapándose, pero tienen algunas diferencias clave que se describen a continuación:

• Experiencia de creación. Gen1 y Gen2 usan la experiencia de Power Query Online en el servicio de Power BI, pero Gen2 incluye guardado automático (incluidos los borradores) y validación en segundo plano.
• Destino de salida. Gen1, de forma predeterminada, persiste la salida en el almacenamiento interno proporcionado por Power BI, o en una cuenta de almacenamiento de ADLS Gen2 que proporcionas tú. Gen2 puede enviar el resultado de una consulta a una variedad de destinos: tabla de base de datos Azure SQL, tabla de Azure Data Explorer (Kusto), archivo de ADLS Gen2, tabla delta de Lakehouse de Fabric, archivo de Lakehouse de Fabric, tabla de Warehouse de Fabric, tabla de base de datos KQL de Fabric, tabla de base de datos SQL de Fabric y archivo de SharePoint. Los destinos se configuran por consulta, por lo que un único Dataflow Gen2 puede cargar distintas consultas en distintos destinos.
• Forma de salida. Gen1 publica entidades en almacenamiento administrado pensado para consumirse como tablas mediante los conectores de Dataflow/CDM, no como archivos diseñados por el usuario. Gen2 puede publicar tablas o archivos, donde los “archivos” son un destino de primera clase para flujos de trabajo posteriores basados en archivos.
• Licenciamiento. Gen1 está disponible en Workspaces Pro. Algunas características importantes de los Dataflows Gen1, como Enhanced Compute Engine, DirectQuery, actualización incremental y entidades calculadas/vinculadas, solo están disponibles en Workspaces con capacidad de Fabric, Premium o PPU. Gen2 requiere que el Workspace esté en una capacidad de Fabric o en una capacidad de prueba de Fabric.
• Ejecución y cómputo. Los Dataflows Gen1 en Workspaces Pro se ejecutan en la capacidad compartida de Power BI, con límites de actualización más estrictos. Si Gen1 está en un Workspace con capacidad de Fabric, Premium o PPU, se puede habilitar Enhanced Compute Engine (ECE), tras lo cual pasan a estar disponibles características como DirectQuery a ese Dataflow Gen1. Entonces también es posible reutilizar consultas de Dataflows existentes referenciándolas (las entidades vinculadas) dentro de nuevas entidades calculadas. Los Dataflows Gen2 se ejecutan en motores de cómputo SQL de Fabric respaldados por la capacidad de Fabric y usan recursos de preparación creados automáticamente, como Lakehouses y Warehouses, para el acceso y el almacenamiento de datos. Estos recursos de preparación existen en el Workspace y Microsoft recomienda no acceder a ellos ni modificarlos directamente.
• Actualización incremental. El mecanismo de actualización incremental de Gen1 se basa en particiones. Las particiones se recargan de forma selectiva y pueden fusionarse de manera oportunista con el tiempo a medida que salen del rango incremental (por ejemplo, meses que se fusionan en trimestres) para mejorar el almacenamiento y el rendimiento de las consultas. La actualización incremental de Gen2 funciona con segmentos fijos de una sola unidad (es decir, días o semanas o meses, etc.) y usa un enfoque de reemplazo en el destino para los segmentos de datos que procesa (es decir, eliminar e insertar para ese rango). Se configura directamente en el editor de Gen2 y tiene límites explícitos (por ejemplo, número de segmentos).
• Integración con otros recursos de Fabric." El almacenamiento predeterminado de Power BI de Gen1 se puede consumir mediante el conector de Dataflows de Power Query disponible en modelos semánticos y Dataflows. Otros recursos de Fabric solo pueden usar Dataflows Gen1 si has aportado tu propio almacenamiento de ADLS Gen2. En los Dataflows Gen2, el resto de recursos de Fabric son elementos de primera clase: el almacenamiento puede escribirse en la variedad de destinos descrita antes y los pipelines pueden orquestar ejecuciones de Dataflows Gen2.
• DevOps y ciclo de vida. Los Dataflows Gen1 son compatibles con los pipelines de implementación de Fabric (con algunas limitaciones), pero no con la integración de Git del Workspace. En la práctica, para CI/CD eso significa que necesitarías soluciones alternativas, como exportar e importar definiciones de Dataflows Gen1 a través de la API REST. Los Dataflows Gen2 están totalmente compatibles con los pipelines de implementación de Fabric y la integración de Git del Workspace.
• Cambios de esquema. Gen1 almacena los datos en un formato administrado por el Dataflow, por lo que el esquema es el que haya en el momento de la actualización. Cambiar el esquema elimina todos los datos y siempre requiere una recarga completa. Gen2, en cambio, puede escribir en destinos donde hay que gestionar los cambios de esquema: de forma estricta (esquema fijo y fallo si no coincide) o de forma flexible (dinámico/administrado: el esquema del destino se ajusta para coincidir).
• Supervisión. Gen1 tiene historial de actualizaciones por Dataflow en la interfaz de usuario del servicio de Power BI. Las actualizaciones de Gen2 están disponibles en la interfaz ‘Monitoring Hub’, con más metadatos de ejecución y detalles a nivel de actividad.
• Permisos. Gen1 puede ser consumido por visores del Workspace, sin compatibilidad con la seguridad a nivel de filas. Gen2 solo puede ser consumido por colaboradores del Workspace y superiores; no se admite el rol de visor. La seguridad a nivel de filas se admite a través del destino.
• Restricciones del gateway. Tanto los Dataflows Gen1 como los Gen2 solo pueden usar un Gateway por Dataflow. Actualmente, Gen2 tiene algunos problemas conocidos con el puerto de salida 1433 del Gateway para destinos.
• Límites de la plataforma. Gen1 en capacidad compartida tiene límites más estrictos (por ejemplo, tiempos de espera de actualización de 2 horas por tabla y 3 horas por Dataflow) y características útiles como la actualización incremental están sujetas al requisito de capacidad. Los límites de Gen2 son más específicos y están relacionados con Data Factory, como restricciones de permisos y de tenant.
• Integración con Copilot e IA. No hay integración con IA ni compatibilidad con Copilot para los Dataflows Gen1. Gen2 incluye compatibilidad con Copilot para crear consultas y datos de ejemplo con prompts en lenguaje natural, si has configurado Copilot en Fabric con las suscripciones adecuadas.

Estas diferencias revelan una dirección general clara: en la mayoría de los casos, Gen2 ha sustituido a los Dataflows Gen1. Los esfuerzos de desarrollo de Microsoft están claramente centrados en Gen2, por lo que es esperable que la brecha de funcionalidades se amplíe. Gen1 puede seguir siendo una opción pragmática si trabajas principalmente con Workspaces Pro/compartidos y/o aún no estás listo para adoptar Fabric. Sin embargo, la falta de características avanzadas como la actualización incremental y los límites de actualización más estrictos en Workspaces Pro/compartidos pueden pasar factura.

Dataflows vs Power Query en modelos semánticos de importación

Power Query dentro de un modelo semántico de importación suele ser la forma más rápida de empezar, pero escala mal cuando tienes varios modelos, varios equipos o transformaciones de datos repetidas que deberían ser coherentes en todo el tenant/la organización.

Los dataflows suelen ser mejores cuando quieres:

• Transformación reutilizable entre modelos. Si la misma lógica de transformación se duplica en varios modelos, tienes la sobrecarga de gestionarla entre modelos y el riesgo de divergencia entre modelos. Centralizar la lógica en un Dataflow reduce la sobrecarga y elimina el riesgo de divergencia.
• Acceso controlado al origen. En lugar de que cada modelo semántico o usuario tenga acceso directo al sistema de origen, un Dataflow puede convertirse en la capa administrada de ingesta y transformación. Esto es especialmente útil cuando solo se deben consumir datos concretos de un origen.
• Separación de la actualización. Los Dataflows se actualizan de forma independiente de los modelos semánticos. Pueden ejecutarse según su propia programación y, si fallan, no provocarán que fallen las actualizaciones de los modelos aguas abajo. Eso también significa que hay dos capas de actualización que coordinar: los Dataflows y, después, el modelo semántico.
• Compatibilidad con varios consumidores. Power Query en un modelo semántico solo puede servir a ese modelo. Un Dataflow Gen2 puede guardar tablas transformadas en un Lakehouse o Warehouse y luego alimentar a modelos semánticos, notebooks, consumidores basados en SQL, etc.

Incrustar Power Query en modelos semánticos a menudo sigue siendo la opción correcta si:

• Las transformaciones específicas del modelo no se pueden llevar aguas arriba y es poco probable que se reutilicen en otros modelos.
• Quieres una sola actualización (la del modelo semántico) de la que ocuparte.

Dataflows vs notebooks de Fabric

Los notebooks y los Dataflows se solapan porque ambos pueden ingestar y transformar datos. La diferencia no es «qué se puede hacer», sino quién es el usuario principal y cuánta sobrecarga de ingeniería estás dispuesto a asumir.

Normalmente, los Dataflows son mejores cuando quieres:

• Priorizar la simplicidad. Esto encaja mejor en escenarios descentralizados o de autoservicio, donde equipos no técnicos asumen la responsabilidad del ETL.
• Transformaciones de bajo código con Power Query M en una interfaz gráfica de usuario. Los desarrolladores de Power BI a menudo ya tienen conocimientos de Power Query, así que pueden empezar con Dataflows rápidamente.
• Una forma sencilla de publicar tablas reutilizables en distintos formatos. Gen2 puede escribir tablas o archivos en destinos compatibles por consulta.
• Un modelo operativo de ingesta para BI más ligero, en un entorno donde las transformaciones con mucha ingeniería son poco habituales y Power Query M está bien adoptado.

En general, los notebooks son una mejor opción cuando:

• Quieres optimizar el coste. En muchos escenarios, los notebooks de Fabric suelen considerarse más rentables y con mejor rendimiento que las alternativas (aunque no es algo universal).
• Necesitas flexibilidad u observabilidad de nivel de ingeniería, como bibliotecas personalizadas, pruebas, lógica compleja y registro estructurado. Esto suele encajar mejor en escenarios centralizados, donde los equipos de BI o TI son responsables de los procesos de ETL, o donde los equipos descentralizados se sienten más cómodos trabajando con código.
• Quieres un ciclo de vida "code-first". Los notebooks suelen escribirse en PySpark, Python o T-SQL. Esto es especialmente interesante cuando usas LLMs y agentes de programación como Claude Code para facilitar el desarrollo de notebooks. Data Wrangler reduce la «barrera de entrada» al código al proporcionar una interfaz gráfica para elegir fragmentos de código para transformaciones habituales y la integración de Copilot para ayudarte a escribir código.
• Las cargas de trabajo suelen ser pesadas o de gran escala.

Primeros pasos con Dataflows

Al empezar con Dataflows, la primera decisión es si crear un Dataflow Gen1 o Gen2:

• Si no estás en capacidad de Fabric, Gen1 es la única opción.
• Si sí tienes acceso a una capacidad de Fabric, entonces Gen2 es una opción viable. Aun así, no tienes por qué optar por Gen2 automáticamente. Si los modelos semánticos van a ser los únicos consumidores del Dataflow y no necesitas almacenar los datos en un Lakehouse/Warehouse/SharePoint/etc., Gen1 puede ser una forma práctica de empezar.
• Si el Dataflow se va a usar más allá de los modelos semánticos o los datos deben volcarse en un Lakehouse/Warehouse/SharePoint/etc., Gen2 es la única opción de Dataflow.

Una vez elegida la generación, las siguientes decisiones tienen que ver sobre todo con el alcance, los contratos y las operaciones:

• Mantén el alcance reutilizable, no específico del modelo. Los Dataflows aportan más valor cuando producen tablas depuradas y útiles de forma amplia. Si te ves añadiendo transformaciones que solo aplican a un modelo semántico, es una señal de que esa lógica corresponde, en su lugar, al Power Query de ese modelo semántico.
• Trata el esquema de salida como un contrato. Tanto si publicas en el almacenamiento administrado de Gen1 como en los destinos de Gen2 (Lakehouse, SharePoint, etc.), los consumidores posteriores dependerán de nombres de columnas, tipos y significados concretos. Si cualquiera de estos cambia sin aviso previo, las actualizaciones fallarán y los usuarios pueden verse afectados. Cuando se esperan cambios frecuentes, planifícalos desde el principio (sobre todo en destinos de Gen2, donde puedes elegir entre un control de esquema estricto o flexible).
• Sé deliberado al orquestar las actualizaciones, Mover transformaciones a un Dataflow introduce otra capa de actualización. Esta separación puede ser una fortaleza (calendarios independientes, aislamiento de fallos), pero también implica asegurarte de que los Dataflows se han actualizado correctamente antes de que se actualicen los consumidores aguas abajo.
• Elige el destino en función de quién necesita los datos, En Gen2, el destino de salida forma parte del diseño. Elige el destino que mejor se ajuste a los patrones de consumo:
  • Usa tablas de Lakehouse o Warehouse cuando quieras una capa depurada y duradera que puedan consumir varios modelos semánticos, notebooks o consumidores basados en SQL.
  • Usa archivos cuando el flujo de trabajo posterior se base en archivos (p. ej., exportaciones para compartir externamente, interoperabilidad con Spark).
• Define una regla para cuándo cambiar a notebooks, Los Dataflows van bien para transformaciones de bajo código y ETL sencillo. Si las transformaciones pasan a requerir mucha ingeniería (p. ej., algoritmos complejos, uniones grandes, etc.), los notebooks suelen ser la mejor opción a largo plazo.
• Nombra y documenta los Dataflows como si fueran un activo compartido, Los Dataflows se convierten en elementos de los que muchos dependen en cuanto se reutilizan. Usa nombres claros, descripciones breves y convenciones de propiedad para que la gente pueda descubrirlos y adoptarlos (de forma segura).

Empieza con algo pequeño, optimiza para la reutilización y evita convertir los Dataflows en un almacén de datos sin querer.

Lecturas recomendadas

• Guía de decisiones para mover datos en Microsoft Fabric (Microsoft Learn) 

• La máxima de Roche sobre la transformación de datos (BI Polar) 

• Comparación del coste de Dataflows Gen1 y Gen2 (Brunner BI) 

• Comparación de Dataflow Gen2 vs Notebook en costes y usabilidad (FourMoo) 

• Tutorial para crear Dataflows Gen2 (Microsoft Learn) 
  

En conclusión

Los Dataflows se entienden mejor como una capa reutilizable de transformación de bajo código que se sitúa entre las fuentes y los modelos semánticos. Gen1 sigue siendo una opción pragmática para escenarios de Power BI centrados en Pro, mientras que Gen2 es la opción de futuro en capacidad de Fabric, especialmente cuando quieres destinos más amplios, una integración más estrecha y un ciclo de vida más orientado a la automatización. Si las transformaciones pasan a requerir mucha ingeniería o el coste/rendimiento es la principal preocupación, los notebooks suelen ser la mejor opción a largo plazo.