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 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 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 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 cadrage en (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 pour 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 utilisent 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 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, 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à préparé les 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 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, si un analyste libre-service n’a pas d’autorisations d’écriture sur un lakehouse géré par l’informatique, le mode d’importation de 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, 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.
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 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, un retour en arrière peut se produire lorsqu'une table Delta contient plus de lignes de données que celles supportées par votre capacité Fabric (décrite ultérieurement 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 d’un utilisateur qui ouvre un rapport Power BI.
Le diagramme illustre les actions, processus et fonctionnalités utilisateur suivants.
É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 pour l'analyse SQL, qui offre une expérience SQL conviviale 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 reviennent 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 celles des requêtes en mémoire. |
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 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 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ésident 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 cadrage la plus récente. Cette heure ne correspond pas nécessairement à l’état le plus récent des tables Delta.
Notez que le modèle sémantique analyse le journal Delta de chaque table Delta pendant l’encadrement pour supprimer uniquement les segments de colonne affectés et recharger les données nouvellement ajoutées pendant le 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 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 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.
Pour plus d’informations sur la gestion de version et le cadricage des tables Delta, consultez Comprendre le 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 à 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
Une requête envoyée à un modèle sémantique Direct Lake peut revenir à 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 moment 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 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 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. 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 SKU par capacité de Power BI Premium. 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 (ce qui entraîne une augmentation des coûts).
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. 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 Import, DirectQuery ou Dual (à l’exception de cas spéciaux, y compris les groupes de calcul , les paramètres de scénarioet 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 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 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.
- 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 uni-côté.
- L'intelligence automatique des données temporelles 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.
- 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.
- 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 dans 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 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.
- 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 Contributeur ou supérieures à l’espace de travail de votre modèle sémantique Direct Lake.
- L’intégration de rapports nécessite un jeton d’intégration V2.
- Direct Lake ne prend pas en charge les profils de principal de service pour l’authentification.
- Les modèles sémantiques Direct Lake personnalisés créés par le principal de service et la visionneuse avec le principal de service sont pris en charge, mais les modèles sémantiques Direct Lake par défaut ne sont pas pris en charge.
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.
Capacité | Lac direct | Importer | DirectQuery |
---|---|---|---|
Licence | 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 | 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 | Oui, mais revient 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 | Sans objet | Oui |
Tables calculées | 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 | Non | Oui | Oui |
Tables hybrides | Non | Oui | Oui |
Partitions de tables de modèles | 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 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 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 | 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 | 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 recadrage par programmation. Toutefois, la préparation des données doit d’abord être effectuée en amont | Non | Oui |
Power BI Embedded | Oui 2 | Oui | Oui |
1 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 .