Meilleures pratiques : Delta Lake

Cet article décrit les meilleures pratiques lors de l’utilisation de Delta Lake.

Vue d’ensemble des meilleures pratiques

Voici les recommandations générales qui s’appliquent à la plupart des charges de travail Delta Lake :

• Utilisez des tables gérées par le catalogue Unity. Consultez les tables managées du catalogue Unity dans Azure Databricks pour Delta Lake et Apache Iceberg.
• Utilisez l’optimisation prédictive. Consultez Optimisation prédictive pour les tables managées Unity Catalog.
• Utilisez le clustering liquide. Voir Utilisation du clustering liquide pour les tables.
• Lors de la suppression et de la recréation d’une table dans le même emplacement, vous devez toujours utiliser une instruction CREATE OR REPLACE TABLE. Voir Supprimer ou remplacer une table Delta.

Supprimer les configurations Delta héritées

Databricks recommande de supprimer la plupart des configurations Delta héritées explicites des configurations Spark et des propriétés de table lors de la mise à niveau vers une nouvelle version de Databricks Runtime. Les configurations héritées peuvent empêcher les nouvelles optimisations et les valeurs par défaut introduites par Databricks d’être appliquées aux charges de travail migrées.

Fichiers compactés

L’optimisation prédictive exécute automatiquement les commandes OPTIMIZE et VACUUM sur des tables managées par Unity Catalog. Consultez Optimisation prédictive pour les tables managées Unity Catalog.

Databricks recommande fréquemment d’exécuter la OPTIMIZE commande pour compacter les petits fichiers.

N’utilisez pas la mise en cache Spark avec Delta Lake

Databricks vous déconseille d’utiliser la mise en cache Spark pour les raisons suivantes :

• Vous perdez toutes les données ignorées qui peuvent provenir de filtres supplémentaires ajoutés au-dessus du cache DataFrame.
• Les données mises en cache peuvent ne pas être mises à jour, si la table est consultée avec un identificateur différent.

Différences entre Delta Lake et Parquet sur Apache Spark

Delta Lake gère automatiquement les opérations suivantes. Vous ne devez jamais effectuer ces opérations manuellement :

• REFRESH TABLE : les tables Delta retournent toujours les informations les plus récentes. Il n’est donc pas nécessaire d’appeler REFRESH TABLE manuellement après des modifications.
• Ajouter et supprimer des partitions : Delta Lake effectue automatiquement le suivi de l’ensemble des partitions présentes dans une table, et met à jour la liste à mesure que des données sont ajoutées ou supprimées. Par conséquent, il n’est pas nécessaire d’exécuter ALTER TABLE [ADD|DROP] PARTITION ou MSCK.
• Charger une partition unique : la lecture directe des partitions n’est pas nécessaire. Par exemple, vous n’avez pas besoin d’exécuter spark.read.format("parquet").load("/data/date=2017-01-01"). Utilisez plutôt une clause WHERE pour ignorer les données, par exemple spark.read.table("<table-name>").where("date = '2017-01-01'").
• Ne modifiez pas manuellement les fichiers de données : Delta Lake utilise le journal des transactions pour valider les modifications apportées à la table de manière atomique. Ne modifiez, n’ajoutez et ne supprimez pas directement des fichiers de données Parquet dans une table Delta, car cela peut entraîner une perte de données ou l’endommagement de la table.

Améliorer les performances de la fusion Delta Lake

Vous pouvez réduire le temps pris par la fusion en adoptant les approches suivantes :

• Réduire l’espace de recherche des correspondances : par défaut, l’opération merge recherche dans la table Delta entière des correspondances dans la table source. Une manière d’accélérer l’opération merge consiste à réduire l’espace de recherche en ajoutant des contraintes connues dans la condition de correspondance. Par exemple, supposons que vous avez une table partitionnée par country et date, et que vous souhaitez utiliser merge pour mettre à jour les informations pour le dernier jour et un pays spécifique. L’ajout de la condition suivante accélère la requête, car elle recherche uniquement des correspondances dans les partitions appropriées :

  events.date = current_date() AND events.country = 'USA'
  

  De plus, cette requête contribue également à réduire les risques de conflits avec d’autres opérations concurrentes. Pour plus d’informations, consultez Niveaux d’isolation et conflits d’écriture sur Azure Databricks.

• Compacter les fichiers : si les données sont stockées dans de nombreux fichiers de petite taille, la lecture des données pour rechercher des correspondances peut devenir lente. Vous pouvez compacter des fichiers de petite taille dans des fichiers plus volumineux pour améliorer le débit de lecture. Pour plus d’informations, consultez Optimiser la disposition des fichiers de données.

• Contrôler les partitions de réarrangement pour l'écriture des données : l’opération merge réarrange plusieurs fois les données pour calculer et écrire les données mises à jour. Le nombre de tâches utilisées pour mélanger est contrôlé par la configuration de session Spark spark.sql.shuffle.partitions. La définition de ce paramètre permet non seulement de contrôler le parallélisme, mais aussi de déterminer le nombre de fichiers de sortie. L’augmentation de la valeur augmente le parallélisme, mais génère aussi un plus grand nombre de fichiers de données plus petits.

• Activer les écritures optimisées : pour les tables partitionnées, merge peut produire un beaucoup plus grand nombre de petits fichiers que le nombre de partitions générées de façon aléatoire. Cela est dû au fait que chaque tâche de mélange peut écrire plusieurs fichiers dans plusieurs partitions, ce qui peut entraîner un goulot d'étranglement au niveau des performances. Vous pouvez réduire le nombre de fichiers en activant les écritures optimisées. Consultez Écritures optimisées pour Delta Lake sur Azure Databricks.

• Ajuster la taille des fichiers dans le tableau : Azure Databricks peut détecter automatiquement si une table Delta comporte des opérations fréquentes merge de réécriture de fichiers et peut choisir de réduire la taille des fichiers réécrits en prévision de nouvelles réécritures de fichiers à l'avenir. Pour plus d’informations, consultez la section relative au réglage des tailles de fichier.

• Low Shuffle Merge : Low Shuffle Merge fournit une implémentation optimisée de MERGE qui offre de meilleures performances pour les charges de travail les plus courantes. En outre, elle conserve les optimisations de disposition des données existantes, telles que l'ordre Z sur des données non modifiées.