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 les grands volumes de données qui peuvent être rapidement chargés en mémoire à partir de tables Delta, qui stockent leurs données dans des fichiers Parquet dans OneLake, le magasin unique pour toutes les données d’analyse. Une fois chargé en mémoire, le modèle sémantique active des requêtes hautes performances. Direct Lake élimine la nécessité lente et coûteuse d’importer des données dans le modèle.

Vous pouvez utiliser le mode de stockage Direct Lake pour vous connecter aux tables ou aux vues d’un lakehouse Fabric ou entrepôt Fabric unique. Ces deux éléments Fabric et les modèles sémantiques Direct Lake nécessitent une licence de capacité Fabric.

D’une certaine manière, un modèle sémantique Direct Lake est similaire à un modèle sémantique Importation. Cela est dû au fait que les données de modèle sont chargées en mémoire par le moteur VertiPaq pour des performances de requête rapides (sauf dans le cas de retour à DirectQuery, qui est expliqué plus loin dans cet article).

Toutefois, un modèle sémantique Direct Lake diffère d’un modèle sémantique Importation d’une manière importante. En effet, 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 Importation. Pour un modèle sémantique Direct Lake, une actualisation implique une opération de cadrage (décrite plus loin dans cet article), qui peut prendre quelques secondes. 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 et est mis à jour pour référencer les derniers fichiers dans OneLake. En revanche, pour un modèle sémantique 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).

Remarque

L’actualisation incrémentielle pour un modèle sémantique Importation peut contribuer à réduire le temps d’actualisation et l’utilisation des ressources de capacité.

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

Le cas d’usage principal d’un mode de stockage Direct Lake est généralement destiné aux projets d’analytique pilotés par l’informatique qui tirent parti des architectures centrées sur le lac. Dans ce scénario, vous avez de grands volumes de données dans OneLake, ou vous vous attendez à en accumuler. 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 tous importants pour ce cas d’usage.

Remarque

Les modèles sémantiques 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 de stockage Importation fonctionne souvent bien pour un analyste libre-service qui a besoin de la liberté et de l’agilité de pouvoir agir rapidement, et sans dépendance sur le service informatique pour ajouter de nouveaux éléments de données.

En outre, l’intégration OneLake écrit automatiquement des données pour les tables en mode de stockage Importation sur des tables Delta dans OneLake sans impliquer d’effort de migration. À l’aide de cette option, vous pouvez tirer parti de nombreux avantages de Fabric qui sont mis à la disposition des utilisateurs de modèles sémantiques Importation, tels que l’intégration à des lakehouses via des raccourcis, des requêtes SQL, des notebooks, etc. Nous vous recommandons de considérer cette option comme un moyen rapide de récolter les avantages de Fabric sans nécessairement ou immédiatement concevoir à nouveau votre entrepôt de données existant et/ou système d’analytique.

Le mode de stockage Direct Lake convient également à la réduction de la latence des données pour rendre les données rapidement accessibles aux utilisateurs de l’entreprise. Si vos tables Delta sont modifiées par intermittence (et en supposant que vous avez déjà effectué la préparation des données dans le lac de données), vous pouvez compter sur les mises à jour automatiques pour recadrer en réponse à ces modifications. Dans ce cas, les requêtes envoyées au modèle sémantique retournent les données les plus récentes. Cette fonctionnalité fonctionne bien en partenariat avec la fonctionnalité d’actualisation automatique des pages des rapports Power BI.

N’oubliez pas que 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 des travaux Spark pour les lakehouses Fabric, des instructions T-SQL DML pour les entrepôts Fabric, des flux de données, des pipelines et autres. Cette approche permet de garantir que la logique de préparation des données s’effectue au plus faible niveau possible de 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, dans le cas d’un analyste libre-service qui n’a peut-être pas d’autorisations d’écriture sur un lakehouse géré par le service informatique, le mode de stockage Importation peut constituer un meilleur choix. Cela est dû au fait qu’il 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, tenez compte des considérations et limitations décrites plus loin dans cet article.

Conseil

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

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 obtenues à partir de tables Delta. Le stockage sous-jacent d’une table Delta comprend 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 de tables Delta en mémoire lorsqu’elles sont nécessitées par les requêtes.

Un modèle sémantique Direct Lake peut également utiliser le retour à DirectQuery, qui implique un basculement transparent 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 retour peut se produire lorsqu’une table Delta contient plus de lignes de données que prises en charge par votre capacité Fabric (décrite plus loin dans cet article). 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.

Le diagramme suivant montre comment Direct Lake fonctionne à l’aide du scénario dans lequel un utilisateur ouvre un rapport Power BI.

Le diagramme décrit les actions utilisateur, processus et fonctionnalités qui suivent.

Élément	Description
	OneLake est un lac de données qui stocke les données analytiques au format Parquet. Ce format de fichier est optimisé pour stocker des données pour les modèles sémantiques Direct Lake.
	Un lakehouse Fabric ou un entrepôt Fabric existe dans un espace de travail sur la capacité Fabric. Le lakehouse dispose d’un point de terminaison d’analytique SQL, qui offre une expérience basée sur SQL pour les requêtes. Les tables (ou vues) fournissent un moyen d’interroger les tables Delta dans OneLake à l’aide de Transact-SQL (T-SQL).
	Un modèle sémantique Direct Lake existe dans un espace de travail Fabric. Il se connecte à des tables ou des vues dans le lakehouse ou l’entrepôt.
	Un utilisateur ouvre un rapport Power BI.
	Le rapport Power BI envoie des requêtes DAX (Data Analysis Expressions) au modèle sémantique Direct Lake.
	Si possible (et nécessaire), le modèle sémantique charge des colonnes en mémoire directement à partir des fichiers Parquet stockés dans OneLake. Les requêtes obtiennent des performances en mémoire, ce qui est très rapide.
	Le modèle sémantique retourne les résultats de la requête.
	Le rapport Power BI affiche les visuels.
	Dans certaines circonstances, par exemple lorsque le modèle sémantique dépasse les garde-fous de la capacité, les requêtes de modèle sémantique retournent automatiquement au mode DirectQuery. Dans ce mode, les requêtes sont envoyées au point de terminaison d’analytique SQL du lakehouse ou de l’entrepôt.
	Les requêtes DirectQuery envoyées au point de terminaison d’analytique SQL à leur tour interrogent les tables Delta dans OneLake. Pour cette raison, les performances des requêtes peuvent être plus lentes que les requêtes en mémoire.

Les sections suivantes décrivent les concepts et fonctionnalités de Direct Lake, notamment le chargement des colonnes, le cadrage, les mises à jour automatiques et le retour au mode DirectQuery.

Chargement de colonnes (transcodage)

Les modèles sémantiques Direct Lake chargent des données de OneLake uniquement quand des 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 MDX, expression multidimensionnelle), il détermine d’abord les colonnes nécessaires pour produire le résultat de la requête. Les colonnes nécessaires incluent toutes les colonnes directement utilisées par la requête, 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 que les colonnes nécessaires sont déterminées, le modèle sémantique vérifie 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 très 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 de colonnes supplémentaires 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é (voir Cadrage dans la section suivante).
• Aucune requête n’a utilisé la colonne depuis 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 référence SKU Fabric détermine la mémoire maximale disponible pour chaque modèle sémantique Direct Lake sur la capacité. Pour plus d’informations sur les garde-fous de ressources et les limites de mémoire maximales, consultez Garde-fous de capacité Fabric et limitations plus loin dans cet article.

Cadrage

Le cadrage 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 qui, dans la plupart des cas, ne prend que quelques secondes. Il s’agit en effet 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 se met à jour pour référencer les fichiers Parquet les plus récents dans OneLake.

Lorsque le cadrage se produit, les colonnes résidentes peuvent être supprimées de la mémoire 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 là, les requêtes Direct Lake considèrent uniquement les données dans les tables Delta à compter 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 cadrage la plus récente. Cette heure ne correspond pas nécessairement à l’état le plus récent des tables Delta.

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

Le diagramme illustre les processus et fonctionnalités suivants.

Élément	Description
	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 point dans le temps 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 cadrage 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 cadrage 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, par exemple lorsque des processus d’extraction, transformation et chargement (ETL) de longue durée 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.

Pour plus d’informations sur le contrôle de version et le cadrage de tables Delta, consultez Présentation du stockage pour les modèles sémantiquesDirect Lake.

Mises à jour automatiques

Il existe un paramètre au niveau du modèle sémantique permettant de mettre à jour automatiquement les 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. Vous devez désactiver les mises à jour automatiques lorsque vous souhaitez contrôler les modifications de données par cadrage, comme 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èle sémantique).

Retour au mode DirectQuery

Une requête envoyée à un modèle sémantique Direct Lake peut revenir au mode DirectQuery. Dans ce cas, 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 point dans le temps de la dernière opération de cadrage.

Une requête retourne toujours au mode DirectQuery lorsque le modèle sémantique interroge une vue dans le point de terminaison d’analytique SQL ou une table du point de terminaison d’analytique SQL qui applique la sécurité au niveau des lignes (RLS).

En outre, une requête peut retourner au mode DirectQuery lorsque le modèle sémantique 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 au mode DirectQuery. Cela est dû au fait qu’il peut entraîner des performances de requêtes plus lentes.

Vous pouvez contrôler le retour de vos modèles sémantiques Direct Lake au mode DirectQuery en définissant sa propriété DirectLakeBehavior. Pour plus d’informations, consultez Définir la propriété de comportement Direct Lake.

Garde-fous de capacité Fabric et limitations

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). Sachez que 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 doivent plutôt envisager l’achat d’abonnements de capacité Fabric (SKU F).

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 (en 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 / 750	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

¹ Pour les modèles sémantiques Direct Lake, la mémoire maximale représente la limite de ressource de mémoire supérieure pour la quantité de données pouvant être paginé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.

En cas de dépassement, la Taille maximale du modèle sur le disque/OneLake entraîne le retour de toutes les requêtes vers le modèle sémantique au mode DirectQuery. Tous les autres garde-fous présentés dans le tableau 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 (ce qui entraîne une augmentation des coûts).

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

Observations et limitations

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

Remarque

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

• Lorsqu’une table de modèle sémantique Direct Lake se connecte à une table dans le point de terminaison d’analytique SQL qui applique la sécurité au niveau des lignes (RLS), les requêtes qui impliquent cette table de modèle retourne toujours au mode DirectQuery. Les performances des requêtes peuvent être plus lentes.
• Lorsqu’une table de modèle sémantique Direct Lake se connecte à une vue dans le point de terminaison d’analytique SQL, les requêtes qui impliquent cette table de modèles retournent toujours au mode DirectQuery. Les performances des requêtes peuvent être plus lentes.
• La modélisation composite n’est pas prise en charge. Cela signifie que les tables de modèle sémantique Direct Lake ne peuvent pas être mélangées avec des tables dans d’autres modes de stockage, tels que le mode Importation, DirectQuery ou Double (à l’exception de cas spéciaux, notamment les groupes de calcul, les paramètres de simulation et les paramètres de champ).
• Les colonnes calculées et les tables calculées qui référencent des colonnes ou des tables en mode de 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.
• Les tables en mode de 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 non plus pris en charge. Vous devez convertir ces types de données en chaînes ou en autres types de données pris en charge.
• Les relations de table nécessitent que les types de données des colonnes associées correspondent.
• Les colonnes du côté un des relations doivent contenir des valeurs uniques. Les requêtes échouent si des valeurs dupliquées sont détectées dans une colonne de côté un.
• L’Intelligence automatique des données/temps dans Power BI Desktop n’est pas prise en charge. Le marquage de votre propre table de dates en tant que table de dates est pris en charge.
• La longueur des valeurs de colonne de chaîne est limitée à 32 764 caractères Unicode.
• La valeur à virgule flottante NAN (n’est pas un nombre) n’est pas prise en charge.
• Les scénarios d’incorporation qui utilisent le scénario d’utilisation Pour votre client ne sont pas pris en charge.
• La publication sur le web à partir de Power BI est prise en charge uniquement lors de l’utilisation d’une identité fixe pour le modèle sémantique Direct Lake.
• 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.
• Sur le portail Fabric, l’onglet Direct Lake de l’historique des actualisations répertorie uniquement les échecs d’actualisation liés à Direct Lake. Les opérations d’actualisation (cadrage) réussies ne sont pas répertoriées.
• 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.
• La création d’un modèle sémantique Direct Lake dans un espace de travail situé dans une région différente de l’espace de travail de source de données n’est pas prise en charge. Par exemple, si le 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.
• Vous pouvez créer et afficher un modèle sémantique Direct Lake personnalisé à l’aide d’une identité de principal de service, mais le modèle sémantique Direct Lake par défaut ne prend pas en charge les principaux de service. Assurez-vous que l’authentification du principal de service est activée pour les API REST Fabric de votre locataire et accordez au principal de service des autorisations de collaborateur ou supérieures sur l’espace de travail de votre modèle sémantique Direct Lake.
• Direct Lake ne prend pas en charge les profils de principal de service pour l’authentification.

Comparaison avec d’autres modes de stockage

Le tableau suivant compare le mode de stockage Direct Lake aux modes de stockage Importation et DirectQuery.

Fonctionnalité	Direct Lake	Importer	DirectQuery
Gestion des licences	Abonnement à la capacité Fabric (SKU) uniquement	N’importe quelle licence Fabric ou Power BI (y compris les licences Gratuites Microsoft Fabric)	N’importe quelle licence Fabric ou Power BI (y compris les licences gratuites Microsoft Fabric)
Source de données	Seules les tables (ou vues) de lakehouse ou d’entrepôt	N’importe quel connecteur	N’importe quel connecteur prenant en charge le mode DirectQuery
Se connecter aux vues de point de terminaison d’analytique SQL	Oui, mais retourne automatiquement au mode DirectQuery	Oui	Oui
Modèles composites	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	Non applicable	Oui
Tables calculées	Non, à l’exception des groupes de calcul, des paramètres de simulation et des paramètres de champ, qui créent implicitement des tables calculées	Oui	Non, les tables calculées utilisent le mode de stockage Importation même lorsqu’elles font référence à d’autres tables en mode DirectQuery
Colonnes calculées	Non	Oui	Oui
Tables hybrides	Non	Oui	Oui
Modéliser les partitions de table	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	Oui	Oui
Sécurité au niveau objet ou sécurité au niveau des colonnes du point de terminaison d’analytique SQL	Oui, mais les requêtes retournent au mode DirectQuery et peuvent générer des erreurs lorsque l’autorisation est refusée	Oui, mais doit dupliquer les autorisations avec la sécurité au niveau 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 du point de terminaison d’analytique SQL	Oui, mais les requêtes retournent au mode DirectQuery	Oui, mais doit dupliquer les autorisations avec la sécurité au niveau des lignes du modèle sémantique	Oui
Sécurité au niveau des lignes du modèle sémantique	Oui, mais il est fortement recommandé d’utiliser une connexion cloud avec identité fixe	Oui	Oui
Sécurité au niveau objet du modèle sémantique	Oui	Oui	Oui
Volumes de données volumineux sans exigence d’actualisation	Oui	Moins adaptée : une plus grande taille de capacité peut être nécessaire pour l’interrogation et l’actualisation	Oui
Réduire la latence des données	Oui, lorsque les mises à jour automatiques sont activées ou le recadrage par programmation. Toutefois, la préparation des données doit d’abord être effectuée en amont	Non	Oui

¹ Vous ne pouvez pas combiner les tables en mode de stockage Direct Lake avec des tables en mode de stockage DirectQuery ou 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 de stockage Importation, DirectQuery ou Double) ou des calculs. Pour plus d’informations, consultez Créer un modèle composite sur un modèle sémantique.

Contenu connexe

• Développer des modèles sémantiques Direct Lake
• Gérer des modèles sémantiques Direct Lake
• Comprendre le stockage pour les modèles sémantiques Direct Lake
• Créer un lakehouse pour Direct Lake
• Analyser le traitement des requêtes pour les modèles sémantiques Direct Lake