Optimisation de la table Delta Lake et V-Order
Les formats de table Lakehouse et Delta Lake sont essentiels à Microsoft Fabric. Il est essentiel que les tables soient optimisées pour l’analyse. Ce guide décrit les concepts et les configurations d’optimisation des tables Delta Lake et explique comment appliquer l’optimisation aux modèles d’utilisation du Big Data les plus courants.
Qu’est-ce que V-Order ?
V-Order est une optimisation du temps d’écriture au format de fichier Parquet qui permet des lectures rapides sous les moteurs de calcul Microsoft Fabric, tels que Power BI, SQL, Spark et autres.
Les moteurs Power BI et SQL utilisent la technologie Microsoft Verti-Scan et les fichiers Parquet avec V-Order pour obtenir des temps d’accès aux données en mémoire similaires. Spark et d’autres moteurs de calcul non-Verti-Scan bénéficient également des fichiers avec V-Order avec une moyenne de temps de lecture 10 % plus rapide, avec certains scénarios jusqu’à 50 %.
V-Order fonctionne en appliquant un tri spécial, la distribution de groupes de lignes, le codage de dictionnaire et la compression sur les fichiers Parquet, ce qui nécessite moins de ressources réseau, de disque et de processeur dans les moteurs de calcul pour les lire, ce qui offre une plus grande rentabilité et de meilleures performances. Le tri V-Order a un impact de 15 % sur les temps d’écriture moyens, mais offre jusqu’à 50 % de compression supplémentaire.
Son format Parquet 100 % open source compatible ; tous les moteurs Parquet peuvent le lire comme un fichier Parquet standard. Les tables Delta sont plus efficaces que jamais ; les fonctionnalités telles que Z-Order sont compatibles avec V-Order. Les propriétés de table et les commandes d’optimisation peuvent être utilisées sur le contrôle V-Order sur ses partitions.
V-Order est appliqué au niveau du fichier Parquet. Les tables Delta et ses fonctionnalités, telles que Z-Order, le compactage, le nettoyage, le voyage dans le temps, etc. sont orthogonaux à V-Order, et en tant que tels, sont compatibles et peuvent être utilisés ensemble pour des avantages supplémentaires.
Contrôle des écritures V-Order
V-Order est activé par défaut dans Microsoft Fabric et dans Apache Spark. Il est contrôlé par les configurations suivantes.
| Configuration | Default value | Description |
|---|---|---|
| spark.sql.parquet.vorder.enabled | true | Contrôle l’écriture avec V-Order au niveau de la session. |
| TBLPROPERTIES(“delta.parquet.vorder.enabled”) | false | Mode V-Order par défaut sur les tables |
| Option d’enregistreur de trame de données : parquet.vorder.enabled | non défini | Contrôler les écritures V-Order à l’aide de l’enregistreur de trame de données |
Utilisez les commandes suivantes pour contrôler l’utilisation des écritures V-Order.
Vérifier la configuration de V-Order dans une session Apache Spark
%%sql
SET spark.sql.parquet.vorder.enabled
Désactiver l’écriture V-Order dans une session Apache Spark
%%sql
SET spark.sql.parquet.vorder.enabled=FALSE
Activer l’écriture V-Order dans une session Apache Spark
Important
Lorsqu’elle est activée au niveau de la session. Toutes les écritures Parquet sont effectuées avec V-Order activé. Cela inclut les tables Parquet non Delta et les tables Delta avec la propriété de table parquet.vorder.enabled définie sur true ou false.
%%sql
SET spark.sql.parquet.vorder.enabled=TRUE
Contrôler V-Order à l’aide des propriétés de table Delta
Activez la propriété de table V-Order lors de la création de la table :
%%sql
CREATE TABLE person (id INT, name STRING, age INT) USING parquet TBLPROPERTIES("delta.parquet.vorder.enabled" = "true");
Important
Lorsque la propriété de table est définie sur true, les commandes INSERT, UPDATE et MERGE se comportent comme prévu et effectuent une optimisation du temps d’écriture. Si la configuration de session V-Order est définie sur true ou si spark.write l’active, les écritures sont avec V-Order même si la valeur TBLPROPERTIES est définie sur false.
Activez ou désactivez V-Order en modifiant la propriété de table :
%%sql
ALTER TABLE person SET TBLPROPERTIES("delta.parquet.vorder.enabled" = "true");
ALTER TABLE person SET TBLPROPERTIES("delta.parquet.vorder.enabled" = "false");
ALTER TABLE person UNSET TBLPROPERTIES("delta.parquet.vorder.enabled");
Une fois que vous avez activé ou désactivé V-Order à l’aide des propriétés de table, seules les écritures ultérieures dans la table sont affectées. Les fichiers Parquet conservent l’ordre utilisé lors de leur création. Pour modifier la structure physique actuelle afin d'appliquer ou de supprimer V-Order, lisez la section « Contrôler V-Order lors de l'optimisation d'une table » ci-dessous.
Contrôle de V-Order directement sur les opérations d’écriture
Toutes les commandes d’écriture Apache Spark héritent du paramètre de session s’il n’est pas explicite. Toutes les commandes suivantes écrivent à l’aide de V-Order en héritant implicitement la configuration de session.
df_source.write\
.format("delta")\
.mode("append")\
.saveAsTable("myschema.mytable")
DeltaTable.createOrReplace(spark)\
.addColumn("id","INT")\
.addColumn("firstName","STRING")\
.addColumn("middleName","STRING")\
.addColumn("lastName","STRING",comment="surname")\
.addColumn("birthDate","TIMESTAMP")\
.location("Files/people")\
.execute()
df_source.write\
.format("delta")\
.mode("overwrite")\
.option("replaceWhere","start_date >= '2017-01-01' AND end_date <= '2017-01-31'")\
.saveAsTable("myschema.mytable")
Important
V-Order ne s’applique qu’aux fichiers affectés par le prédicat.
Dans une session où spark.sql.parquet.vorder.enabled est non défini ou défini sur false, les commandes suivantes écrivent à l’aide de V-Order :
df_source.write\
.format("delta")\
.mode("overwrite")\
.option("replaceWhere","start_date >= '2017-01-01' AND end_date <= '2017-01-31'")\
.option("parquet.vorder.enabled ","true")\
.saveAsTable("myschema.mytable")
DeltaTable.createOrReplace(spark)\
.addColumn("id","INT")\
.addColumn("firstName","STRING")\
.addColumn("middleName","STRING")\
.addColumn("lastName","STRING",comment="surname")\
.addColumn("birthDate","TIMESTAMP")\
.option("parquet.vorder.enabled","true")\
.location("Files/people")\
.execute()
Qu’est-ce que l’écriture optimisée ?
Les charges de travail analytiques sur les moteurs de traitement Big Data tels qu’Apache Spark s’effectuent plus efficacement lors de l’utilisation de tailles de fichiers plus volumineuses standardisées. La relation entre la taille du fichier, le nombre de fichiers, le nombre de travailleurs Spark et ses configurations jouent un rôle essentiel sur les performances. L’ingestion de données dans des tables de lac de données peut avoir comme caractéristique héritée celle d’écrire constamment de nombreux petits fichiers, ce que l’on appelle communément le « problème des petits fichiers ».
Optimiser l’écriture est une fonctionnalité Delta Lake sur Microsoft Fabric et Azure Synapse Analytics dans le moteur Apache Spark qui réduit le nombre de fichiers écrits et vise à augmenter la taille des fichiers individuels des données écrites. La taille de fichier cible peut être modifiée à l’aide de configurations pour répondre aux exigences de charge de travail.
La fonctionnalité est activée par défaut dans Microsoft Fabric Runtime pour Apache Spark. Pour en savoir plus sur les scénarios d’utilisation de la fonctionnalité Optimiser l’écriture, lisez l’article La nécessité d’optimiser l’écriture sur Apache Spark.
Optimisation de fusion
La commande MERGE de Delta Lake permet aux utilisateurs de mettre à jour une table delta avec des conditions avancées. Cela permet de mettre à jour les données d’une table source, d’un affichage ou d’une DataFrame dans une table cible à l’aide de la commande MERGE. Toutefois, l’algorithme actuel dans la distribution open source de Delta Lake n’est pas entièrement optimisé pour la gestion des lignes non modifiées. L’équipe Microsoft Spark Delta a implémenté une optimisation personnalisée de la fusion faible et aléatoire, les lignes non modifiées sont exclues d’une opération de lecture aléatoire coûteuse nécessaire à la mise à jour des lignes correspondantes.
L’implémentation est contrôlée par la configuration spark.microsoft.delta.merge.lowShuffle.enabled, activée par défaut dans le runtime. Elle ne nécessite aucune modification du code et est entièrement compatible avec la distribution open source de Delta Lake. Pour en savoir plus sur les scénarios d’utilisation de la fusion faible et aléatoire, lisez l’article Optimisation de la fusion faible et aléatoire sur les tables Delta.
Maintenance des tables Delta
À mesure que les tables Delta changent, les performances et la rentabilité du stockage ont tendance à se dégrader pour les raisons suivantes :
- Les nouvelles données ajoutées à la table peuvent fausser les données.
- Les taux d’ingestion de données par lot et en streaming peuvent générer de nombreux petits fichiers.
- Les opérations de mise à jour et de suppression finissent par créer une surcharge de lecture. Les fichiers Parquet étant immuables par conception, les tables Delta ajoutent de nouveaux fichiers Parquet avec l’ensemble de modifications, amplifiant davantage les problèmes imposés par les deux premiers éléments.
- Fichiers de données et fichiers journaux qui ne sont plus nécessaires, disponibles dans le stockage.
Afin de maintenir les tables dans un état optimal pour de meilleures performances, effectuez des opérations de compactage bin-compact et de nettoyage dans les tables Delta. Le compactage bin-compact est obtenu par la commande OPTIMIZE. Elle fusionne toutes les modifications dans des fichiers Parquet plus volumineux et consolidés. Le stockage déréférencé propre est obtenu par la commande VACUUM.
Les commandes de maintenance de table OPTIMIZE et VACUUM peuvent être utilisées dans les notebooks et les définitions de travaux Spark, puis orchestrées à l’aide de fonctionnalités de plateforme. Le Lakehouse dans Fabric offre une fonctionnalité permettant d’utiliser l’interface utilisateur pour effectuer une maintenance de table ad hoc, comme expliqué dans l’article Maintenance des tables Delta Lake.
Important
La conception correcte de la structure physique de la table en fonction de la fréquence d’ingestion et des modèles de lecture attendus est probablement plus importante que l’exécution des commandes d’optimisation décrites dans cette section.
Contrôler V-Order lors de l’optimisation d’une table
La commande suivante structure bin-compact et réécrit tous les fichiers affectés à l’aide de V-Order, indépendamment du paramètre TBLPROPERTIES ou du paramètre de configuration de session :
%%sql
OPTIMIZE <table|fileOrFolderPath> VORDER;
OPTIMIZE <table|fileOrFolderPath> WHERE <predicate> VORDER;
OPTIMIZE <table|fileOrFolderPath> WHERE <predicate> [ZORDER BY (col_name1, col_name2, ...)] VORDER;
Lorsque ZORDER et VORDER sont utilisés ensemble, Apache Spark effectue le compactage bin-compact, ZORDER, VORDER séquentiellement.
Les commandes suivantes effectuent une opération bin-compact et réécrivent tous les fichiers affectés à l’aide du paramètre TBLPROPERTIES. Si TBLPROPERTIES est défini sur true pour V-Order, tous les fichiers affectés sont écrits en tant que V-Order. Si TBLPROPERTIES est non défini ou défini sur false pour V-Order, il hérite du paramètre de session. Par conséquent, pour supprimer V-Order de la table, définissez la configuration de session sur false.
%%sql
OPTIMIZE <table|fileOrFolderPath>;
OPTIMIZE <table|fileOrFolderPath> WHERE predicate;
OPTIMIZE <table|fileOrFolderPath> WHERE predicate [ZORDER BY (col_name1, col_name2, ...)];