Guides de décision
1. Introduction aux guides de décision Fabric
Microsoft Fabric propose un large éventail de services et d'outils pour couvrir l'ensemble du cycle de vie des données : ingestion, transformation, stockage, analyse et visualisation. Face a cette richesse fonctionnelle, il est essentiel de savoir choisir le bon outil pour le bon usage.
Ce document synthétise les quatre guides de décision officiels de Microsoft et les présente sous une forme pédagogique, structurée autour de quatre questions fondamentales :
- Comment intégrer les données ? Quelle stratégie globale d'intégration choisir (déplacement, orchestration, transformation)
- Comment déplacer les données ? Quel outil de déplacement privilégier (mise en miroir, travail de copie, activité de copie, flux d'événements)
- Où stocker les données ? Quel magasin de données utiliser (lakehouse, warehouse, eventhouse, base de données SQL, Cosmos DB)
- Lakehouse ou warehouse ? Comment trancher entre ces deux options d'entreposage
À retenir
Ces guides ne sont pas exclusifs : dans une architecture Fabric réelle, vous combinerez généralement plusieurs de ces outils. L'objectif est de comprendre le cas d'usage principal de chacun pour faire un choix éclaire.
2. Choisir une stratégie d'intégration des données
Le premier niveau de décision consiste à identifier votre objectif principal. Microsoft Fabric organise l'intégration des données autour de trois piliers : le déplacement, l'orchestration et la transformation. Chaque pilier dispose de ses propres outils.
2.1. Les quatre questions clés
Pour choisir la bonne stratégie, posez-vous ces questions :
2.2. Les stratégies de déplacement des données
Le déplacement des données consiste à amener les données depuis vos sources vers Fabric. Quatre outils sont disponibles :
Table 9
| Cas d'usage | Réplication continue | Ingestion + réplication | Ingestion de données | Streaming temps réel |
| Sources | 6+ connecteurs | 50+ connecteurs | 50+ connecteurs | 25+ sources |
| Destinations | OneLake (lecture seule) | 40+ connecteurs | 40+ connecteurs | 4+ destinations |
| Type de données | Quasi temps réel | Batch / incrémentiel / CDC | Batch / bulk | Streaming continu |
| Niveau de code | Aucun code | Aucun / low-code | Aucun / low-code | Aucun / low-code |
| Transformations | Aucune | Faibles | Faibles | Moyennes (Stream Analytics) |
| Persona cible | Admin BDD, analyste | Analyste, integrateur | Integrateur, ingénieur | Ingénieur, analyste |
Source : Microsoft Learn - Guide d'intégration
2.3. Les stratégies d'orchestration
L'orchestration permet de coordonner et planifier l'exécution de plusieurs taches de données. Deux options s'offrent à vous :
Table 10
| Approche | Low-code, visuelle (glisser-deposer) | Code-first (Python, DAGs) |
| Connecteurs | Tous les connecteurs Fabric | 100+ connecteurs Airflow |
| Niveau de code | Aucun / low-code | Code-first (Python) |
| Persona cible | Analyste, integrateur, ingénieur | Utilisateurs Apache Airflow |
| Cas d'usage | Regroupement logique d'activites multiples | Workflows complexes orientes code |
2.4. Les stratégies de transformation
La transformation consiste à nettoyer, enrichir et préparer les données pour l'analyse. Trois outils sont disponibles selon votre profil :
Table 11
| Approche | Code-first | Sans code (Power Query) | Sans code / SQL |
| Sources | 100+ bibliotheques Spark | 170+ connecteurs + SDK | 25+ sources |
| Destinations | 100+ bibliotheques Spark | 7+ connecteurs | 4+ destinations |
| Complexite | Elevee (jointures, ML, etc.) | Elevee (400+ transformations) | Moyenne |
| Niveau de code | Code-first (Python, Scala, R, SQL) | Aucun / low-code | Aucun / low-code |
| Persona cible | Data scientist, développeur | Ingénieur, analyste | Ingénieur, analyste |
Source : Microsoft Learn - Guide d'intégration
3. Choisir une stratégie de déplacement des données
Ce chapitre approfondit le choix du bon outil de déplacement en comparant en détail les quatre mécanismes disponibles dans Fabric.
3.1. Arbre de décision simplifié
Pour choisir rapidement, suivez ce raisonnement :
3.2. Comparaison détaillée des capacités
Le tableau ci-dessous détaillé les capacités fonctionnelles de chaque outil de déplacement :
3.3. Concepts clés par outil
- Mise en miroir (Mirroring)
- Solution simple et économique pour répliquer des données dans Fabric.
- Offre une synchronisation en quasi temps réel sans configuration de pipeline.
- Données écrites en lecture seule dans OneLake au format Delta.
- Idéale pour rendre les bases de données accessibles à l'analytique sans impacter les systèmes sources.
- Travail de copie (Copy Job)
- Comble le vide entre la mise en miroir et l'activité de copie.
- Offre une interface assistée sans code.
- Propose la copie incrémentielle native basée sur des filigranes.
- Détecte automatiquement les tables compatibles CDC (Change Data Capture)
- Prend en charge la sélection multi-tables, les comportements upsert et la planification personnalisée sans construction de pipeline.
- Activité de copie (Copy Activity)
- Intégrée aux pipelines, offre le plus haut niveau de personnalisation.
- Permet des requêtes SQL personnalisées à la source.
- Orchestration avec d'autres activités (procédures stockées, appels API, notifications).
- Gestion avancée des erreurs.
- Solution privilégiée pour les architectures médaillon complexes et les volumes à l'échelle du petaoctet.
- Flux d'événements (Eventstreams)
- Conçus pour l'ingestion et le traitement de données en streaming temps réel.
- Permettent d'appliquer des transformations légères (analyse de flux SQL).
- Routent les événements vers plusieurs destinations (eventhouse, lakehouse, activateur).
- Créent des tableaux de bord mis à jour en quelques secondes.
- Adaptés aux scénarios IoT, monitoring et alerting.
Bonne pratique
Dans de nombreux projets, vous combinerez plusieurs de ces outils. Par exemple : la mise en miroir pour les bases opérationnelles, le travail de copie pour les sources externes, et les flux d'événements pour le monitoring temps réel.
4. Choisir un magasin de données
Une fois les données ingérées dans Fabric, il faut choisir ou les stocker. Fabric propose cinq types de magasins de données, chacun optimise pour des cas d'usage spécifiques. Tous stockent leurs données dans OneLake au format ouvert.
4.1. Les cinq magasins de données Fabric
Table 25
| Lakehouse | Big data, ML, données non/semi-structurées, ingénierie des données | Ingénieur données, data scientist | PySpark, Delta Lake, notebooks | Spark (Scala, PySpark, SQL, R) |
| Entrepôt de données (Warehouse) | BI SQL, OLAP, entreposage d'entreprise, transactions multi-tables | Développeur warehouse, architecte | Concepts d'entreposage, schema en etoile | T-SQL |
| Eventhouse | Données de streaming, analytique interactive, series temporelles, haute granularité | Développeur, data scientist, ingénieur | KQL, SQL | KQL, T-SQL |
| Base de données SQL | Base OLTP, transactions ACID, applications opérationnelles | Développeur, admin BDD | Administration BDD, Azure SQL | T-SQL |
| Cosmos DB dans Fabric | IA, NoSQL, recherche vectorielle | Développeur IA, développeur applicatif | NoSQL, API REST | JavaScript, Python, C#, Java |
Source : Microsoft Learn - Guide magasin de données
4.2. Arbre de décision simplifié
À retenir
- Tous les magasins de données Fabric stockent leurs données dans OneLake au format ouvert (Delta).
- = les données d'un lakehouse peuvent être interrogées depuis un entrepôt via des requêtes inter-bases de données, et vice versa.
- Le choix du magasin n'est donc pas un choix d'isolation mais de moteur de traitement optimal.
5. Lakehouse ou entrepôt de données ?
C'est probablement la question la plus fréquente dans un projet Fabric. Ces deux magasins de données couvrent des cas d'usage proches mais avec des approches différentes. Cette section vous aide à trancher.
5.1. Les trois critères de décision
Microsoft propose trois critères simples pour choisir :
- Comment souhaitez-vous développer ?
Si vous travaillez principalement avec Spark (PySpark, Scala, R) : choisissez le lakehouse.
Si vous travaillez principalement avec T-SQL : choisissez l'entrepôt.
- Avez-vous besoin de transactions multi-tables ?
Non : le lakehouse convient.
Oui : choisissez l'entrepôt (support transactionnel complet T-SQL).
- Quel type de données analysez-vous ?
Données structurées et non structurées (fichiers, images, JSON) : choisissez le lakehouse.
Données structurées uniquement : choisissez l'entrepôt.
Vous ne savez pas encore : commencez par le lakehouse (plus flexible).
5.2. Comparaison fonctionnelle détaillée
Table 26
| Fonctionnalite principale | Entreposage complet avec transactions T-SQL (lecture + écriture) | Point de terminaison en lecture seule pour interroger les tables Delta |
| Profil de développeur | Développeur SQL, citoyen-développeur | Ingénieur données, développeur SQL |
| Chargement des données | SQL, pipelines, dataflows | Spark, pipelines, dataflows, raccourcis |
| Prise en charge Delta | Lecture et écriture | Lecture seule |
| Support T-SQL | Complet : DQL + DML + DDL, transactions complètes | DQL complet, pas de DML, DDL limitée (vues, fonctions table) |
| Couche de stockage | Format ouvert Delta dans OneLake | Format ouvert Delta dans OneLake |
| Cas d'usage recommande | Entrepôt d'entreprise, BI SQL, analyses structurées avec tables/vues/procedures | Exploration de tables Delta, zone de préparation (staging), architecture médaillon |
Source : Microsoft Learn - Lakehouse vs Warehouse
5.3. Points forts de l'entrepôt de données
- Support transactionnel complet multi-tables (ACID) en T-SQL
- Chargement de données à grande échelle avec COPY INTO
- Requêtes inter-bases de données via des noms en trois parties
- Compatible avec les outils SQL Server classiques (SSMS, Azure Data Studio)
- Création de vues, procédures stockées, fonctions et schémas
- Idéal pour les équipes majoritairement SQL
5.4. Points forts du lakehouse
- Gestion native des données structurées et non structurées
- Moteur Spark pour les traitements distribués à grande échelle
- Support multi-langages : PySpark, Scala, Spark SQL, R
- Architecture médaillon (bronze / argent / or) naturelle
- Découverte et enregistrement automatiques des tables
- Point de terminaison d'analytique SQL généré automatiquement pour les consommateurs T-SQL
- Idéal pour l'ingénierie des données et le machine learning
Bonne pratique
- Dans la pratique, beaucoup d'organisations utilisent les deux.
- Le lakehouse sert de zone d'atterrissage et de préparation (couches bronze et argent), tandis que l'entrepôt expose les données modélisées (couche or) aux consommateurs BI.
- Les deux sont accessibles en lecture croisée grâce au format Delta partagé dans OneLake.
6. Scénarios de décision
Cette section présente des cas concrets pour illustrer le processus de décision. Pour chaque scénario, identifiez le besoin principal, le profil technique et la solution recommandée.
Scénario 1 : réplication d'une base opérationnelle pour le reporting
- Contexte : une administratrice de bases de données doit rendre des bases SQL Server accessibles à l'analytique en quasi temps réel, sans impacter les systèmes de production. Elle ne souhaite pas créer de pipelines ETL complexes.
- Solution recommandée : mise en miroir. La réplication est automatique, sans configuration de pipeline, gratuite, et les données sont disponibles en lecture dans OneLake sous forme de tables Delta.
Scénario 2 : consolidation incrémentielle multi-sources
- Contexte : un analyste doit consolider des données de ventes provenant de plusieurs bases régionales avec suivi CDC. Il a besoin d'une charge initiale complète puis de mises a jour incrémentielles automatiques, sans code.
- Solution recommandée : travail de copie. Il offre la sélection multi-tables, la détection automatique CDC, la copie incrémentielle native et une interface assistée sans construction de pipeline.
Scénario 3 : migration de données à grande échelle avec architecture médaillon
- Contexte : une ingénieure données doit migrer des volumes massifs (de Go à Po) depuis Oracle vers Fabric avec une architecture médaillon (bronze, argent, or). Elle a besoin de planification et d'orchestration.
- Solution recommandée : activité de copie dans les pipelines. Elle offre la scalabilité nécessaire, l'orchestration des couches médaillon et le support de plus de 50 connecteurs.
Scénario 4 : monitoring temps réel et alerting
- Contexte : un chef de produit doit surveiller des métriques opérationnelles en temps réel (volumes d'appels, temps d'attente) et déclencher des alertes automatiques en cas de dépassement de seuils SLA.
- Solution recommandée : flux d'événements (Eventstreams). Ingestion streaming, transformations légères, routage vers l'eventhouse et l'activateur de données pour les alertes automatiques.
Scénario 5 : entrepôt de données pour la BI
- Contexte : une équipe principalement SQL doit créer un entrepôt de données central pour alimenter des tableaux de bord Power BI. Les membres de l'équipe maitrisent T-SQL et les outils SQL Server classiques.
- Solution recommandée : entrepôt de données Fabric. Support T-SQL complet, requêtes inter-bases, intégration native avec Power BI via Direct Lake, et compatibilité avec les outils existants (SSMS, Azure Data Studio).
Scénario 6 : plateforme de data science et d'exploration
- Contexte : une data scientist doit travailler sur des jeux de données volumineux en formats variés (CSV, JSON, Parquet), effectuer des analyses statistiques complexes et développer des modèles ML avec Python et Scala.
- Solution recommandée : lakehouse + notebooks Spark. Environnement interactif multi-langages, calcul distribue, support de centaines de bibliothèques, et combinaison code / visualisations / documentation dans les notebooks.
Scénario 7 : préparation de données sans code
- Contexte : une analyste métier doit intégrer et nettoyer des données provenant de multiples sources (bases de données, API, fichiers) en appliquant des règles métier complexes. Elle maitrise Power Query grâce a son expérience Excel et Power BI.
- Solution recommandée : Dataflow Gen2. Interface Power Query familière avec 170+ connecteurs et 400+ fonctions de transformation, sans écrire de code.
Source : Microsoft Learn - Guide d'intégration
7. Fiche récapitulative
Ce tableau de synthèse résume les principaux outils et leurs cas d'usage pour faciliter vos décisions quotidiennes :
Table 27
| Elément | Rôles | Besoins |
| Mise en miroir | Réplication simple et gratuite de bases de données vers OneLake, sans transformation | Vous avez besoin de transformations, de planification personnalisée ou de destinations multiples |
| Travail de copie | Copie incrémentielle/CDC, multi-tables, sans pipeline, avec planification | Vous avez besoin d'orchestration complexe ou de requêtes personnalisées à la source |
| Activité de copie (pipeline) | Ingestion orchestrée, requêtes personnalisées, architecture médaillon, gros volumes | Le scénario est simple (réplication directe) : la mise en miroir ou le travail de copie suffisent |
| Flux d'événements | Streaming temps réel, ingestion IoT, alerting, tableaux de bord temps réel | Le traitement par lots suffit a votre besoin |
| Pipeline | Orchestration low-code de flux complexes avec plusieurs etapes | Vous avez besoin d'orchestration code-first Python (utilisez Apache Airflow) |
| Apache Airflow | Orchestration Python code-first, DAGs complexes, intégration ML | Votre équipe n'a pas de compétences Python |
| Notebooks Spark | Transformations complexes code-first, ML, exploration de données | Vos utilisateurs préfèrent le sans code (utilisez Dataflow Gen2) |
| Dataflow Gen2 | Transformations sans code (Power Query), 170+ connecteurs, profilage | Vous avez besoin de traitements distribués à grande échelle (utilisez les notebooks) |
| Lakehouse | Big data, ML, données mixtes (structurées + non structurées), architecture médaillon | Vous n'avez que des données structurées et une équipe SQL |
| Entrepôt de données | BI SQL, transactions multi-tables, schema en etoile, reporting d'entreprise | Vous traitez des données non structurées ou faites du ML |
| Eventhouse | Analytique temps réel, series temporelles, données haute granularité | Vos données sont statiques ou changent rarement |
| Base de données SQL | Applications OLTP, transactions ACID, accès concurrent élevé | Vous construisez un entrepôt analytique (utilisez le warehouse) |
Sources
- Guide de décision : choisir une stratégie d'intégration des données (Microsoft Learn)
- Guide de décision : choisir une stratégie de déplacement des données (Microsoft Learn)
- Guide de choix du Fabric : choisir un stockage de données - Microsoft Fabric
- Guide de décision Microsoft Fabric : Choisir entre l’entrepôt et Lakehouse - Microsoft Fabric
- Guide de décision de Fabric : activité de copie, flux de données ou Spark - Microsoft Fabric