Dataflow Gen2 vs Fabric Notebook :
Le framework de décision que personne n'a écrit

C'est l'une des questions les plus fréquentes que je vois sur les forums de la communauté Fabric :

« Est-ce que je dois construire cette transformation dans un Dataflow Gen2 ou dans un Fabric Notebook ? »

La documentation officielle dit : « Utilisez les Dataflows pour les transformations low-code, utilisez les Notebooks pour la logique complexe. » Ce n'est pas un framework de décision. C'est un slogan.

En pratique, le mauvais choix vous coûte des CUs, du temps de debug et de la maintenabilité. Voici un framework qui répond vraiment à la question, construit à partir de l'expérience sur de vrais workloads.

01.Les 5 dimensions qui comptent vraiment

Avant l'arbre de décision : voici les facteurs qui changent réellement la réponse.

02.L'arbre de décision

03.La réalité des coûts CU

C'est là que la décision devient contre-intuitive. Voici les chiffres réels.

Facturation Dataflow Gen2

Dataflow Gen2 facture par query de sortie, à :

• 12 CU/seconde pour les 10 premières minutes de chaque query
• 1,5 CU/seconde au-delà de 10 minutes (8× moins cher)

Plus en option : High Scale Compute (Staging) : 6 CU/s fixe quand activé | Fast Copy : 1,5 CU/s quand applicable.

Facturation Spark (Notebook / Spark Job Definition)

Les jobs Spark (exécutés via Notebook ou Spark Job Definition) facturent par session Spark (pas par query) :

• Starter pool : démarre à 4 CU/s (8 vCores), monte à 8 CU/s minimum après scale-up automatique ; Custom Pool Small : 2 CU/s
• La session est partagée entre toutes les cellules

Comparaison directe

04.4 scénarios concrets

Scénario A : Charger un fichier Excel SharePoint dans 15 tables Lakehouse

Si vous utilisez un Notebook ici, vous ouvrez le fichier Excel 15 fois (15 appels HTTP vers SharePoint), vous le parsez 15 fois, et vous payez 15 lectures Spark séparées d'un format non-natif.

Scénario B : Construire une table de faits Gold avec SCD Type 2

spark.sql("""
  MERGE INTO gold.dim_customer AS target
  USING (SELECT * FROM silver.stg_customer) AS source
  ON target.customer_id = source.customer_id AND target.is_current = true
  WHEN MATCHED AND (target.email != source.email OR target.city != source.city) THEN
    UPDATE SET target.is_current = false, target.end_date = current_date()
  WHEN NOT MATCHED THEN
    INSERT (customer_id, email, city, start_date, end_date, is_current)
    VALUES (source.customer_id, source.email, source.city, current_date(), null, true)
""")

Scénario C : Chargement incrémental quotidien, 200k lignes depuis SQL Server

// Query helper watermark
LastLoadDate = List.Max(
  Table.Column(Lakehouse.Contents(...){[Name="fact_sales"]}[Data], "load_date"),
  #date(2020, 1, 1)
)

// Query principale : filtrer la source avant chargement
FilteredRows = Table.SelectRows(Source, each [created_at] > LastLoadDate)

Scénario D : Table de faits de 200M lignes, fonctions fenêtre complexes

from pyspark.sql.window import Window
from pyspark.sql.functions import lag, col

w = Window.partitionBy("customer_id").orderBy("order_date")

df = df.withColumn("prev_order_date", lag("order_date", 1).over(w)) \
       .withColumn("days_since_last_order",
                   (col("order_date").cast("long") - col("prev_order_date").cast("long")) / 86400)

05.Quand utiliser les deux ensemble

Le pattern le plus puissant est un pipeline qui combine les deux outils :

[Dataflow Gen2]                    [Notebook]
Charger les données brutes    →    Appliquer la logique métier
(Excel, SharePoint, APIs)          (SCD2, agrégations, features ML)
Écrire en Bronze/Silver        →    Écrire en Gold Lakehouse

Dataflow gère l'extraction et la normalisation légère (son point fort). Le Notebook gère la logique de transformation (son point fort). Aucun outil n'est forcé à faire ce pour quoi il est mauvais.

06.Carte de référence rapide

Jean-Marie Sadio

Data Engineer · Microsoft Fabric Community · Tamanchu