Partage via

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

  • Article

Cet article présente les concepts de stockage de 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 des performances de requête fiables et rapides.

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 des tables Delta à l’aide d’expressions d’analyse de données (DAX), d’expressions multidimensionnelles (MDX), de T-SQL (Transact-SQL), de Spark SQL et même de 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 à l’aide d’un raccourci OneLake , qui pointe vers un emplacement de stockage spécifique, tel que 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 liens 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. D'où le nom Delta en référence à la modification incrémentielle des données. Chaque fois qu’une opération d’écriture dans une table Delta a lieu, par exemple 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 de données sous la forme d’une 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 liens pour déterminer quels fichiers Parquet physiques sont nécessaires pour produire le résultat correct de la requête.

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

ProductID StockOnHand
Un 1
B 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 l’horodatage lorsque Parquet file 1 a été créé et enregistre que des données ont été ajoutées.

Opérations d’insertion

Considérez ce qui se passe lorsqu’une opération d’insertion se produit : une nouvelle ligne pour le produit C avec une valeur de stock 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 l’horodatage de la création de Parquet file 1 et indique que des données ont été ajoutées.
  • Fichier de lien 2 :
    • Contient l’horodatage de la création de Parquet file 2 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 provienne de plusieurs fichiers Parquet.

IDProduit StockOnHand
Un 1
B 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 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 :
    • ID de produit: 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 l’horodatage de la création de Parquet file 1 et indique que des données ont été ajoutées.
  • Fichier de lien 2 :
    • Contient l’horodatage de la création de Parquet file 2 et enregistre que des données ont été ajoutées.
  • Fichier de lien 3 :
    • Contient l’horodatage de la création de Parquet file 3 et consigne que les données ont été mises à jour.

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

ProductID StockOnHand
Un 1
B 2
C 10
D 4

Les données pour le produit C existent désormais dans plusieurs fichiers Parquet. Toutefois, les requêtes sur la table Delta combinent les fichiers de liens 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 fichier de lien. 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 l'horodatage de la création de Parquet file 1 et enregistre que des données ont été ajoutées.
  • Fichier de lien 2 :
    • Contient l'horodatage de la création de Parquet file 2 et enregistre que les données ont été ajoutées.
  • Fichier de lien 3 :
    • Contient l’horodatage de la création de Parquet file 3 et indique que les données ont été mises à jour.
  • Fichier de lien 4 :
    • Contient l’horodatage lorsque Parquet file 4 a été créé et enregistre que les données ont été supprimées.

Notez que Parquet file 4 ne contient plus de données pour le produit B, mais qu’elle 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.

ProductID StockOnHand
Un 1
C 10
D 4

Remarque

Cet exemple est simple, car il implique une petite table, seulement quelques opérations et seulement des modifications mineures. Les tables volumineuses qui connaissent 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, cela peut entraîner de nombreux 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.

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

Voyage temporel Delta

Les fichiers de liaison permettent d’interroger des données à partir d’un point antérieur dans le temps. 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 à l’aide de la syntaxe abrégée @ pour spécifier l’horodatage ou la version dans le cadre du nom de la table. Le timestamp doit être au format yyyyMMddHHmmssSSS. Vous pouvez spécifier un numéro de version après @ en ajoutant un v devant le numéro de version.

Voici les exemples de 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 les déplacements temporels.

Cadrage

Framing est une opération Direct Lake qui définit la version d'une table Delta à utiliser 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 les 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 à partir d’une table Delta, l’horodatage/version associé à l’opération de trame la plus récente est utilisé 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 trame sont ignorées (jusqu’à l’opération de trame suivante).

Important

Étant donné qu’un modèle sémantique encadré fait 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 rencontreront des erreurs lorsque les fichiers de la table Delta, qui doivent être accessibles par le modèle, auront été purgés ou autrement supprimés par la charge de travail du producteur.

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

Partitionnement de tables

Les tables Delta peuvent être partitionnées afin qu’un sous-ensemble de lignes soit stocké ensemble dans un 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, les performances peuvent être améliorées 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 les lignes à stocker dans quelles séries. Pour les tables Delta, la clé de partition peut être définie en fonction des valeurs distinctes d’une colonne spécifiée (ou des colonnes), telles qu’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 qu’elles insèrent de nouvelles valeurs de clé de partition, de nouvelles partitions sont créées automatiquement. Dans OneLake, vous trouverez un sous-dossier pour chaque valeur unique de clé de partition, et chaque sous-dossier stocke son propre ensemble de fichiers Parquet et de fichiers de liens. Au moins un fichier Parquet et un fichier de lien 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 sur une table Delta partitionnée est filtrée pour n'inclure que les trois derniers mois de données de vente, le sous-ensemble de fichiers Parquet et les fichiers de liens nécessaires peut être 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 risquent de ne pas toujours s’améliorer. 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 la récupération des données à partir de plusieurs fichiers Parquet sur plusieurs nœuds de cluster, de nombreux petits fichiers Parquet peuvent affecter négativement les E/S de fichiers et, par conséquent, les performances 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 (ETL) des processus en tireraient clairement parti.

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. Les performances d’écriture s’améliorent 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, les 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 nouveaux fichiers de partition et 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érence pour optimiser la charge de 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 des performances de requête élevées via la parallélisation, mais il peut ne pas nécessairement fournir les meilleures performances d’écriture.

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

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 est un ou plusieurs fichiers Parquet. Le format de fichier Parquet est généralement utilisé pour les applications write-once, read-many. Les 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 à des tables Delta à l’aide d’un outil, comme 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 le déplacement d’autres fichiers. Toutefois, il s’agit de la combinaison de fichiers Parquet et de fichiers de liaison JSON qui permettent 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, tels que 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 partagent beaucoup en commun avec Power BI. Cette similarité signifie qu’un modèle sémantique Direct Lake peut charger efficacement des données à partir des fichiers Parquet directement en mémoire. En fait, de très grands volumes de données peuvent être chargés en secondes. Contrastez cette fonctionnalité avec l’actualisation d’un modèle sémantique d’importation qui doit récupérer des blocs ou des données sources, puis traiter, encoder, stocker, puis charger celui-ci en mémoire. Une opération d’actualisation du 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 produisent lorsque le fichier Parquet est généré.

Comment les fichiers Parquet stockent les données

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

Date ProductID StockOnHand
16/09/2024 Un 10
16/09/2024 B 11
17/09/2024 Un 13
…

Lorsqu’elles sont stockées 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 mêmes valeurs dans une représentation plus petite. Dans l'exemple suivant, un dictionnaire associant des clés numériques à des valeurs est créé dans l'en-tête, et les valeurs de clé inférieures sont utilisées à la place de celles des 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 regroupée par ProductID, seul le dictionnaire et les données associés aux deux colonnes sont requises. 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, telles que 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 moins de demandes sur les ressources de capacité. Elle entraîne également des performances de requête plus rapides, 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, les performances de lecture ne seront probablement pas aussi rapides qu’un fichier Parquet équivalent ayant appliqué V-Order.

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 la 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 pourrait entraîner des performances de requête plus lentes.

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 l'ordre V est appliqué, car il en résulte un fichier plus petit et donc une lecture plus rapide.

Type de données de colonne

Essayez de réduire la cardinalité (le nombre de valeurs uniques) dans chaque colonne de chaque table Delta. Cela est dû au fait que toutes les colonnes sont compressées et stockées à l’aide de l'encodage de 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 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 n’importe quelle table de données, les tables Delta doivent uniquement stocker les colonnes requises. Dans le contexte de cet article, cela signifie exigé par le modèle sémantique, même s'il peut exister d'autres flux de travail analytiques qui consultent les tables Delta.

Les tables delta doivent inclure des 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 les performances 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 charger et gérer.

Étant donné que les modèles sémantiques Direct Lake ne prennent 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 FirstName et LastName colonnes, et que vous avez 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 du 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 les performances de lecture et d’écriture, peut-être en créant plusieurs copies des mêmes tables Delta avec différentes configurations pour comparer les minutages.

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 de la table Delta

Au fil du temps, à mesure que des opérations d’écriture ont lieu, les versions de table Delta s’accumulent. Finalement, vous pouvez atteindre un point auquel un impact négatif sur les performances de lecture devient visible. 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.

OPTIMISER

Vous pouvez utiliser OPTIMIZE pour optimiser une table Delta pour fusionner des fichiers 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 cette commande sur de grandes tables Delta fréquemment mises à jour régulièrement, peut-être chaque jour lorsque votre processus ETL se termine. Équilibrez le compromis entre de meilleures performances de requête et le coût de l’utilisation des ressources requis pour optimiser la table.

VACUUM

Vous pouvez utiliser vacuum pour supprimer les fichiers qui ne sont plus référencés et/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

Étant donné qu’un modèle sémantique encadré fait 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 rencontreront des erreurs lorsque le modèle tentera d'accéder aux fichiers de la table Delta qui ont été nettoyés ou autrement 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 les fichiers pour purger les données supprimées de manière temporaire, par exemple lorsque vous supprimez une colonne en utilisant ALTER TABLE DROP COLUMN.

Automatiser la maintenance des tables

Pour automatiser les opérations de maintenance de table, vous pouvez utiliser l’API Lakehouse. Pour plus d'informations, consultez Gérer la 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