Partager via

Gérer des modèles sémantiques Direct Lake

  • Article

Cet article décrit les rubriques de conception relatives à la gestion de modèles sémantiques Direct Lake.

Tâches postérieures à la publication

Une fois que vous avez publié un modèle sémantique Direct Lake prêt pour la création de rapports, vous devez immédiatement effectuer certaines tâches postérieures à la publication. Ces tâches peuvent également être ajustées à tout moment pendant le cycle de vie du modèle sémantique.

Si vous le souhaitez, vous pouvez également configurer la découverte de données pour permettre aux créateurs de rapports de lire les métadonnées, de les aider à découvrir des données dans le hub de données OneLake et à demander l’accès à celui-ci. Vous pouvez également approuver (certifié ou promu) le modèle sémantique pour communiquer qu’il représente des données de qualité adaptées à l’utilisation.

Configurer la connexion cloud

Un modèle sémantique Direct Lake utilise une connexion cloud pour se connecter au point de terminaison d’analytique SQL. Il permet d’accéder aux données sources, soit aux fichiers Parquet dans OneLake (mode stockage Direct Lake, ce qui implique le chargement de données de colonne en mémoire) ou au point de terminaison d’analyse SQL (lorsque les requêtes reviennent en mode DirectQuery).

Connexion cloud par défaut

Lorsque vous créez un modèle sémantique Direct Lake, la connexion cloud par défaut est utilisée. Il tire parti de l’authentification unique (SSO), ce qui signifie que l’identité qui interroge le modèle sémantique (souvent un utilisateur de rapport) est utilisée pour interroger les données de point de terminaison SQL Analytics.

Connexion cloud partageable

Si vous le souhaitez, vous pouvez créer une connexion cloud partageable (SCC) afin que les connexions à la source de données puissent être établies avec une identité fixe. Il peut aider les clients d’entreprise à protéger leurs magasins de données d’organisation. Le service informatique peut gérer les informations d’identification, créer des SCC et les partager avec les créateurs prévus pour la gestion centralisée des accès.

Pour configurer une identité fixe, consultez Spécifier une identité fixe pour un modèle sémantique Direct Lake.

Authentification

L’identité fixe peut s’authentifier à l’aide de OAuth 2.0 ou d’un principal de service.

Remarque

Seule l’authentification Microsoft Entra est prise en charge. Par conséquent, l’authentification de base n’est pas prise en charge pour les modèles sémantiques Direct Lake.

OAuth 2.0

Lorsque vous utilisez OAuth 2.0, vous pouvez vous authentifier auprès d’un compte d’utilisateur Microsoft Entra. Le compte d’utilisateur doit avoir l’autorisation d’interroger les tables et vues de point de terminaison SQL Analytics et les métadonnées de schéma.

L’utilisation d’un compte d’utilisateur spécifique n’est pas une pratique recommandée. Cela est dû au fait que les requêtes de modèle sémantique échouent si le mot de passe change ou que le compte d’utilisateur est supprimé (par exemple, lorsqu’un employé quitte l’organisation).

Principal du service

L’authentification auprès d’un principal de service est la pratique recommandée, car elle ne dépend pas d’un compte d’utilisateur spécifique. Le principal de sécurité doit avoir l’autorisation d’interroger les tables et vues de point de terminaison SQL Analytics et les métadonnées de schéma.

Pour assurer la continuité, les informations d’identification du principal de service peuvent être gérées par la rotation des secrets ou des certificats.

Remarque

Les paramètres du locataire Fabric doivent autoriser les principaux de service, et le principal de service doit appartenir à un groupe de sécurité déclaré.

Authentification unique

Lorsque vous créez une connexion cloud partageable, la case à cocher Authentification unique n’est pas cochée par défaut. Il s’agit de la configuration correcte lors de l’utilisation d’une identité fixe.

Vous pouvez activer l’authentification unique lorsque vous souhaitez que l’identité qui interroge le modèle sémantique interroge également le point de terminaison d’analyse SQL. Dans cette configuration, le modèle sémantique Direct Lake utilise l’identité fixe pour actualiser le modèle et l’identité de l’utilisateur pour interroger des données.

Lors de l’utilisation d’une identité fixe, il est courant de désactiver l’authentification unique afin que l’identité fixe soit utilisée pour les actualisations et les requêtes, mais il n’y a aucune exigence technique à faire.

Voici les pratiques recommandées relatives aux connexions cloud :

  • Lorsque tous les utilisateurs peuvent accéder aux données (et avoir l’autorisation de le faire), il n’est pas nécessaire de créer une connexion cloud partagée. Au lieu de cela, les paramètres de connexion cloud par défaut peuvent être utilisés. Dans ce cas, l’identité de l’utilisateur qui interroge le modèle doit revenir au mode DirectQuery.
  • Créez une connexion cloud partagée lorsque vous souhaitez utiliser une identité fixe pour interroger les données sources. Cela peut être dû au fait que les utilisateurs qui interrogent le modèle sémantique ne sont pas autorisés à lire le lakehouse ou l’entrepôt. Cette approche est particulièrement pertinente lorsque le modèle sémantique applique RLS.
  • Si vous utilisez une identité fixe, utilisez l’option de principal de service, car elle est plus sécurisée et plus fiable. Cela est dû au fait qu’il ne s’appuie pas sur un seul compte d’utilisateur ou ses autorisations, et qu’il ne nécessite pas de maintenance (et d’interruption) s’il modifie son mot de passe ou quitte l’organisation.
  • Si différents utilisateurs doivent être limités à accéder uniquement à des sous-ensembles de données, s’ils sont viables, appliquez uniquement la sécurité au niveau de la couche de modèle sémantique. De cette façon, les utilisateurs bénéficieront de requêtes en mémoire hautes performances.
  • Si possible, évitez OLS et CLS, car cela entraîne des erreurs dans les visuels de rapport. Les erreurs peuvent créer une confusion ou une préoccupation pour les utilisateurs. Pour les colonnes résumées, envisagez de créer des mesures qui retournent BLANK dans certaines conditions au lieu de CLS (si possible).

Gérer l’appartenance aux rôles de sécurité

Si votre modèle sémantique Direct Lake applique la sécurité au niveau des lignes (RLS), vous devrez peut-être gérer les membres affectés aux rôles de sécurité. Pour plus d’informations, consultez Gérer la sécurité sur votre modèle.

Configurer les autorisations des éléments Fabric

Les modèles sémantiques Direct Lake adhèrent à un modèle de sécurité en couches. Ils effectuent des vérifications d’autorisation via le point de terminaison d’analytique SQL pour déterminer si l’identité qui tente d’accéder aux données dispose des autorisations d’accès aux données nécessaires.

Vous devez accorder des autorisations aux utilisateurs afin qu’ils puissent utiliser ou gérer le modèle sémantique Direct Lake. En bref, les consommateurs de rapports ont besoin d’une autorisation Lecture, et les créateurs de rapports ont besoin d’une autorisation Générer. Les autorisations de modèle sémantique peuvent être affectées directement ou acquises implicitement via des rôles d’espace de travail. Pour gérer les paramètres du modèle sémantique (pour l’actualisation et d’autres configurations), vous devez être le propriétaire du modèle sémantique.

Selon la configuration de la connexion cloud et si les utilisateurs doivent interroger le lakehouse ou le point de terminaison d’analytique SQL de l’entrepôt, vous devrez peut-être accorder d’autres autorisations (décrites dans le tableau de cette section).

Remarque

Notamment, les utilisateurs n’ont jamais besoin d’autorisation pour lire des données dans OneLake. Cela est dû au fait que Fabric accorde les autorisations nécessaires au modèle sémantique pour lire les tables Delta et les fichiers Parquet associés (pour charger des données de colonne en mémoire). Le modèle sémantique dispose également des autorisations nécessaires pour lire périodiquement le point de terminaison d’analyse SQL pour effectuer des vérifications d’autorisations pour déterminer les données que l’utilisateur d’interrogation (ou identité fixe) peut accéder.

Tenez compte des scénarios et des exigences d’autorisation suivants.

Scénario Autorisations requises Commentaires
Les utilisateurs peuvent afficher les rapports • Accordez l’autorisation Lecture pour les rapports et l’autorisation Lecture pour le modèle sémantique.
• Si la connexion cloud utilise l’authentification unique, accordez au moins l’autorisation Lecture pour le lakehouse ou l’entrepôt.		 Les rapports n’ont pas besoin d’appartenir au même espace de travail que le modèle sémantique. Pour plus d’informations, consultez Stratégie pour les consommateurs en lecture seule.
Les utilisateurs peuvent créer des rapports • Accordez l’autorisation Générer pour le modèle sémantique.
• Si la connexion cloud utilise l’authentification unique, accordez au moins l’autorisation Lecture pour le lakehouse ou l’entrepôt.		 Pour plus d’informations, consultez Stratégie pour les créateurs de contenu.
Les utilisateurs peuvent interroger le modèle sémantique, mais sont refusés d’interroger le point de terminaison Lakehouse ou SQL Analytics • N’accordez aucune autorisation pour le lac ou l’entrepôt. Convient uniquement lorsque la connexion cloud utilise une identité fixe.
Les utilisateurs peuvent interroger le modèle sémantique et le point de terminaison d’analytique SQL, mais sont refusés d’interroger le lakehouse • Accordez des autorisations Lecture et ReadData pour le lakehouse ou l’entrepôt. Important : les requêtes envoyées au point de terminaison d’analyse SQL contournent les autorisations d’accès aux données appliquées par le modèle sémantique.
Gérer le modèle sémantique, y compris les paramètres d’actualisation • Nécessite la propriété du modèle sémantique. Pour plus d'informations, consultez Propriété du modèle sémantique.

Important

Vous devez toujours tester soigneusement les autorisations avant de libérer votre modèle sémantique et vos rapports en production.

Pour plus d'informations, consultez Autorisations du modèle sémantique.

Actualiser les modèles sémantiques Direct Lake

Une actualisation d’un modèle sémantique Direct Lake entraîne une opération de trame. Une opération d’actualisation peut être déclenchée :

  • Manuellement, en effectuant une actualisation à la demande dans le portail Fabric, ou en exécutant la Commande d’actualiser TMSL (Tabular Model Scripting Language) Refresh à partir d’un script dans SQL Server Management Studio (SSMS) ou à l’aide d’un outil tiers qui se connecte via le point de terminaison XMLA.
  • Automatiquement, en configurant une planification d’actualisation dans le portail Fabric.
  • Automatiquement, lorsque des modifications sont détectées dans les tables Delta sous-jacentes, pour plus d’informations, consultez Mises à jour automatiques (décrites ci-dessous).
  • Programmatiquement, en déclenchant une actualisation à l’aide de l’API REST Power BI ou TOM. Vous pouvez déclencher une actualisation programmatique en tant qu’étape finale d’un processus d’extraction, de transformation et de chargement (ETL).

Mises à jour automatiques

Il existe un paramètre sémantique au niveau du modèle nommé Conserver vos données Direct Lake à jour qui effectue les mises à jour automatiques des tables Direct Lake. Elle est activée par défaut. Cela garantit que les modifications de données dans OneLake sont automatiquement reflétées dans le modèle sémantique Direct Lake. Le paramètre est disponible dans le portail Fabric, dans la section Actualiser des paramètres du modèle sémantique.

Lorsque le paramètre est activé, le modèle sémantique effectue une opération de trame chaque fois que des modifications de données dans les tables Delta sous-jacentes sont détectées. L’opération de trame est toujours spécifique uniquement à ces tables où les modifications de données sont détectées.

Nous vous recommandons de laisser le paramètre activé, en particulier lorsque vous avez un modèle sémantique de petite ou moyenne taille. Il est particulièrement utile lorsque vous avez des exigences de création de rapports à faible latence et que les tables Delta sont modifiées régulièrement.

Dans certains cas, vous pouvez désactiver les mises à jour automatiques. Par exemple, vous devrez peut-être autoriser l’achèvement des travaux de préparation des données ou le processus ETL avant d’exposer de nouvelles données aux consommateurs du modèle sémantique. En cas de désactivation, vous pouvez déclencher une actualisation à l’aide d’une méthode programmatique (décrite précédemment).

Remarque

Power BI suspend les mises à jour automatiques lorsqu’une erreur non récupérable est rencontrée lors de l’actualisation. Une erreur non récupérable peut se produire, par exemple lorsqu’une actualisation échoue après plusieurs tentatives. Par conséquent, assurez-vous que votre modèle sémantique peut être actualisé avec succès. Power BI reprend automatiquement les mises à jour automatiques lorsqu’une actualisation à la demande ultérieure se termine sans erreur.

Chauffer le cache

Une opération d’actualisation du modèle sémantique Direct Lake peut supprimer toutes les colonnes résidentes de la mémoire. Cela signifie que les premières requêtes après une actualisation d’un modèle sémantique Direct Lake peuvent rencontrer un certain délai à mesure que les colonnes sont chargées en mémoire. Les retards peuvent être visibles uniquement lorsque vous avez des volumes de données extrêmement volumineux.

Pour éviter ces retards, envisagez de réchauffer le cache en envoyant par programme une requête au modèle sémantique. Un moyen pratique d’envoyer une requête consiste à utiliser le lien sémantique. Cette opération doit être effectuée immédiatement après la fin de l’opération d’actualisation.

Important

Le réchauffement du cache n’a de sens que lorsque les retards sont inacceptables. Veillez à ne pas charger inutilement des données en mémoire qui pourraient faire pression sur d’autres charges de travail de capacité, ce qui les oblige à limiter ou à les priver de leur priorité.

Définir la propriété de comportement Direct Lake

Vous pouvez contrôler le retour de vos modèles sémantiques Direct Lake en définissant sa propriété DirectLakeBehavior. Il peut être défini sur :

  • Automatique : (par défaut) Les requêtes reviennent en mode DirectQuery si les données requises ne peuvent pas être chargées efficacement en mémoire.
  • DirectLakeOnly : toutes les requêtes utilisent uniquement le mode de stockage Direct Lake. Le mode DirectQuery est désactivé. Si les données ne peuvent pas être chargées en mémoire, une erreur est retournée.
  • DirectQueryOnly : toutes les requêtes utilisent uniquement le mode DirectQuery. Utilisez ce paramètre pour tester les performances de secours, où, par exemple, vous pouvez observer les performances des requêtes dans les rapports connectés.

Vous pouvez définir la propriété dans l’expérience de modélisation web, ou à l’aide du modèle objet tabulaire (TOM) ou du langage TMSL (Tabular Model Scripting Language).

Conseil

Envisagez de désactiver la secours DirectQuery lorsque vous souhaitez traiter des requêtes en mode stockage Direct Lake uniquement. Nous vous recommandons de désactiver la secours lorsque vous ne souhaitez pas revenir à DirectQuery. Il peut également être utile lorsque vous souhaitez analyser le traitement des requêtes pour un modèle sémantique Direct Lake afin d’identifier si et la fréquence de secours se produit.

Surveiller des modèles sémantiques Direct Lake

Vous pouvez surveiller un modèle sémantique Direct Lake pour déterminer les performances des requêtes DAX visuelles de rapport ou pour déterminer quand il revient en mode DirectQuery.

Vous pouvez utiliser Analyseur de performances, SQL Server Profiler, Azure Log Analytics ou un outil de communauté open source, comme DAX Studio.

Analyseur de performances

Vous pouvez utiliser Performance Analyzer dans Power BI Desktop pour enregistrer le temps de traitement requis pour mettre à jour les éléments de rapport initiés à la suite de toute interaction utilisateur qui entraîne l’exécution d’une requête. Si les résultats de surveillance affichent une métrique de requête directe, cela signifie que les requêtes DAX ont été traitées en mode DirectQuery. En l’absence de cette métrique, les requêtes DAX ont été traitées en mode Direct Lake.

Pour plus d’informations, consultez Analyser à l’aide de Performance Analyzer.

SQL Server Profiler

Vous pouvez utiliser SQL Server Profiler pour récupérer des détails sur les performances des requêtes en traçant les événements de requête. Il est installé avec SQL Server Management Studio (SSMS). Avant de commencer, assurez-vous que la dernière version de SSMS est installée.

Pour plus d’informations, consultez Analyser à l’aide de SQL Server Profiler.

Important

En règle générale, le mode stockage Direct Lake offre des performances de requête rapides, sauf si un secours au mode DirectQuery est nécessaire. Étant donné que le mode DirectQuery peut avoir un impact sur les performances des requêtes, il est important d’analyser le traitement des requêtes pour un modèle sémantique Direct Lake afin d’identifier si, à quelle fréquence et pourquoi des secours se produisent.

Azure Log Analytics

Vous pouvez utiliser Azure Log Analytics pour collecter, analyser et agir sur les données de télémétrie associées à un modèle sémantique Direct Lake. Il s’agit d’un service dans Azure Monitor, que Power BI utilise pour enregistrer les journaux d’activité.

Pour plus d’informations, consultez Utilisation de Azure Log Analytics dans Power BI.

Contenu connexe