Partager via

Vue d’ensemble de Direct Lake

Direct Lake est une option de mode de stockage pour les tables d’un modèle sémantique Power BI stocké dans un espace de travail Microsoft Fabric. Il est optimisé pour de grands volumes de données qui peuvent être rapidement chargés en mémoire à partir de tables Delta stockées dans OneLake , le magasin unique pour toutes les données d’analyse. Une fois chargé en mémoire, le modèle sémantique active une analyse interactive hautes performances.

Diagramme montre un modèle sémantique Direct Lake et comment il se connecte aux tables Delta dans OneLake, comme décrit dans les paragraphes précédents.

Direct Lake est idéal pour les modèles sémantiques qui se connectent à de grands entrepôts, entrepôts et autres sources avec des tables Delta, en particulier lorsque la réplication du volume de données entier dans un modèle d’importation est difficile ou impossible. Les requêtes Direct Lake sont, comme le mode Importation, traitées par le moteur de requête VertiPaq, tandis que DirectQuery fédère les requêtes vers la source de données sous-jacente. Cela signifie que les requêtes Direct Lake, comme le mode d’importation, surpassent normalement DirectQuery.

Toutefois, un lac direct diffère d’un mode Importation d’une manière importante : une opération d’actualisation pour un modèle sémantique Direct Lake est conceptuellement différente d’une opération d’actualisation pour un modèle sémantique d’importation. Le mode d’importation réplique les données et crée une copie en cache complète des données pour le modèle sémantique, tandis qu’une actualisation Direct Lake copie uniquement les métadonnées ( appelées trames, décrites plus loin dans cet article), ce qui peut prendre quelques secondes. L’actualisation de Direct Lake est une opération à faible coût qui analyse les métadonnées de la dernière version des tables Delta et est mise à jour pour référencer les derniers fichiers dans OneLake. En revanche, pour une Importation, une actualisation produit une copie des données, ce qui peut prendre beaucoup de temps et consommer des ressources significatives de source de données et de capacité (mémoire et processeur). Direct Lake déplace la préparation des données vers OneLake et utilise ainsi l’étendue complète des technologies Fabric pour la préparation des données, notamment les travaux Spark, les instructions DML T-SQL, les flux de données, les pipelines, etc.

Le mode stockage Direct Lake offre les avantages clés suivants :

  • Comme pour le mode Importation, les requêtes Direct Lake sont traitées par le moteur VertiPaq et offrent ainsi des performances de requête comparables au mode Importation sans la surcharge de gestion des cycles d’actualisation des données pour charger l’intégralité du volume de données.
  • Utilise les investissements existants dans Fabric en s'intégrant parfaitement à de vastes systèmes de lakehouses, entrepôts et autres sources Fabric avec des tables Delta. Par exemple, Direct Lake est un choix idéal pour la couche d'analyse or dans l’architecture du lac de médaillon.
  • Optimise le retour sur investissement (ROI), car les volumes de données analysés peuvent dépasser les limites de mémoire maximales de la capacité, car seules les données nécessaires pour répondre à une requête sont chargées en mémoire.
  • Réduit les latences de données en synchronisant rapidement et automatiquement un modèle sémantique avec ses sources, rendant les nouvelles données disponibles pour les utilisateurs professionnels sans planifier d’actualisation.

Quand devez-vous utiliser le mode de stockage Direct Lake ?

Le cas d’usage principal pour le mode de stockage Direct Lake est généralement destiné aux projets d’analytique pilotés par l’informatique qui utilisent des architectures centrées sur le lac. Dans de tels scénarios, vous avez ou vous attendez à accumuler de grands volumes de données dans OneLake. Le chargement rapide de ces données en mémoire, les opérations d’actualisation fréquentes et rapides, l’utilisation efficace des ressources de capacité et les performances des requêtes rapides sont toutes importantes pour ce cas d’usage.

Remarque

Les modèles sémantiques d’importation et DirectQuery sont toujours pertinents dans Fabric et constituent le bon choix de modèle sémantique pour certains scénarios. Par exemple, le mode d’importation de stockage fonctionne souvent bien pour un analyste libre-service qui a besoin de la liberté et de l’agilité pour agir rapidement, et sans dépendance sur l’informatique pour ajouter de nouveaux éléments de données.

En outre, l’intégration de OneLake écrit automatiquement des données pour les tables en mode Importation de stockage dans les tables Delta dans OneLake sans impliquer d’effort de migration, ce qui vous permet de réaliser de nombreux avantages de Fabric mis à la disposition des utilisateurs de modèle sémantique, tels que l’intégration avec lakehouses par le biais de raccourcis, de requêtes SQL, de notebooks, etc. Nous vous recommandons cette option comme moyen rapide de récolter les avantages de Fabric sans nécessairement ou immédiatement reconcevoir votre entrepôt de données existant et/ou système d’analyse.

Direct Lake dépend de la préparation des données effectuée dans le lac de données. La préparation des données peut être effectuée à l’aide de différents outils, tels que les travaux Spark pour les lakehouses Fabric, les instructions DML T-SQL pour les entrepôts Fabric, les flux de données, les pipelines et d’autres, ce qui permet de s’assurer que la logique de préparation des données est effectuée en amont dans l’architecture pour optimiser la réutilisation. Toutefois, si l’auteur du modèle sémantique n’a pas la possibilité de modifier l’élément source, par exemple si un analyste libre-service n’a pas d’autorisations d’écriture sur un lakehouse géré par l’informatique, l’augmentation du modèle avec les tables du mode de stockage d’importation peut être un bon choix, car le mode Importation prend en charge la préparation des données à l’aide de Power Query, qui est défini dans le cadre du modèle sémantique.

Veillez à prendre en compte votre licence de capacité Fabric actuelle et les garde-fous de capacité Fabric lorsque vous envisagez le mode de stockage Direct Lake. En outre, prenez en compte les considérations et limitations , qui sont décrites plus loin dans cet article.

Conseil

Nous vous recommandons de produire un prototype (ou preuve de concept) pour déterminer si un modèle sémantique Direct Lake est la bonne solution et pour atténuer les risques.

Concepts clés et terminologie

Cet article part du principe que vous connaissez les concepts suivants :

  • Les utilisateurs interagissent avec des visuels dans les rapports Power BI, qui génèrent des requêtes DAX sur le modèle sémantique.
  • Mode de stockage : le modèle sémantique traite les requêtes DAX différemment selon le mode de stockage utilisé. Par exemple:
    • Les modes d’importation et de stockage Direct Lake utilisent le moteur VertiPaq pour traiter les requêtes DAX et retourner les résultats au rapport Power BI et à l’utilisateur.
    • DirectQuery, d’autre part, traduit les requêtes DAX en syntaxe de requête de la source de données (généralement une forme de SQL) et les fédère vers la base de données sous-jacente. Les processeurs de requêtes de base de données source ne sont souvent pas destinés aux requêtes de type BI, agrégées et entraînent donc des performances plus lentes et une interactivité utilisateur réduite par rapport aux modes Import et Direct Lake.

Le mode de stockage est une propriété d’une table dans le modèle sémantique. Lorsqu’un modèle sémantique inclut des tables avec différents modes de stockage, il est appelé modèle composite. Pour plus d’informations sur les modes de stockage, consultez les modes de modèle sémantique dans le service Power BI.

  • Le mode Direct Lake peut utiliser deux méthodes d’accès différentes :

    • Direct Lake sur OneLake ne dépend pas des points de terminaison SQL et peut utiliser des données à partir de n’importe quelle source de données Fabric avec des tables Delta. Direct Lake sur OneLake ne revient pas en mode DirectQuery.

    Remarque

    Direct Lake sur OneLake est actuellement en aperçu public.

    • Direct Lake sur les points de terminaison SQL utilise les points de terminaison SQL d’un lakehouse ou d’un entrepôt Fabric pour la découverte des tables Delta et les vérifications d’autorisation. Direct Lake sur les points de terminaison SQL peut revenir au mode DirectQuery lorsqu’il ne peut pas charger les données directement à partir d’une table Delta, par exemple lorsque la source de données est une vue SQL ou lorsque l’entrepôt utilise la sécurité au niveau des lignes (RLS). Direct Lake sur les points de terminaison SQL est généralement disponible et entièrement pris en charge en production.

Comparaison des modes de stockage

Le tableau suivant compare le mode de stockage Direct Lake aux modes d’importation et de stockage DirectQuery.

Capacité Direct Lake sur OneLake Direct Lake sur les points de terminaison SQL Importer Requête Directe
Licence Abonnement à la capacité Fabric (SKU) uniquement Abonnement à la capacité Fabric (SKU) uniquement Toute licence Fabric ou Power BI (y compris les licences Gratuites Microsoft Fabric) Toute licence Fabric ou Power BI (y compris les licences Gratuites Microsoft Fabric)
Source de données Tables de n’importe quelle source de données Fabric sauvegardée par des tables Delta Seules les tables (ou vues) de lakehouse ou d’entrepôt N’importe quel connecteur Tout connecteur prenant en charge le mode DirectQuery
Se connecter aux vues de point de terminaison d’analytique SQL Non Oui, mais revient automatiquement au mode DirectQuery Oui Oui
Modèles composites Non 1 Non 1 Oui, il peut être combiné avec des tables en mode de stockage DirectQuery ou double Oui, il peut être combiné avec des tables en mode de stockage Importation ou double
Authentification unique (SSO) Oui Oui Sans objet Oui
Tables calculées Oui, mais les calculs ne peuvent pas faire référence aux colonnes de tables en mode Direct Lake. Non, sauf les groupes de calcul , les paramètres d'analyse de simulation et les paramètres de champ , qui créent implicitement des tables calculées. Oui Non : les tables calculées utilisent le mode Importation de stockage même lorsqu’elles font référence à d’autres tables en mode DirectQuery
Colonnes calculées Oui, mais les calculs ne peuvent pas faire référence aux colonnes de tables en mode Direct Lake. Non Oui Oui
Tables hybrides Non Non Oui Oui
Partitions de tables de modèles Non. Toutefois, le partitionnement peut être effectué au niveau de la table Delta Non. Toutefois, le partitionnement peut être effectué au niveau de la table Delta Oui, soit automatiquement créé par actualisation incrémentielle, soit créé manuellement à l’aide du point de terminaison XMLA Non
Agrégations définies par l’utilisateur Non Non Oui : importer des tables d’agrégation sur des tables DirectQuery sont prises en charge Oui
Sécurité au niveau objet ou sécurité au niveau des colonnes du point de terminaison d’analytique SQL Non Oui , mais peut générer des erreurs lorsque l’autorisation est refusée Oui, mais il faut dupliquer les autorisations en utilisant la sécurité au niveau de l'objet du modèle sémantique. Oui , mais les requêtes peuvent générer des erreurs lorsque l’autorisation est refusée
Sécurité au niveau des lignes (RLS) du point de terminaison d’analytique SQL Non Oui, mais les requêtes reviennent au mode DirectQuery. Oui , mais doit dupliquer les autorisations avec le modèle sémantique RLS Oui
Sécurité au niveau des lignes du modèle sémantique (RLS) Oui, mais il est fortement recommandé d’utiliser une connexion au cloud avec l'identité fixe . Oui, mais il est fortement recommandé d’utiliser une connexion au cloud avec l'identité fixe . Oui Oui
Sécurité au niveau objet du modèle sémantique (OLS) Oui Oui Oui Oui
Volumes de données volumineux sans exigence d’actualisation Oui Oui Non Oui
Réduire la latence des données Oui : lorsque les mises à jour automatiques sont activées ou le recadrage par programmation Oui : lorsque les mises à jour automatiques sont activées ou le recadrage par programmation Non Oui
Power BI Intégré Oui 2 Oui 2 Oui Oui

1 Lorsque vous utilisez Direct Lake sur des points de terminaison SQL, vous ne pouvez pas combiner des tables en mode stockage Direct Lake avec des tables en mode DirectQuery ou en mode de stockage double dans le même modèle sémantique. Toutefois, vous pouvez utiliser Power BI Desktop pour créer un modèle composite sur un modèle sémantique Direct Lake, puis l’étendre avec de nouvelles tables (à l’aide du mode Importation, DirectQuery ou Double stockage) ou des calculs. Pour plus d’informations, consultez Créer un modèle composite sur un modèle sémantique.

2 nécessite un jeton d'intégration V2. Si vous utilisez un principal de service, vous devez utiliser une connexion cloud avec une identité fixe .

Fonctionnement de Direct Lake

En règle générale, les requêtes envoyées à un modèle sémantique Direct Lake sont gérées à partir d’un cache en mémoire des colonnes sources à partir de tables Delta. Le stockage sous-jacent d’une table Delta est un ou plusieurs fichiers Parquet dans OneLake. Les fichiers Parquet organisent les données par colonnes plutôt que par lignes. Les modèles sémantiques chargent des colonnes entières des tables Delta en mémoire, car elles sont requises par les requêtes.

Direct Lake sur OneLake n’est pas couplé au point de terminaison SQL, offrant une intégration plus étroite avec des fonctionnalités OneLake telles que la sécurité OneLake et des plans de requête DAX plus efficaces, car, par exemple, la vérification de la sécurité basée sur SQL n’est pas nécessaire. Le mode de secours DirectQuery n'est pas pris en charge par Direct Lake sur OneLake.

Avec Direct Lake sur les points de terminaison SQL, une requête DAX peut utiliser le repli DirectQuery, ce qui implique une transition fluide vers le mode DirectQuery. Le retour à DirectQuery récupère les données directement à partir du point de terminaison d’analyse SQL du lakehouse ou de l’entrepôt. Par exemple, le repli se produit lorsque la sécurité basée sur SQL est détectée dans l'extrémité SQL. Dans ce cas, une opération DirectQuery envoie une requête au point de terminaison d’analytique SQL. Les opérations de retour peuvent entraîner des performances de requête plus lentes.

Les sections suivantes décrivent les concepts ainsi que les fonctionnalités de Direct Lake, notamment le chargement des colonnes, les mises en forme, les mises à jour automatiques et le repli DirectQuery.

Chargement de colonnes (transcodage)

Les modèles sémantiques Direct Lake chargent uniquement les données de OneLake comme et quand les colonnes sont interrogées pour la première fois. Le processus de chargement des données à la demande à partir de OneLake est appelé transcodage.

Lorsque le modèle sémantique reçoit une requête DAX (ou expressions multidimensionnelles mdX), elle détermine d’abord les colonnes nécessaires pour produire un résultat de requête. Toute colonne directement utilisée par la requête est nécessaire, ainsi que les colonnes requises par les relations et les mesures. En règle générale, le nombre de colonnes nécessaires pour produire un résultat de requête est beaucoup plus petit que le nombre de colonnes définies dans le modèle sémantique.

Une fois qu’il comprend les colonnes nécessaires, le modèle sémantique détermine les colonnes qui sont déjà en mémoire. Si les colonnes nécessaires à la requête ne sont pas en mémoire, le modèle sémantique charge toutes les données de ces colonnes à partir de OneLake. Le chargement des données de colonne est généralement une opération rapide, mais elle peut dépendre de facteurs tels que la cardinalité des données stockées dans les colonnes.

Les colonnes chargées en mémoire résident ensuite dans la mémoire. Les requêtes futures qui impliquent uniquement les colonnes résidentes n’ont pas besoin de charger plus de colonnes en mémoire.

Une colonne reste résidente jusqu’à ce qu’elle soit supprimée de la mémoire. Les raisons pour lesquelles les colonnes peuvent être supprimées sont les suivantes :

  • Le modèle ou la table a été actualisée après une mise à jour de la table Delta à partir de la source (voir Encadrement dans la section suivante).
  • Aucune requête n’a utilisé la colonne pendant un certain temps.
  • D’autres raisons de gestion de la mémoire, notamment la sollicitation de la mémoire dans la capacité en raison d’autres opérations simultanées.

Votre choix de SKU Fabric détermine la quantité maximale de mémoire disponible pour chaque modèle sémantique Direct Lake en fonction de la capacité. Pour plus d'informations sur les règles de protection des ressources et les capacités maximales de mémoire, consultez Règles de protection et limitations de la capacité de Fabric plus loin dans cet article.

Cadrage

Le cadre fournit aux propriétaires de modèles un contrôle à un point dans le temps sur les données chargées dans le modèle sémantique. Le cadrage est une opération Direct Lake déclenchée par une actualisation d’un modèle sémantique et, dans la plupart des cas, ne prend que quelques secondes. C’est parce qu’il s’agit d’une opération à faible coût où le modèle sémantique analyse les métadonnées de la dernière version des tables Delta Lake et est mis à jour pour référencer les derniers fichiers Parquet dans OneLake.

Lorsque le cadrage se produit, les segments et dictionnaires de colonnes de table résidents peuvent être supprimés de la mémoire si les données sous-jacentes ont changé et le point dans le temps de l’actualisation devient la nouvelle base de référence pour tous les événements de transcodage futurs. À partir de ce point, les requêtes Direct Lake considèrent uniquement les données dans les tables Delta à partir de l’heure de l’opération de cadrage la plus récente. Pour cette raison, les tables Direct Lake sont interrogées pour retourner des données en fonction de l’état de la table Delta au moment de l’opération de mise en cadre la plus récente. Cette heure ne correspond pas nécessairement à l’état le plus récent des tables Delta.

Le modèle sémantique analyse le journal Delta de chaque table Delta durant le processus de cadrage pour supprimer uniquement les segments de colonnes affectés et recharger les données nouvellement ajoutées lors du transcodage. Une optimisation importante est que les dictionnaires ne seront généralement pas supprimés lorsque le cadrage incrémentiel prend effet et que de nouvelles valeurs sont ajoutées aux dictionnaires existants. Cette approche de cadrage incrémentiel permet de réduire la charge de rechargement et améliore les performances des requêtes. Dans le cas idéal, lorsqu’une table Delta n’a reçu aucune mise à jour, aucun rechargement n’est nécessaire pour les colonnes qui résident déjà dans la mémoire et les requêtes présentent un impact beaucoup moins sur les performances après l’encadrement, car l’encadrement incrémentiel permet essentiellement au modèle sémantique de mettre à jour des parties substantielles des données en mémoire existantes en place.

Le diagramme suivant montre comment fonctionnent les opérations de cadrage de Direct Lake.

Le diagramme montre comment fonctionnent les opérations de cadrage Direct Lake.

Le diagramme illustre les processus et fonctionnalités suivants.

Élément Descriptif
Un modèle sémantique existe dans un espace de travail Fabric.
Les opérations de cadrage ont lieu régulièrement et définissent la base de référence pour tous les événements de transcodage futurs. Les opérations de cadrage peuvent se produire automatiquement, manuellement, selon la planification ou par programmation.
OneLake stocke les métadonnées et les fichiers Parquet, qui sont représentés en tant que tables Delta.
La dernière opération de cadrage inclut des fichiers Parquet liés aux tables Delta, et plus précisément les fichiers Parquet qui ont été ajoutés avant la dernière opération de cadrage.
Une opération de cadrage ultérieure inclut les fichiers Parquet ajoutés après la dernière opération de cadrage.
Les colonnes résidentes dans le modèle sémantique Direct Lake peuvent être supprimées de la mémoire, et le moment de l’actualisation devient la nouvelle base de référence pour tous les événements de transcodage futurs.
Les modifications de données suivantes, représentées par de nouveaux fichiers Parquet, ne sont pas visibles tant que l’opération de trame suivante n’a pas lieu.

Il n’est pas toujours souhaitable d’avoir des données représentant l’état le plus récent d’une table Delta lorsqu’une opération de transcodage a lieu. Considérez que le cadre peut vous aider à fournir des résultats de requête cohérents dans des environnements où les données des tables Delta sont temporaires. Les données peuvent être temporaires pour plusieurs raisons, telles que lorsque des processus d’extraction, de transformation et de chargement longs (ETL) se produisent.

L’actualisation d’un modèle sémantique Direct Lake peut être effectuée manuellement, automatiquement ou par programmation. Pour plus d’informations, consultez Actualiser les modèles sémantiques Direct Lake.

Mises à jour automatiques

Il existe un paramètre sémantique au niveau du modèle pour mettre à jour automatiquement les tables Direct Lake. Elle est activée par défaut. Elle garantit que les modifications de données dans OneLake sont automatiquement reflétées dans le modèle sémantique Direct Lake. Vous devez désactiver les mises à jour automatiques lorsque vous souhaitez contrôler les modifications de données en encadrant, ce qui a été expliqué dans la section précédente. Pour plus d’informations, consultez Gérer les modèles sémantiques Direct Lake.

Conseil

Vous pouvez configurer l’actualisation automatique des pages dans vos rapports Power BI. Il s'agit d'une fonctionnalité qui actualise automatiquement une page de rapport spécifique à condition que le rapport se connecte à un modèle sémantique Direct Lake (ou à d'autres types de modèles sémantiques).

Retour au mode DirectQuery

Lorsque vous utilisez Direct Lake sur des points de terminaison SQL, une requête envoyée à un modèle sémantique Direct Lake peut revenir au mode DirectQuery , auquel cas la table ne fonctionne plus en mode Direct Lake. Il récupère les données directement à partir du point de terminaison d’analytique SQL du lakehouse ou de l’entrepôt. Ces requêtes retournent toujours les données les plus récentes, car elles ne sont pas limitées au moment de la dernière opération de cadrage.

Lorsque le basculement DirectQuery se produit, une requête n’utilise plus le mode Direct Lake. Une requête ne peut pas tirer parti du mode Direct Lake lorsque le modèle sémantique interroge une vue dans le point de terminaison d’analyse SQL ou une table du point de terminaison d’analyse SQL qui applique la sécurité au niveau des lignes (RLS). En outre, une requête ne peut pas tirer parti du mode Direct Lake lorsqu’une table Delta dépasse les garde-fous de la capacité.

Important

Si possible, vous devez toujours concevoir votre solution, ou dimensionner votre capacité, pour éviter le retour à DirectQuery. Cela est dû au fait qu’il peut entraîner des performances de requête plus lentes.

Vous pouvez contrôler le repli de vos modèles sémantiques Direct Lake en définissant leur propriété DirectLakeBehavior. Ce paramètre s’applique uniquement aux points de terminaison SQL sur Direct Lake. Direct Lake sur OneLake ne prend pas en charge le secours DirectQuery. Pour plus d’informations, consultez Définir la propriété de comportement Direct Lake.

Autorisations de sécurité et d’accès aux données

Par défaut, Direct Lake utilise l’authentification unique (SSO), ce qui signifie que l’identité qui interroge le modèle sémantique (souvent un utilisateur de rapport) doit être autorisée à accéder aux données. Vous pouvez également lier un modèle Direct Lake à une connexion cloud partageable (SCC) pour fournir une identité fixe et désactiver l’authentification unique. Dans ce cas, seule l’identité fixe nécessite un accès en lecture aux données de la source.

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 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 dans l’élément de données source et le modèle sémantique. Les autorisations peuvent être affectées directement ou acquises implicitement à l’aide de rôles d’espace de travail dans Microsoft Fabric.

Il est important de savoir que Direct Lake sur OneLake et Direct Lake sur les points de terminaison SQL effectuent des vérifications d’autorisation différemment.

  • Direct Lake sur OneLake nécessite des autorisations Read et ReadAll sur le lakehouse ou warehouse pour accéder aux tables Delta.
  • Direct Lake sur les points de terminaison SQL nécessite des autorisations Read et ReadData sur le lakehouse ou warehouse pour accéder aux données à partir du point de terminaison d’analytique SQL.

Remarque

Direct Lake sur OneLake exige que les utilisateurs aient l’autorisation de lire des tables Delta dans OneLake et pas nécessairement le point de terminaison SQL. Cela applique une conception de sécurité centralisée dans laquelle OneLake est la source unique du contrôle d’accès.

Direct Lake sur les points de terminaison SQL, d’autre part, exige que les utilisateurs aient un accès en lecture au point de terminaison SQL et non pas nécessairement aux tables Delta 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.

Autorisations de modèle sémantique

En plus des autorisations d’élément Fabric, vous devez également 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 build supplémentaire. Les autorisations de modèle sémantique peuvent être affectées directement ou acquises implicitement à l’aide de 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 .

Spécifications relatives aux autorisations

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

Scénario Autorisations requises Commentaires
Les utilisateurs peuvent afficher des rapports Accordez l’autorisation Lecture pour les rapports et l’autorisation Lecture pour le modèle sémantique.

Si le modèle sémantique utilise Direct Lake sur les points de terminaison SQL et que la connexion cloud utilise l’authentification unique, accordez au moins des autorisations Lecture et LectureDonnées pour le lakehouse ou l’entrepôt.

Si le modèle sémantique utilise Direct Lake sur OneLake et que la connexion cloud utilise l’authentification unique, accordez au moins l’autorisation Read et ReadAll pour les tables Delta dans OneLake.		 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 Build pour le modèle sémantique.

Si le modèle sémantique utilise Direct Lake sur les points de terminaison SQL et que la connexion cloud utilise l’authentification unique, accordez au moins des autorisations Lecture et ReadData pour le lakehouse ou l’entrepôt.

Si le modèle sémantique utilise Direct Lake sur OneLake et que la connexion cloud utilise l’authentification unique, accordez au moins l’autorisation Read et ReadAll pour les tables Delta dans OneLake.		 Pour plus d’informations, consultez Stratégie pour les créateurs de contenu.
Les utilisateurs peuvent afficher des rapports, mais ils ne sont pas autorisés à interroger les tables Lakehouse, SQL Analytics ou Delta dans OneLake Accordez l’autorisation Lecture pour les rapports et l’autorisation Lecture pour le modèle sémantique.

N’accordez aucune autorisation aux utilisateurs pour les tables lakehouse, warehouse ou Delta.		 Convient uniquement lorsque le modèle Direct Lake utilise une identité fixe par le biais d’une connexion cloud avec l’authentification unique désactivée.
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.

Besoins en capacité Fabric

Les modèles sémantiques Direct Lake nécessitent une licence de capacité Fabric. En outre, il existe des garde-fous de capacité et des limitations qui s’appliquent à votre abonnement de capacité Fabric (SKU), comme indiqué dans le tableau suivant.

Important

La première colonne du tableau suivant inclut également les abonnements de capacité Power BI Premium (SKU P). Microsoft consolide les options d’achat et met hors service les références SKU Power BI Premium par capacité. Les clients nouveaux et existants devraient envisager d’acheter des abonnements de capacité Fabric (SKU F) à la place.

Pour plus d’informations, consultez la Mise à jour importante à venir dans les licences Power BI Premium et Power BI Premium.

SKU Fabric Fichiers Parquet par table Groupes de lignes par table Lignes par table (millions) Taille maximale du modèle sur disque/OneLake (Go) Mémoire max. (Go) 1
F2 1 000 1 000 300 10 3
F4 1 000 1 000 300 10 3
F8 1 000 1 000 300 10 3
F16 1 000 1 000 300 20 5
F32 1 000 1 000 300 40 10
F64/FT1/P1 5 000 5 000 1,500 Illimité 25
F128/P2 5 000 5 000 3 000 Illimité 50
F256/P3 5 000 5 000 6 000 Illimité 100
F512/P4 10 000 10 000 12,000 Illimité 200
F1024/P5 10 000 10 000 24,000 Illimité 400
F2048 10 000 10 000 24,000 Illimité 400

1 Pour les modèles sémantiques Direct Lake, Max Memory représente la limite supérieure des ressources de mémoire pour la quantité de données pouvant être chargées. Il ne s’agit donc pas d’un garde-fou, car le dépassement n’entraîne pas un retour au mode DirectQuery. Toutefois, cela peut avoir un impact sur les performances si la quantité de données est suffisamment grande pour provoquer une pagination excessive des données du modèle à partir des données OneLake.

Si elle est dépassée, la taille maximale du modèle sur le disque/OneLake amène toutes les requêtes au modèle sémantique à revenir au mode DirectQuery. Tous les autres garde-fous présentés dans la table sont évalués par requête. Il est donc important d’optimiser vos tables Delta et votre modèle sémantique Direct Lake pour éviter d’avoir à effectuer inutilement un scale-up vers une référence SKU Fabric plus élevée.

En outre, unité de capacité et mémoire maximale par limite de requête s’appliquent aux modèles sémantiques Direct Lake. Pour plus d’informations, consultez Capacités et SKU.

Considérations et limitations

Les modèles sémantiques Direct Lake présentent certaines considérations et limitations.

Remarque

Les capacités et fonctionnalités des modèles sémantiques Direct Lake évoluent rapidement. Veillez à consulter régulièrement la liste des considérations et limitations les plus récentes.

Considérations / limitation Direct Lake sur OneLake Direct Lake sur les points de terminaison SQL
Lorsque le point de terminaison d’analyse SQL applique la sécurité au niveau des lignes, les requêtes DAX sont traitées différemment en fonction du type de mode Direct Lake utilisé.

Lorsque Direct Lake sur OneLake est utilisé, les requêtes réussissent et les lignes RLS basées sur SQL ne sont pas appliquées. Direct Lake sur OneLake nécessite que l’utilisateur ait accès aux fichiers dans OneLake, ce qui n’observe pas les lignes RLS basées sur SQL.		 Les requêtes réussissent. Oui, sauf si le basculement est désactivé, dans ce cas, les requêtes échouent.
Si une table du modèle sémantique est basée sur une vue SQL (non matérialisée), les requêtes DAX sont traitées différemment en fonction du type de mode Direct Lake utilisé.

Le service Direct Lake sur les points de terminaison SQL passera à DirectQuery dans ce cas.

Il n'est pas possible de créer une table Direct Lake sur OneLake à partir d'une vue SQL non matérialisée. Vous pouvez plutôt utiliser une vue matérialisée de type lakehouse, car les tables Delta sont créées. Vous pouvez également utiliser un autre mode de stockage tel que Import ou DirectLake pour les tables basées sur des vues SQL non matérialisées.		 Sans objet Oui, sauf si le basculement est désactivé, dans ce cas, les requêtes échouent.
La modélisation composite n’est pas prise en charge pour l’instant, ce qui signifie que les tables de modèle sémantique Direct Lake ne peuvent pas être mélangées à des tables dans d’autres modes de stockage, tels que l’importation, DirectQuery ou Double (à l’exception de cas spéciaux, notamment des groupes de calcul, des paramètres de simulation et des paramètres de champ). Non prise en charge Non prise en charge
Les colonnes calculées et les tables calculées qui référencent des colonnes ou des tables en mode stockage Direct Lake ne sont pas prises en charge. Les groupes de calcul, les paramètres de simulation et les paramètres de champ, qui créent implicitement des tables calculées, et les tables calculées qui ne référencent pas les colonnes ou tables Direct Lake sont pris en charge. Non prise en charge Non prise en charge
Les tables en mode stockage Direct Lake ne prennent pas en charge les types de colonnes de table Delta complexes. Les types sémantiques binaires et GUID ne sont pas pris en charge. Vous devez convertir ces types de données en chaînes ou d’autres types de données pris en charge. Non prise en charge Non prise en charge
Les relations de table nécessitent que les types de données des colonnes associées correspondent. Oui Oui
Les colonnes à côté unique des relations doivent contenir des valeurs uniques. Les requêtes échouent si des valeurs dupliquées sont détectées dans une colonne uni-côté. Oui Oui
Intelligence de date/heure automatique dans Power BI Desktop pour créer des relations à l’aide uniquement de la partie date d’une colonne datetime. Remarque : le marquage de votre propre table de dates en tant que table de dates et la création de relations à l’aide de colonnes de date est pris en charge. Soutenu Non prise en charge
La longueur des valeurs de colonne de chaîne est limitée à 32 764 caractères Unicode. Oui Oui
Les valeurs à virgule flottante non numériques, telles que NaN (pas un nombre), ne sont pas prises en charge. Oui Oui
Publier sur le web à partir de Power BI à l’aide d’un principal de service n’est pris en charge que lors de l’utilisation d’une identité fixe pour le modèle sémantique Direct Lake. Oui Oui
Dans l’expérience de modélisation web , la validation est limitée pour les modèles sémantiques Direct Lake. Les sélections utilisateur sont supposées être correctes et aucune requête n’est émise pour valider la cardinalité ou les sélections de filtre croisé pour les relations, ou pour la colonne de date sélectionnée dans une table de dates marquée. Oui Oui
Dans le portail Fabric, l’onglet Direct Lake dans l’historique des actualisations répertorie les échecs d’actualisation liés à Direct Lake. Les opérations d’actualisation réussies ne sont généralement pas répertoriées, sauf si l’état de l’actualisation change, par exemple en cas d’absence d’exécution précédente, d’échec de l’actualisation qui passe à une réussite, ou de réussite avec avertissement. Oui Oui
Votre référence SKU Fabric détermine la mémoire maximale disponible par modèle sémantique Direct Lake pour la capacité. Lorsque la limite est dépassée, les requêtes vers le modèle sémantique peuvent être plus lentes en raison d’une pagination excessive des données du modèle. Oui Oui
La création d’un modèle sémantique Direct Lake dans un espace de travail situé dans une autre région de l’espace de travail de source de données n’est pas prise en charge. Par exemple, si lakehouse se trouve dans la région USA Centre Ouest, vous pouvez uniquement créer des modèles sémantiques à partir de ce Lakehouse dans la même région. Une solution de contournement consiste à créer un lakehouse dans l’espace de travail de l’autre région et un raccourci vers les tables avant de créer le modèle sémantique. Pour trouver la région dans laquelle vous vous trouvez, consultez rechercher votre région d’accueil Fabric. Oui Oui
L’intégration de rapports nécessite un jeton d’intégration V2. Oui Non prise en charge
Direct Lake ne prend pas en charge les profils de principal de service pour l’authentification. Non prise en charge Oui
Les modèles sémantiques Power BI Direct Lake peuvent être créés et interrogés par les principaux de services, et l’appartenance au rôle Visionneuse avec principaux de services est prise en charge. Cependant, les modèles sémantiques Direct Lake par défaut sur le lac de données ou le dépôt de données ne prennent pas en charge ce scénario. Oui
Les raccourcis d’un lakehouse peuvent être utilisés comme sources de données pour les tables de modèle sémantique. Pas pris en charge pendant la préversion publique Oui

Contenu connexe