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, qui stockent leurs données dans des fichiers Parquet dans OneLake , le magasin unique pour toutes les données analytiques. 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 vues d’un seul entrepôt fabric lakehouse ou Fabric. Ces deux éléments fabric et 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 d’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 la secours DirectQuery, qui est expliquée plus loin dans cet article).

Toutefois, un modèle sémantique Direct Lake diffère d’un modèle sémantique d’importation d’une manière importante. Cela est dû au fait qu’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. Pour un modèle sémantique Direct Lake, une actualisation implique une opération de trame (décrite plus loin dans cet article), ce 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 mise à jour pour référencer les derniers fichiers dans OneLake. En revanche, pour un modèle sémantique d’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 d’un modèle sémantique d’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 ou vous attendez à accumuler de grandes quantités 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 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, tels que l’intégration à 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 est également adapté à la réduction de la latence des données pour rendre rapidement les données accessibles aux utilisateurs professionnels. 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 dépendre des mises à jour automatiques pour reframeiser 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 d’autres. Cette approche permet de garantir que la logique de préparation des données est aussi faible que possible 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, 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 Importer le stockage peut être 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 prototype ou 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 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.

Un modèle sémantique Direct Lake peut également utiliser le secours DirectQuery, ce qui implique un basculement transparent vers le mode DirectQuery. Le secours 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, la secours 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 secours peuvent entraîner des performances de requête plus lentes.

Le diagramme suivant montre comment Direct Lake fonctionne à l’aide du scénario d’un utilisateur qui 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 entrepôt Fabric lakehouse ou 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 l’interrogation. 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 revient automatiquement au mode DirectQuery. Dans ce mode, les requêtes sont envoyées au point de terminaison d’analyse 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, l’encadrement, les mises à jour automatiques et le secours 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. 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 qu’il est compris quelles colonnes sont 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 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 plus de colonnes en mémoire.

Une colonne reste résidente jusqu’à ce qu’elle soit supprimée (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 Cadre 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 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 l’image 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 ce stade, les requêtes Direct Lake considèrent uniquement les données dans les tables Delta à partir de l’heure de l’opération de trame 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 point de l’opération de trame la plus récente. Cette heure n’est pas nécessairement l’état le plus récent des tables Delta.

Le diagramme suivant montre comment fonctionnent les opérations de trame 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 trame 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 d’encadrement 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 trame 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 trame.
	Une opération de trame ultérieure inclut les fichiers Parquet ajoutés après la dernière opération de trame.
	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 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.

Pour plus d’informations sur le contrôle de version et l’encadrement de tables Delta, consultez Présentation du stockage pour 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, qui fournit que le rapport se connecte à un modèle sémantique Direct Lake (ou à d’autres types de modèle sémantique).

Secours 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’analyse 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 trame.

Une requête revient toujours 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 peut revenir 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 la secours DirectQuery. Cela est dû au fait qu’il peut entraîner des performances de requête plus lentes.

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

Garde-fous et limitations de capacité de l’infrastructure

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 maximale (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 ressources de mémoire supérieure pour la quantité de données pouvant être paginées. C’est pour cette raison qu’il n’est pas un garde-fou, car le dépassement n’entraîne pas de secours en mode DirectQuery ; Toutefois, elle 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 entraîne la restauration de toutes les requêtes vers le modèle sémantique en 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 (ce qui entraîne une augmentation des coûts).

En outre, l’unité de capacité et la 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 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 et fonctionnalités des modèles sémantiques Direct Lake évoluent. Veillez à consulter régulièrement la liste des considérations et limitations les plus récentes.

• Lorsqu’une table de modèle sémantique Direct Lake se connecte à une table dans le point de terminaison d’analyse SQL qui applique la sécurité au niveau des lignes (RLS), les requêtes qui impliquent cette table de modèle revient 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’analyse SQL, les requêtes qui impliquent cette table de modèles reviennent 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 l’importation, DirectQuery ou Double (à l’exception de cas spéciaux, notamment des groupes de calcul, des paramètres de scénario et des paramètres de champ).
• 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 scénario et les paramètres de champ, qui créent implicitement des tables calculées et des tables calculées qui ne référencent pas les colonnes ou tables Direct Lake sont prises 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 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 un-côté des relations doivent contenir des valeurs uniques. Les requêtes échouent si des valeurs dupliquées sont détectées dans une colonne latérale.
• L’intelligence automatique des données/du 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 (pas un nombre) n’est pas prise en charge.
• Les scénarios d’incorporation qui utilisent le scénario d’utilisation de 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.
• Dans 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 réussies (encadrage) 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 et hors 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 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 à accéder aux tables avant de créer le modèle sémantique. Pour trouver la région dans laquelle vous vous trouvez, consultez votre région d’accueil Fabric.

Comparaison avec d’autres modes de stockage

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

Fonctionnalité	Direct Lake	Importer	DirectQuery
Gestion des licences	Abonnement à la capacité de l’infrastructure (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	Seules les tables lakehouse ou entrepôt (ou vues)	N’importe quel connecteur	Tout connecteur prenant en charge le mode DirectQuery
Se connecter aux vues de point de terminaison SQL Analytics	Oui, mais revient automatiquement au mode DirectQuery	Oui	Oui
Modèles composites	Non 1	Oui : peut être combiné avec des tables en mode de stockage Double ou DirectQuery	Oui : peut être combiné avec des tables en mode Importation ou Double stockage
Authentification unique (SSO)	Oui	Non applicable	Oui
Tables calculées	Non , à l’exception des groupes de calcul, des paramètres de définition et des 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	Non	Oui	Oui
Tables hybrides	Non	Oui	Oui
Partitions de table de modèles	Non : toutefois , le partitionnement peut être effectué au niveau de la table Delta	Oui : soit automatiquement créé par l’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 de l’objet du point de terminaison SQL Analytics ou sécurité au niveau des colonnes	Oui , mais les requêtes revient en 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 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 du point de terminaison SQL Analytics (RLS)	Oui , mais les requêtes revient 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 cloud d’identité fixe	Oui	Oui
Sécurité au niveau objet du modèle sémantique (OLS)	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 interroger et actualiser	Oui
Réduire la latence des données	Oui : lorsque les mises à jour automatiques sont activées ou le reframing programmatique ; 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 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 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.

Contenu connexe

• Développer des modèles sémantiques Direct Lake
• Gérer les 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