Partager via

Comprendre le stockage pour les modèles sémantiques Direct Lake

  • Article

Cet article présente les concepts de stockage Direct Lake. Il décrit les tables Delta et les fichiers Parquet. Il décrit également comment optimiser les tables Delta pour les modèles sémantiques Direct Lake, et comment les conserver pour vous aider à fournir un niveau de performance des requêtes fiable et rapide.

Tables Delta

Les tables delta existent dans OneLake. Elles organisent les données basées sur des fichiers en lignes et colonnes et sont disponibles pour les moteurs de calcul Microsoft Fabric tels que les notebooks, Kusto, et les lakehouse et warehouse. Vous pouvez interroger les tables Delta en utilisant des expressions d’analyse de données (DAX), des expressions multidimensionnelles (MDX), T-SQL (Transact-SQL), Spark SQL et même Python.

Remarque

Delta (ou Delta Lake) est un format de stockage open source. Cela signifie que Fabric peut également interroger des tables Delta créées par d’autres outils et fournisseurs.

Les tables Delta stockent leurs données dans des fichiers Parquet, qui sont généralement stockés dans un lakehouse qu’un modèle sémantique Direct Lake utilise pour charger des données. Toutefois, les fichiers Parquet peuvent également être stockés en externe. Les fichiers Parquet externes peuvent être référencés en utilisant un raccourci OneLake, qui pointe vers un emplacement de stockage spécifique, comme Azure Data Lake Storage (ADLS) Gen2, des comptes de stockage Amazon S3 ou Dataverse. Dans presque tous les cas, les moteurs de calcul accèdent aux fichiers Parquet en interrogeant des tables Delta. Toutefois, en règle générale, les modèles sémantiques Direct Lake chargent les données de colonne directement depuis des fichiers Parquet optimisés dans OneLake en utilisant un processus appelé transcodage.

Contrôle de version des données

Les tables Delta comprennent un ou plusieurs fichiers Parquet. Ces fichiers sont accompagnés d’un ensemble de fichiers de liaison JSON, qui suivent l’ordre et la nature de chaque fichier Parquet associé à une table Delta.

Il est important de comprendre que les fichiers Parquet sous-jacents sont de nature incrémentielle. Par conséquent, le nom Delta est une référence à la modification incrémentielle des données. Chaque fois qu’une opération d’écriture dans une table Delta a lieu, comme lorsque des données sont insérées, mises à jour ou supprimées, de nouveaux fichiers Parquet sont créés qui représentent les modifications des données en tant que version. Les fichiers Parquet sont donc immuables, ce qui signifie qu’ils ne sont jamais modifiés. Il est donc possible que les données soient dupliquées plusieurs fois sur un ensemble de fichiers Parquet pour une table Delta. L’infrastructure Delta s’appuie sur des fichiers de liaison pour déterminer quels fichiers Parquet physiques sont nécessaires pour produire le résultat de requête correct.

Prenons un exemple simple d’une table Delta utilisée dans cet article pour expliquer différentes opérations de modification des données. La table comporte deux colonnes et stocke trois lignes.

IDProduit StockOnHand
A 1
G 2
C 3

Les données de table Delta sont stockées dans un fichier Parquet unique qui contient toutes les données, et il existe un fichier de liaison unique qui contient des métadonnées sur le moment où les données ont été insérées (ajoutées).

  • Fichier Parquet 1 :
    • ProductID : A, B, C
    • StockOnHand : 1, 2, 3
  • Fichier de liaison 1 :
    • Contient le timestamp du moment où Parquet file 1 a été créé et enregistre que des données ont été ajoutées.

Opérations d'insertion

Tenez compte de ce qui se passe lorsqu’une opération d’insertion se produit : une nouvelle ligne pour le produit C avec une valeur de stock disponible de 4 est insérée. Ces opérations entraînent la création d’un fichier Parquet et d’un fichier de liaison. Il existe maintenant deux fichiers Parquet et deux fichiers de liaison.

  • Fichier Parquet 1 :
    • ProductID : A, B, C
    • StockOnHand : 1, 2, 3
  • Fichier Parquet 2 :
    • ProductID : D
    • StockOnHand : 4
  • Fichier de liaison 1 :
    • Contient le timestamp du moment où Parquet file 1 a été créé et enregistre que des données ont été ajoutées.
  • Fichier de liaison 2 :
    • Contient le timestamp du moment où Parquet file 2 a été créé et enregistre que des données ont été ajoutées.

À ce stade, une requête de la table Delta retourne le résultat suivant. Il n’est pas important que le résultat soit sourcé depuis plusieurs fichiers Parquet.

IDProduit StockOnHand
A 1
G 2
C 3
D 4

Chaque opération d’insertion suivante crée de nouveaux fichiers Parquet et fichiers de liaison. Cela signifie que le nombre de fichiers Parquet et de fichiers de liaison augmente avec chaque opération d’insertion.

Opérations de mise à jour

Considérez maintenant ce qui se passe lorsqu’une opération de mise à jour se produit : la ligne du produit D a sa valeur de stock disponible modifiée en 10. Ces opérations entraînent la création d’un fichier Parquet et d’un fichier de liaison. Il existe désormais trois fichiers Parquet et trois fichiers de liaison.

  • Fichier Parquet 1 :
    • ProductID : A, B, C
    • StockOnHand : 1, 2, 3
  • Fichier Parquet 2 :
    • ProductID : D
    • StockOnHand : 4
  • Fichier Parquet 3 :
    • ProductID : C
    • StockOnHand : 10
  • Fichier de liaison 1 :
    • Contient le timestamp du moment où Parquet file 1 a été créé et enregistre que des données ont été ajoutées.
  • Fichier de liaison 2 :
    • Contient le timestamp du moment où Parquet file 2 a été créé et enregistre que des données ont été ajoutées.
  • Fichier de liaison 3 :
    • Contient le timestamp du moment où Parquet file 3 a été créé et enregistre que des données ont été mises à jour.

À ce stade, une requête de la table Delta retourne le résultat suivant.

IDProduit StockOnHand
A 1
G 2
C 10
D 4

Les données du produit C existent désormais dans plusieurs fichiers Parquet. Toutefois, les requêtes sur la table Delta combinent les fichiers de liaison pour déterminer quelles données doivent être utilisées pour fournir le résultat correct.

Opérations de suppression

Considérez maintenant ce qui se passe lorsqu’une opération de suppression se produit : la ligne du produit B est supprimée. Cette opération entraîne un nouveau fichier Parquet et un nouveau fichier de liaison. Il existe désormais quatre fichiers Parquet et quatre fichiers de liaison.

  • Fichier Parquet 1 :
    • ProductID : A, B, C
    • StockOnHand : 1, 2, 3
  • Fichier Parquet 2 :
    • ProductID : D
    • StockOnHand : 4
  • Fichier Parquet 3 :
    • ProductID : C
    • StockOnHand : 10
  • Fichier Parquet 4 :
    • ProductID : A, C, D
    • StockOnHand : 1, 10, 4
  • Fichier de liaison 1 :
    • Contient le timestamp du moment où Parquet file 1 a été créé et enregistre que des données ont été ajoutées.
  • Fichier de liaison 2 :
    • Contient le timestamp du moment où Parquet file 2 a été créé et enregistre que des données ont été ajoutées.
  • Fichier de liaison 3 :
    • Contient le timestamp du moment où Parquet file 3 a été créé et enregistre que des données ont été mises à jour.
  • Fichier de liaison 4 :
    • Contient le timestamp du moment où Parquet file 4 a été créé et enregistre que des données ont été supprimées.

Notez que Parquet file 4 ne contient plus de données pour le produit B, mais contient des données pour toutes les autres lignes de la table.

À ce stade, une requête de la table Delta retourne le résultat suivant.

IDProduit StockOnHand
A 1
C 10
D 4

Remarque

Cet exemple est simple, car il implique une petite table, quelques opérations et seulement des modifications mineures. Les tables volumineuses sur lesquelles se déroulent de nombreuses opérations d’écriture et qui contiennent de nombreuses lignes de données génèrent plusieurs fichiers Parquet par version.

Important

Selon la façon dont vous définissez vos tables Delta et la fréquence des opérations de modification des données, de nombreux fichiers Parquet peuvent être créés. N’oubliez pas que chaque licence de capacité Fabric a des garde-fous. Si le nombre de fichiers Parquet d’une table Delta dépasse la limite de votre référence SKU, les requêtes reviendront à DirectQuery, ce qui peut entraîner un niveau de performance des requêtes plus lent.

Pour gérer le nombre des fichiers Parquet, consultez Maintenance des tables Delta plus loin dans cet article.

Voyage dans le temps Delta

Les fichiers de liaison permettent d’interroger des données depuis un point dans le passé. Cette fonctionnalité est connue sous le nom Voyage dans le temps Delta. Le point dans le passé peut être un timestamp ou une version.

Considérez les exemples de requête suivants.

SELECT * FROM Inventory TIMESTAMP AS OF '2024-04-28T09:15:00.000Z';
SELECT * FROM Inventory AS OF VERSION 2;

Conseil

Vous pouvez également interroger une table en utilisant la syntaxe abrégée @ pour spécifier le timestamp ou la version comme élément du nom de la table. Le timestamp doit être au format yyyyMMddHHmmssSSS. Vous pouvez spécifier une version après @ en ajoutant v à la version.

Voici des exemples de la requête précédents réécrits avec la syntaxe abrégée.

SELECT * FROM Inventory@20240428091500000;
SELECT * FROM Inventory@v2;

Important

Les versions de table accessibles avec le voyage dans le temps sont déterminées par une combinaison du seuil de rétention des fichiers journaux de transactions et de la fréquence et de la rétention spécifiée pour les opérations VACUUM (décrites plus loin dans la section Maintenance des tables Delta). Si vous exécutez VACUUM quotidiennement avec les valeurs par défaut, sept jours de données seront disponibles pour le voyage dans le temps.

Cadrage

Le Cadrage est une opération Direct Lake qui définit la version d’une table Delta qui doit être utilisée pour charger des données dans une colonne de modèle sémantique. Tout aussi important, la version détermine également ce qui doit être exclu lorsque des données sont chargées.

Une opération de cadrage marque le timestamp/la version de chaque table Delta dans les tables de modèle sémantique. À partir de ce stade, lorsque le modèle sémantique doit charger des données depuis une table Delta, le timestamp/la version associés à l’opération de cadrage la plus récente sont utilisés pour déterminer les données à charger. Toutes les modifications de données suivantes qui se produisent pour la table Delta depuis la dernière opération de cadrage sont ignorées (jusqu’à l’opération de cadrage suivante).

Important

Un modèle sémantique encadré faisant référence à une version particulière de la table Delta, la source doit s’assurer qu’elle conserve la version de la table Delta jusqu’à ce que l’encadrement d’une nouvelle version soit terminé. Sinon, les utilisateurs rencontrent des erreurs lorsque le modèle doit accéder aux fichiers de table Delta, qui ont été vidés ou supprimés par la charge de travail du producteur.

Pour plus d’informations sur le cadrage, consultez Vue d’ensemble Direct Lake.

Partitionnement de tables

Les tables Delta peuvent être partitionnées afin qu’un sous-ensemble de lignes soit stocké ensemble dans un seul ensemble de fichiers Parquet. Les partitions peuvent accélérer les requêtes ainsi que les opérations d’écriture.

Considérez une table Delta qui comporte un milliard de lignes de données de ventes pour une période de deux ans. Bien qu’il soit possible de stocker toutes les données dans un seul ensemble de fichiers Parquet, ce volume de données n’est pas optimal pour les opérations de lecture et d’écriture. Au lieu de cela, le niveau de performance peut être amélioré en répartissant les milliards de lignes de données sur plusieurs séries de fichiers Parquet.

Une clé de partition doit être définie lors de la configuration du partitionnement de table. La clé de partition détermine quelles lignes doivent être stockées dans quelles séries de données. Pour les tables Delta, la clé de partition peut être définie en fonction des valeurs distinctes d’une ou plusieurs colonnes spécifiées, comme une colonne mois/année d’une table de dates. Dans ce cas, deux années de données seraient réparties sur 24 partitions (2 ans x 12 mois).

Les moteurs de calcul Fabric ne connaissent pas les partitions de table. À mesure que de nouvelles valeurs de clé de partition sont insérées, de nouvelles partitions sont créées automatiquement. Dans OneLake, vous trouverez un sous-dossier pour chaque valeur de clé de partition unique, et chaque sous-dossier stocke son propre ensemble de fichiers Parquet et de fichiers de liaison. Au moins un fichier Parquet et un fichier de liaison doivent exister, mais le nombre réel de fichiers dans chaque sous-dossier peut varier. À mesure que des opérations de modification de données ont lieu, chaque partition conserve son propre ensemble de fichiers Parquet et de fichiers de liaison pour suivre ce qu’il faut retourner pour un timestamp ou une version donnés.

Si une requête d’une table Delta partitionnée est filtrée uniquement sur les trois derniers mois de données de vente, le sous-ensemble de fichiers Parquet et de fichiers de liaison auxquels il faut accéder est rapidement identifié. Cela permet ensuite d’ignorer complètement de nombreux fichiers Parquet, ce qui entraîne un meilleur niveau de performance en lecture.

Toutefois, les requêtes qui ne filtrent pas sur la clé de partition peuvent ne pas toujours être plus performantes. Cela peut être le cas lorsqu’une table Delta stocke toutes les données dans un seul ensemble de fichiers Parquet volumineux et qu’il existe une fragmentation des fichiers ou des groupes de lignes. Bien qu’il soit possible de paralléliser l’extraction de données depuis plusieurs fichiers Parquet sur plusieurs nœuds de cluster, de nombreux petits fichiers Parquet peuvent affecter négativement les E/S de fichier et, par conséquent, le niveau de performance des requêtes. Pour cette raison, il est préférable d’éviter de partitionner les tables Delta dans la plupart des cas, sauf si les opérations d’écriture ou d’extraction, de transformation et de chargement (Extract, Transform, and Load/ETL) des processus en bénéficieraient clairement.

Le partitionnement offre également des avantages pour les opérations d’insertion, de mise à jour et de suppression, car l’activité de fichier se produit uniquement dans les sous-dossiers correspondant à la clé de partition des lignes modifiées ou supprimées. Par exemple, si un lot de données est inséré dans une table Delta partitionnée, les données sont évaluées pour déterminer quelles valeurs de clé de partition existent dans le lot. Les données sont ensuite dirigées uniquement vers les dossiers pertinents pour les partitions.

Comprendre comment les tables Delta utilisent des partitions peuvent vous aider à concevoir des scénarios ETL optimaux, qui réduisent les opérations d’écriture qui doivent se produire lors de la mise à jour de tables Delta volumineuses. Le niveau de performance en écriture s’améliore en réduisant le nombre et la taille des nouveaux fichiers Parquet qui doivent être créés. Pour une table Delta volumineuse partitionnée par mois/année, comme décrit dans l’exemple précédent, de nouvelles données ajoutent uniquement de nouveaux fichiers Parquet à la dernière partition. Les sous-dossiers des mois calendaires précédents restent inchangés. Si des données des mois calendaires précédents doivent être modifiées, seuls les dossiers de partition appropriés reçoivent de nouvelles partitions et de nouveaux fichiers de liaison.

Important

Si l’objectif principal d’une table Delta est de servir de source de données pour les modèles sémantiques (et secondairement, d’autres charges de travail de requête), il est généralement préférable d’éviter le partitionnement en préférant l’optimisation de la charge des colonnes en mémoire.

Pour les modèles sémantiques Direct Lake ou le point de terminaison d’analytique SQL, la meilleure façon d’optimiser les partitions de table Delta consiste à permettre à Fabric de gérer automatiquement les fichiers Parquet pour chaque version d’une table Delta. Le fait de laisser la gestion à Fabric doit entraîner un niveau de performance des requêtes élevé via la parallélisation, toutefois il n’est pas garanti que cela fournisse un meilleur niveau de performance en écriture.

Si vous devez optimiser les opérations d’écriture, envisagez d’utiliser des partitions pour optimiser les opérations d’écriture dans les tables Delta en fonction de la clé de partition. Toutefois, sachez que le partitionnement d’une table Delta peut avoir un impact négatif sur le niveau de performance en lecture. Pour cette raison, nous vous recommandons de tester attentivement le niveau de performance en lecture et en écriture, peut-être en créant plusieurs copies de la même table Delta avec différentes configurations pour comparer les durées.

Avertissement

Si vous partitionnez sur une colonne de cardinalité élevée, cela peut entraîner un nombre excessif de fichiers Parquet. N’oubliez pas que chaque licence de capacité Fabric a des garde-fous. Si le nombre de fichiers Parquet d’une table Delta dépasse la limite de votre référence SKU, les requêtes reviendront à DirectQuery, ce qui peut entraîner un niveau de performance des requêtes plus lent.

Fichiers Parquet

Le stockage sous-jacent d’une table Delta comprend un ou plusieurs fichiers Parquet. Le format de fichier Parquet est généralement utilisé pour les applications write-once, read-many. De nouveaux fichiers Parquet sont créés chaque fois que les données d’une table Delta sont modifiées, que ce soit par une opération d’insertion, de mise à jour ou de suppression.

Remarque

Vous pouvez accéder aux fichiers Parquet associés aux tables Delta à l’aide d’un outil, comme l’Explorateur de fichiers OneLake. Les fichiers peuvent être téléchargés, copiés ou déplacés vers d’autres destinations aussi facilement que pour le déplacement d’autres fichiers. Toutefois, c’est la combinaison de fichiers Parquet et de fichiers de liaison JSON qui permet aux moteurs de calcul d’émettre des requêtes sur les fichiers sous la forme d’une table Delta.

Format de fichier Parquet

Le format interne d’un fichier Parquet diffère d’autres formats de stockage de données courants, comme CSV, TSV, XMLA et JSON. Ces formats organisent les données par lignes, tandis que Parquet organise les données par colonnes. En outre, le format de fichier Parquet diffère de ces formats, car il organise les lignes de données en un ou plusieurs groupes de lignes.

La structure de données interne d’un modèle sémantique Power BI est basée sur des colonnes, ce qui signifie que les fichiers Parquet ont beaucoup en commun avec Power BI. Cette similarité signifie qu’un modèle sémantique Direct Lake peut charger efficacement des données depuis des fichiers Parquet directement en mémoire. En fait, de très grands volumes de données peuvent être chargés en quelques secondes. Comparez cette capacité avec l’actualisation d’un modèle sémantique d’importation qui doit récupérer des blocs ou des données sources, puis les traiter, les encoder, les stocker, puis les charger en mémoire. Une opération d’actualisation de modèle sémantique d’importation peut également consommer des quantités significatives de calcul (mémoire et processeur) et prendre beaucoup de temps. Toutefois, avec les tables Delta, la plupart des efforts de préparation des données adaptées au chargement direct dans un modèle sémantique se produit lorsque le fichier Parquet est généré.

Comment les fichiers Parquet stockent les données

Considérez l’exemple d’ensemble de données qui suit.

Date IDProduit StockOnHand
16/09/2024 A 10
16/09/2024 G 11
17/09/2024 A 13
…

Lorsqu’il est stocké au format de fichier Parquet, de façon conceptuelle, cet ensemble de données peut ressembler au texte suivant.

Header:
RowGroup1:
    Date: 2024-09-16, 2024-09-16, 2024-09-17…
    ProductID: A, B, A…
    StockOnHand: 10, 11, 13…
RowGroup2:
    …
Footer:

Les données sont compressées en remplaçant les clés de dictionnaire pour les valeurs courantes et en appliquant un encodage de longueur d’exécution (Run-Length Encoding/RLE). RLE s’efforce de compresser une série de données de mêmes valeurs dans une représentation plus petite. Dans l’exemple suivant, un mappage de dictionnaire de clés numériques aux valeurs est créé dans l’en-tête, et les valeurs de clé plus petites sont utilisées à la place des valeurs de données.

Header:
    Dictionary: [
        (1, 2024-09-16), (2, 2024-09-17),
        (3, A), (4, B),
        (5, 10), (6, 11), (7, 13)
        …
    ]
RowGroup1:
    Date: 1, 1, 2…
    ProductID: 3, 4, 3…
    StockOnHand: 5, 6, 7…
Footer:

Lorsque le modèle sémantique Direct Lake a besoin de données pour calculer la somme de la colonne StockOnHand groupée par ProductID, seul le dictionnaire et les données associés aux deux colonnes sont nécessaires. Dans les fichiers volumineux qui contiennent de nombreuses colonnes, des parties substantielles du fichier Parquet peuvent être ignorées pour accélérer le processus de lecture.

Remarque

Le contenu d’un fichier Parquet n’est pas lisible par l’homme et n’est donc pas adapté à l’ouverture dans un éditeur de texte. Toutefois, il existe de nombreux outils open source qui peuvent ouvrir et révéler le contenu d’un fichier Parquet. Ces outils peuvent également vous permettre d’inspecter les métadonnées, comme le nombre de lignes et de groupes de lignes contenus dans un fichier.

V-Order

Fabric prend en charge une optimisation supplémentaire appelée V-Order. V-Order est une optimisation du temps d'écriture au format de fichier Parquet. Une fois que V-Order est appliqué, il génère un fichier plus petit et donc plus rapide à lire. Cette optimisation est particulièrement pertinente pour un modèle sémantique Direct Lake, car elle prépare les données pour un chargement rapide en mémoire, et donc elle fait moins de demandes sur les ressources de capacité. Elle entraîne également un niveau de performance des requêtes plus rapide, car moins de mémoire doit être analysée.

Les tables Delta créées et chargées par des éléments Fabric comme les pipelines de données, les flux de données et les notebooks appliquent automatiquement V-Order. Toutefois, les fichiers Parquet chargés dans un lakehouse Fabric, ou référencés par un raccourci, peuvent ne pas avoir cette optimisation appliquée. Bien que les fichiers Parquet non optimisés puissent toujours être lus, le niveau de performance en lecture ne sera probablement pas aussi rapide que celui d’un fichier Parquet équivalent auquel V-Order a été appliqué.

Remarque

Les fichiers Parquet auxquels V-Order est appliqué sont toujours conformes au format de fichier Parquet open source. Par conséquent, ils peuvent être lus par des outils autres que Fabric.

Pour plus d'informations, consultez Optimisation de la table Delta Lake et V-Order.

Optimisation de table Delta

Cette section décrit différentes rubriques pour optimiser les tables Delta pour les modèles sémantiques.

Volume de données

Bien que les tables Delta puissent croître pour stocker des volumes de données extrêmement volumineux, les garde-fous de capacité Fabric imposent des limites aux modèles sémantiques qui les interrogent. Lorsque ces limites sont dépassées, les requêtes reviennent à DirectQuery, ce qui peut entraîner un niveau de performance des requêtes plus lent.

Par conséquent, envisagez de limiter le nombre de lignes d’une table de faits volumineuse en augmentant sa granularité (stocker des données résumées), en réduisant la dimensionnalité ou en stockant moins d’historique.

Vérifiez également que V-Order est appliqué, car il génère un fichier plus petit, et donc plus rapide à lire.

Type de données de colonne

Essayez de réduire la cardinalité (le nombre de valeurs uniques) dans chaque colonne de chaque table Delta. Ceci car toutes les colonnes sont compressées et stockées en utilisant un encodage par hachage. L’encodage par hachage demande à l’optimisation V-Order d’affecter un identificateur numérique à chaque valeur unique contenue dans la colonne. C’est par la suite l’identificateur numérique qui est stocké, nécessitant une recherche de hachage pendant le stockage et l’interrogation.

Lorsque vous utilisez des types de données numériques approximatifs (comme flottant et réel), envisagez d’arrondir les valeurs et d’utiliser une précision inférieure.

Colonnes inutiles

Comme pour toute table de données, les tables Delta ne doivent stocker que les colonnes requises. Dans le contexte de cet article, cela signifie requis par le modèle sémantique, bien qu’il puisse y avoir d’autres charges de travail analytiques qui interrogent les tables Delta.

Les tables Delta doivent inclure les colonnes requises par le modèle sémantique pour le filtrage, le regroupement, le tri et la synthèse, en plus des colonnes qui prennent en charge les relations de modèle. Bien que les colonnes inutiles n’affectent pas le niveau de performance des requêtes de modèle sémantique (car elles ne seront pas chargées en mémoire), elles entraînent une plus grande taille de stockage et nécessitent donc davantage de ressources de calcul pour les charger et les gérer.

Les modèles sémantiques Direct Lake ne prenant pas en charge les colonnes calculées, vous devez matérialiser ces colonnes dans les tables Delta. Notez que cette approche de conception est un anti-modèle pour les modèles sémantiques Import et DirectQuery. Par exemple, si vous avez les colonnes FirstName et LastName, et besoin d’une colonne FullName, matérialisez les valeurs de cette colonne lors de l’insertion de lignes dans la table Delta.

Considérez que certaines synthèses de modèle sémantique peuvent dépendre de plusieurs colonnes. Par exemple, pour calculer les ventes, la mesure dans le modèle additionne le produit de deux colonnes : Quantity et Price. Si aucune de ces colonnes n’est utilisée indépendamment, il serait plus efficace de matérialiser le calcul des ventes en tant que colonne unique que de stocker ses valeurs de composant dans des colonnes distinctes.

Taille de groupe de lignes

En interne, un fichier Parquet organise des lignes de données en plusieurs groupes de lignes au sein de chaque fichier. Par exemple, un fichier Parquet qui contient 30 000 lignes peut les segmenter en trois groupes de lignes, chacun ayant 10 000 lignes.

Le nombre de lignes d’un groupe de lignes influence la rapidité avec laquelle Direct Lake peut lire les données. Un nombre plus élevé de groupes de lignes avec moins de lignes risque d’avoir un impact négatif sur le chargement des données de colonne dans un modèle sémantique en raison d’E/S excessives.

En règle générale, nous vous déconseillons de modifier la taille du groupe de lignes par défaut. Toutefois, vous pouvez envisager de modifier la taille du groupe de lignes pour les tables Delta volumineuses. Veillez à tester attentivement le niveau de performance en lecture et en écriture, peut-être en créant plusieurs copies des mêmes tables Delta avec différentes configurations pour comparer les durées.

Important

N’oubliez pas que chaque licence de capacité Fabric a des garde-fous. Si le nombre de groupes de lignes d’une table Delta dépasse la limite de votre référence SKU, les requêtes reviendront à DirectQuery, ce qui peut entraîner un niveau de performance des requêtes plus lent.

Maintenance des tables Delta

Au fil du temps, à mesure que des opérations d’écriture ont lieu, les versions de table Delta s’accumulent. Vous pourriez finalement atteindre un point auquel un impact négatif sur le niveau de performance en lecture devient constatable. Pire, si le nombre de fichiers Parquet par table, ou de groupes de lignes par table, ou de lignes par table dépassent les garde-fous de votre capacité, les requêtes reviendront à DirectQuery, ce qui peut entraîner un niveau de performance des requêtes plus lent. Il est donc important de maintenir régulièrement les tables Delta.

OPTIMIZE

Vous pouvez utiliser OPTIMIZE pour optimiser une table Delta, pour fusionner les fichiers les plus petits en fichiers plus volumineux. Vous pouvez également définir la clause WHERE pour cibler uniquement un sous-ensemble filtré de lignes qui correspondent à un prédicat de partition donné. Seuls les filtres impliquant des clés de partition sont pris en charge. La commande OPTIMIZE peut également appliquer V-Order pour compacter et réécrire les fichiers Parquet.

Nous vous recommandons d’exécuter régulièrement cette commande sur les grandes tables Delta fréquemment mises à jour, peut-être chaque jour lorsque votre processus ETL se termine. Cherchez un compromis entre un meilleur niveau de performance des requêtes et le coût de l’utilisation des ressources requises pour optimiser la table.

VACUUM

Vous pouvez utiliser VACUUM pour supprimer les fichiers qui ne sont plus référencés ou antérieurs à un seuil de rétention défini. Veillez à définir une période de rétention appropriée, sinon vous risquez de perdre la possibilité du voyage dans le temps pour revenir à une version antérieure au cadre marqué dans les tables de modèles sémantiques.

Important

Un modèle sémantique encadré faisant référence à une version particulière de la table Delta, la source doit s’assurer qu’elle conserve la version de la table Delta jusqu’à ce que l’encadrement d’une nouvelle version soit terminé. Sinon, les utilisateurs rencontrent des erreurs lorsque le modèle doit accéder aux fichiers de table Delta, qui ont été vidés ou supprimés par la charge de travail du producteur.

REORG TABLE

Vous pouvez utiliser REORG TABLE pour réorganiser une table Delta en réécrivant des fichiers pour vider les données supprimées de manière réversible, comme lorsque vous supprimez une colonne en utilisant ALTER TABLE DROP COLUMN.

Automatiser la maintenance de table

Pour automatiser les opérations de maintenance de table, vous pouvez utiliser l’API Lakehouse. Pour plus d’informations, consultez Gérer le lakehouse avec l’API REST Microsoft Fabric.

Conseil

Vous pouvez également utiliser la fonctionnalité de maintenance de table Lakehouse dans le portail Fabric pour simplifier la gestion de vos tables Delta.

Contenu connexe