Transformer des données avec les Notebooks Spark de Fabric

Power Query suffit pour nettoyer la plupart des jeux de données, mais il atteint ses limites quand les volumes deviennent massifs ou que les transformations exigent une vraie logique de programmation : boucles, fonctions réutilisables, calculs distribués sur des millions de lignes. C’est là qu’interviennent les notebooks de Microsoft Fabric, qui mettent la puissance d’Apache Spark à portée de quelques lignes de Python. Ce tutoriel apprend à lire, transformer et réécrire des données dans un Lakehouse à l’aide d’un notebook Spark, en expliquant chaque concept au passage.

Ce tutoriel s’inscrit dans une série sur Power BI et Microsoft Fabric ; le guide de référence Power BI et Microsoft Fabric en donne la vue d’ensemble. Il suppose un Lakehouse déjà créé contenant au moins une table à transformer.

Prérequis

• Un accès à Microsoft Fabric (capacité F ou essai) et un Lakehouse alimenté.
• Des notions de base en Python ; la connaissance de Spark n’est pas requise, on l’introduit progressivement.
• Niveau : intermédiaire à avancé.
• Temps estimé : 70 à 90 minutes.

Étape 1 — Créer un notebook et y attacher un Lakehouse

Un notebook Fabric est un document interactif mêlant code et texte, où chaque bloc de code (une « cellule ») s’exécute indépendamment. Avant d’écrire la moindre ligne, il faut lui indiquer sur quelles données travailler en lui attachant un Lakehouse. Depuis l’espace de travail, cliquez sur Nouvel élément > Notebook. À gauche s’ouvre un explorateur Lakehouse : cliquez sur Ajouter et sélectionnez votre Lakehouse.

Ce rattachement est essentiel : il fait du Lakehouse la source et la destination par défaut du notebook, ce qui permet d’écrire des chemins courts et lisibles vers les données. Une fois le Lakehouse attaché, ses zones Tables et Files apparaissent dans le volet de gauche, et vous pouvez parcourir vos tables d’un clic. Le langage par défaut des cellules est PySpark, c’est-à-dire Python piloté par le moteur Spark — exactement ce qu’il nous faut.

Étape 2 — Lire des données dans un DataFrame

La structure centrale de Spark est le DataFrame : une table distribuée, manipulable par du code, qui peut s’étendre sur des volumes qu’aucun tableur ne supporterait. La première opération consiste donc à charger une table du Lakehouse dans un DataFrame. Comme le Lakehouse est attaché, la lecture est directe :

df = spark.read.table("ventes")
display(df)

spark.read.table charge la table Delta nommée ventes de la zone Tables. La fonction display, propre aux notebooks Fabric, affiche un aperçu interactif avec tri et mini-graphiques, bien plus pratique qu’un simple affichage texte. Vous devez voir les premières lignes de votre table : c’est la confirmation que le notebook lit correctement le Lakehouse. Si une erreur signale que la table est introuvable, vérifiez qu’elle existe bien dans la zone Tables et que le bon Lakehouse est attaché.

Étape 3 — Inspecter la structure des données

Avant de transformer, il faut comprendre ce qu’on manipule : les colonnes, leurs types, les valeurs aberrantes. Quelques commandes d’inspection font gagner un temps précieux et évitent des erreurs en aval. On examine d’abord le schéma, puis quelques statistiques :

df.printSchema()
print("Nombre de lignes :", df.count())
display(df.describe())

printSchema liste chaque colonne avec son type, ce qui révèle immédiatement un montant resté en texte ou une date mal typée. count donne le volume, utile pour mesurer l’effet des filtres ultérieurs. describe calcule des statistiques de base (min, max, moyenne) qui font ressortir les anomalies, comme un montant négatif inattendu. Cette inspection systématique est le réflexe professionnel qui précède toute transformation : on ne transforme bien que ce qu’on a d’abord compris.

Étape 4 — Transformer le DataFrame

Le cœur du travail consiste à filtrer, calculer et agréger. Spark propose une API claire où chaque opération renvoie un nouveau DataFrame, ce qui permet d’enchaîner les transformations de façon lisible. Construisons une agrégation des ventes par région, en ne gardant que les montants positifs :

from pyspark.sql.functions import col, sum as _sum

agg = (
    df.filter(col("Montant") > 0)
      .groupBy("Region")
      .agg(_sum("Montant").alias("TotalVentes"))
      .orderBy(col("TotalVentes").desc())
)
display(agg)

On importe d’abord les fonctions nécessaires. Puis on enchaîne : filter ne garde que les montants positifs, groupBy regroupe par région, agg additionne les montants en nommant le résultat TotalVentes, et orderBy trie par ordre décroissant. Le résultat est un DataFrame compact, prêt à être enregistré. Cette écriture chaînée, lue de haut en bas, se relit comme une phrase : c’est la marque d’un code Spark propre. Notez que rien n’est encore calculé réellement à ce stade — Spark est « paresseux » et n’exécute le travail qu’au moment de l’affichage ou de l’écriture.

Étape 5 — Mélanger Python et SQL

Tout le monde dans une équipe ne maîtrise pas Python, mais beaucoup connaissent le SQL. Les notebooks Fabric permettent de basculer une cellule en SQL grâce à une instruction magique, ce qui rend le code accessible et parfois plus naturel pour certaines requêtes. On préfixe simplement la cellule :

%%sql
SELECT Region, SUM(Montant) AS TotalVentes
FROM ventes
WHERE Montant > 0
GROUP BY Region
ORDER BY TotalVentes DESC

La directive %%sql indique que toute la cellule est du SQL exécuté par Spark sur les tables du Lakehouse. Le résultat est identique à notre agrégation Python, mais exprimé dans un langage familier à davantage de personnes. On peut alterner librement : préparer en Python, vérifier en SQL, ou l’inverse. Pour passer un résultat d’un langage à l’autre, on crée une vue temporaire avec df.createOrReplaceTempView("ma_vue"), ensuite interrogeable en SQL. Cette souplesse fait des notebooks un terrain de rencontre entre profils techniques variés.

Étape 6 — Écrire le résultat comme table Delta

Une transformation n’a de valeur que si son résultat est persisté pour être réutilisé par les rapports. On enregistre donc le DataFrame agrégé comme une nouvelle table Delta dans le Lakehouse — typiquement une table de couche or, prête pour l’analyse :

agg.write.mode("overwrite") \
   .format("delta") \
   .saveAsTable("ventes_par_region")

saveAsTable écrit la table ventes_par_region dans la zone Tables, au format Delta. Le mode overwrite remplace toute version précédente ; append ajouterait à l’existant, utile pour accumuler des chargements successifs. Dès l’écriture terminée, la table apparaît dans l’explorateur du Lakehouse et devient immédiatement interrogeable en SQL comme par Power BI. C’est le point où la transformation rejoint la chaîne de valeur : une table propre, structurée, exploitable par tous les outils de Fabric sans recopie.

Étape 7 — Optimiser la table pour la lecture

Au fil des écritures, une table Delta peut se fragmenter en de nombreux petits fichiers, ce qui ralentit les lectures — un enjeu direct pour la performance des rapports. Delta fournit une commande de maintenance qui regroupe ces fichiers et réorganise les données pour des lectures plus rapides :

%%sql
OPTIMIZE ventes_par_region

La commande OPTIMIZE compacte les petits fichiers en fichiers plus volumineux et mieux ordonnés. Fabric propose par ailleurs une optimisation d’écriture appelée V-Order, qui réorganise les fichiers Parquet pour accélérer les lectures du moteur d’analyse — un atout pour les rapports en mode DirectLake. Attention toutefois : dans les espaces de travail créés à partir d’avril 2025 (profil orienté écriture), V-Order n’est plus activé par défaut et doit être activé explicitement sur les tables très lues, alors qu’il l’était d’office dans les espaces plus anciens. Ces rapports sont, traités dans le tutoriel connecter Power BI au Lakehouse en mode DirectLake. Lancer périodiquement OPTIMIZE sur les tables très sollicitées est une bonne habitude d’entretien, surtout après de nombreuses insertions.

Étape 8 — Tirer parti des utilitaires de notebook

Au-delà des transformations, Fabric fournit une boîte à outils intégrée pour les tâches courantes : parcourir des fichiers, gérer des secrets, enchaîner des notebooks. Elle s’appelle notebookutils (l’ancien nom, mssparkutils, reste accepté mais il est recommandé d’adopter le nouveau). Quelques exemples parlants :

notebookutils.fs.ls("Files/brut")
notebookutils.notebook.run("Transformation_Argent", 120)

La première ligne liste le contenu d’un dossier de la zone Files, pratique pour vérifier qu’un fichier attendu est bien arrivé. La seconde exécute un autre notebook nommé Transformation_Argent avec un délai d’attente de 120 secondes, ce qui permet de chaîner des traitements et de construire des flux modulaires. Ces utilitaires évitent de réinventer la roue pour les opérations système et facilitent l’organisation de traitements complexes en plusieurs notebooks spécialisés, chacun responsable d’une étape.

Étape 9 — Automatiser l’exécution du notebook

Un notebook exécuté à la main ne tient pas dans la durée ; il faut l’automatiser. Deux voies existent. La plus simple : planifier directement le notebook via son option de planification, comme on planifie un pipeline. La plus robuste : intégrer le notebook dans un pipeline de données via une activité Notebook, ce qui permet de l’enchaîner après une ingestion et de gérer les cas d’échec.

Cette seconde approche est généralement préférable en production, car elle place la transformation dans un flux orchestré et surveillé, décrit dans le tutoriel pipeline d’ingestion avec Fabric Data Factory. Avant d’automatiser, exécutez le notebook entièrement une dernière fois, cellule par cellule, pour confirmer qu’aucune erreur ne subsiste et que la table de sortie se remplit comme attendu. Un notebook validé de bout en bout, puis intégré à un pipeline planifié, devient une brique de transformation fiable et répétable.

Comprendre comment Spark exécute votre code

Spark déroute souvent les débutants par son comportement « paresseux » : on enchaîne des transformations sans qu’apparemment rien ne se passe, puis tout se déclenche d’un coup au moment d’un affichage ou d’une écriture. Comprendre ce mécanisme évite de mauvaises interprétations et aide à écrire un code performant. Les opérations comme filter, select ou groupBy sont des transformations : elles décrivent un plan sans l’exécuter. Seules les actions — display, count, saveAsTable — déclenchent réellement le calcul.

Cette paresse est un atout : Spark voit l’ensemble du plan avant de l’exécuter, et peut l’optimiser globalement, par exemple en repoussant les filtres au plus tôt pour réduire le volume traité. En pratique, cela signifie qu’il vaut mieux filtrer et sélectionner les colonnes utiles le plus tôt possible dans la chaîne, pour que Spark ait moins de données à brasser. Quand une exécution paraît lente, le notebook Fabric donne accès à l’interface de suivi Spark, qui décompose le travail en étapes et révèle où le temps est passé : un regroupement coûteux, un volume mal réparti entre les partitions. Apprendre à lire ce suivi transforme le débogage à l’aveugle en diagnostic méthodique, et c’est ce qui distingue un usage occasionnel d’une maîtrise réelle de Spark.

Erreurs fréquentes

Tutoriels liés

• Créer un Lakehouse dans Microsoft Fabric — la source et la destination des transformations.
• Pipeline d’ingestion avec Fabric Data Factory — orchestrer l’exécution du notebook.
• Connecter Power BI au Lakehouse en mode DirectLake — exploiter les tables transformées.

Références

• Documentation « Notebooks Microsoft Fabric » et « Charger des données dans un Lakehouse avec un notebook » (Microsoft Learn).
• Guide « Utilitaires de notebook (NotebookUtils) » et migration depuis MSSparkUtils.
• Documentation « Tables Delta dans Apache Spark » et commande OPTIMIZE / V-Order.

Questions fréquentes

Faut-il être développeur pour utiliser les notebooks Fabric ?
Non, mais des notions de Python aident. Pour beaucoup de besoins, on peut même rester en SQL grâce à la cellule magique, ce qui ouvre les notebooks à un public plus large que les seuls programmeurs.

Quand préférer un notebook à Power Query ou un Dataflow ?
Dès que les volumes sont massifs, que la logique est complexe (boucles, fonctions), ou qu’il faut la réutiliser et l’automatiser à grande échelle. Pour des transformations simples et visuelles, Power Query reste plus rapide à mettre en œuvre.

Le notebook consomme-t-il beaucoup de capacité ?
L’exécution d’un cluster Spark consomme des ressources proportionnelles au travail demandé. On maîtrise ce coût en filtrant tôt, en n’écrivant que les tables utiles, et en ne planifiant les exécutions qu’à la fréquence réellement nécessaire.

Mes tables écrites en Spark sont-elles utilisables ailleurs ?
Oui. Comme elles sont au format Delta dans le Lakehouse, elles sont immédiatement interrogeables en SQL et exploitables par Power BI, sans aucune recopie ni conversion.