Lire en anglais

Partager via

Développer des modèles sémantiques Direct Lake

  • Article

Cet article décrit les rubriques de conception relatives au développement de modèles sémantiques Direct Lake.

Créer le modèle

Vous utilisez le portail Fabric pour créer un modèle sémantique Direct Lake dans un espace de travail. Il s’agit d’un processus simple qui implique de sélectionner les tables d’un seul lakehouse ou entrepôt à ajouter au modèle sémantique.

Vous pouvez ensuite utiliser l’expérience de modélisation web pour développer davantage le modèle sémantique. Cette expérience vous permet de créer des relations entre les tables, de créer des mesures et des groupes de calcul, de marquer des tables de dates et de définir des propriétés pour le modèle et ses objets (comme les formats de colonne). Vous pouvez également configurer le modèle sécurité au niveau des lignes (RLS) en définissant des rôles et des règles, et en ajoutant des membres (comptes d’utilisateur ou groupes de sécurité Microsoft Entra) à ces rôles.

Vous pouvez également poursuivre le développement de votre modèle à l’aide d’un outil compatible XMLA, tel que SQL Server Management Studio (SSMS) (version 19.1 ou ultérieure) ou des outils de communauté open source. Pour plus d’informations, consultez Prise en charge de l’écriture de modèles avec le point de terminaison XMLA plus loin dans cet article.

Conseil

Vous pouvez apprendre à créer un lakehouse, une table Delta et un modèle sémantique Direct Lake de base en suivant ce tutoriel.

Tables de modèle

Les tables de modèle sont basées sur une table ou une vue du point de terminaison d’analytique SQL. Toutefois, évitez autant que possible d'utiliser des vues. En effet, les requêtes portant sur une table de modèle basée sur une vue reviendront toujours au mode DirectQuery, ce qui peut entraîner une baisse des performances de la requête.

Les tables doivent inclure des colonnes pour le filtrage, le regroupement, le tri et la synthèse, en plus des colonnes qui prennent en charge les relations de modèle. Bien que les colonnes inutiles n’affectent pas les performances des requêtes de modèle sémantique (car elles ne seront pas chargées en mémoire), elles entraînent une plus grande taille de stockage dans OneLake et nécessitent davantage de ressources de calcul pour charger et gérer.

Avertissement

L’utilisation de colonnes qui appliquent le masquage dynamique des données (DDM) dans les modèles sémantiques Direct Lake n’est pas prise en charge.

Pour savoir comment sélectionner les tables à inclure dans votre modèle sémantique Direct Lake, consultez Modifier les tables pour les modèles sémantiques Direct Lake.

Pour plus d’informations sur les colonnes à inclure dans vos tables de modèles sémantiques, consultez Comprendre le stockage pour les modèles sémantiques Direct Lake.

Appliquer des règles d’accès aux données

Lorsque vous avez des exigences pour fournir des sous-ensembles de données de modèle à différents utilisateurs, vous pouvez appliquer des règles d’accès aux données. Vous appliquez des règles en configurant la sécurité au niveau de l'objet (OLS) et/ou au niveau des lignes (RLS) dans le point de terminaison d'analyse SQL ou dans le modèle sémantique.

Notes

La question de l'application de règles d'accès aux données est différente, mais elle est liée à la définition des autorisations pour les consommateurs de contenu, les créateurs et les utilisateurs qui géreront le modèle sémantique (ainsi que les éléments Fabric connexes). Pour plus d’informations sur la définition des autorisations, consultez Gérer les modèles sémantiques Direct Lake.

Sécurité au niveau de l’objet (OLS)

L’OLS consiste à restreindre l’accès à la découverte et à la requête d’objets ou de colonnes. Par exemple, vous pouvez utiliser OLS pour limiter les utilisateurs qui peuvent accéder à la colonne Salary à partir de la table Employee.

Pour un point de terminaison d’analyse SQL, vous pouvez configurer OLS pour contrôler l’accès aux objets du point de terminaison, tels que les tables ou les vues, et la sécurité au niveau des colonnes (CLS) pour contrôler l’accès aux colonnes des tables du point de terminaison.

Pour un modèle sémantique, vous pouvez configurer OLS pour contrôler l’accès aux tables ou colonnes de modèle. Vous devez utiliser des outils de communauté open source comme l’éditeur tabulaire pour configurer OLS.

Sécurité au niveau des lignes (RLS)

RLS implique de restreindre l’accès aux sous-ensembles de données dans les tables. Par exemple, vous pouvez utiliser RLS pour vous assurer que les vendeurs peuvent uniquement accéder aux données de vente pour les clients de leur région de vente.

Pour un point de terminaison d’analytique SQL, vous pouvez configurer SNL pour contrôler l’accès aux lignes d’une table de point de terminaison.

Important

Lorsqu’une requête utilise une table qui dispose de SNL dans le point de terminaison d’analytique SQL, elle revient au mode DirectQuery. Les performances des requêtes peuvent être plus lentes.

Pour un modèle sémantique, vous pouvez configurer SNL pour contrôler l’accès aux lignes dans les tables de modèles. La fonctionnalité RLS peut être configurée dans l’expérience de modélisation web ou à l’aide d’un outil tiers.

Évaluation des requêtes

La raison de développer des modèles sémantiques Direct Lake consiste à obtenir des requêtes hautes performances sur de grands volumes de données dans OneLake. Par conséquent, vous devez vous efforcer de concevoir une solution qui maximise les opportunités de requêtes en mémoire.

Les étapes suivantes indiquent comment les requêtes sont évaluées (et si elles échouent). Les avantages du mode de stockage Direct Lake ne sont possibles que lorsque la cinquième étape est obtenue.

  1. Si la requête contient une table ou une colonne restreinte par OLS de modèle sémantique, un résultat d’erreur est retourné (le visuel de rapport ne sera pas rendu).
  2. Si la requête contient une colonne restreinte par le CLS du point de terminaison SQL Analytics (ou si la table est refusée), un message d'erreur est renvoyé (le visuel du rapport échouera à s'afficher).
    1. Si la connexion cloud utilise l’authentification unique (par défaut), CLS est déterminé par le niveau d’accès du consommateur de rapports.
    2. Si la connexion cloud utilise une identité fixe, CLS est déterminé par le niveau d’accès de l’identité fixe.
  3. Si la requête contient une table dans le point de terminaison d’analyse SQL qui applique RLS ou une vue est utilisée, la requête revient au mode DirectQuery.
    1. Si la connexion cloud utilise l’authentification unique (par défaut), la RLS est déterminée par le niveau d’accès du consommateur de rapports.
    2. Si la connexion cloud utilise une identité fixe, la RLS est déterminée par le niveau d’accès de l’identité fixe.
  4. Si la requête dépasse les garde-fous de la capacité, elle revient en mode DirectQuery.
  5. Sinon, la requête est satisfaite à partir du cache en mémoire. Les données de colonne sont chargées en mémoire à mesure qu’elles sont nécessaires.

Autorisations d’élément source

Le compte utilisé pour accéder aux données est l’un des éléments suivants.

  • Si la connexion cloud utilise l’authentification unique (par défaut), il s’agit du consommateur de rapports.
  • Si la connexion cloud utilise une identité fixe, il s’agit de l’identité fixe.

Le compte doit disposer au moins d’autorisations Read et ReadData sur l’élément source (lakehouse ou entrepôt). Les autorisations d’élément peuvent être héritées des rôles d’espace de travail ou affectées explicitement pour l’élément, comme décrit dans cet article.

En supposant que cette exigence est remplie, Fabric accorde l’accès nécessaire 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) et les règles d’accès aux données peuvent être appliquées.

Options de règle d’accès aux données

Vous pouvez configurer des règles d’accès aux données dans :

  • Modèle sémantique uniquement.
  • Le point de terminaison analytique SQL uniquement.
  • Dans le modèle sémantique et le point de terminaison d’analytique SQL.

Règles dans le modèle sémantique

Si vous devez appliquer des règles d’accès aux données, vous devez le faire dans le modèle sémantique chaque fois qu’il est viable. Cela est dû au fait que les RLS appliquées par le modèle sémantique sont obtenues en filtrant le cache en mémoire des données pour obtenir des requêtes hautes performances.

Il s’agit également d’une approche appropriée lorsque les consommateurs de rapports n’ont pas l’autorisation d’interroger le lakehouse ou l’entrepôt.

Dans les deux cas, il est fortement recommandé que la connexion cloud utilise une identité fixe au lieu de l’authentification unique. L’authentification unique implique que les utilisateurs finaux puissent accéder directement au point de terminaison d’analyse SQL et peuvent donc contourner les règles de sécurité dans le modèle sémantique.

Important

Les autorisations d’élément de modèle sémantique peuvent être définies explicitement via des applications Power BI ou acquises implicitement via des rôles d’espace de travail.

Il est important de noter que les règles d’accès aux données du modèle sémantique ne sont pas appliquées pour les utilisateurs qui disposent d’une autorisation d’écriture sur le modèle sémantique. À l’inverse, les règles d’accès aux données s’appliquent aux utilisateurs affectés au rôle d’espace de travail Visionneuse. Toutefois, les utilisateurs affectés au rôle Administrateur, au rôle Membre, ou au rôle Contributeur ont implicitement l'autorisation Écrire sur le modèle sémantique et donc les règles d’accès aux données ne sont pas appliquées. Pour plus d’informations, consultez Rôles dans les espaces de travail.

Règles dans le point de terminaison d’analytique SQL

Il convient d’appliquer les règles d’accès aux données dans le point de terminaison d’analytique SQL lorsque la connexion cloud de modèle sémantique utilise l’authentification unique (SSO). Cela est dû au fait que l’identité de l’utilisateur est déléguée pour interroger le point de terminaison d’analyse SQL, ce qui garantit que les requêtes retournent uniquement les données auxquelles l’utilisateur est autorisé à accéder. Il est également approprié d’appliquer des règles d’accès aux données à ce niveau lorsque les utilisateurs interrogent directement le point de terminaison d’analytique SQL pour d’autres charges de travail (par exemple, pour créer un rapport paginé Power BI ou exporter des données).

Toutefois, une requête de modèle sémantique revient au mode DirectQuery lorsqu’elle inclut une table qui applique la RLS au niveau du point de terminaison d'analyse SQL. Par conséquent, le modèle sémantique peut ne jamais mettre en cache les données en mémoire pour obtenir des requêtes hautes performances.

Règles aux deux niveaux

Les règles d’accès aux données peuvent être appliquées aux deux couches. Toutefois, cette approche implique une complexité et une surcharge de gestion supplémentaires. Dans ce cas, il est fortement recommandé que la connexion cloud utilise une identité fixe au lieu de l’authentification unique.

Comparaison des options de règle d’accès aux données

Le tableau suivant compare les options de configuration de l’accès aux données.

Appliquer des règles d’accès aux données Commentaire
Modèle sémantique uniquement Utilisez cette option lorsque les utilisateurs ne disposent pas des autorisations d’élément pour interroger le lakehouse ou l’entrepôt. Configurez la connexion cloud pour utiliser une identité fixe. Des performances de requête élevées peuvent être obtenues à partir du cache en mémoire.
Point de terminaison d’analytique SQL uniquement Utilisez cette option lorsque les utilisateurs doivent accéder aux données à partir de l’entrepôt ou du modèle sémantique et avec des règles d’accès aux données cohérentes. Vérifiez que l’authentification unique est activée pour la connexion cloud. Les performances des requêtes peuvent être lentes.
Lakehouse ou entrepôt et modèle sémantique Cette option implique une surcharge de gestion supplémentaire. Configurez la connexion cloud pour utiliser une identité fixe.

Voici les pratiques recommandées relatives à l’application des règles d’accès aux données :

  • Si différents utilisateurs doivent être limités à des sous-ensembles de données, il convient, dans la mesure du possible, d’appliquer uniquement SNL à la couche du modèle sémantique. De cette façon, les utilisateurs bénéficieront de requêtes en mémoire hautes performances. Dans ce cas, il est fortement recommandé que la connexion cloud utilise une identité fixe au lieu de l’authentification unique.
  • Si possible, évitez d’appliquer OLS et CLS à l’une ou l’autre couche, car cela entraîne des erreurs dans les visuels de rapport. Les erreurs peuvent entraîner 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).

Prise en charge de l’écriture de modèle avec le point de terminaison XMLA

Les modèles sémantiques Direct Lake prennent en charge les opérations d’écriture avec le point de terminaison XMLA à l’aide d’outils tels que SSMS (19.1 ou version ultérieure) et des outils de communauté open source.

Conseil

Pour plus d’informations sur l’utilisation d’outils tiers pour développer, gérer ou optimiser des modèles sémantiques, consultez les scénario de gestion avancée des modèles de données scénario d’utilisation.

Avant de pouvoir effectuer des opérations d'écriture, l'option de lecture-écriture XMLA doit être activée pour la capacité. Pour plus d’informations, consultez Activer l’écriture en lecture-écriture XMLA.

Opérations d’écriture de modèle avec la prise en charge du point de terminaison XMLA :

  • Personnalisation, fusion, script, débogage et test des métadonnées du modèle Direct Lake.
  • Contrôle de code source et de version, intégration continue et déploiement continu (CI/CD) avec Azure DevOps et GitHub. Pour plus d’informations, consultez gestion du cycle de vie du contenu.
  • Tâches d’automatisation telles que l’actualisation du modèle sémantique et l’application de modifications aux modèles sémantiques Direct Lake à l’aide de PowerShell et des API REST.

Lorsque vous modifiez un modèle sémantique à l’aide de XMLA, vous devez mettre à jour les ChangedProperties et PBI_RemovedChildren collection pour l’objet modifié afin d’inclure les propriétés modifiées ou supprimées. Si vous n’effectuez pas cette mise à jour, les outils de modélisation Power BI peuvent remplacer les modifications à la prochaine synchronisation du schéma avec Lakehouse.

En savoir plus sur les balises de lignage des objets des modèles sémantiques dans l'article des balises de lignage pour les modèles sémantiques Power BI.

Important

Les tables Direct Lake créées à l’aide d’applications XMLA seront initialement dans un état non traité jusqu’à ce que l’application envoie une commande d’actualisation. Les requêtes qui impliquent des tables non traitées reviennent toujours au mode DirectQuery. Par conséquent, lorsque vous créez un modèle sémantique, veillez à actualiser le modèle pour traiter ses tables.

Pour plus d’informations, consultez Connectivité de modèle sémantique avec le point de terminaison XMLA.

Métadonnées du modèle Direct Lake

Lorsque vous vous connectez à un modèle sémantique Direct Lake avec le point de terminaison XMLA, les métadonnées ressemblent à celles d’un autre modèle. Toutefois, les modèles Direct Lake présentent les différences suivantes :

  • La propriété compatibilityLevel de l’objet de base de données est 1604 (ou version ultérieure).
  • La propriété mode des partitions Direct Lake est définie sur directLake.
  • Les partitions Direct Lake utilisent des expressions partagées pour définir des sources de données. L’expression pointe vers le point de terminaison d’analytique SQL du lakehouse ou de l’entrepôt. Direct Lake utilise le point de terminaison analytique SQL pour découvrir les informations relatives au schéma et à la sécurité. Toutefois, elle charge les données directement à partir de OneLake (à moins qu’elle ne revienne au mode DirectQuery pour une raison quelconque).

Tâches postérieures à la publication

Après avoir publié un modèle sémantique Direct Lake, vous devez effectuer certaines tâches d’installation. Pour plus d’informations, consultez Gérer les modèles sémantiques Direct Lake.

Fonctionnalités non prises en charge

Les fonctionnalités de modèle suivantes ne sont pas prises en charge par les modèles sémantiques Direct Lake :

  • Tables calculées référençant des tables ou des colonnes en mode de stockage Direct Lake
  • Colonnes calculées référençant des tables ou des colonnes en mode de stockage Direct Lake
  • Tables hybrides
  • Agrégations définies par l’utilisateur
  • Modèles composites, en ce sens que vous ne pouvez pas combiner des tables en mode de stockage Direct Lake avec des tables en mode de stockage DirectQuery ou double dans le même modèle. Toutefois, vous pouvez utiliser Power BI Desktop pour créer une connexion dynamique à un modèle sémantique Direct Lake, puis l’étendre avec de nouvelles mesures, et à partir de là, vous pouvez cliquer sur l’option pour apporter des modifications à ce modèle pour ajouter de nouvelles tables (à l’aide de l’importation, de DirectQuery ou du mode de stockage double). Cette action crée une connexion DirectQuery au modèle sémantique en mode Direct Lake, de sorte que les tables s’affichent en mode de stockage DirectQuery, mais ce mode de stockage n’indique pas de secours vers DirectQuery. Seule la connexion entre ce nouveau modèle et le modèle Direct Lake est DirectQuery et les requêtes utilisent toujours Direct Lake pour obtenir des données à partir de OneLake. Pour plus d’informations, consultez Créer un modèle composite sur un modèle sémantique.
  • Colonnes basées sur des colonnes de point de terminaison d’analytique SQL qui appliquent le masquage des données dynamiques.

Contenu connexe