Dataflows Gen1 frente a Gen2 en Microsoft Fabric: cómo elegir la arquitectura adecuada de staging y cómputo
By Mirko Peters ·
Compara Dataflows Gen1 y Gen2 en Microsoft Fabric. Descubre cómo el almacenamiento, el staging de cómputo y la capacidad afectan a tu estrategia de ETL en la nube.
Automatically translated with AI from the original post. Read the English original

Al migrar cargas de trabajo de ETL a Microsoft Fabric, elegir la arquitectura adecuada de staging y cómputo entre Dataflows Gen1 y Gen2 afecta directamente al rendimiento de tus canalizaciones, a los costes de recursos y a la fiabilidad de los datos. Entender las diferencias de fondo en la asignación de cómputo y en el manejo del almacenamiento evita cuellos de botella arquitectónicos costosos antes de que tu equipo escale sus informes.
Puntos clave
- Los Dataflows Gen2 introducen una integración nativa con OneLake, lo que cambia de forma fundamental la manera en que los datos se preparan y almacenan en comparación con Gen1.
- Elegir una opción de cómputo incorrecta durante la creación puede provocar limitaciones inesperadas de capacidad y una degradación del rendimiento en tu área de trabajo de Fabric.
- Gen1 dependía en gran medida de mecanismos de almacenamiento externos, mientras que Gen2 escribe directamente en tablas de Lakehouse de Fabric como destino predeterminado.
- Una configuración de staging adecuada evita transformaciones de datos redundantes y optimiza las actualizaciones de tu modelo semántico de Power BI.
- Alinear tu estrategia de ETL con las unidades de capacidad de Fabric evita que tu organización acabe con costes de cómputo descontrolados.
Entender el cambio de arquitectura en Fabric
La transición de los dataflows heredados de Power BI a los dataflows de Microsoft Fabric no es simplemente un cambio de nombre; representa una reestructuración arquitectónica completa de la forma en que los datos en la nube se ingieren, transforman y persisten. En el mundo heredado de Gen1, los dataflows se diseñaban principalmente para alimentar modelos semánticos de Power BI. Operaban dentro de un ecosistema algo aislado: las transformaciones de datos se realizaban en Power Query Online y la salida se almacenaba en un almacenamiento interno gestionado íntegramente por el servicio de Power BI.
Con la llegada de Microsoft Fabric, los Dataflows Gen2 se han diseñado desde cero para usar OneLake como repositorio central de datos. Esto significa que cada transformación que aplicas a través de Power Query Online ya no queda atrapada en un contenedor de modelo propietario. En su lugar, Gen2 tiende un puente entre la preparación de datos de autoservicio tradicional y la ingeniería de datos empresarial, escribiendo directamente en tablas Delta Parquet de formato abierto dentro de un Lakehouse de Fabric. Este cambio fundamental modifica la forma en que los arquitectos cloud abordan el staging de datos, el uso del cómputo y la confianza en los informes posteriores.
El cambio de paradigma en el almacenamiento
En entornos heredados, si un analista de negocio necesitaba limpiar una exportación de Excel, eliminar filas en blanco y dar formato a las fechas, esos datos quedaban dentro del límite de almacenamiento del flujo de datos. Si otro departamento quería usar ese mismo conjunto de datos ya limpio, a menudo tenía que extraerlo desde el informe o volver a crear la consulta. Dataflows Gen2 resuelve esto tratando el Lakehouse como el destino principal. Una vez ejecutado el flujo de datos, los datos limpios quedan disponibles de inmediato como tablas Delta, listas para los cuadernos de Spark, los puntos de conexión de análisis SQL y los informes de DirectLake, sin necesidad de mover datos adicionalmente.
La decisión de cómputo y almacenamiento provisional que la mayoría de equipos pasa por alto
Una de las decisiones de arquitectura más críticas a las que se enfrentan los ingenieros al crear Dataflows Gen2 es cómo gestionar las fases de cómputo y de almacenamiento provisional. A diferencia de Gen1, donde la gestión del cómputo estaba en gran medida abstraída y a veces era opaca, Gen2 se ejecuta sobre las unidades de capacidad (CU) de Fabric subyacentes. Si tu organización no supervisa con cuidado cómo y cuándo se almacenan los datos provisionalmente durante la fase de evaluación de consultas, corres el riesgo de consumir tu asignación de capacidad más rápido de lo previsto.
Cuando aplicas transformaciones complejas, Power Query evalúa si los pasos pueden trasladarse (plegarse) al origen de datos o si deben ejecutarse localmente en el motor del flujo de datos. En Gen2, el área de almacenamiento provisional actúa como una zona de aterrizaje intermedia. Si está mal configurada, grandes conjuntos de datos pueden cargarse repetidamente en memoria, procesarse y volver a escribirse, lo que genera una sobrecarga de cómputo innecesaria. Los arquitectos deben evaluar sus sistemas de origen, la latencia de red y la complejidad de las transformaciones para decidir si trasladan el procesamiento a la base de datos de origen o dejan que Fabric haga el trabajo pesado.
Optimización de unidades de capacidad para cargas de trabajo ETL
La capacidad de Fabric es un grupo compartido en toda la organización. Cuando un Dataflow Gen2 poco optimizado ejecuta actualizaciones programadas en horas punta de negocio, puede consumir capacidad y provocar limitaciones que afecten a la representación de informes de Power BI para los usuarios directivos. Para evitarlo, los equipos deben aislar los trabajos ETL pesados en áreas de trabajo dedicadas con reservas de capacidad adecuadas, o programarlos fuera de las horas punta. Entender cómo interactúan los trabajos de cómputo en segundo plano con las cargas de trabajo interactivas es esencial para mantener un entorno de Fabric estable.
Generar confianza con una arquitectura coherente
El objetivo final de modernizar tus canalizaciones de datos es eliminar las correcciones manuales en Excel que lastran los informes de negocio. Cuando los informes fallan, rara vez es por falta de datos; casi siempre es por falta de confianza. Cuando los usuarios ven cifras contradictorias porque un informe se alimenta de un CSV sin procesar y otro de un flujo de datos heredado, la adopción se desploma.
Al estandarizar en Dataflows Gen2 y aprovechar la arquitectura de Lakehouse, las organizaciones establecen una única fuente de verdad. Las fechas limpias, los nombres de columna normalizados y la lógica de negocio validada se codifican una sola vez en el flujo de datos y se propagan automáticamente a los niveles inferiores. Esto reduce los errores humanos, elimina la dependencia de equipos de escritorio individuales y garantiza que, cuando la dirección abra un panel, las cifras subyacentes sean fiables y estén listas para auditoría.
Conclusión
Migrar y crear con Dataflows Gen2 requiere un cambio en la forma de pensar sobre el almacenamiento en la nube, los presupuestos de cómputo y la gobernanza de datos. Si empiezas por un proceso repetitivo y caótico de hojas de cálculo y lo asignas correctamente a un Lakehouse de Fabric, tu equipo podrá crear canalizaciones escalables que resistan el paso del tiempo. Para conocer los conceptos fundamentales detrás de esta evolución y escuchar la opinión de expertos sobre las estrategias modernas de la nube de Microsoft, no dejes de escuchar el episodio completo del podcast M365 FM.
Preguntas frecuentes
¿Cuál es la principal diferencia entre Dataflows Gen1 y Gen2 en cuanto al almacenamiento?
Dataflows Gen1 almacena los datos transformados dentro de los límites de almacenamiento interno de Power BI, mientras que Dataflows Gen2 escribe de forma nativa en tablas Delta Parquet de formato abierto dentro de un Lakehouse de Microsoft Fabric a través de OneLake.
¿Cómo afectan los Dataflows Gen2 a las unidades de capacidad de Fabric?
Los dataflows Gen2 consumen la capacidad subyacente de Fabric durante sus fases de cómputo y almacenamiento provisional. Las transformaciones poco optimizadas o ejecutar actualizaciones pesadas en horas punta pueden agotar tu asignación de capacidad y limitar otras cargas de trabajo.
¿Pueden los Dataflows Gen2 reemplazar a las canalizaciones tradicionales de Azure Data Factory?
Para la preparación de datos de autoservicio, el ETL ligero y la transformación de datos de bajo código, los Dataflows Gen2 son una excelente alternativa. Sin embargo, para la orquestación empresarial compleja, la lógica de ramificación y la ingeniería de datos avanzada, Azure Data Factory o Fabric Pipelines siguen siendo las herramientas preferidas.
¿Por qué es importante la fase de staging en los Dataflows Gen2?
La fase de staging actúa como un área de aterrizaje intermedia para las transformaciones de datos. Configurar correctamente el staging evita el procesamiento redundante de datos, optimiza el plegado de consultas (query folding) y garantiza escrituras eficientes en tu Lakehouse de destino.
¿Cómo mejoran los Dataflows Gen2la confianza en los datos de los informes?
Al automatizar la limpieza de exportaciones manuales desordenadas y centralizar las transformaciones en tablas reutilizables de Lakehouse, Gen2 elimina los workarounds manuales en Excel y garantiza datos coherentes y fiables en todos los informes posteriores.