Partager via

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.

Important

Les OPTIMIZE commandes de cet article sont des commandes Spark SQL et doivent être exécutées dans des environnements Spark tels que :

Ces commandes ne sont pas prises en charge dans l’éditeur de requête SQL Analytics Endpoint ou Warehouse SQL, qui prennent uniquement en charge les commandes T-SQL. Pour la maintenance des tables via le point de terminaison SQL Analytics, utilisez les options de l’interface utilisateur pour la maintenance dans Lakehouse ou exécutez les commandes dans un notebook Fabric.

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 similaires à ceux obtenus avec des données en mémoire. 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 optimise les fichiers Parquet via le tri, la distribution de groupes de lignes, l’encodage et la compression, ce qui réduit l’utilisation des ressources et améliore les performances et l’efficacité des coûts. Bien qu’il ajoute ~15% aux temps d’écriture, il peut augmenter la compression d’un maximum de 50%. Le tri V-Order a un impact de 15 % sur les temps d’écriture moyens, mais offre jusqu’à 50 % de compression supplémentaire.

Il est 100 % conforme au format Parquet open source ; 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 pour contrôler l’ordre V de ses partitions.

V-Order est appliqué au niveau du fichier Parquet. Les tables Delta et leurs fonctionnalités, telles que Z-Order, le compactage, le nettoyage, le voyage dans le temps, etc., sont orthogonales à V-Order. Elles sont donc compatibles et peuvent être utilisées ensemble pour des bénéfices supplémentaires.

Contrôle des écritures V-Order

V-Order est utilisé pour optimiser la disposition des fichiers Parquet afin d'améliorer les performances des requêtes, en particulier dans les scénarios de lecture intensive. Dans Microsoft Fabric, V-Order est désactivé par défaut pour tous les espaces de travail nouvellement créés afin d’optimiser les performances pour les charges de travail d’ingénierie de données lourdes en écriture.

Le comportement de l'ordre V dans Apache Spark est contrôlé par les configurations suivantes :

Paramétrage Valeur par défaut Descriptif
spark.sql.parquet.vorder.default false Contrôle l'écriture en V-Order au niveau de la session. false Défini par défaut dans les nouveaux espaces de travail Fabric.
TBLPROPERTIES("delta.parquet.vorder.enabled") Annuler Le comportement par défaut de V-Order est contrôlé au niveau de la table.
Option d’enregistreur DataFrame : parquet.vorder.enabled Annuler Permet de contrôler V-Order au niveau de l’opération d’écriture.

Utilisez les commandes suivantes pour activer ou remplacer les écritures V-Order en fonction des besoins de votre scénario.

Important

  • L'option de commande virtuelle est désactivée par défaut dans les nouveaux espaces de travail Fabric (spark.sql.parquet.vorder.default=false) pour améliorer les performances des pipelines d'ingestion et de transformation des données.

  • Si votre charge de travail est en lecture intensive, comme les requêtes interactives ou le tableau de bord, activez V-Order avec les configurations suivantes :

    • Définissez la propriété Spark spark.sql.parquet.vorder.default sur true.
    • Changer les profils de ressources vers les profils readHeavyforSpark ou ReadHeavy. Ce profil active automatiquement v-Order pour améliorer les performances de lecture.

Dans le runtime Fabric 1.3 et versions ultérieures, le spark.sql.parquet.vorder.enable paramètre est supprimé. Étant donné que V-Order est appliqué automatiquement pendant l’optimisation Delta à l’aide d’instructions OPTIMIZE, il n’est pas nécessaire d’activer manuellement ce paramètre dans les versions d’exécution plus récentes. Si vous migrez du code à partir d’une version d’exécution antérieure, vous pouvez supprimer ce paramètre, car le moteur le gère automatiquement.

Vérifier la configuration de V-Order dans une session Apache Spark

%%sql 
SET spark.sql.parquet.vorder.default

Désactiver l’écriture V-Order dans une session Apache Spark

%%sql 
SET spark.sql.parquet.vorder.default=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 le V-Order activé, ce qui comprend les tables parquet non Delta et les tables Delta avec la propriété de table définie sur parquet.vorder.enabled, true ou false.

%%sql 
SET spark.sql.parquet.vorder.default=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 a la valeur true, les commandes INSERT, UPDATE et MERGE se comportent comme prévu et effectuent l’optimisation du temps d’écriture. Si la configuration de la session V-Order a la valeur true ou si spark.write l’active, les écritures sont V-Order même si le TBLPROPERTIES a la valeur 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 pour appliquer ou supprimer V-Order, découvrez comment contrôler V-Order lors de l’optimisation d’une table.

Contrôler directement le V-Order lors des 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.default 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 Optimize Write ?

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 ».

Optimize Write est une fonctionnalité Delta Lake dans Fabric et Synapse qui réduit le nombre de fichiers et augmente la taille de fichier individuelle pendant les écritures dans Apache Spark. 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 "Low Shuffle Merge", où les lignes non modifiées sont exclues d’une opération de réorganisation 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 ajoutent une surcharge de lecture. Les fichiers Parquet sont immuables par conception. Quand les tables Delta ajoutent de nouveaux fichiers Parquet avec l’ensemble de modifications, cela amplifie encore les problèmes posé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. Celle-ci fusionne toutes les modifications dans des fichiers Parquet plus volumineux et consolidés. Le nettoyage du stockage déréférencé s'effectue à l'aide de 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 de la structure physique de la table en fonction de la fréquence d’ingestion et des modèles de lecture est souvent plus importante que les commandes d’optimisation de 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 n’est pas défini ou défini sur false, il hérite du paramètre de session. Pour supprimer V-Order de la table, définissez la configuration de session sur false.

Note

Lorsque vous utilisez ces commandes dans les notebooks Fabric, vérifiez qu’il existe un espace entre %%sql et la OPTIMIZE commande. La syntaxe correcte est la suivante :

%%sql 
OPTIMIZE table_name;

Non:%%sqlOPTIMIZE table_name; (cela entraîne une erreur de syntaxe)

%%sql 
OPTIMIZE <table|fileOrFolderPath>;

OPTIMIZE <table|fileOrFolderPath> WHERE predicate;

OPTIMIZE <table|fileOrFolderPath> WHERE predicate [ZORDER BY (col_name1, col_name2, ...)];

Contenu connexe

  • Last updated on