Guide

Interroger une table Delta massive (plus de 500 millions de lignes) dans un lakehouse Fabric avec des performances optimales et un accès aux données quasi en temps réel.

→Utiliser un modèle sémantique en mode Direct Lake.

Pourquoi: Direct Lake lit les fichiers Parquet directement depuis OneLake, contournant l'importation de données ou la traduction de requêtes. Il offre des performances similaires à l'importation sans duplication de données ni latence de rafraîchissement. DirectQuery est plus lent ; le mode Import introduit de la latence.

Appliquer des calculs d'intelligence temporelle courants (YTD, QTD, MTD) à des dizaines de mesures de base (Ventes, Profit, Quantité) sans créer des centaines de mesures DAX.

→Implémenter un groupe de calcul avec des éléments de calcul pour YTD, QTD et MTD.

Pourquoi: Les groupes de calcul éliminent la prolifération des mesures. Ils définissent un ensemble de calculs génériques qui peuvent être appliqués dynamiquement à toute mesure sélectionnée, simplifiant considérablement la maintenance du modèle.

Plusieurs modèles sémantiques dans un espace de travail doivent partager des tables de dimensions communes (par exemple, Date, Client) pour assurer la cohérence et réduire la duplication des données.

→Créer un modèle sémantique "central" contenant les dimensions partagées. Construire d'autres modèles "composites" qui se connectent au modèle central via DirectQuery et aux tables de faits via Direct Lake/Import.

Pourquoi: Cette architecture "en étoile" favorise une source unique de vérité pour les dimensions. Les modèles composites permettent de combiner des données de différentes sources et modes de stockage dans un modèle unifié.

Une table de faits a plusieurs colonnes de date (par exemple, OrderDate, ShipDate) qui doivent toutes se rapporter à une seule table de dimensions de date.

→Créer une relation active et plusieurs relations inactives entre les tables de faits et de dates. Utiliser la fonction DAX `USERELATIONSHIP()` dans les mesures pour activer la relation inactive appropriée.

Pourquoi: Power BI n'autorise qu'une seule relation active entre deux tables. Ce modèle permet l'analyse par différents rôles de date sans dupliquer la table de dimensions.

Un modèle sémantique avec une grande table de faits (des milliards de lignes) prend trop de temps à rafraîchir. Seules les données des 30 derniers jours changent fréquemment.

→Configurer le rafraîchissement incrémentiel sur la table de faits. Définir les paramètres `RangeStart` et `RangeEnd`. Définir une politique pour archiver les anciennes données (par exemple, stocker les 5 dernières années) et rafraîchir les données récentes (par exemple, rafraîchir les 30 derniers jours).

Pourquoi: Cela réduit considérablement le temps de rafraîchissement et la consommation de ressources en ne traitant que les partitions contenant des données nouvelles ou modifiées, plutôt que de recharger toute la table.

Une mesure DAX complexe est lente car elle calcule à plusieurs reprises la même valeur intermédiaire dans sa formule.

→Utiliser des variables (`VAR`) pour stocker le résultat du calcul intermédiaire une fois, puis référencer la variable plusieurs fois dans l'instruction `RETURN`.

Pourquoi: Les variables empêchent le moteur de réévaluer la même logique plusieurs fois au cours d'une seule exécution de mesure, ce qui améliore considérablement les performances, en particulier dans les contextes itératifs.

Créer une mesure pour calculer le pourcentage de contribution d'une valeur (par exemple, les ventes de produits) à un total plus grand (par exemple, toutes les ventes de produits), tout en respectant les autres filtres (comme la date).

→Utiliser `DIVIDE([Sales], CALCULATE([Sales], ALLEXCEPT(Product, Product[Category])))` pour le pourcentage de catégorie ou `CALCULATE([Sales], ALL(Product))` pour le pourcentage du total général.

Pourquoi: `CALCULATE` combiné avec `ALL`, `ALLEXCEPT` ou `REMOVEFILTERS` vous permet de modifier le contexte de filtre pour obtenir le dénominateur correct pour le calcul du pourcentage.

Un rapport a besoin d'un segment qui permet aux utilisateurs de choisir quelle métrique (par exemple, "Revenue", "Cost", "Profit") un visuel doit afficher.

→Créer une table déconnectée avec les noms des métriques. Créer une mesure DAX unique utilisant `SWITCH(SELECTEDVALUE(MetricTable[Metric]), "Revenue", [Total Revenue], "Cost", [Total Cost], ...)`

Pourquoi: Ce modèle, souvent à l'aide d'un paramètre de champ, offre un moyen dynamique et convivial de basculer entre les calculs sans avoir besoin de signets ou de plusieurs visuels, rendant les rapports plus interactifs et concis.

Une équipe BI d'entreprise doit utiliser des outils professionnels (comme Visual Studio, Tabular Editor, SQL Profiler) pour gérer, déployer et dépanner un modèle sémantique Fabric.

→Activer le point de terminaison XMLA en lecture/écriture pour l'espace de travail.

Pourquoi: Le point de terminaison XMLA expose le modèle sémantique comme une instance Analysis Services standard, permettant la connectivité à partir d'un vaste écosystème d'outils BI et ALM avancés pour l'accès programmatique et les tâches de modélisation complexes.

Un modèle Direct Lake est lent. L'enquête révèle qu'il repasse en mode DirectQuery.

→Utiliser DAX Studio ou Performance Analyzer pour identifier la requête qui provoque le retour en arrière. Les causes courantes incluent des fonctions DAX non prises en charge, un RLS complexe, ou un lakehouse non optimisé/obsolète.

Pourquoi: Direct Lake a des limitations. Lorsqu'une requête utilise une fonctionnalité non prise en charge, elle repasse silencieusement au moteur DirectQuery plus lent. Identifier et corriger la cause profonde (par exemple, optimiser DAX, exécuter OPTIMIZE sur la table Delta) est essentiel pour restaurer les performances.

Un modèle a une relation plusieurs-à-plusieurs (par exemple, Ventes et Promotions via une table pont). Les mesures renvoient des totaux incorrects lors du filtrage par le côté "plusieurs".

→S'assurer que la direction du filtre croisé sur les relations (Dimension -> Pont -> Fait) est définie correctement (typiquement unidirectionnelle). Utiliser des fonctions DAX comme `TREATAS` ou `INTERSECT` pour des calculs M2M plus complexes si nécessaire.

Pourquoi: Une direction de filtre croisé incorrecte est une cause fréquente de résultats incorrects dans les modèles M2M. Bien que le filtrage bidirectionnel puisse sembler fonctionner, il conduit souvent à l'ambiguïté et au double-comptage. Un modèle bien défini avec des motifs DAX explicites est plus robuste.

Un modèle composite utilisant DirectQuery sur une table de faits massive est lent. La plupart des requêtes utilisateur sont à un niveau agrégé (par exemple, ventes mensuelles par catégorie).

→Créer une table d'agrégation définie par l'utilisateur en mode Import. La table d'agrégation doit contenir des données pré-résumées au niveau des requêtes courantes (Mois, Catégorie).

Pourquoi: Le moteur de requête redirigera automatiquement les requêtes vers la table d'agrégation plus petite, en mémoire, lorsque cela est possible, offrant des gains de performance massifs. Il n'interrogera la source DirectQuery que pour les requêtes qui nécessitent un niveau de détail inférieur.

Calculer des totaux cumulatifs complexes ou des moyennes mobiles en DAX qui fonctionnent mal avec les approches traditionnelles basées sur les filtres.

→Utiliser les fonctions de fenêtre DAX comme `WINDOW` ou `OFFSET`.

Pourquoi: Ces fonctions sont spécifiquement optimisées pour les calculs positionnels sur un ensemble de lignes triées. Elles sont souvent plus performantes et syntaxiquement plus simples que les anciens modèles qui reposent sur un filtrage intensif et des transitions de contexte.

Calculer les totaux de l'année à ce jour (YTD) pour une entreprise dont l'exercice fiscal commence le 1er juillet.

→Utiliser les fonctions `TOTALYTD` ou `DATESYTD` avec le paramètre optionnel `YearEndDate`. Exemple : `TOTALYTD([Sales], 'Date'[Date], "6/30")`.

Pourquoi: Spécifier le paramètre de date de fin d'année est le moyen correct et le plus simple de rendre les fonctions DAX d'intelligence temporelle conscientes du calendrier fiscal personnalisé.

Promouvoir un modèle sémantique à travers les étapes de Dev, Test et Prod où chaque étape a une chaîne de connexion de base de données différente.

→Utiliser les pipelines de déploiement Fabric avec des règles de déploiement.

Pourquoi: Les règles de déploiement automatisent la modification des connexions aux sources de données, des paramètres et d'autres configurations pour chaque environnement. Cela évite les modifications manuelles et sujettes aux erreurs après le déploiement.

Référence↗

Implémenter une architecture de maillage de données décentralisée où les domaines d'activité possèdent et gèrent leurs propres produits de données.

→Créer des espaces de travail spécifiques aux domaines. Utiliser les raccourcis OneLake pour permettre le partage et la consommation de données inter-domaines sans centraliser la propriété des données.

Pourquoi: Ce modèle s'aligne sur les principes du maillage de données de propriété de domaine et de données en tant que produit. Les espaces de travail fournissent la limite de propriété, tandis que les raccourcis fournissent la couche d'interopérabilité.

Une équipe de développeurs doit collaborer sur des éléments Fabric (modèles sémantiques, rapports, notebooks) avec le contrôle de code source et l'historique des versions.

→Configurer l'intégration Git pour l'espace de travail Fabric, en le connectant à un référentiel Azure DevOps ou GitHub.

Pourquoi: L'intégration Git stocke les définitions d'éléments Fabric sous forme de fichiers texte (JSON, TMDL), permettant des pratiques DevOps standard comme le branchement, les demandes de tirage (pull requests) et le suivi de version. Ceci est essentiel pour la gestion du cycle de vie des applications (ALM) de niveau entreprise.

Avant de modifier une table de lakehouse, un ingénieur doit identifier tous les rapports et modèles sémantiques en aval qui seront affectés.

→Utiliser la vue de lignage (Lineage View) et sélectionner "Analyse d'impact" sur l'élément lakehouse.

Pourquoi: Cette fonctionnalité offre une vue complète et automatisée de toutes les dépendances. C'est un outil de gouvernance critique pour gérer les changements dans un environnement d'analyse complexe, prévenant les ruptures inattendues.

Une équipe a besoin de contrôler la version d'un modèle sémantique dans un format textuel et lisible par l'homme, facile à différencier et à fusionner.

→Enregistrer le fichier Power BI en tant que projet Power BI (.pbip). Cela stocke la définition du modèle au format Tabular Model Definition Language (TMDL).

Pourquoi: TMDL est un format convivial pour les développeurs qui représente le modèle comme une structure de dossiers avec des fichiers texte individuels pour les tables, les mesures, etc. C'est bien supérieur au fichier binaire .bim pour la collaboration basée sur Git et le CI/CD.

Implémenter une architecture en médaillon (Bronze, Silver, Gold) et avoir besoin d'accéder aux données à travers les couches sans duplication physique des données.

→Utiliser les raccourcis OneLake pour référencer les données dans d'autres lakehouses ou couches.

Pourquoi: Les raccourcis sont des liens symboliques dans OneLake. Ils fournissent un espace de noms unifié et permettent d'accéder aux données sans copier, ce qui est idéal pour un maillage de données logique ou une architecture en médaillon.

Référence↗

Migrer une charge de travail analytique existante à forte utilisation de T-SQL d'Azure Synapse vers Fabric.

→Utiliser un Fabric Data Warehouse.

Pourquoi: Le Fabric Warehouse offre une compatibilité T-SQL complète, ce qui en fait la cible idéale pour migrer les scripts SQL existants, les procédures stockées et les requêtes d'analystes avec des modifications minimales. Le point de terminaison SQL du Lakehouse a un accès T-SQL en lecture seule et utilise Spark SQL pour les écritures.

Ingérer et interroger des données de streaming à volume élevé et haute vélocité (par exemple, télémétrie IoT) avec une latence inférieure à la seconde.

→Utiliser Fabric Eventstream pour l'ingestion et une base de données KQL pour le stockage et l'analyse.

Pourquoi: Il s'agit de la pile d'analyse de streaming spécialement conçue dans Fabric. KQL (Kusto Query Language) est optimisé pour l'analyse de séries chronologiques sur les données de streaming, offrant une latence bien inférieure à celle des lakehouses ou warehouses orientés lot.

Implémenter une dimension à évolution lente (SCD) de Type 2 pour maintenir un historique complet des modifications de dimension dans un lakehouse.

→Utiliser une instruction `MERGE INTO` dans un notebook ou un pipeline Spark. Correspondre à la clé métier ; `WHEN MATCHED` met à jour l'ancien enregistrement (définit `IsCurrent` sur false, `EndDate` sur la date actuelle) ; `WHEN NOT MATCHED` insère le nouvel enregistrement.

Pourquoi: L'opération `MERGE` de Delta Lake offre des capacités d'upsert atomiques, ce qui en fait le moyen standard et le plus efficace d'implémenter la logique SCD dans un lakehouse Fabric.

Répliquer des données quasi en temps réel depuis une base de données opérationnelle (par exemple, Azure SQL DB) vers un lakehouse Fabric pour l'analyse.

→Utiliser Fabric Mirroring.

Pourquoi: Mirroring est une solution de capture de données modifiées (CDC) à faible latence et faible impact intégrée à Fabric. Elle réplique automatiquement les modifications de données et de schéma vers OneLake en tant que tables Delta, éliminant le besoin de pipelines ETL complexes.

Ingérer et transformer des données JSON complexes et imbriquées provenant d'une API en une table Delta aplatie et structurée.

→Utiliser un notebook PySpark. Utiliser des fonctions comme `from_json` pour analyser le schéma, et `explode` pour aplatir les tableaux en lignes.

Pourquoi: PySpark fournit les outils les plus puissants et flexibles pour gérer les structures JSON complexes et évolutives de manière programmatique, bien au-delà des capacités d'une activité de copie standard.

Ingérer des données dans Fabric depuis une base de données SQL Server sur site qui se trouve derrière un pare-feu d'entreprise.

→Installer et configurer une passerelle de données locale sur un serveur du réseau local. Ajouter la passerelle comme source de données dans Fabric.

Pourquoi: La passerelle agit comme un pont sécurisé, relayant les requêtes et les données entre les services cloud Fabric et les sources de données sur site sans nécessiter l'ouverture de ports de pare-feu entrants.

Les performances des requêtes sur une grande table Delta fréquemment mise à jour se sont dégradées en raison d'une accumulation de nombreux petits fichiers de données.

→Exécuter la commande `OPTIMIZE` pour compacter les petits fichiers en des plus grands. Utiliser éventuellement `ZORDER BY` sur les colonnes fréquemment filtrées pour co-localiser les données associées.

Pourquoi: Moins de fichiers, mais plus grands, sont beaucoup plus efficaces pour Spark à lire. Le Z-ordering améliore le saut de données, permettant aux requêtes de lire encore moins de données. C'est une tâche de maintenance critique pour les tables Delta.

Agréger des données de séries chronologiques en streaming dans des intervalles de temps fixes et non chevauchants (par exemple, la température moyenne par capteur toutes les 5 minutes).

→Utiliser une requête KQL avec l'opérateur `summarize` et la fonction `bin()`. Exemple : `SensorData | summarize avg(temperature) by sensor_id, bin(timestamp, 5m)`

Pourquoi: La fonction `bin()` est le moyen standard et hautement optimisé en KQL pour regrouper les événements en des intervalles de temps fixes (fenêtres glissantes) pour l'agrégation.

Un rafraîchissement Dataflow Gen2 est lent. La source de données est une base de données relationnelle comme Azure SQL.

→Examiner les étapes de transformation dans l'éditeur Power Query pour s'assurer que le repliement de requête est actif. Réorganiser ou modifier les étapes pour maximiser le repliement.

Pourquoi: Le repliement de requête renvoie la logique de transformation à la base de données source pour être exécutée comme une seule requête native. C'est bien plus efficace que de tirer toutes les données brutes dans le moteur de flux de données et de les transformer en mémoire.

Un notebook Spark effectue une jointure lente entre une très grande table de faits (des milliards de lignes) et une petite table de dimensions (des milliers de lignes).

→Utiliser une jointure de diffusion (broadcast join) en fournissant un indice (`spark.sql.functions.broadcast`) ou en laissant l'optimiseur choisir en fonction des statistiques.

Pourquoi: La diffusion envoie toute la petite table à chaque nœud d'exécution. Cela évite une coûteuse opération de "shuffle" où les données de la grande table doivent être repartitionnées et envoyées à travers le réseau, améliorant considérablement les performances.

Un pipeline de données orchestre plusieurs activités. Une activité peut échouer, mais les activités suivantes, indépendantes, doivent toujours s'exécuter, et l'échec global doit être enregistré.

→Configurer les dépendances d'activité. Les activités qui doivent s'exécuter quel que soit le résultat doivent dépendre de l'activité précédente avec la condition "Achèvement".

Pourquoi: Cela permet de construire des chemins d'exécution robustes et parallèles. Vous pouvez créer des branches séparées pour les conditions "Réussite" et "Échec" pour implémenter une logique de journalisation ou de notification personnalisée.

Un pipeline pour charger de manière incrémentielle des données à partir d'une source avec un horodatage `last_modified`.

→Implémenter un modèle de filigrane (watermark). Stocker le `max(last_modified)` de la dernière exécution réussie. Lors de la prochaine exécution, interroger la source pour les enregistrements où `last_modified` est supérieur au filigrane stocké.

Pourquoi: C'est le modèle le plus efficace pour les chargements incrémentiels à partir de sources qui fournissent un horodatage de modification, garantissant que seules les données nouvelles ou mises à jour sont traitées, minimisant le transfert de données et le calcul.

Analyser un flux en temps réel de données IoT pour détecter des pics ou des baisses inhabituels dans les lectures de capteurs.

→Utiliser la fonction `series_decompose_anomalies()` dans une requête KQL au sein d'une base de données Eventhouse/KQL.

Pourquoi: Cette fonction KQL intégrée est spécifiquement conçue pour la détection d'anomalies dans les séries chronologiques. Elle décompose automatiquement la série en composants saisonniers, de tendance et résiduels pour identifier les valeurs aberrantes statistiquement significatives, nécessitant une configuration manuelle minimale.

Besoin de joindre des données d'un Warehouse, d'un Lakehouse et d'une base de données Azure SQL miroir dans une seule requête T-SQL sans déplacer les données.

→Utiliser des conventions de nommage en trois parties (`database.schema.table`) dans une requête exécutée depuis le point de terminaison SQL du Warehouse ou du Lakehouse. Utiliser des raccourcis pour référencer la base de données miroir.

Pourquoi: Fabric fournit un moteur de requête unifié capable d'accéder aux données à travers différents éléments Fabric au sein du même espace de travail en utilisant une seule instruction SQL, permettant la virtualisation des données.

Un flux de données doit traiter un fichier où certaines lignes peuvent être invalides. Le flux entier ne doit pas échouer ; les lignes valides doivent être chargées, et les lignes invalides doivent être enregistrées.

→Dans Power Query, ajouter une étape pour valider les lignes et créer une colonne "IsValid". Ensuite, créer deux requêtes de référence à partir de ce point : une qui filtre `IsValid = true` pour charger vers la destination, et une autre qui filtre `IsValid = false` pour charger vers un journal d'erreurs.

Pourquoi: Ce modèle offre une gestion robuste des erreurs en divisant le flux de données. Il empêche quelques mauvaises lignes d'arrêter l'ensemble du processus et fournit un mécanisme clair pour auditer les problèmes de qualité des données.

Implémenter la sécurité au niveau des lignes (RLS) où les utilisateurs ne devraient voir que les données correspondant à leur identité (par exemple, un responsable des ventes ne voit que ses magasins).

→Créer une table de sécurité qui mappe les utilisateurs aux entités de données. Dans le rôle RLS, utiliser une expression de filtre DAX comme `[ManagerEmail] = USERPRINCIPALNAME()`

Pourquoi: Le RLS dynamique est scalable. Il utilise une approche axée sur les données au lieu de créer un rôle statique pour chaque personne ou entité. `USERPRINCIPALNAME()` résout correctement l'identité Azure AD.

Masquer les colonnes sensibles ou des tables entières (par exemple, Salaire) d'un groupe spécifique d'utilisateurs tout en leur permettant d'accéder au reste du modèle sémantique.

→Définir des rôles de sécurité et configurer la sécurité au niveau des objets (OLS) à l'aide d'un outil externe comme Tabular Editor pour définir les autorisations de table/colonne sur "None".

Pourquoi: OLS offre un contrôle granulaire sur la visibilité des métadonnées du modèle. Contrairement au RLS qui filtre les lignes, OLS masque l'objet entier. Il doit être configuré via le point de terminaison XMLA.

Les utilisateurs signalent des performances lentes et des limitations dans Fabric. L'administrateur doit identifier la cause profonde.

→Utiliser l'application Fabric Capacity Metrics.

Pourquoi: Cette application fournit des informations détaillées sur la consommation d'unités de capacité (CU), les événements de limitation et l'utilisation des ressources par type de charge de travail (par exemple, requête de modèle sémantique, rafraîchissement de flux de données). C'est l'outil principal pour la surveillance des performances et la planification de la capacité.

Appliquer une politique de classification des données où les rapports et tableaux de bord héritent automatiquement de l'étiquette de sensibilité du modèle sémantique auquel ils se connectent.

→Activer le paramètre de locataire pour l'héritage en aval des étiquettes de sensibilité.

Pourquoi: Cela automatise la gouvernance des données, garantissant que les protections appliquées à la source de données (par exemple, "Hautement Confidentiel") sont appliquées de manière cohérente à tout le contenu en aval, réduisant le risque de fuite de données.

Dans un Fabric Warehouse, les utilisateurs généraux devraient voir les données PII masquées (par exemple, `XXX-XX-1234`), tandis que les utilisateurs privilégiés voient les données complètes et non masquées.

→Appliquer le masquage dynamique des données (DDM) sur les colonnes sensibles du Warehouse. Accorder les permissions `UNMASK` aux rôles d'utilisateurs privilégiés.

Pourquoi: Le DDM est une fonctionnalité de sécurité au niveau de la base de données qui masque les données à la volée en fonction des autorisations de l'utilisateur. Il protège les données sensibles en place sans nécessiter de vues ou de copies séparées des données.