Aller au contenu principal
Dernière mise à jour le

Bonnes pratiques : Delta Lake

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

Vue d'ensemble des bonnes pratiques​

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

Supprimer les configurations Delta héritées​

Databricks vous 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 existantes peuvent empêcher de nouvelles optimisations et les valeurs 'default' introduites par Databricks d'être appliquées aux charges de travail migrées.

Compacter les fichiers​

L'optimisation prédictive exécute automatiquement les commandes OPTIMIZE et VACUUM sur les tables gérées par Unity Catalog. Consultez Optimisation prédictive pour les tables gérées par Unity Catalog.

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

remarque

Cette opération ne supprime pas les anciens fichiers. Pour les supprimer, exécutez la commande VACUUM.

Ne pas utiliser la mise en cache Spark avec Delta Lake​

Databricks ne recommande pas d'utiliser la mise en cache Spark pour les raisons suivantes :

  • Vous perdez tout saut de données pouvant provenir de filtres supplémentaires ajoutés au DataFrame mis en cache.
  • Les données mises en cache risquent de ne pas être mises à jour si la table est consultée à l'aide d'un identifiant 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 Lake renvoient toujours les informations les plus récentes, il n'est donc pas nécessaire d'appeler REFRESH TABLE manuellement après les modifications.
  • Ajouter et supprimer des partitions : Delta Lake suit automatiquement 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 seule partition : Il n'est pas nécessaire de lire directement les partitions. 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 l'omission de données, telle que spark.read.table("<table-name>").where("date = '2017-01-01'").
  • Ne modifiez pas manuellement les fichiers de données : Delta Lake utilise le Log de transaction pour commit les modifications de la table de manière atomique. Ne modifiez, n'ajoutez ou ne supprimez pas directement les fichiers de données Parquet dans une table Delta Lake, car cela peut entraîner une perte de données ou une corruption de la table.

Améliorer les performances pour les Merge Delta Lake​

Vous pouvez réduire le temps nécessaire à la Merge en utilisant les approches suivantes :

  • Réduire l'espace de recherche de correspondances : Par default, l'merge opération recherche l'intégralité de la table Delta Lake afin de trouver des correspondances dans la table source. Une façon d'accélérer merge est de réduire l'espace de recherche en ajoutant des contraintes connues dans la condition de correspondance. Par exemple, supposons que vous ayez une table partitionnée par country et date et que vous souhaitiez utiliser merge pour mettre à jour les informations du dernier jour et d'un pays spécifique. L'ajout de la condition suivante accélère la query, car elle ne recherche les correspondances que dans les partitions pertinentes :

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

    En outre, cette query réduit également les risques de conflits avec d'autres opérations concurrentes. Consultez les niveaux d'isolation et les conflits d'écriture pour plus de détails.

  • Fichiers compacts : si les données sont stockées dans de nombreux petits fichiers, la lecture des données pour rechercher des correspondances peut devenir lente. Vous pouvez compacter de petits fichiers en fichiers plus volumineux pour améliorer le throughput de lecture. Voir Optimiser le layout des fichiers de données pour plus de détails.

  • Contrôlez les partitions de shuffle pour les écritures : L’opération merge shuffles les données plusieurs fois pour compute et écrire les données mises à jour. Le nombre de tâches utilisées pour le shuffle est contrôlé par la configuration de session Spark spark.sql.shuffle.partitions. La définition de ce parameter contrôle non seulement le parallélisme, mais détermine également le nombre de fichiers de sortie. L’augmentation de la valeur accroît le parallélisme, mais génère également 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 nombre beaucoup plus important de petits fichiers que le nombre de partitions de brassage. C'est parce que chaque tâche de shuffle peut écrire plusieurs fichiers dans plusieurs partitions et peut devenir un goulot d'étranglement en termes de performances. Vous pouvez réduire le nombre de fichiers en activant les écritures optimisées. Voir écritures optimisées.

  • Ajuster la taille des fichiers dans une table : Databricks ajuste automatiquement la taille des fichiers en fonction de la taille de la table, en utilisant des fichiers plus petits pour les tables de petite taille et des fichiers plus grands pour les tables de grande taille. Consultez la section sur le réglage de la taille des fichiers pour plus de détails.

  • Low Shuffle Merge : Low Shuffle Merge fournit une implémentation optimisée de MERGE qui offre de meilleures performances pour la plupart des workloads courants. En outre, il préserve les optimisations existantes du Layout des données, telles que le clustering liquide sur les données non modifiées.

Sur cette page