Supprimer les fichiers de données inutilisés avec le nettoyage

  • Article

Vous pouvez supprimer des fichiers de données qui ne sont plus référencés par une table Delta qui sont antérieurs au seuil de conservation des données en exécutant la commande VACUUM sur la table. L’exécution régulière de VACUUM est importante pour les coûts et la conformité en raison des considérations suivantes :

  • La suppression des fichiers de données inutilisés réduit les coûts de stockage cloud.
  • Les fichiers de données supprimés par VACUUM peuvent contenir des enregistrements qui ont été modifiés ou supprimés. La suppression définitive de ces fichiers du stockage cloud garantit que ces enregistrements ne sont plus accessibles.

Le seuil de rétention par défaut pour des fichiers de données après l’exécution de VACUUM est de 7 jours. Pour modifier ce comportement, consultez Configurer la conservation des données pour des requêtes de voyage dans le temps.

Databricks recommande d’utiliser l’optimisation prédictive afin d’exécuter automatiquement VACUUM pour les tables Delta. Consultez l’article Optimisation prédictive pour Delta Lake.

Certaines fonctionnalités de Delta Lake utilisent des fichiers de métadonnées pour marquer les données comme supprimées plutôt que de réécrire les fichiers de données. Vous pouvez utiliser REORG TABLE ... APPLY (PURGE) pour valider ces suppressions et réécrire des fichiers de données. Consultez Supprimer uniquement les métadonnées pour forcer la réécriture des données.

Important

  • Dans Databricks Runtime 13.3 LTS et versions ultérieures, la sémantiqueVACUUMdes clones superficiels avec des tableaux gérés Unity Catalog diffère des autres tableaux Delta. Consultez Clones superficiels vides et Unity Catalog.
  • VACUUM supprime tous les fichiers des répertoires non gérés par Delta Lake, tout en ignorant les répertoires commençants par _ ou .. Si vous stockez des métadonnées supplémentaires telles que des points de contrôle Structured Streaming dans un répertoire de table Delta, utilisez un nom de répertoire tel que _checkpoints.
  • La possibilité d’interroger des versions de table antérieures à la période de conservation est perdue après l’exécution de VACUUM.
  • Les fichiers journaux sont supprimés automatiquement et de manière asynchrone après des opérations de vérification et ne sont pas régis par VACUUM. Alors que la période de rétention par défaut des fichiers journaux est de 30 jours, l’exécution de VACUUM sur une table supprime les fichiers de données nécessaires pour le voyage dans le temps.

Notes

Lorsque la mise en cache du disque est activée, il peut arriver qu’un cluster contienne des données de fichiers Parquet supprimés avec la commande VACUUM. Par conséquent, il est possible d’interroger les données de versions précédentes de la table, dont les fichiers ont été supprimés. Le redémarrage du cluster entraîne la suppression des données mises en cache. Consultez Configurer le cache de disque.

Exemple de syntaxe pour le nettoyage

VACUUM eventsTable   -- vacuum files not required by versions older than the default retention period

VACUUM '/data/events' -- vacuum files in path-based table

VACUUM delta.`/data/events/`

VACUUM delta.`/data/events/` RETAIN 100 HOURS  -- vacuum files not required by versions more than 100 hours old

VACUUM eventsTable DRY RUN    -- do dry run to get the list of files to be deleted

Pour plus d’informations sur la syntaxe de Spark SQL, consultez VACUUM.

Pour plus d’informations sur les syntaxes Scala, Java et Python, consultez Documentation sur l’API Delta Lake.

Remarque

Utilisez le mot clé RETAIN afin de spécifier le seuil utilisé pour déterminer si un fichier de données doit être supprimé. La commande VACUUM utilise ce seuil pour revenir à une date antérieure spécifiée et identifier la version de table la plus récente à ce moment-là. Delta conserve tous les fichiers de données requis afin d’interroger cette version de table et toutes les versions de table plus récentes. Ce paramètre interagit avec d’autres propriétés de table. Voir Configurer la conservation des données pour des requêtes de voyage dans le temps.

Supprimer uniquement les métadonnées pour forcer la réécriture des données

La commande REORG TABLE fournit la syntaxe APPLY (PURGE) permettant de réécrire les données afin d’appliquer des suppressions réversibles. Les suppressions réversibles ne réécrivent pas les données et ne suppriment pas les fichiers de données, mais utilisent plutôt des fichiers de métadonnées pour indiquer que certaines valeurs de données ont changé. Consultez REORG TABLE.

Les opérations qui créent des suppressions réversibles dans Delta Lake sont les suivantes :

  • la suppression de colonnes avec le mappage de colonnes activé.
  • la suppression de lignes avec des vecteurs de suppression activés.
  • Toutes les modifications de données sur les clusters avec Photon lorsque les vecteurs de suppression sont activés.

Une fois les suppressions réversibles activées, les anciennes données peuvent rester physiquement présentes dans les fichiers actuels de la table, même après la suppression ou la mise à jour des données. Pour supprimer physiquement ces données de la table, procédez comme suit :

  1. Exécutez REORG TABLE ... APPLY (PURGE). Après cela, les anciennes données ne sont plus présentes dans les fichiers actuels de la table, mais elles sont toujours présentes dans les anciens fichiers utilisés pour le voyage dans le temps.
  2. Exécutez VACUUM pour supprimer ces fichiers plus anciens.

REORG TABLE crée une nouvelle version de la table à mesure que l’opération se termine. Toutes les versions de tables de l’historique avant cette transaction font référence à des fichiers de données plus anciens. D’un point de vue conceptuel, cela est similaire à la commande OPTIMIZE, où les fichiers de données sont réécrits même si les données de la version actuelle de la table restent cohérentes.

Important

Les fichiers de données ne sont supprimés que lorsque les fichiers ont expiré en fonction de la période de rétention de VACUUM. Cela signifie que le VACUUM doit être effectué avec un délai après le REORG afin que les fichiers plus anciens aient expiré. La période de conservation de VACUUM peut être réduite pour raccourcir le temps d’attente requis, au prix d’une réduction de l’historique maximal qui est conservé.

De quelle taille de cluster le nettoyage a-t-il besoin ?

Pour sélectionner la taille de cluster appropriée pour VACUUM, il est utile de comprendre que l’opération se produit en deux phases :

  1. Le travail commence par l’utilisation de tous les nœuds de l’exécuteur disponibles pour répertorier les fichiers dans le répertoire source en parallèle. Cette liste est comparée à tous les fichiers actuellement référencés dans le journal des transactions Delta pour identifier les fichiers à supprimer. Le pilote reste inactif pendant ce temps.
  2. Le pilote émet ensuite des commandes de suppression pour chaque fichier à supprimer. La suppression de fichiers est une opération de pilote uniquement, ce qui signifie que toutes les opérations se produisent sur un seul nœud alors que les nœuds Worker restent inactifs.

Pour optimiser les coûts et les performances, Databricks recommande les éléments suivants, en particulier pour les tâches de nettoyage de longue durée :

  • Exécutez le nettoyage sur un cluster avec mise à l’échelle automatique définie pour 1 à 4 Workers, où chacun a 8 cœurs.
  • Sélectionnez un pilote avec entre 8 et 32 cœurs. Augmentez la taille du pilote pour éviter les erreurs de mémoire insuffisante (OOM).

Si les opérations de VACUUM suppriment régulièrement plus de 10 000 fichiers ou prennent plus de 30 minutes de temps de traitement, vous pouvez augmenter la taille du pilote ou le nombre de Workers.

Si vous constatez que le ralentissement se produit lors de l’identification des fichiers à supprimer, ajoutez d’autres nœuds Worker. Si le ralentissement se produit pendant l’exécution des commandes de suppression, essayez d’augmenter la taille du pilote.

À quelle fréquence devez-vous exécuter le nettoyage ?

Databricks recommande d’exécuter VACUUM régulièrement sur toutes les tables pour réduire les coûts de stockage de données cloud excédentaires. Le seuil de conservation des données par défaut pour le nettoyage s’élève à 7 jours. La définition d’un seuil plus élevé vous donne accès à un plus grand historique pour votre table, mais augmente le nombre de fichiers de données stockés et, par conséquent, entraîne des coûts de stockage plus élevés de la part de votre fournisseur de cloud.

Pourquoi ne pouvez-vous pas nettoyer une table Delta avec un seuil de conservation faible ?

Avertissement

Nous vous recommandons de définir un intervalle de rétention d’au moins sept jours, car les anciens instantanés et les fichiers non validés peuvent toujours être utilisés par des lecteurs ou des enregistreurs simultanés dans la table. Si VACUUM nettoie les fichiers actifs, les lecteurs concurrents risquent d’échouer ou, pire, les tables peuvent être corrompues lorsque VACUUM supprime des fichiers qui n'ont pas encore été validés. Vous devez choisir un intervalle qui plus long que la plus longue transaction simultanée en cours d’exécution et la période la plus longue pendant laquelle un flux peut dépasser la mise à jour la plus récente de la table.

Delta Lake effectue un contrôle de sécurité pour vous éviter d'exécuter une commande VACUUM dangereuse. Si vous êtes certain qu'aucune opération effectuée sur cette table ne prend plus de temps que l'intervalle de rétention que vous comptez spécifier, vous pouvez désactiver ce contrôle de sécurité en réglant la propriété de configuration Spark spark.databricks.delta.retentionDurationCheck.enabled sur false.

Informations d'audit

Les validations de VACUUM dans le journal des transactions Delta contiennent des informations d’audit. Vous pouvez interroger les événements d’audit à l’aide de la syntaxe DESCRIBE HISTORY.