Guide

Concevoir la couche d'ingestion de données initiale dans une architecture en médaillon pour capturer les données brutes sources.

→Ingérer les données dans la couche Bronze avec une transformation minimale et un schéma permissif.

Pourquoi: Préserve la fidélité des données d'origine, y compris les enregistrements malformés, pour le retraitement, l'audit et la lignée des données.

Implémenter des environnements isolés et un processus de promotion pour les artefacts Fabric.

→Utiliser les Fabric Deployment Pipelines avec des étapes d'espace de travail distinctes Development, Test et Production.

Pourquoi: Fournit un mécanisme structuré et sûr pour tester les changements et promouvoir les artefacts sans impacter les charges de travail de production.

Appliquer le contrôle de source et les flux de travail d'approbation pour les modifications apportées aux éléments Fabric de production.

→Intégrer l'espace de travail Fabric avec Azure DevOps Git. Utiliser des politiques de branche pour appliquer les révisions de pull request.

Pourquoi: Permet le contrôle de version, le suivi des modifications et les révisions par les pairs obligatoires, alignant l'ingénierie des données sur les meilleures pratiques DevOps.

Automatiser les changements de chaîne de connexion spécifiques à l'environnement pendant les déploiements de pipeline.

→Configurer des règles de déploiement dans le pipeline de déploiement pour paramétrer les connexions de source de données pour chaque étape.

Pourquoi: Élimine la configuration manuelle après le déploiement, réduisant les erreurs et garantissant que chaque environnement se connecte à la bonne source de données.

Organiser les espaces de travail pour plusieurs unités commerciales nécessitant à la fois une isolation et une gouvernance partagée.

→Créer des espaces de travail séparés par unité commerciale et les regrouper sous des Fabric Domains.

Pourquoi: Les espaces de travail offrent une isolation du contenu et de la sécurité, tandis que les Domains permettent une gouvernance et une découverte centralisées à travers les espaces de travail liés.

Améliorer la découverte des données et signaler la qualité des ensembles de données aux utilisateurs professionnels.

→Appliquer des descriptions et des étiquettes aux tables lakehouse et utiliser des étiquettes Endorsement (Promoted, Certified).

Pourquoi: Les niveaux d'Endorsement renforcent la confiance des utilisateurs et les guident vers des ensembles de données de haute qualité et organisés pour le reporting et l'analyse.

Assurer une classification et une protection cohérentes des données sur tous les éléments Fabric.

→Intégrer avec Microsoft Purview Information Protection et activer l'héritage en aval pour les étiquettes de sensibilité.

Pourquoi: Automatise l'application des étiquettes de sensibilité des sources de données aux artefacts en aval comme les modèles sémantiques et les rapports, appliquant ainsi les politiques de sécurité.

Déterminer le facteur principal pour dimensionner une capacité Fabric.

→Analyser l'exécution de requêtes concurrentes et les exigences de calcul de la charge de travail.

Pourquoi: La capacité Fabric est consommée par les opérations de calcul (Capacity Units), et non par le volume de stockage de données. La concurrence et la complexité des tâches sont les principaux moteurs.

Fournir un accès sécurisé et de qualité production depuis un Fabric shortcut vers un compte ADLS Gen2 externe.

→Utiliser un Service Principal avec l'authentification Azure AD, en lui accordant des rôles RBAC à moindre privilège sur le compte de stockage.

Pourquoi: Le Service Principal est la méthode la plus sécurisée et la plus auditable, évitant les risques liés aux clés de compte partagées ou aux jetons SAS.

Créer une réplique en quasi temps réel et en lecture seule d'une base de données Azure SQL dans Fabric sans impacter la source.

→Utiliser Fabric Mirroring pour Azure SQL Database.

Pourquoi: Mirroring offre une réplication continue et à faible latence des données dans OneLake sous forme de tables Delta, idéale pour l'analyse en temps réel sans développement ETL.

Partager un ensemble de données avec un autre espace de travail ou accéder à des données externes sans créer de copie.

→Créer un Shortcut pointant vers la table lakehouse source ou l'emplacement des données externes.

Pourquoi: Les Shortcuts agissent comme des liens symboliques, offrant une vue unifiée des données dans OneLake tout en évitant la duplication des données, les coûts de stockage et les problèmes de synchronisation.

Combiner des données de streaming à haute vélocité avec des données batch historiques pour une analyse unifiée.

→Utiliser Eventstream pour l'ingestion en temps réel et un Lakehouse avec des tables Delta Lake pour le stockage unifié.

Pourquoi: Eventstream gère le chemin de streaming, tandis que les propriétés ACID de Delta Lake lui permettent de servir de cible pour les ajouts en streaming et les mises à jour batch.

Permettre à la fois l'analyse basée sur T-SQL et la science des données basée sur Python sur les mêmes données lakehouse.

→Utiliser le point de terminaison d'analyse SQL généré automatiquement pour le Lakehouse.

Pourquoi: Fabric fournit un accès double moteur aux mêmes tables Delta : un point de terminaison SQL pour les requêtes T-SQL et le moteur Spark pour les notebooks, sans duplication de données.

Ingérer des données depuis une source de données sur site (par exemple, Oracle, SQL Server) dans Fabric.

→Installer et configurer une passerelle de données sur site.

Pourquoi: La passerelle agit comme un pont sécurisé, transmettant les données entre le réseau sur site et le service cloud Fabric sans exposer la source à Internet.

Traiter automatiquement les nouveaux fichiers dès leur arrivée dans Azure Blob Storage.

→Utiliser un déclencheur d'événement de stockage pour le pipeline de données, configuré pour se déclencher sur les événements de création de blob.

Pourquoi: Les déclencheurs basés sur des événements offrent une latence plus faible et sont plus efficaces que l'interrogation planifiée, qui peut manquer des données ou s'exécuter inutilement.

Extraire tous les enregistrements d'une REST API qui renvoie des données par pages.

→Dans une activité Copy, configurer les règles de pagination intégrées du connecteur REST. Alternativement, utiliser une boucle Until ou ForEach avec des variables pour gérer les jetons de page.

Pourquoi: Automatise le processus d'itération à travers toutes les pages API jusqu'à ce que toutes les données soient récupérées, gérant les liens de page suivante ou les décalages dynamiques.

Implémenter une logique de type 2 de dimension à évolution lente (SCD2) ou traiter des flux de capture de données modifiées (CDC).

→Utiliser l'opération Delta Lake MERGE avec les clauses `WHEN MATCHED` et `WHEN NOT MATCHED`.

Pourquoi: MERGE offre des capacités upsert (mise à jour/insertion/suppression) atomiques, qui est l'opération fondamentale pour maintenir les enregistrements historiques dans les modèles SCD2.

Transformer une colonne de DataFrame contenant des tableaux d'objets imbriqués en lignes séparées.

→Appliquer la fonction `explode()` à la colonne de tableau dans un notebook PySpark.

Pourquoi: `explode()` est la fonction Spark standard pour désimbriquer les tableaux, créant une nouvelle ligne pour chaque élément du tableau.

Gérer les données arrivant en retard dans une agrégation de streaming avec état (par exemple, des comptages fenêtrés).

→Configurer un watermark sur la colonne de temps de l'événement dans la requête Spark Structured Streaming.

Pourquoi: Le watermarking définit un seuil de temps pendant lequel le moteur attendra les données en retard, empêchant l'état de croître indéfiniment tout en garantissant la correction.

Effectuer un chargement de données incrémental depuis un système source qui a une colonne d'horodatage mais pas de CDC.

→Implémenter un modèle de high-watermark. Stocker l'horodatage maximal de la dernière exécution et l'utiliser pour filtrer la source lors de la prochaine exécution.

Pourquoi: Ceci est un modèle efficace et courant pour extraire uniquement les enregistrements nouveaux ou mis à jour sans la surcharge des balayages de table complets ou l'exigence d'un CDC formel.

Une activité de pipeline échoue par intermittence en raison de problèmes réseau transitoires ou de la charge du système source.

→Configurer la politique de nouvelle tentative de l'activité avec un nombre spécifié et un intervalle de backoff exponentiel.

Pourquoi: Intègre la résilience dans le pipeline en relançant automatiquement les opérations échouées, résolvant souvent les problèmes transitoires sans intervention manuelle.

Ingérer et interroger des données de télémétrie ou de journalisation à haut volume et faible latence pour une analyse exploratoire en temps réel.

→Ingérer les données dans un Eventhouse et les interroger en utilisant Kusto Query Language (KQL).

Pourquoi: Eventhouse (basé sur Azure Data Explorer) et KQL sont conçus spécifiquement pour l'analyse de séries chronologiques et de journaux haute performance.

Créer un pipeline unique et réutilisable pour charger des dizaines de tables qui partagent la même logique de transformation.

→Utiliser une approche basée sur les métadonnées. Stocker les informations source/destination dans une table de contrôle et utiliser une activité ForEach pour itérer et passer des paramètres à un pipeline enfant générique.

Pourquoi: Ce modèle est hautement scalable et maintenable, évitant la duplication et la surcharge de gestion de la création de pipelines séparés pour chaque table.

Optimiser les performances d'un Dataflow Gen2 qui tire ses données d'une base de données relationnelle comme SQL Server.

→Concevoir des transformations qui peuvent être pliées (folded). Vérifier l'état du query folding dans l'éditeur Power Query.

Pourquoi: Le query folding pousse la logique de transformation vers le moteur de la base de données source, ce qui est significativement plus performant que de tirer toutes les données dans le moteur Spark pour la transformation.

Interroger une table telle qu'elle existait à un moment précis dans le passé pour un audit ou pour récupérer après une mise à jour accidentelle.

→Utiliser la fonction de time travel de Delta Lake avec `VERSION AS OF` ou `TIMESTAMP AS OF` dans la requête.

Pourquoi: Delta Lake versionne nativement chaque transaction, permettant des requêtes ponctuelles sans nécessiter de snapshots ou de sauvegardes manuelles.

Appliquer la sécurité au niveau des lignes (RLS) où les utilisateurs ne devraient voir que les données correspondant à leur région ou département.

→Implémenter des règles RLS en utilisant des expressions DAX au sein du semantic model.

Pourquoi: Le semantic model est la couche centralisée et recommandée pour l'application des règles métier comme la RLS. La logique est appliquée dynamiquement en fonction de l'identité de l'utilisateur.

Empêcher un groupe d'utilisateurs de voir des colonnes sensibles (par exemple, salaire, PII) dans une table.

→Implémenter la sécurité au niveau des colonnes (CLS) dans le semantic model ou l'entrepôt.

Pourquoi: CLS offre un contrôle granulaire pour restreindre l'accès à des colonnes spécifiques pour des rôles d'utilisateur désignés, protégeant les données sensibles au sein d'une table partagée.

Construire un rapport Power BI sur un très grand ensemble de données lakehouse avec des exigences de haute performance.

→Créer un semantic model en utilisant le mode DirectLake.

Pourquoi: DirectLake offre les performances du mode Import en chargeant les données en mémoire, mais sans dupliquer les données, en lisant directement les fichiers Delta dans OneLake.

Améliorer les performances des requêtes et réduire la consommation de capacité pour les rapports avec des résumés de haut niveau.

→Créer et configurer des tables d'agrégation au sein du semantic model.

Pourquoi: Les requêtes ciblant des données pré-agrégées sont significativement plus rapides et consomment moins de ressources que celles qui scannent la table détaillée complète, optimisant l'expérience utilisateur et le coût.

Réduire le temps de rafraîchissement et l'utilisation des ressources pour un grand semantic model où seules les données récentes changent.

→Configurer une politique de rafraîchissement incrémental sur les grandes tables de faits dans le semantic model.

Pourquoi: Ceci partitionne les données et ne rafraîchit que les partitions les plus récentes, évitant les rechargements complets coûteux de données historiques qui ne changent pas.

Les performances de requête sur une table Delta se sont dégradées en raison d'un grand nombre de petits fichiers provenant de l'ingestion en streaming.

→Exécuter la commande `OPTIMIZE` sur la table Delta.

Pourquoi: `OPTIMIZE` compacte les petits fichiers en moins de fichiers, mais plus grands. Cela améliore significativement les performances de lecture car le moteur de requête doit ouvrir moins de fichiers.

Améliorer les performances de requête sur une grande table Delta qui est fréquemment filtrée par une colonne non partitionnée à haute cardinalité.

→Exécuter `OPTIMIZE` avec une clause `ZORDER BY` sur les colonnes fréquemment filtrées.

Pourquoi: Le Z-Ordering co-localise les données liées au sein des fichiers, permettant au moteur de requête d'utiliser le saut de données pour lire moins de données, accélérant considérablement les requêtes filtrées.

Optimiser les performances de lecture pour les rapports Power BI interrogeant des tables Delta dans un lakehouse Fabric.

→S'assurer que l'optimisation V-Order est activée sur les tables Delta.

Pourquoi: V-Order est une optimisation Fabric spécifique au moment de l'écriture qui améliore les performances de lecture pour le moteur Power BI en améliorant la compression et l'ordonnancement des données.

Récupérer de l'espace de stockage à partir d'une table Delta qui a accumulé un historique significatif suite à des mises à jour et des suppressions.

→Exécuter la commande `VACUUM` sur la table.

Pourquoi: `VACUUM` supprime physiquement les fichiers de données qui ne sont plus référencés par la table et sont plus anciens que la période de rétention, réduisant ainsi les coûts de stockage.

Optimiser une jointure Spark entre une très grande table de faits et une petite table de dimensions.

→Utiliser une jointure de diffusion (broadcast join) en fournissant une indication (`broadcast()`) pour envoyer la petite table à tous les executors.

Pourquoi: La diffusion évite une opération de shuffle coûteuse et gourmande en réseau de la grande table, qui est un goulot d'étranglement majeur des performances dans les jointures à grande échelle.

Une opération de jointure Spark est lente ou échoue parce qu'une valeur de clé contient une quantité de données disproportionnellement grande (data skew).

→Implémenter une technique de "salting" : ajouter une clé aléatoire aux valeurs asymétriques pour les distribuer sur davantage de partitions, puis joindre et agréger.

Pourquoi: Le salting divise manuellement la partition asymétrique, permettant à la charge de travail d'être équilibrée entre tous les executors et évitant les erreurs OOM ou les tâches de longue durée.

Un job de notebook Spark s'exécute plus lentement que prévu et la cause n'est pas claire.

→Utiliser l'interface utilisateur Spark (Spark UI), accessible depuis le centre de surveillance, pour analyser le Directed Acyclic Graph (DAG), les durées des stages et les détails des tâches.

Pourquoi: La Spark UI offre une vue physique détaillée de l'exécution de la requête, vous permettant d'identifier les goulots d'étranglement comme l'asymétrie des données, les déversements sur disque ou les shuffles inefficaces.

Un job Spark échoue avec une erreur OutOfMemoryError sur le nœud driver, même avec une grande mémoire executor.

→Examiner le code pour des actions comme `.collect()` ou `.toPandas()` qui tirent de grandes quantités de données distribuées dans la mémoire du nœud driver.

Pourquoi: Le driver a sa propre limite de mémoire. Collecter un grand DataFrame vers le driver est un anti-modèle courant qui provoque des erreurs OOM ; utiliser des opérations distribuées à la place.

Identifier quels espaces de travail, rapports ou pipelines consomment le plus de ressources de calcul dans une capacité Fabric.

→Installer et analyser l'application Fabric Capacity Metrics.

Pourquoi: Cette application fournit une ventilation détaillée de la consommation d'Unités de Capacité (CU) au fil du temps par espace de travail, type d'élément et opération spécifique, permettant une optimisation ciblée et une analyse des coûts.

Implémenter un audit et une surveillance centralisés et à long terme de toutes les activités au sein d'un espace de travail Fabric.

→Dans les paramètres d'administration de Fabric, configurer les paramètres de diagnostic pour l'espace de travail afin de diffuser les journaux vers un espace de travail Azure Log Analytics.

Pourquoi: Fournit un stockage robuste, interrogeable et à long terme pour tous les journaux d'audit et opérationnels, permettant une surveillance avancée, des alertes et des rapports de conformité.

Réduire le coût opérationnel d'une capacité Fabric qui présente des périodes d'inactivité prévisibles (par exemple, nuits, week-ends).

→Implémenter l'automatisation (par exemple, via des API et Azure Automation) pour suspendre la capacité pendant les heures creuses et la reprendre avant les heures ouvrables.

Pourquoi: Le calcul de capacité est un facteur de coût primaire. La mise en pause de la capacité arrête la facturation des CU, ce qui permet des économies significatives pendant les périodes d'inactivité.

Un pipeline de données critique doit être surveillé, et l'équipe des opérations doit être immédiatement informée en cas d'échec.

→Configurer des alertes dans le Fabric Monitoring Hub ou utiliser Data Activator pour surveiller l'état du pipeline et déclencher des notifications.

Pourquoi: L'alerte proactive garantit que les échecs sont détectés et traités rapidement, minimisant les temps d'arrêt des données et l'impact sur les utilisateurs professionnels.