Direct Lake et Microsoft Fabric : ce qui change pour un utilisateur Power BI
Microsoft Fabric change la façon de stocker les données, pas la façon de construire un rapport.
Direct Lake est le mode de stockage qui incarne ce changement.
Il supprime l'actualisation complète du modèle, mais il retire aussi des libertés.
Cet article dit ce qui change vraiment, et ce que cela coûte.
Prenons une table Ventes de 120 millions de lignes, posée dans un lakehouse Fabric.
En mode Import, Power BI en fabrique une copie compressée. Supposons 40 minutes d'actualisation chaque nuit.
En mode Direct Lake, aucune copie n'est fabriquée. L'actualisation se réduit à une lecture de métadonnées de quelques secondes.
Le rapport interroge ensuite les mêmes fichiers, en mémoire, à une vitesse comparable au mode Import.
Fabric et Power BI : qui contient quoi
Power BI n'a pas disparu. Il est devenu une charge de travail de Microsoft Fabric.
Fabric est une plateforme de données complète. Elle couvre l'ingestion, le stockage, la transformation et la restitution.
OneLake en est le stockage unique. Toutes les données Fabric y atterrissent au format Delta Parquet.
Ce qui ne change pas dans votre quotidien
Power BI Desktop reste gratuit et se comporte comme avant.
Un modèle en mode Import s'actualise exactement de la même manière.
Le DAX, Power Query et les visuels sont inchangés.
Une licence Pro suffit toujours pour publier et partager un rapport.
La documentation Microsoft est explicite sur ce point. Les tables Import et DirectQuery restent pertinentes dans Fabric.
Ce que Fabric ajoute réellement
Un lakehouse, un entrepôt, des pipelines et des notebooks.
Le mode de stockage Direct Lake, réservé aux capacités Fabric.
Une facturation à la capacité, exprimée en unités de calcul.
OneLake, avec des raccourcis vers des stockages externes.
Un seul de ces éléments touche vraiment votre modélisation. C'est Direct Lake.
Direct Lake, le troisième mode de stockage
Direct Lake n'est pas un connecteur. C'est un mode de stockage, réglé table par table.
Un même modèle peut donc mélanger des tables Direct Lake et des tables Import.
Le point décisif est le moteur. Import et Direct Lake sont traités par VertiPaq, le moteur en mémoire de Power BI.
DirectQuery, lui, traduit chaque requête DAX en SQL. Il l'envoie ensuite à la base source.
Voilà toute l'explication de la performance. Direct Lake ne quitte jamais le moteur en mémoire.
Le chargement à la demande, appelé transcodage
Le modèle ne charge pas tout. Il charge une colonne uniquement quand une requête la demande.
Cette opération s'appelle le transcodage. La colonne devient ensuite résidente en mémoire.
Une colonne résidente est évincée dans trois cas.
Un framing a modifié les données sous-jacentes.
Aucune requête n'a utilisé la colonne depuis un moment.
La capacité subit une pression mémoire liée à d'autres traitements.
Les trois modes côte à côte
Critère | Import | DirectQuery | Direct Lake |
Moteur de requête | VertiPaq | Base source | VertiPaq |
Copie des données | Oui | Non | Non |
Actualisation | Recopie complète | Aucune | Framing des métadonnées |
Fraîcheur | Dernière actualisation | Immédiate | Dernier framing |
Colonnes calculées | Oui | Oui | Non |
Power Query | Oui | Partiel | Non |
Licence | Toute licence | Toute licence | Capacité Fabric |
[[ IMAGE 1 ici - direct_lake_trois_modes.avif ]]
Schéma comparant les trois modes de stockage Power BI. Import copie les données dans le modèle. DirectQuery envoie une requête SQL à la source. Direct Lake lit les tables Delta de OneLake en mémoire.
L'actualisation devient un framing
Un modèle Import recopie les données. Un modèle Direct Lake recopie uniquement des métadonnées.
Cette opération porte un nom : le framing. Microsoft indique qu'elle dure le plus souvent quelques secondes.
Le framing fixe un point dans le temps. Le rapport ne voit que l'état des tables Delta à cet instant.
C'est le piège le plus fréquent en production. Les données sont dans OneLake, mais le rapport ne les affiche pas encore.
[[ IMAGE 2 ici - direct_lake_framing.avif ]]
Frise chronologique montrant deux écritures ETL dans OneLake et deux opérations de framing. Le rapport affiche les données arrêtées au dernier framing réussi, pas la dernière écriture.
Ce que fait un framing, étape par étape
Il lit le journal Delta de chaque table.
Il met à jour les références vers les derniers fichiers Parquet.
Il évince de la mémoire les segments de colonnes modifiés.
Il conserve les dictionnaires existants quand c'est possible.
Ce dernier point s'appelle le framing incrémentiel. Il explique pourquoi un framing dégrade peu les performances.
Les mises à jour automatiques
Un paramètre du modèle actualise automatiquement les tables Direct Lake. Il est activé par défaut.
Désactivez-le si vous voulez maîtriser la fraîcheur vous-même.
Un traitement long en cours peut sinon exposer des données partielles à vos lecteurs.
Attention
Un framing ne recopie aucune donnée.
Il ne remplace donc pas l'actualisation des tables Import présentes dans le même modèle.
Deux Direct Lake, pas un seul
Le nom est unique, la mécanique ne l'est pas.
Il existe Direct Lake sur OneLake et Direct Lake sur SQL. La confusion entre les deux explique la plupart des mauvaises surprises.
Direct Lake sur OneLake
Lit directement les tables Delta.
Plusieurs sources Fabric dans un même modèle.
Aucun repli DirectQuery possible.
Mélange avec des tables Import autorisé.
Direct Lake sur SQL
Passe par le point de terminaison SQL analytique.
Une seule source Fabric par modèle.
Repli DirectQuery possible.
Pas de mélange avec des tables Import.
Microsoft recommande Direct Lake sur OneLake pour tout nouveau modèle sémantique.
Le repli DirectQuery, silencieux par défaut
Avec Direct Lake sur SQL, une requête peut basculer en DirectQuery. Le rapport continue de fonctionner.
Les performances, elles, s'effondrent. Aucune alerte n'est envoyée.
Les causes sont connues et limitées.
Une sécurité au niveau des lignes définie sur le point de terminaison SQL.
Un masquage dynamique des données ou une sécurité au niveau des objets.
Une table basée sur une vue SQL non matérialisée.
Une table qui dépasse les garde-fous de la capacité.
Une table ajoutée par script, puis jamais framée.
Le paramètre DirectLakeBehavior pilote ce comportement. Il n'existe que sur Direct Lake sur SQL.
Valeur | Comportement |
Automatic (défaut) | Repli silencieux vers DirectQuery, le rapport continue de fonctionner |
DirectLakeOnly | La requête échoue, à réserver au développement |
DirectQueryOnly | Force DirectQuery, utile pour mesurer le coût du repli |
Diagnostiquer un repli en une requête
La vue Requête DAX de Power BI Desktop suffit. Une seule ligne donne l'état de chaque table.
EVALUATE TABLETRAITS()La colonne DirectLakeFallbackInfo indique la raison du repli, table par table.
La valeur None signifie que la table reste bien en mode Direct Lake.
Ce que Direct Lake vous retire
Le gain a une contrepartie. Direct Lake supprime plusieurs libertés de modélisation.
Ni colonnes calculées, ni Power Query
Les colonnes calculées ne sont pas prises en charge sur une table Direct Lake.
La règle vaut pour les deux variantes, sur OneLake comme sur SQL.
Power Query n'intervient pas non plus. Aucune transformation ne se fait dans le modèle.
Toute préparation doit être réalisée en amont, dans le lakehouse ou dans l'entrepôt.
Restent disponibles : les groupes de calcul, les paramètres de simulation et les paramètres de champ.
Les tables calculées sont en préversion sur Direct Lake sur OneLake. Elles ne sont pas prises en charge sur SQL.
Les tables hybrides et les agrégations définies par l'utilisateur sont exclues.
Le modèle n'a pas de partitions. Le partitionnement se traite au niveau de la table Delta.
La conséquence est organisationnelle autant que technique. Direct Lake déplace la préparation vers l'ingénierie de données.
Les garde-fous de capacité, découverts trop tard
Chaque SKU Fabric impose des limites. Elles s'évaluent par requête, sauf la taille du modèle.
SKU Fabric | Lignes par table | Taille du modèle | Mémoire maximale |
F2 à F8 | 300 millions | 10 Go | 3 Go |
F16 | 300 millions | 20 Go | 5 Go |
F32 | 300 millions | 40 Go | 10 Go |
F64 | 1,5 milliard | Illimitée | 25 Go |
F128 | 3 milliards | Illimitée | 50 Go |
F256 | 6 milliards | Illimitée | 100 Go |
Une seule table hors limite suffit à faire basculer le modèle entier.
Sur Direct Lake sur OneLake, l'actualisation échoue et le modèle ne répond plus.
Sur Direct Lake sur SQL, les requêtes basculent en DirectQuery si le repli est autorisé.
Les commandes OPTIMIZE et VACUUM sur la table Delta règlent souvent le problème.
Le vrai prix d'entrée : une capacité Fabric
Direct Lake exige une capacité Fabric. Aucune licence Pro ou PPU ne donne accès à ce mode.
Les capacités vont de F2 à F8192. Elles se paient à l'usage ou en réservation annuelle.
La réservation sur un an coûte environ 40 % de moins que le paiement à l'usage.
L'entrée de gamme F2 se situe autour de 260 dollars par mois en paiement à l'usage.
Le seuil F64 reste le point de bascule du modèle économique.
En dessous de F64, chaque lecteur a besoin d'une licence Pro ou PPU.
À partir de F64, une licence gratuite suffit pour consulter un rapport.
Les capacités Power BI Premium P sont en cours de retrait. Microsoft oriente les nouveaux déploiements vers les SKU F.
Les tarifs bougent selon la région et la date. Vérifiez la grille Azure avant tout engagement.
Le détail des offres figure dans notre article sur les prix et licences de Power BI.
Faut-il passer à Direct Lake ?
La réponse dépend du volume, de l'organisation et du budget. Elle ne dépend pas de la mode.
Les cas où la réponse est non
Vos données tiennent en mode Import et l'actualisation passe dans la fenêtre disponible.
Personne, chez vous, ne prépare les données en amont du modèle.
Vous avez besoin de colonnes calculées ou de transformations Power Query.
Vous ne financez pas déjà une capacité Fabric.
Les cas où la réponse est oui
Le volume rend la copie Import impraticable ou impossible.
Vos données arrivent déjà dans OneLake et la fraîcheur compte.
Une capacité Fabric est déjà financée pour d'autres charges.
Votre couche gold est déjà modélisée en étoile dans un lakehouse.
À retenir
Direct Lake n'est pas une mise à jour de Power BI. C'est une décision d'architecture.
Elle se prend au niveau du projet, jamais au niveau d'un rapport.
Microsoft recommande de produire une preuve de concept avant de trancher. Le conseil est sain.
