Supprimer les fichiers de données inutilisés avec la commande VACUUM

Supprimez les fichiers de données qui ne sont plus référencés par une table antérieure au seuil de rétention en exécutant la VACUUM commande 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.

Sur les tables avec les lectures Iceberg (UniForm) activées, VACUUM nettoie également les fichiers de métadonnées Iceberg inaccessibles. Voir VACUUM et le nettoyage des métadonnées d’Iceberg.

L’optimisation prédictive exécute automatiquement VACUUM sur les tables managées par Unity Catalog. Databricks recommande d’activer les optimisations prédictives pour toutes les tables managées par Unity Catalog afin de simplifier la maintenance des données et de réduire les coûts de stockage. Consultez Optimisation prédictive pour les tables managées Unity Catalog.

Mises en garde pour aspirateur

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.

VACUUM peut laisser derrière des répertoires vides après avoir supprimé tous les fichiers qu’ils contiennent. Les opérations VACUUM suivantes suppriment ces répertoires vides.

Certaines fonctionnalités de table, telles que les vecteurs de suppression, utilisent des fichiers de métadonnées pour marquer les données comme supprimées plutôt que de réécrire des fichiers de données. Permet REORG TABLE ... APPLY (PURGE) de valider ces suppressions et de réécrire les 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émantique des clones peu profonds VACUUM pour les tables gérées par Unity Catalog diffère des autres tables. Consultez Utilisation de VACUUM avec les clones superficiels Unity Catalog.
  • VACUUM supprime tous les fichiers des répertoires non gérés par Azure Databricks, ignorant les répertoires commençant 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, 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.
  • 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

Pour supprimer les fichiers qui ne sont plus requis par les versions antérieures à la période de rétention par défaut, exécutez VACUUM sans configurations supplémentaires :

VACUUM table_name

Pour afficher un aperçu de la liste des fichiers à supprimer sans les supprimer, exécutez VACUUM avec DRY RUN:

VACUUM table_name DRY RUN

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

Pour plus d’informations sur la syntaxe Scala, Java et Python, consultez la documentation de l’API Delta Lake.

Note

Dans Databricks Runtime 18.0 et versions ultérieures, utilisez la propriété de table deletedFileRetentionDuration pour contrôler la rétention. Pour les tables managées du catalogue Unity, cela s’applique à Databricks Runtime 13.3 LTS et versions ultérieures.

Voir Configurer la conservation des données pour des requêtes de voyage dans le temps.

Mode complet et lite

Important

Cette fonctionnalité est disponible en préversion publique dans Databricks Runtime 16.4 LTS et versions ultérieures.

Pour améliorer les performances et réduire les coûts en évitant de répertorier tous les fichiers dans le répertoire de table, spécifiez le LITE mot clé dans votre instruction vide pour déclencher un autre mode de VACUUM. Cela est utile pour les tables volumineuses qui nécessitent des opérations fréquentes VACUUM .

LITE le mode utilise le journal des transactions pour identifier les fichiers de données qui ne sont plus dans le VACUUM seuil de rétention et supprime ces fichiers de données de la table.

Note

L’exécution de VACUUM en mode LITE ne supprime pas les fichiers qui ne sont pas référencés dans le journal des transactions. Par exemple, les fichiers créés par une transaction abandonnée.

Utilisez la syntaxe suivante pour VACUUM en mode LITE :

VACUUM table_name LITE

FULL mode est la valeur par défaut pour le vide. Vous pouvez exécuter explicitement le mode complet avec la commande suivante :

VACUUM table_name FULL

Voir VACUUM.

Requirements

LITE mode a la configuration requise suivante :

  • Vous devez avoir exécuté au moins une opération réussie VACUUM dans le seuil de rétention du journal des transactions configuré (30 jours par défaut).

Si cette exigence n’est pas remplie, lorsque vous essayez d’exécuter VACUUM en LITE mode, le message d’erreur suivant s’affiche. Pour continuer, vous devez exécuter VACUUM en mode FULL.

VACUUM <tableName> LITE cannot delete all eligible files as some files are not referenced by the log. Please run VACUUM FULL.

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

La REORG TABLE commande avec la APPLY (PURGE) syntaxe vous permet de réécrire des données pour appliquer des suppressions douces. 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é. Voir REORG TABLE.

Les opérations qui créent des suppressions réversibles incluent les suivantes :

  • La suppression de colonnes avec le mappage de colonnes activé.
  • Toutes les modifications de données avec des vecteurs de suppression activés.

Lorsque les suppressions réversibles sont 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 fichiers plus anciens utilisés pour les déplacements temporels.
  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 pour garantir que les fichiers plus anciens ont 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é.

Recommandations relatives à la taille du cluster pour le vide

Pour sélectionner la taille de cluster appropriée, VACUUMconsidérez 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. Le travail compare cette liste à tous les fichiers actuellement référencés dans le journal des transactions pour identifier les fichiers à supprimer. Le pilote reste inactif pendant ce temps.
  2. Le pilote émet des commandes de suppression pour chaque fichier identifié pour la suppression. Étant donné que la suppression de fichier est une opération de pilote uniquement, toutes les opérations se produisent dans un nœud unique tandis que les nœuds Worker sont 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 pourriez envisager d'augmenter soit la taille du driver soit le nombre de travailleurs.

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 capacité du pilote.

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 par défaut pour l'aspirateur s’élève à 7 jours. La définition d’un seuil plus élevé vous permet d’accéder à un historique plus élevé pour votre table, mais augmente le nombre de fichiers de données stockés et, par conséquent, augmente les coûts de stockage de votre fournisseur de cloud.

Seuils sous vide et à faible rétention

Avertissement

Databricks recommande vivement de définir un intervalle de rétention d’au moins 7 jours. Si vous avez des travaux qui s’exécutent pendant plusieurs jours, les travaux de longue durée peuvent écrire des fichiers qui ne sont pas encore validés. Si votre période de rétention est trop courte, VACUUM pourrait supprimer ces fichiers non validés avant l'achèvement du travail.

Il y a un contrôle de sécurité pour vous empêcher d’exécuter une commande dangereuse VACUUM . Si vous êtes certain qu’aucune opération n’est exécutée sur cette table qui prend plus de temps que l’intervalle de rétention que vous prévoyez de spécifier, désactivez cette vérification de sécurité en définissant la retentionDurationCheck configuration Spark sur false:

Delta

SET spark.databricks.delta.retentionDurationCheck.enabled = false

Iceberg

SET spark.databricks.iceberg.retentionDurationCheck.enabled = false

Informations d'audit

VACUUM valide les informations d’audit dans le journal des transactions. Interrogez les événements d’audit à l’aide de DESCRIBE HISTORY.

Par défaut, la journalisation d’audit est activée sur toutes les plateformes pour les tables gérées par le catalogue Unity. Contrôler la journalisation des audits du vacuum à l’aide de la configuration Spark vacuum.logging :

Delta

SET spark.databricks.delta.vacuum.logging.enabled = true

Iceberg

SET spark.databricks.iceberg.vacuum.logging.enabled = true

Pour appliquer cette configuration à l’ensemble d’un espace de travail, pour tous les clusters, utilisez une stratégie de cluster et ajoutez ce qui suit au JSON de la stratégie :

Delta

{
  "spark_conf.spark.databricks.delta.vacuum.logging.enabled": {
    "type": "fixed",
    "value": "true"
  }
}

Iceberg

{
  "spark_conf.spark.databricks.iceberg.vacuum.logging.enabled": {
    "type": "fixed",
    "value": "true"
  }
}

Consultez Créer et gérer des stratégies de calcul.

Note

La journalisation d’audit est également activée par défaut pour les tables externes.

  • Last updated on