Direct Lake

Le mode Direct Lake est une capacité de modèle sémantique pour analyser de très importants volumes de données dans Power BI. Direct Lake est basé sur le chargement de fichiers au format Parquet directement à partir d’un lac de données sans avoir à interroger un point de terminaison lakehouse ou warehouse, et sans avoir à importer ou à dupliquer des données dans un modèle Power BI. Direct Lake est un chemin d’accès rapide pour charger les données depuis le lac directement dans le moteur Power BI, prêtes pour l’analyse. Le diagramme suivant présente les modes d’importation classique et DirectQuery comparés au mode Direct Lake.

En mode DirectQuery, le moteur Power BI interroge les données à la source, ce qui peut être lent, mais évite la copie des données comme en mode importation. Toutes les modifications apportées à la source de données sont immédiatement répercutées dans les résultats de la requête.

En revanche, avec le mode importation, les performances peuvent être meilleures, car les données sont mises en cache et optimisées pour les requêtes de rapport DAX et MDX, sans avoir à traduire et passer SQL et d’autres types de requêtes à la source de données. Toutefois, le moteur Power BI doit d’abord copier toutes les nouvelles données dans le modèle pendant l’actualisation. Les modifications à la source ne sont récupérées que lors de la suivante actualisation du modèle.

Le mode Direct Lake élimine l’exigence d’importation en chargeant les données directement à partir de OneLake. Contrairement à DirectQuery, il n’y a pas de traduction à partir de DAX ou de MDX vers d’autres langages de requête, ni d’exécution de requête sur d’autres systèmes de base de données sur des systèmes de base de données différents, ce qui entraîne des performances similaires au mode d’importation. En l’absence de processus d’importation explicite, il est possible de récupérer les modifications apportées à la source de données au fur et à mesure, en combinant les avantages des modes DirectQuery et importation, tout en évitant leurs inconvénients. Le mode Direct Lake peut être le choix idéal pour analyser des modèles très volumineux et des modèles avec de fréquentes mises à jour de la source de données.

Direct Lake prend également en charge la sécurité au niveau des lignes et la sécurité au niveau des objets pour que les utilisateurs ne voient que les données qu’ils sont autorisés à voir.

Prérequis

Direct Lake est uniquement pris en charge sur les références SKU Microsoft Premium (P) et Microsoft Fabric (F).

Important

Pour les nouveaux clients, Direct Lake n’est pris en charge qu’avec les références SKU Microsoft Fabric (F). Les clients existants peuvent continuer à utiliser Direct Lake avec des références SKU Premium (P), mais la transition vers une référence SKU de capacité Fabric est recommandée. Consultez l’annonce relative à la gestion des licences pour plus d’informations sur la gestion des licences Power BI Premium.

Lakehouse

Avant d’utiliser Direct Lake, vous devez approvisionner un lakehouse (ou un entrepôt) avec une ou plusieurs tables Delta dans un espace de travail hébergé sur une capacité Microsoft Fabric prise en charge. Le lakehouse est obligatoire, car fournissant l’emplacement de stockage de vos fichiers au format parquet dans OneLake. Le lakehouse fournit également un point d’accès pour lancer la fonctionnalité de modélisation Web pour créer un modèle Direct Lake.

Pour savoir comment approvisionner un lakehouse, créer une table Delta dans le lakehouse et créer un modèle de base pour le lakehouse, consultez Créer un lakehouse pour Direct Lake.

point de terminaison SQL

Dans le cadre de l’approvisionnement d’un lakehouse, un point de terminaison SQL pour l’interrogation SQL et un modèle par défaut pour la création de rapports sont créés et mis à jour avec toutes les tables ajoutées au lakehouse. Bien que le mode Direct Lake n’interroge pas le point de terminaison SQL lors du chargement des données directement depuis OneLake, il est requis lorsqu’un modèle Direct Lake doit revenir en toute transparence en mode DirectQuery, comme par exemple, lorsque la source de données utilise des fonctionnalités spécifiques comme la sécurité avancée ou des vues qui ne peuvent pas être lues dans Direct Lake. Le mode Direct Lake interroge également le point de terminaison SQL pour obtenir des informations relatives au schéma et à la sécurité.

entrepôt de données

En guise d’alternative à un lakehouse avec un point de terminaison SQL, vous pouvez également approvisionner un warehouse et ajouter des tables à l’aide d’instructions SQL ou de pipelines de données. La procédure d’approvisionnement d’un data warehouse autonome est presque identique à la procédure d’un lakehouse.

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

Les modèles Direct Lake prennent en charge les opérations d’écriture via le point de terminaison XMLA à l’aide d’outils tels que SQL Server Management Studio (19.1 et versions ultérieures) et les dernières versions d’outils décisionnels externes comme Tabular Editor et le studio DAX. Les opérations d’écriture d’un modèle via le point de terminaison XMLA prennent en charge :

• Personnalisation, fusion, scripts, débogage et test de métadonnées d’un modèle Direct Lake.

• Gestion des versions et des sources, intégration et déploiement continus (CI/CD) avec Azure DevOps et GitHub.

• Tâches d’automatisation comme l’actualisation et l’application de modifications aux modèles Direct Lake à l’aide de PowerShell et des API REST.

Notez que les tables Direct Lake créées à l’aide d’applications XMLA seront initialement dans un état non traité jusqu’à ce que l’application émette une commande d’actualisation. Les tables non traitées basculent en mode DirectQuery. Lors de la création d’un modèle sémantique, veillez à actualiser votre modèle sémantique pour traiter vos tables.

Activer l’accès en lecture-écriture XMLA

Avant d’effectuer des opérations d’écriture sur des modèles Direct Lake via le point de terminaison XMLA, la lecture-écriture XMLA doit être activée sur la capacité.

Pour des capacités d’évaluation Fabric, l’utilisateur d’évaluation gratuite dispose des privilèges d’administrateur nécessaires pour activer la lecture-écriture XMLA.

1. Dans le Portail d’administration, sélectionnez Paramètres de capacité.

2. Cliquez sur l’onglet Version d’évaluation.

3. Sélectionnez la capacité avec Version d’évaluation et votre nom d’utilisateur dans le nom de capacité.

4. Développez Charges de travail Power BI, puis dans le paramètre Point de terminaison XMLA, sélectionnez Lecture/écriture.

   

N’oubliez pas que le paramètre du point de terminaison XMLA s’applique à tous les espaces de travail et modèles attribués à la capacité.

Métadonnées du modèle Direct Lake

Lors de la connexion à un modèle autonome Direct Lake via le point de terminaison XMLA, les métadonnées ressemblent à n’importe quel autre modèle. Toutefois, les modèles Direct Lake présentent les différences suivantes :

• La propriété compatibilityLevel de l’objet de base de données est 1604 ou ultérieure.

• La propriété Mode de partitions Direct Lake est définie sur directLake.

• Les partitions Direct Lake utilisent des expressions partagées pour définir des sources de données. L’expression pointe vers le point de terminaison SQL d’un lakehouse ou warehouse. Direct Lake utilise le point de terminaison SQL pour découvrir les informations de schéma et de sécurité, mais charge les données directement à partir des tables Delta (sauf si Direct Lake doit basculer vers le mode DirectQuery pour une raison quelconque).

Voici un exemple de requête XMLA dans SSMS :

Pour en savoir plus sur la prise en charge des outils via le point de terminaison XMLA, consultez Connectivité du modèle sémantique avec le point de terminaison XMLA.

De base

Les modèles sémantiques Power BI en mode Direct Lake lisent des tables Delta directement depuis OneLake. Toutefois, si une requête DAX sur un modèle Direct Lake dépasse les limites de la référence SKU ou utilise des fonctionnalités qui ne prennent pas en charge le mode Direct Lake, comme des vues SQL dans un entrepôt, la requête peut revenir en mode DirectQuery. En mode DirectQuery, les requêtes utilisent SQL pour récupérer les résultats à partir du point de terminaison SQL du lakehouse ou de l’entrepôt, ce qui peut affecter les performances des requêtes. Vous pouvez désactiver la secours en mode DirectQuery si vous souhaitez traiter des requêtes DAX uniquement en mode Direct Lake pur. La désactivation du retour est recommandée si vous n’avez pas besoin de revenir en mode DirectQuery. Cela peut également être utile lors de l’analyse du traitement des requêtes d’un modèle Direct Lake pour identifier si un retour se produit et à quelle fréquence. Pour en savoir plus sur le mode DirectQuery, consultez les Modes de modèle sémantique dans Power BI.

Les garde-fous définissent des limites de ressources en mode Direct Lake au-delà desquelles il est nécessaire de revenir en mode DirectQuery pour traiter les requêtes DAX. Pour plus d’informations sur la façon de déterminer le nombre de fichiers Parquet et de groupes de lignes d’une table Delta, reportez-vous aux Informations de référence sur les propriétés de table Delta.

Pour les modèles sémantiques Direct Lake, Max Memory représente la limite de ressources mémoire supérieure pour la quantité de données pouvant être paginées. En effet, ce n’est pas un garde-fou, car la dépasser n’entraîne pas un retour en mode DirectQuery. Toutefois, elle peut avoir un impact sur les performances si la quantité de données est suffisamment importante pour provoquer une pagination entrante et sortante des données du modèle depuis les données OneLake.

La table suivante répertorie les garde-fous de ressources et la mémoire maximale :

Références SKU Fabric	Fichiers Parquet par table	Groupes de lignes par table	Lignes par table (en millions)	Taille maximale du modèle sur disque/OneLake1 (Go)	Mémoire max. (Go)
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

1 : si elle est dépassée, la taille maximale du modèle sur le disque/Onelake entraîne le basculement de toutes les requêtes sur le modèle en mode DirectQuery, contrairement aux autres garde-fous qui sont évalués par requête.

Selon votre référence SKU Fabric, des limites supplémentaires d’unités de capacité et de mémoire maximale par requête s’appliquent également aux modèles Direct Lake. Pour en savoir plus, consultez Capacités et références SKU.

Comportement de secours

Les modèles Direct Lake incluent la propriété DirectLakeBehavior, disposant de trois options :

Automatique : (valeur par défaut) spécifie que les requêtes reviennent en mode DirectQuery si les données ne peuvent pas être chargées efficacement en mémoire.

DirectLakeOnly : spécifie que toutes les requêtes utilisent uniquement le mode Direct Lake. Le mode Secours vers DirectQuery est désactivé. Si les données ne peuvent pas être chargées en mémoire, une erreur est retournée. Utilisez ce paramètre pour déterminer si les requêtes DAX ne parviennent pas à charger des données en mémoire, forçant une erreur à retourner.

DirectQueryOnly : spécifie que toutes les requêtes utilisent uniquement le mode DirectQuery. Utilisez ce paramètre pour tester les performances de secours.

La propriété DirectLakeBehavior peut être configurée à l’aide du modèle objet tabulaire (TOM) ou du langage TMSL (Tabular Model Scripting Language).

L’exemple suivant spécifie que toutes les requêtes utilisent uniquement le mode Direct Lake :

// Disable fallback to DirectQuery mode.
//
database.Model.DirectLakeBehavior = DirectLakeBehavior.DirectLakeOnly = 1;
database.Model.SaveChanges();

Analyser un traitement de requêtes

Pour déterminer si les requêtes DAX d’un visuel de rapport émises vers la source de données offrent les meilleures performances en utilisant le mode Direct Lake ou en revenant au mode DirectQuery, vous pouvez utiliser l’analyseur de performances dans Power BI Desktop, SQL Server Profiler ou d’autres outils tiers pour analyser les requêtes. Pour en savoir plus, consultez Analyser un traitement de requêtes pour des modèles Direct Lake.

Actualiser

Par défaut, les modifications de données dans OneLake se reflètent automatiquement dans un modèle Direct Lake. Vous pouvez modifier ce comportement en désactivant Maintenir à jour vos données Direct Lake dans les paramètres du modèle.

Il est possible de le désactiver si, par exemple, vous devez autoriser l’achèvement des travaux de préparation des données avant d’exposer de nouvelles données aux consommateurs du modèle. Une fois la fonctionnalité désactivée, vous pouvez appeler l’actualisation manuellement ou en tirant parti des API d’actualisation. L’appel de l’actualisation d’un modèle Direct Lake est une opération à faible coût dans laquelle le modèle analyse les métadonnées de la dernière version de la table Delta Lake qui est mise à jour pour référencer les derniers fichiers de OneLake.

Notez que Power BI peut suspendre les mises à jour automatiques des tables Direct Lake si une erreur non récupérable est rencontrée lors de l’actualisation. Assurez-vous que votre modèle sémantique peut être actualisé avec succès. Power BI reprend automatiquement les mises à jour automatiques lorsqu’une actualisation ultérieure provoquée par l’utilisateur se termine sans erreur.

Sécurité en couche d’accès aux données

Les modèles Direct Lake créés sur les lakehouses et les entrepôts adhèrent au modèle de sécurité en couches qu’ils prennent en charge en effectuant des contrôles d’autorisation via le point de terminaison T-SQL en vue de déterminer si l’identité qui tente d’accéder aux données dispose des autorisations d’accès aux données requises. Par défaut, les modèles Direct Lake utilisent l’authentification unique (SSO), de sorte que les autorisations effectives de l’utilisateur interactif déterminent si l’utilisateur est autorisé à accéder aux données ou s’il est refusé. Si le modèle Direct Lake est configuré pour utiliser une identité fixe, l’autorisation effective de l’identité fixe détermine si les utilisateurs qui interagissent avec le modèle sémantique peuvent accéder aux données. Le point de terminaison T-SQL renvoie la valeur Autorisé ou Refusé au modèle Direct Lake en fonction de la combinaison des autorisations de sécurité OneLake et SQL.

Par exemple, un administrateur d’entrepôt peut octroyer à un utilisateur des autorisations SELECT sur une table afin que l’utilisateur puisse lire à partir de cette table même s’il n’a pas d’autorisations de sécurité OneLake. L’utilisateur a été autorisé au niveau du lakehouse/de l’entrepôt. À l’inverse, un administrateur d’entrepôt peut également refuser (DENY) à un utilisateur un accès en lecture à une table. L’utilisateur ne pourra pas lire à partir de cette table même si l’utilisateur dispose des autorisations de lecture de sécurité OneLake. L’instruction DENY supplante toutes les autorisations de sécurité OneLake ou SQL octroyées. Reportez-vous au tableau suivant pour obtenir les autorisations effectives qu’un utilisateur peut avoir selon les combinaisons d’autorisations de sécurité OneLake et SQL.

Autorisations de sécurité OneLake	Autorisations SQL	Autorisations effectives
Autoriser	Aucun	Autoriser
Aucun	Autoriser	Autoriser
Autoriser	Deny	Deny
Aucun	Deny	Deny

Problèmes connus et limitations

• Par conception, seules les tables du modèle sémantique dérivées des tables d'un Lakehouse ou de l'Entrepôt prennent en charge le mode Direct Lake. Bien que les tables du modèle puissent être dérivées du mode SQL dans l'entrepôt ou le Lakehouse, les requêtes utilisant ces tables reviendront au mode DirectQuery.

• Les tables du modèle sémantique Direct Lake ne peuvent être dérivées que des tables et des vues d'un seul Lakehouse ou entrepôt.

• Les tables Direct Lake ne peuvent actuellement pas être mélangées avec d’autres types de tables, tels que Import, DirectQuery ou Dual, dans le même modèle. Les modèles composites ne sont actuellement pas pris en charge.

• Les relations date/heure ne sont pas prises en charge dans les modèles Direct Lake.

• Les colonnes et tables calculées ne sont pas prises en charge.

• Certains types de données peuvent ne pas être pris en charge, comme les décimales de haute précision et les types d’argent.

• Les tables Direct Lake ne prennent pas en charge les types de colonnes complexes des tables Delta. Les types sémantiques Binary 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 de leurs colonnes clés coïncident. Les colonnes de clé primaire doivent contenir des valeurs uniques. Les requêtes DAX échouent si des valeurs de clé primaire en double sont détectées.

• 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 dans les modèles Direct Lake.

• Les scénarios incorporés qui reposent sur des entités incorporées ne sont pas encore pris en charge.

• La validation est limitée pour les modèles Direct Lake. Les sélections de l’utilisateur sont considérées comme correctes et aucune requête ne validera les sélections de cardinalité et de filtre croisé pour les relations, ou pour la colonne de date sélectionnée dans une table de dates.

• L’onglet Direct Lake de l’historique des actualisations ne répertorie que les échecs d’actualisations liés à Direct Lake. Les actualisations réussies sont actuellement omises.

Bien démarrer

La meilleure façon de commencer à utiliser une solution Direct Lake dans votre organisation consiste à créer un lakehouse, y créer une table Delta, puis créer un modèle sémantique de base pour le lakehouse de votre espace de travail Microsoft Fabric. Pour plus d’informations, consultez Créer un lakehouse pour Direct Lake.

Contenu connexe

• Créer un lakehouse pour Direct Lake
• Analyser le traitement des requêtes pour les modèles sémantiques Direct Lake