Optimisation de la table Delta Lake et ordre en V
Le format de table Lakehouse et Delta Lake sont essentiels à Microsoft Fabric. Il est essentiel que les tables soient optimisées pour l’analytique. Ce guide décrit les concepts et les configurations d’optimisation des tables Delta Lake et explique comment l’appliquer aux modèles d’utilisation du Big Data les plus courants.
Important
Microsoft Fabric est actuellement en préversion. Certaines informations portent sur un produit en préversion susceptible d’être substantiellement modifié avant sa publication. Microsoft ne donne aucune garantie, expresse ou implicite, concernant les informations fournies ici.
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 triés en V 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 triés en V avec une moyenne de temps de lecture 10 % plus rapides, avec certains scénarios jusqu’à 50 %.
V-Order fonctionne en appliquant un tri spécial, la distribution de groupes de lignes, l’encodage 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 un rapport coût-efficacité et des 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 conforme ; tous les moteurs parquet peuvent le lire comme un fichier parquet normal. 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, compactage, vide, voyage dans le temps, etc. sont orthogonaux à V-Order, 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 | Valeur par défaut | Description |
|---|---|---|
| spark.sql.parquet.vorder.enabled | true | Contrôle l’écriture de L’ordre V au niveau de la session. |
| TBLPROPERTIES(« delta.parquet.vorder.enabled ») | false | Mode ordre V par défaut sur les tables |
| Option d’enregistreur de trame de données : parquet.vorder.enabled | Unset | 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 l’ordre virtuel dans la session Apache Spark
%%sql
GET spark.sql.parquet.vorder.enabled
Désactiver l’écriture V-Order dans la session Apache Spark
%%sql
SET spark.sql.parquet.vorder.enabled=FALSE
Activer l’écriture V-Order dans la session Apache Spark
Important
Lorsqu’il est activé 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 parquet.vorder.enabled propriété de table définie sur true ou false.
%%sql
SET spark.sql.parquet.vorder.enabled=TRUE
Contrôler L’ordre en V à 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 fonctionnent. Si la configuration de session V-Order est définie sur true ou si spark.write l’active, les écritures sont 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 sa création. Pour modifier la structure physique actuelle afin d’appliquer ou de supprimer V-Order, lisez la section « Contrôler l’ordre V 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’ils ne sont pas explicites. 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 applique uniquement les 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. Les charges de travail d’ingestion dans des tables data lake peuvent avoir la caractéristique héritée d’écrire constamment de nombreux petits fichiers ; ce scénario est communément appelé « problème de petit fichier ».
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 du fichier cible peut être modifiée en fonction des exigences d’une charge de travail à l’aide de configurations.
La fonctionnalité est activée par défaut dans Microsoft Fabric Runtime pour Apache Spark. Pour en savoir plus sur optimiser les scénarios d’utilisation de l’écriture, lisez l’article 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 aléatoire faible, les lignes non modifiées sont exclues d’une opération de shuffling coûteuse nécessaire à la mise à jour des lignes correspondantes.
L’implémentation est contrôlée par la spark.microsoft.delta.merge.lowShuffle.enabled configuration, activée par défaut dans le runtime. Il 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 aléatoire faible, lisez l’article Optimisation de la fusion aléatoire faible sur les tables Delta
Maintenance de la table 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 apporter 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 que l’ensemble de modifications, amplifiant davantage les problèmes imposés par les deux premiers éléments.
- Plus besoin de fichiers de données et de fichiers journaux disponibles dans le stockage.
Afin de maintenir les tables dans un état optimal pour de meilleures performances, effectuez des opérations de compactage et de nettoyage dans les tables Delta. Le compactage bin 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.
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 l’ordre en V 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, ZORDER, VORDER séquentiellement.
Les commandes suivantes sont bin-compact et réécrire tous les fichiers affectés à l’aide du paramètre TBLPROPERTIES. Si TBLPROPERTIES est défini sur true sur 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 sur 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, ...)];