De los anuncios de la reciente FabCon Europe en Viena, uno que pudo haber pasado desapercibido fue el de las mejoras en el rendimiento y la optimización de costos para Dataflows Gen2.
Antes de profundizar en la explicación de cómo estas mejoras afectan su configuración actual de Dataflows, retrocedamos un paso y brindemos una breve descripción general de Dataflows. Para aquellos de ustedes que son nuevos en Microsoft Fabric, un Dataflow Gen2 es el elemento Fabric sin código o con poco código que se utiliza para extraer, transformar y cargar los datos (ETL).
Un Dataflow Gen2 proporciona numerosos beneficios:
Aproveche más de 100 conectores integrados para extraer los datos de una gran variedad de fuentes de datos. Aproveche una interfaz gráfica de usuario familiar de Power Query para aplicar docenas de transformaciones a los datos sin escribir una sola línea de código: un sueño hecho realidad para muchos desarrolladores ciudadanos. Almacene el resultado de la transformación de datos como una tabla delta en OneLake, de modo que los datos transformados puedan ser utilizados posteriormente por varios motores Fabric (Spark, T-SQL, Power BI…)
Sin embargo, la simplicidad suele tener un coste. En el caso de Dataflows, el costo fue un consumo de CU significativamente mayor en comparación con las soluciones de código primero, como los cuadernos Fabric y/o los scripts T-SQL. Esto ya fue bien explicado y examinado en dos excelentes publicaciones de blog escritas por mis compañeros MVP, Gilbert Quevauvilliers (Fourmoo): Comparación de Dataflow Gen2 vs Notebook en costos y usabilidad, y Stepan Resl: Copy Activity, Dataflows Gen2 y Notebooks vs. SharePoint Lists, así que no perderé el tiempo discutiendo el pasado. En cambio, ¡centrémonos en lo que trae el presente (y el futuro) para Dataflows!
Cambios en el modelo de precios.
Examinemos brevemente lo que se muestra en la ilustración anterior. Anteriormente, cada segundo de ejecución de Dataflow Gen2 se facturaba a 16 CU (CU significa Unidad de capacidad, que representa un conjunto de recursos (CPU, memoria y E/S) utilizados en sinergia para realizar una operación específica). Dependiendo del tamaño de capacidad de Fabric, obtiene una cierta cantidad de unidades de capacidad: F2 proporciona 2 CU, F4 proporciona 4 CU, etc.
Volviendo a nuestro escenario de flujos de datos, analicemos esto usando un ejemplo de la vida real. Supongamos que tiene un flujo de datos que se ejecuta durante 20 minutos (1200 segundos)…
Anteriormente, esta ejecución de Dataflow le habría costado 19.200 CU: 1200 segundos * 16 CU. Ahora, esta ejecución de Dataflow le costará 8.100 CU: 600 segundos (primeros 10 minutos) * 12 CU + 600 segundos (después de los primeros 10 minutos) * 1,5 CU
Cuanto más tiempo deba ejecutarse su flujo de datos, mayores serán los ahorros potenciales en CU que pueda obtener.
Esto es sorprendente por sí solo, pero aún hay más. Quiero decir, es bueno que nos cobren menos por la misma cantidad de trabajo, pero ¿y si pudiéramos hacer que estos 1200 segundos, digamos, 800 segundos? Por lo tanto, no solo nos ahorraría CU, sino que también reduciría el tiempo de análisis, ya que los datos se habrían procesado más rápido. Y de eso se tratan exactamente las siguientes dos mejoras…
Evaluador moderno
La nueva función de vista previa, denominada Modern Evaluator, permite utilizar el nuevo motor de ejecución de consultas (que se ejecuta en .NET core versión 8) para ejecutar flujos de datos. Según los documentos oficiales de Microsoft, los flujos de datos que ejecutan el evaluador moderno pueden proporcionar los siguientes beneficios:
Ejecución de flujo de datos más rápida Procesamiento más eficiente Escalabilidad y confiabilidad
La ilustración anterior muestra las diferencias de rendimiento entre varios “sabores” de Dataflow. No se preocupe, pronto desafiaremos estos números en una demostración y también le mostraré cómo habilitar estas últimas mejoras en sus cargas de trabajo de Fabric.
Computación particionada
Anteriormente, se ejecutaba en secuencia una lógica de Dataflow. Por lo tanto, dependiendo de la complejidad lógica, ciertas operaciones podrían tardar un tiempo en completarse, por lo que otras operaciones en el flujo de datos tuvieron que esperar en la cola. Con la función Partitioned Compute, Dataflow ahora puede ejecutar partes de la lógica de transformación en paralelo, lo que reduce el tiempo total de finalización.
En este momento, existen ciertas limitaciones sobre cuándo se activará el proceso particionado. Es decir, solo los conectores ADLS Gen2, Fabric Lakehouse, Folder y Azure Blob Storage pueden aprovechar esta nueva característica. Nuevamente, exploraremos cómo funciona más adelante en este artículo.
3, 2, 1…¡Acción!
Bien, es hora de desafiar los números proporcionados por Microsoft y comprobar si (y en qué medida) hay una ganancia de rendimiento entre varios tipos de flujos de datos.
Este es nuestro escenario: he generado 50 archivos CSV que contienen datos ficticios sobre pedidos. Cada archivo contiene aproximadamente 575.000 registros, por lo que hay ca. 29 millones de registros en total (aproximadamente 2,5 GB de datos). Todos los archivos ya están almacenados en la carpeta de SharePoint, lo que permite una comparación justa, ya que Dataflow Gen1 no admite OneLake Lakehouse como fuente de datos.
Planeo realizar dos series de pruebas: primero, incluir Dataflow Gen1 en la comparación. En este escenario, no escribiré los datos en OneLake usando Dataflows Gen2 (sí, lo sé, anula el propósito de Dataflow Gen2), ya que quiero comparar “manzanas con manzanas” y excluir el tiempo necesario para escribir datos en OneLake. Probaré los siguientes cuatro escenarios, en los que realizo algunas operaciones básicas para combinar y cargar los datos, aplicando algunas transformaciones básicas (cambiar el nombre de columnas, etc.):
Usar Dataflow Gen1 (el antiguo flujo de datos de Power BI) Usar Dataflow Gen2 sin mejoras de optimización adicionales Usar Dataflow Gen2 solo con el evaluador moderno habilitado Usar Dataflow Gen2 con el evaluador moderno y el proceso particionado habilitados
En la segunda serie, compararé tres versiones de Dataflow Gen2 únicamente (puntos 2 a 4 de la lista anterior), con la escritura de datos en una casa del lago habilitada.
¡Empecemos!
Flujo de datos Gen1
Todo el proceso de transformación en el antiguo Dataflow Gen1 es bastante básico: simplemente combiné los 50 archivos en una sola consulta, dividí las columnas por delimitador y cambié el nombre de las columnas. Entonces, aquí no sucede nada realmente avanzado:
Se ha aplicado el mismo conjunto de operaciones/transformaciones a los tres Dataflows Gen2.
Tenga en cuenta que con Dataflow Gen1 no es posible generar los datos como una tabla Delta en OneLake. Todas las transformaciones persisten dentro del propio flujo de datos, por lo que cuando necesite estos datos, por ejemplo, en el modelo semántico, debe tener en cuenta el tiempo y los recursos necesarios para cargar/actualizar los datos en el modelo semántico del modo de importación. Pero hablaremos de eso más adelante.
Dataflow Gen2 sin mejoras
Ahora hagamos lo mismo, pero esta vez usando el nuevo Dataflow Gen2. En este primer escenario, no he aplicado ninguna de estas nuevas funciones de optimización del rendimiento.
Dataflow Gen2 con evaluador moderno
Bien, ha llegado el momento de la verdad: habilitemos ahora el evaluador moderno para Dataflow Gen2. Iré a Opciones y luego, en la pestaña Escala, marcaré la casilla Permitir el uso del motor de evaluación de consultas moderno:
Todo lo demás sigue exactamente igual que en el caso anterior.
Dataflow Gen2 con evaluador moderno y computación particionada
En el ejemplo final, habilitaré ambas nuevas funciones de optimización en las Opciones de Dataflow Gen2:
Ahora, procedamos a probar y analizar los resultados. Ejecutaré los cuatro flujos de datos en secuencia desde la canalización de Fabric, para que podamos estar seguros de que cada uno de ellos se ejecuta de forma aislada de los demás.
Y aquí están los resultados:
Obviamente, la partición no cuenta mucho en este escenario particular, e investigaré cómo funciona la partición con más detalle en uno de los siguientes artículos, con diferentes escenarios implementados. Dataflow Gen2 con Modern Evaluator habilitado superó a todos los demás con diferencia, logrando un ahorro del 30 % en comparación con el antiguo Dataflow Gen1 y ca. ¡Ahorro de tiempo del 20 % en comparación con el Dataflow Gen2 normal sin ninguna optimización! No olvide que estos ahorros también se reflejan en los ahorros de CU, por lo que el costo final estimado de CU para cada una de las soluciones utilizadas es el siguiente;
Dataflow Gen1: 550 segundos * 12 CU = 6.600 CU Dataflow Gen2 sin optimización: 520 segundos * 12 CU = 6.240 CU Dataflow Gen2 con Modern Evaluator: 368 segundos * 12 CU = 4.416 CU Dataflow Gen2 con Modern Evaluator y particionamiento: 474 segundos * 12 CU = 5.688 CU
Sin embargo, quería volver a verificar y confirmar que mi cálculo es exacto. Por lo tanto, abrí la aplicación de métricas de capacidad y eché un vistazo a las métricas capturadas por la aplicación:
Aunque el resultado general refleja con precisión los números que se muestran en el registro de ejecución de la canalización, el número exacto de CU utilizadas en la aplicación es diferente:
Dataflow Gen1: 7.788 CU Dataflow Gen2 sin optimización: 5.684 CU Dataflow Gen2 con Modern Evaluator: 3.565 CU Dataflow Gen2 con Modern Evaluator y particionamiento: 4.732 CU
Entonces, según la aplicación de métricas de capacidad, un Dataflow Gen2 con Modern Evaluator habilitado consumió menos del 50 % de la capacidad en comparación con el Dataflow Gen1 en este escenario particular. Planeo crear más casos de uso de prueba en los próximos días/semanas y proporcionar una serie más completa de pruebas y comparaciones, que también incluirán un tiempo para escribir los datos en OneLake (usando Dataflows Gen2) versus el tiempo necesario para actualizar el modelo semántico del modo de importación que usa el antiguo Dataflow Gen1.
Conclusión
En comparación con otras opciones (que priorizan el código), los flujos de datos se consideraron (¿con razón?) “la opción más lenta y de menor rendimiento” para la ingesta de datos en Power BI/Microsoft Fabric. Sin embargo, las cosas están cambiando rápidamente en el mundo de Fabric y me encanta cómo el equipo de integración de datos de Fabric realiza mejoras constantes en el producto. Honestamente, tengo curiosidad por ver cómo el rendimiento y el costo de Dataflows Gen2 evolucionan con el tiempo, de modo que podamos considerar aprovechar Dataflows no solo para los requisitos de transformación y ingesta de datos con código bajo o sin código, sino también como una alternativa viable a las soluciones de código primero desde el punto de vista del costo/rendimiento.
¡Gracias por leer!
Descargo de responsabilidad: no tengo ninguna afiliación con Microsoft (excepto ser MVP de la plataforma de datos de Microsoft) y Microsoft no se ha puesto en contacto conmigo ni me ha patrocinado para escribir este artículo.