Ingestar datos con Dataflows Gen2 en Microsoft Fabric

¿Qué te enseña este módulo?

Este es el módulo del ETL low-code en Fabric. Los objetivos oficiales del módulo:

1. Describir las capacidades de Dataflow en Microsoft Fabric.
2. Crear soluciones Dataflow para ingestar y transformar datos.
3. Incluir un Dataflow en un pipeline.

Peso en el examen DP-700

Los Dataflows Gen2 caen principalmente en el Dominio 2 (Ingest and transform):

Definición oficial

Un Dataflow es una herramienta ETL basada en cloud para construir y ejecutar procesos de transformación de datos escalables.

En cristiano: es la forma low-code / visual de hacer ETL en Fabric, usando Power Query Online como interfaz. 🌸

¿Qué puede hacer?

• Extract: conectar a decenas de orígenes (BBDD, Excel, SharePoint, APIs, lakehouses...).
• Transform: aplicar transformaciones visuales (filtrar, agrupar, join, unpivot, etc.).
• Load: escribir a Lakehouse, Warehouse, SQL Database u otros destinos.

¿Cuándo elegir un Dataflow vs otras opciones?

Este es EL escenario clásico de examen:

ETL vs ELT

Los dataflows soportan ambos patterns:

• ETL clásico (Extract → Transform → Load): Dataflow lee source → transforma en memoria → escribe a destino ya transformado.
• ELT moderno (Extract → Load → Transform): Pipeline copia datos raw al lakehouse (bronze) y el Dataflow lee del lakehouse, aplica transformaciones y escribe curado (silver/gold).

Fabric potencia el patrón ELT, especialmente con Fast Copy + staging.

Si has usado Power BI Dataflows clásicos, ese es Gen1. En Fabric tenemos la nueva generación: Gen2.

Qué cambia

Beneficios (según la doc)

1. Extender datos con dimensiones consistentes (ej: tabla de fechas estándar).
2. Self-service para analistas: acceso a subsets de warehouse.
3. Optimizar performance extrayendo datos una vez y reutilizando.
4. Simplificar complejidad: exponer solo dataflows a analistas grandes.
5. Consistencia y calidad: limpiar y transformar antes de cargar al destino.
6. Integración simplificada: interfaz low-code para muchos orígenes.

Estas 3 limitaciones son oro para preguntas de examen. La de RLS especialmente, porque suele venir en escenarios tipo "quiero aplicar RLS al Dataflow" → respuesta: no se puede, aplícalo en downstream.

En Fabric puedes crear un Dataflow Gen2 desde tres sitios:

1. Data Factory workload → New → Dataflow Gen2. La forma más común.
2. Power BI workspace → New → Dataflow Gen2.
3. Directamente desde el lakehouse → New → Dataflow Gen2.

Los tres crean el mismo objeto. La UX y capabilities son idénticas.

Requisitos previos

• Workspace en Fabric capacity (F SKU o Trial).
• Rol Member o superior en el workspace.
• Conector a la fuente que necesitas.

Flujo típico de creación

1. Crear nuevo Dataflow Gen2.
2. Get data → seleccionar conector → configurar credenciales.
3. Aplicar transformaciones visuales en Power Query Online.
4. Configurar data destination (opcional).
5. Save (Gen2 publica automáticamente).
6. Programar refresh o llamarlo desde un pipeline.

La interfaz de Dataflow Gen2 tiene 5 áreas principales. Es idéntica a Power Query Desktop, así que si vienes de Power BI te será familiar 🌸

Power Query ribbon (arriba)

La cinta superior contiene:

• Get data: añadir orígenes.
• Transform data: transformaciones sobre queries.
• Data source settings: gestionar credenciales.
• Parameters: parámetros del dataflow.
• Manage data destinations: configurar dónde escribir.

Queries pane (izquierda)

• Muestra las queries (equivalentes a tablas al cargar).
• Puedes:
  • Duplicar una query (copia independiente).
  • Referenciar una query (referencia; cambios en la original afectan).
  • Disable load: no cargar esta query al destino (útil para queries auxiliares).
  • Agrupar en carpetas.

Concepto clave: puedes tener queries que no cargan a destino pero se referencian por otras. Se llaman "helper queries" o "reference queries".

Diagram View (opcional)

Vista visual de todas las queries y sus relaciones. Muestra:

• Cada query como una forma.
• Líneas conectando queries que se duplican/referencian.
• Iconos indicando transformaciones aplicadas.

Se puede activar/desactivar. Muy útil para entender dataflows complejos.

Data Preview pane (centro)

Muestra un subset de datos para que veas cómo van tus transformaciones. Puedes arrastrar columnas para reordenar, hacer right-click para filtrar o transformar y ver tipos de datos en las cabeceras.

Ojo: es solo preview, no todo el dataset. Para datasets grandes puede ser lento.

Query Settings pane (derecha)

Aquí ves los Applied Steps — cada transformación se registra como un paso.

• Cada paso tiene un icono ⚙️ para modificarlo (algunos no).
• Right-click para renombrar, reordenar o borrar pasos.
• Puedes ver el código M del paso.

También incluye Data Destination para configurar el destino, opciones de incremental refresh y el toggle Enable staging.

Dataflow Gen2 soporta cientos de conectores. Los más comunes, por categorías:

Bases de datos relacionales (cloud y on-prem)

• Azure SQL Database
• SQL Server (on-prem con gateway)
• Oracle
• PostgreSQL
• MySQL
• Snowflake
• Amazon Redshift
• Google BigQuery

Ficheros

• Excel (.xlsx)
• CSV / delimitados
• JSON
• XML
• Parquet
• PDF (con extracción)

Storage

• Azure Data Lake Storage Gen2
• Azure Blob Storage
• Amazon S3 (Preview)

SaaS y aplicaciones

• SharePoint (list, folder)
• Salesforce
• Dynamics 365
• Google Analytics
• Snowflake

Fabric nativos

• Lakehouse
• Warehouse
• KQL Database
• Datamart
• Power BI semantic model

Web

• HTTP / REST APIs
• OData feeds

Autenticación

Según el conector, las opciones típicas: Anonymous, Basic (username + password), OAuth 2.0 (con browser), Windows (para on-prem), Account Key y Service Principal.

Se almacenan como cloud connections, gestionadas centralmente en Fabric.

Dataflow Gen2 soporta prácticamente todas las transformaciones de Power Query. Las más usadas:

Sobre filas

• Filter rows (aplicar condiciones)
• Sort rows (ordenar)
• Remove duplicates
• Choose Top N / Bottom N
• Keep range of rows / Remove range of rows
• Group by (agregaciones)

Sobre columnas

• Add column (custom, from examples, index, conditional)
• Rename columns
• Reorder / Delete columns
• Split column (por delimitador, posición, casing)
• Merge columns
• Replace values
• Change type
• Fill down / Fill up
• Rank column / Percentage calculator

Estructurales

• Merge queries (equivalente a JOIN)
• Append queries (equivalente a UNION)
• Pivot column / Unpivot columns
• Transpose
• Reverse rows

Sobre texto

• Format (uppercase, lowercase, trim, clean...)
• Extract (before delimiter, between, length...)
• Parse (JSON, XML)

Sobre fechas

• Extract (year, month, day, week, quarter)
• Duration (calcular entre fechas)
• Age

Otras

• Split into new column vs Split into rows
• Conditional column
• Fuzzy grouping / Fuzzy matching

Detrás de la interfaz visual, cada transformación se traduce a código M (lenguaje de Power Query).

Ejemplo de código M

Un query simple que lee un CSV y aplica transformaciones:

let
    Source = Csv.Document(
        File.Contents("Files/products.csv"),
        [Delimiter=",", Columns=4, Encoding=1252, QuoteStyle=QuoteStyle.None]
    ),
    #"Promoted Headers" = Table.PromoteHeaders(Source, [PromoteAllScalars=true]),
    #"Changed Type" = Table.TransformColumnTypes(#"Promoted Headers", {
        {"ProductID", Int64.Type},
        {"ProductName", type text},
        {"Category", type text},
        {"ListPrice", type number}
    }),
    #"Filtered Rows" = Table.SelectRows(#"Changed Type", each ([Category] = "Bikes")),
    #"Sorted Rows" = Table.Sort(#"Filtered Rows", {{"ListPrice", Order.Descending}})
in
    #"Sorted Rows"

Estructura de una query M

• let: inicio de la definición.
• Cada línea es un step con nombre y expresión.
• Los steps se referencian entre sí por nombre.
• in: qué devolver como resultado final (normalmente el último step).

Cómo abrir el Advanced Editor

En la ribbon: View → Advanced Editor. O right-click en la query → Advanced Editor.

Ahí puedes editar directamente el código M. Útil para:

• Transformaciones complejas que la UI no cubre.
• Copiar/pegar queries entre dataflows.
• Refactorizar / limpiar código.

Dataflow Gen2 puede escribir el resultado de sus queries a múltiples destinos.

Destinos soportados en Fabric

• ✅ Lakehouse (Delta table)
• ✅ Warehouse (T-SQL table)
• ✅ SQL database in Fabric
• ✅ KQL Database

Destinos Azure

• ✅ Azure SQL Database
• ✅ Azure Data Explorer (Kusto)
• ✅ Azure Synapse Analytics

Cómo configurar destino

Por cada query:

1. En Query Settings pane → botón Data Destination.
2. Seleccionar tipo (Lakehouse, Warehouse, etc.).
3. Configurar workspace, tabla destino, mapping de columnas.
4. Elegir update method:
   • Append: añade filas nuevas.
   • Replace: sobrescribe la tabla completa.

Destination opcional

Un dataflow no está obligado a tener destination. Puedes:

• Crear un dataflow sin destino → las transformaciones se preservan.
• Usarlo como fuente de datos desde Power BI Desktop (discoverable dataflows).
• Incorporarlo en un pipeline para orquestar carga posterior.

Auto-create de tabla

Cuando cargas a un Lakehouse por primera vez, Dataflow puede crear la tabla automáticamente. También puedes elegir una tabla existente.

Query folding es probablemente EL concepto más examinable del módulo. Vamos a fondo.

¿Qué es query folding?

Query folding = capacidad de traducir tus transformaciones Power Query a queries nativas del source (SQL, KQL, etc.) que se ejecutan en el source, no en el dataflow.

Ejemplo:

• Tienes una query: leer tabla Products + filtrar Category = 'Bikes' + seleccionar 3 columnas.
• Sin folding: dataflow trae toda la tabla Products (millones de filas) y filtra localmente.
• Con folding: dataflow ejecuta SELECT ProductName, Category, Price FROM Products WHERE Category = 'Bikes' en el source. Solo se transfieren las filas necesarias.

Por qué importa tantísimo

• ⚡ Rendimiento MUCHO mejor: menos datos transferidos.
• 💰 Costes más bajos: menos CU consumidas.
• 🧠 Aprovecha el motor optimizado del source (índices, particiones, etc.).
• 🔄 Refresh más rápido.

Cómo saber si tu query se folded

En el editor de Power Query, los Applied Steps tienen indicadores visuales:

• 🟢 Círculo verde relleno: paso se folded a source. Todo bien.
• 🟡 Círculo verde parcial: parcialmente folded.
• ⚠️ Círculo naranja/amarillo: no se folded, se ejecuta localmente.

Cuando cualquier step deja de foldear, todos los siguientes tampoco foldean (el folding se "rompe" desde ahí).

Transformaciones que suelen romper folding

Estas transformaciones suelen NO foldear:

• Table.AddIndexColumn (añadir índice)
• Custom columns con funciones Power Query específicas
• Ciertas conversiones de tipo complejas
• Merges (según el conector)
• Table.Buffer
• Iteraciones o loops en M

Transformaciones que suelen SÍ foldear: Filter rows, Select columns, Group by simple, Sort rows, Merge queries (con conectores compatibles) y basic type changes.

Ver la query native (source query)

Right-click en un step → View Native Query (si está disponible). Te muestra el SQL/KQL que se generará. Útil para debugging.

Query folding y source system

Depende del source si puede recibir queries folded:

¿Qué es staging?

Staging = marcar una query para que su output se materialice temporalmente en un staging area interno de Dataflow Gen2.

Dataflow Gen2 tiene dos áreas internas de staging: Staging Lakehouse y Staging Warehouse.

Cuando activas staging en una query, esa query escribe a estos staging areas primero, y las queries downstream pueden leer de ahí.

Filosofía: "stage once, reference many"

El patrón central:

1. Una query lee del source y hace transformaciones simples → staged.
2. Queries downstream referencian esa query staged en lugar de re-leer el source.
3. Las queries downstream pueden foldear al staging SQL endpoint (el warehouse interno).

Beneficios del staging

• ✅ Compute pushdown al staging Warehouse (folding sobre SQL).
• ✅ Evitar leer el source múltiples veces.
• ✅ Habilita transformaciones complejas que no folded al source original.
• ✅ Data quality y auditoría: verificar staged data sin re-leer.
• ✅ Fan-out a múltiples destinos desde un solo staged.

Casos de uso típicos (ELT patterns)

Cómo activar staging

En Query Settings pane → Enable staging toggle en el context menu de la query. También puedes hacer right-click sobre la query.

🎯 Patrón "Extract Previous"

Si notas que en tus applied steps hay un punto donde el folding se rompe:

1. Right-click en el paso donde se rompe el folding.
2. Selecciona Extract previous.
3. Se crea una nueva query con todos los pasos anteriores (que sí foldean).
4. Enable staging en esa nueva query.
5. La query original ahora comienza desde el staged data.

Resultado: la parte inicial folded al source, y la parte compleja folded al staging warehouse. Máxima performance.

¿Qué es Fast Copy?

Fast Copy es una feature que acelera masivamente la ingesta de datos en Dataflow Gen2 usando native, parallelized data movement que bypasea el mashup engine.

🎯 Benchmarks oficiales (impresionantes)

En un test oficial de copia de 5 ficheros Parquet consolidados a Lakehouse:

Y consumió 83% menos capacidad (14.593 CU vs 84.411 CU en Gen1).

Requisitos para Fast Copy

Fast Copy no funciona en cualquier query. Requiere:

1. Source compatible con Fast Copy (ADLS Gen2, S3, Azure SQL, etc.).
2. Transformaciones limitadas en la query — solo las que fold a source.
3. Destino compatible (típicamente Lakehouse).
4. Feature habilitada en workspace settings.

Cómo habilitarlo

Habilitar Fast Copy en el dataflow:

1. En Dataflow Gen2 → Home tab → Options.
2. Tab Scale → activar Allow use of fast copy connectors.

Requerir Fast Copy en una query específica: right-click en query → Require Fast Copy.

Si activas "Require Fast Copy" y la query no es compatible, el dataflow falla. Es una salvaguarda para asegurar que la performance esperada se cumple.

Verificar que se usa

Después del refresh, en detalles → Engine type debe mostrar CopyActivity. Si dice otra cosa, no se usó Fast Copy.

Facturación de Fast Copy

• Standard Compute (mashup engine): 12 CU/segundo hasta 10 minutos, luego 1,5 CU/segundo.
• Fast Copy: 1,5 CU/segundo de copy activity (medido across todos los cores usados).

Fast Copy es ~8× más barato por segundo que el mashup engine. Además, tarda menos.

¿Qué es?

Modern Evaluator es un motor de ejecución mejorado para Dataflow Gen2 que acelera transformaciones heavy sobre conectores no-foldable (o parcialmente foldable).

Cuándo se activa

Automáticamente cuando:

• Trabajas con conectores no-foldable (files, APIs).
• Aplicas filters, derivations, cleansing complejos.

No necesitas hacer nada especial — Fabric lo aplica cuando toca.

Beneficio

Ejecución más rápida sin cambiar la lógica. Es una mejora de infraestructura transparente.

Casos de uso

• Ingesta de ficheros grandes con muchas transformaciones.
• Procesamiento de datos semi-estructurados (JSON, XML).
• Data cleansing intensivo en fuentes no-relacionales.

¿Qué es?

Optimized copy to Lakehouse (Preview) es una feature que optimiza el movimiento de datos desde el staging Warehouse hacia un destino Lakehouse.

Cuándo aplica

Cuando tienes staging activado en una query que escribe a un Lakehouse destination. La feature acelera esa "última milla" (staging → lakehouse).

Cómo habilitarla

En Options → tab Scale → activar Optimized copy to Lakehouse (Preview).

Beneficio

Reduce overhead del staging-to-Lakehouse hop en escenarios ELT.

¿Qué es?

Partitioned Compute (Preview) permite paralelizar transformaciones across particiones/ficheros de datasets grandes.

Cuándo usarlo

• Datasets muy grandes.
• Datos particionados o multi-fichero.
• Transformaciones que pueden ejecutarse en paralelo.
• Se puede combinar con Modern Evaluator.

Beneficio

Ejecución paralela across particiones = tiempos mucho menores en datasets grandes.

Este es uno de los temas más importantes y examinables del módulo. Vamos a fondo 🌸

¿Qué es incremental refresh?

Incremental refresh = en lugar de refrescar toda la tabla cada vez, refrescar solo los datos que han cambiado desde el último refresh.

Beneficios:

• ⚡ Refresh mucho más rápido.
• 💰 Menos recursos consumidos.
• 🌐 Menos carga en el source system.

Requisitos previos

1. La query debe fully fold al source (query folding end-to-end).
2. La query debe incluir una columna DateTime, Date, o DateTimeZone para filtrar.
3. Configurar los settings.

Si tu query no fold, incremental refresh no funciona bien.

Cómo activarlo

1. Crea o abre el dataflow.
2. En el data preview, verifica que tu query devuelve datos con columna temporal.
3. Right-click en la query → Incremental refresh.
4. Configura los settings requeridos.
5. Publica el dataflow.

🎯 Los 4 settings principales

A) Choose a DateTime column to filter by
Columna que usarás para filtrar. Debe ser DateTime, Date, o DateTimeZone.

B) Extract data from the past
Cuánta historia inicial cargar. Valores posibles: x days, x weeks, x months, x quarters, x years. Ejemplo: "1 month" → carga inicial de 1 mes hacia atrás.

C) Bucket size
Tamaño de cada bucket temporal:

• Menor bucket: menos datos por iteración, más iteraciones.
• Mayor bucket: más datos por iteración, menos iteraciones.

Trade-off: buckets pequeños = más granularidad pero más overhead. Buckets grandes = menos overhead pero más datos por iteración.

D) Only extract new data when the maximum value in this column changes
Columna que se usa para detectar cambios. Suele ser la misma que la de filtrado.

Setting opcional: "Only extract data for concluded periods"

Si lo activas, solo extrae data para periodos completos. Ejemplo con bucket = month:

• ✅ Extrae enero, febrero, marzo (completos)
• ❌ NO extrae el mes actual (incompleto)

Útil para evitar datos parciales que aún están cambiando.

Advanced: "Require incremental refresh query to fully fold"

Setting avanzado (recomendado: enabled). Fuerza que la query fully fold. Si no puede foldear, el dataflow falla al guardar.

Beneficio: previene que subas un dataflow que pretende ser incremental pero no lo es realmente.

🎯 Cómo funciona incremental refresh (behind the scenes)

Paso 1: Evaluate changes

• El dataflow lee el max value de la columna DateTime en el source.
• Compara con el max value del último refresh.
• Si cambió → marca el bucket como "changed". Si no cambió → skip.

Paso 2: Get the data

• Para cada bucket cambiado, extrae los datos.
• Procesa múltiples buckets en paralelo.
• Los carga a un staging area.

Paso 3: Replace in destination

• Para cada bucket cambiado: delete + insert en el destino.
• Solo afecta al rango del bucket. Data fuera del rango permanece intacta.

Diferencias Gen1 vs Gen2

Gen2 simplifica mucho vs Gen1.

Troubleshooting: refresh MÁS lento tras activar incremental

Bug conocido documentado: puede pasar que incremental refresh sea más lento que full refresh. Causa: overhead de gestionar muchos buckets pequeños.

Soluciones:

• Aumenta bucket size → menos buckets, menos overhead.
• Considera full refresh si tu scenario no se beneficia.

¿Qué es?

Dataflow Gen2 soporta CI/CD (Continuous Integration/Deployment) y Git integration. Puedes:

• Crear, editar y gestionar dataflows en un repositorio Git conectado al workspace.
• Usar deployment pipelines para mover dataflows entre workspaces (dev → test → prod).
• Refresh y editar settings desde herramientas Fabric.
• Crear Dataflow Gen2 en workspace folders directamente.
• Usar Public APIs (preview) para gestionar dataflows.

Prerequisitos

• Fabric tenant + subscription activa.
• Workspace Fabric-enabled.
• Git integration habilitada en el workspace.

🎯 Save vs Publish (importante)

En Dataflow Gen2 con CI/CD:

• Save reemplaza publish: al guardar, los cambios se publican automáticamente.
• Si quieres descartar cambios: Discard changes al cerrar el editor.

Validación al guardar

Al guardar, el sistema hace "zero row" evaluation:

• Verifica schemas sin devolver filas.
• Si el schema no se determina en 10 minutos → falla.
• Si validation falla → usa la última versión guardada exitosamente para refreshes.

🎯 Just-in-time publishing

Modelo automatizado moderno:

• Cuando guardas → cambios disponibles para el siguiente refresh.
• Sincronizar desde Git o deployment pipelines → guarda el updated dataflow en el workspace.
• El siguiente refresh intenta publicar la última versión guardada.
• Si el publish falla → error visible en refresh history.

Limitaciones y issues conocidos

1. Al borrar el último Dataflow Gen2 con CI/CD → staging items quedan visibles y se pueden borrar manualmente.
2. Al hacer branching a otro workspace → un refresh puede fallar con "staging lakehouse not found". Fix: crear un nuevo Dataflow Gen2 en el workspace, se recrea el staging.
3. Al sincronizar cambios desde Git o deployment pipelines → hay que abrir el dataflow y guardar manualmente para triggerar el publish. O usar la API on-demand Dataflow publish job.
4. Power Automate connector para dataflows NO funciona con esta nueva versión CI/CD.

Combinar Dataflows con Pipelines

Los Dataflows son excelentes para transformación, pero cuando necesitas orquestación multi-paso, los combinas con Pipelines.

Actividades típicas de un pipeline

Un pipeline puede orquestar:

• Copy Data (movimiento raw)
• Dataflow Gen2 activity (transformación)
• Notebook (Spark)
• Get Metadata
• Execute Script / Stored Procedure
• Conditional / Loop activities

Patterns comunes

Pattern A: Pipeline orquesta un dataflow que hace todo

Pipeline
  └── Dataflow Gen2 (extract + transform + load)

Pattern B: ELT clásico

Pipeline
  ├── Copy Data (raw → bronze lakehouse)
  ├── Dataflow Gen2 (bronze → silver, transformación)
  └── Notebook (silver → gold, agregaciones)

Pattern C: Con schedule y trigger

Trigger (schedule diario 6 AM)
  └── Pipeline
        └── Dataflow Gen2 activity
              └── Send email on failure

Ventaja de scheduling desde pipeline

Puedes tener un pipeline programado que ejecute el dataflow en lugar del schedule interno del dataflow. Ventajas:

• Orquestación con dependencias (dataflow → notebook).
• Retry logic.
• Notifications on failure.
• Passing parameters.

Modelo de facturación

Dataflow Gen2 factura por motor separadamente:

Capabilities y sus costes/beneficios

• Trampa 1: "Dataflow Gen2 soporta RLS" ❌ NO. Es una de las limitaciones oficiales. Para RLS → hazlo en el semantic model o warehouse downstream.
• Trampa 2: "Dataflows Gen2 funcionan sin capacidad Fabric" ❌ Requieren workspace en Fabric capacity (F SKU o Trial). Otra limitación oficial.
• Trampa 3: "Dataflow Gen2 = Dataflow Gen1" ❌ Muy distintos. Gen2 tiene destinos múltiples, Fast Copy, CI/CD, first-class incremental refresh, y más.
• Trampa 4: "Todos los conectores soportan Fast Copy" ❌ Solo conectores compatibles (ADLS, S3, Azure SQL, etc.). Ver docs oficiales.
• Trampa 5: "Puedo combinar Fast Copy con transformaciones complejas en la misma query" ❌ Rompe Fast Copy. Divide en dos queries: una Fast Copy pura, otra con transformaciones sobre staged data.
• Trampa 6: "Query folding es automático y siempre pasa" ❌ Depende del conector y de las transformaciones. Muchas cosas rompen folding (custom columns, Table.AddIndex, etc.). Vigila los indicadores.
• Trampa 7: "Incremental refresh funciona con cualquier query" ❌ Requiere fully folding query + columna DateTime/Date. Si no fold, no funciona bien.
• Trampa 8: "Incremental refresh borra la data histórica fuera de rango" ❌ En Gen2 NO borra data fuera del rango del bucket. Solo hace replace de los buckets que cambian.
• Trampa 9: "Puedo tener 500 buckets en un dataflow" ❌ Límites: 50 buckets por query, 150 por dataflow.
• Trampa 10: "Save y Publish son operaciones distintas en Gen2 con CI/CD" ❌ En Gen2 con CI/CD, Save reemplaza Publish (just-in-time publishing).
• Trampa 11: "Un Dataflow debe tener destination" ❌ Es opcional. Puedes tener dataflow sin destination y usarlo como source discoverable.
• Trampa 12: "Staging siempre mejora performance" ❌ Añade costes de storage + write. Si la query ya fold end-to-end, staging es contraproducente.
• Trampa 13: "Dataflow Gen2 y Datamart son lo mismo" ❌ Son items distintos en Fabric. Datamart es más para modelado self-service. Dataflow es para ETL.
• Trampa 14: "Modern Evaluator hay que activarlo manualmente" ❌ Se activa automáticamente cuando aplica.
• Trampa 15: "Los dataflows reemplazan al Data Warehouse" ❌ Es una limitación oficial explícita. Los Dataflows son ETL, no son warehouse.

Dataflow Gen2 vs Notebook vs Pipeline

Dataflow Gen1 vs Gen2

Capabilities de performance

Motores de facturación

Incremental refresh limits

CI/CD Save vs Publish

• Módulo Learn: use-dataflow-gen-2-fabric
• Dataflow Gen2 overview: dataflows-overview
• Best practices performance: dataflow-gen2-performance-best-practices
• Fast Copy: dataflows-gen2-fast-copy
• CI/CD y Git integration: dataflow-gen2-cicd-and-git-integration
• Incremental refresh: dataflow-gen2-incremental-refresh
• Cost and performance benchmarks: dataflow-gen2-cost-performance-benchmarks
• Data destinations and managed settings: dataflow-gen2-data-destinations-and-managed-settings
• Data in Dataflow Gen2 staging items: data-in-staging-items
• Modern Evaluator: dataflow-gen2-modern-evaluator
• Partitioned Compute: dataflow-gen2-partitioned-compute
• Query folding basics: query-folding-basics