Aller au contenu principal
Dernière mise à jour le

Supprimer les fichiers de données inutilisés avec vacuum

Supprimez les fichiers de données qui ne sont plus référencés par une table et qui sont plus anciens que le threshold de rétention 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 pourraient 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.

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

Mises en garde concernant vacuum​

Le default retention threshold pour les fichiers de données après l'exécution de VACUUM est de 7 jours. Pour modifier ce comportement, consultez Configurer la rétention des données pour les queries time travel.

VACUUM pourraient laisser des répertoires vides après avoir supprimé tous les fichiers qu'ils contiennent. Les opérations VACUUM ultérieures 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 les fichiers de données. Utilisez REORG TABLE ... APPLY (PURGE) pour commit ces suppressions et réécrire les fichiers de données. Consultez Purgez les suppressions de métadonnées uniquement pour forcer la réécriture des données.

important

  • Dans Databricks Runtime 13.3 LTS et versions ultérieures, la sémantique VACUUM pour les clones superficiels avec les tables gérées par Unity Catalog diffère des autres tables. Consultez Utiliser VACUUM avec les clones superficiels d'Unity Catalog.

  • VACUUM supprime tous les fichiers des répertoires non gérés par Databricks, en ignorant les répertoires commençant par _ ou .. Si vous stockez des métadonnées supplémentaires telles que des checkpoints Structured Streaming dans un répertoire de table, utilisez un nom de répertoire tel que _checkpoints.

  • La possibilité de query des versions de table antérieures à la période de rétention est perdue après l'exécution de VACUUM.

  • Les fichiers Logs sont supprimés automatiquement et de manière asynchrone après les Opérations de point de contrôle et ne sont pas régis par VACUUM. Bien que la période de rétention par default des fichiers Logs soit de 30 jours, l'exécution de VACUUM sur une table supprime les fichiers de données nécessaires pour le time travel.

  • Lorsque la mise en cache sur disque est activée, un cluster peut contenir des données provenant de fichiers Parquet qui ont été supprimés avec VACUUM. Par conséquent, il peut être possible d'interroger les données des versions précédentes de la table dont les fichiers ont été supprimés. Le redémarrage du cluster supprimera les données mises en cache. Consultez Configurer le cache disque.

Exemple de syntaxe pour vacuum​

Pour supprimer les fichiers qui ne sont plus nécessaires pour les versions antérieures à la période de rétention default, exécutez VACUUM sans configuration supplémentaire :

SQL
VACUUM table_name

Pour prévisualiser la liste des fichiers à supprimer sans les retirer, exécutez VACUUM avec DRY RUN:

SQL
VACUUM table_name DRY RUN

Pour plus de détails sur la syntaxe Spark SQL, veuillez consulter VACUUM.

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

remarque

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 gérées par Unity Catalog, cela s'applique à Databricks Runtime 13.3 LTS et versions ultérieures.

Consultez Configurer la conservation des données pour les requêtes time travel.

Mode complet versus léger​

info

Aperçu

Cette fonctionnalité est en Aperçu public dans Databricks Runtime 16,4 LTS et versions supérieures.

Pour améliorer les performances et réduire les coûts en évitant de lister tous les fichiers du répertoire de la table, spécifiez le mot-clé LITE dans votre déclaration vacuum pour Trigger un mode alternatif de VACUUM. Ceci est utile pour les grandes tables qui nécessitent des opérations VACUUM fréquentes.

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

remarque

L'exécution de VACUUM en mode LITE ne supprimera aucun fichier qui n'est pas référencé dans le log des transactions. Par exemple, les fichiers qui ont été créés par une transaction abandonnée.

Utilisez la syntaxe suivante pour VACUUM en mode LITE :

SQL
VACUUM table_name LITE

FULL le mode est le default pour vacuum. Vous pouvez exécuter explicitement le mode complet avec la commande suivante :

SQL
VACUUM table_name FULL

See vacuum.

Exigences​

LITE Le mode présente l'exigence suivante :

  • Vous devez avoir exécuté au moins une opération VACUUM réussie dans le threshold de rétention des Logs de transaction configuré (30 jours by default).

Si cette exigence n'est pas remplie, lorsque vous essayez d'exécuter VACUUM en mode LITE, 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.

Purger les suppressions de métadonnées uniquement pour forcer la réécriture des données​

La commande REORG TABLE avec la syntaxe APPLY (PURGE) vous permet de réécrire les données pour appliquer des suppressions logiques. Les suppressions logiques ne réécrivent pas les données ni ne suppriment 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é. See REORG TABLE.

Les Opérations qui créent des suppressions logiques incluent les suivantes :

  • Suppression des colonnes avec le mappage des colonnes activé.
  • Toute modification de données avec les vecteurs de suppression activés.

Avec la suppression réversible activée, 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, suivez les étapes suivantes :

  1. Exécutez REORG TABLE ... APPLY (PURGE). Après avoir fait 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 qui sont utilisées pour le Time Travel.
  2. Exécutez VACUUM pour supprimer ces fichiers plus anciens.

REORG TABLE crée une nouvelle version de la table une fois l'opération terminée. Toutes les versions de table dans l'historique antérieures à cette transaction se réfèrent à des fichiers de données plus anciens. Conceptuellement, 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é* selon la VACUUM période de rétention de. 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 rétention de VACUUM peut être réduite pour raccourcir le temps d'attente requis, au détriment de la réduction de l'historique maximal conservé.

Recommandations de taille de cluster pour vacuum​

Pour sélectionner la taille de cluster correcte pour VACUUM, considérez que l'Opération se déroule en deux phases :

  1. Le Job commence par utiliser tous les nœuds d'exécution disponibles pour lister les fichiers du répertoire source en parallèle. Le Job compare cette liste à tous les fichiers actuellement référencés dans le log de transactions pour identifier les fichiers à supprimer. Le driver reste inactif pendant cette période.
  2. Le Driver envoie des commandes de suppression pour chaque fichier identifié pour la suppression. Étant donné que la suppression de fichiers est une opération du Driver uniquement, toutes les Opérations se produisent sur un seul nœud tandis que les nœuds Worker restent inactifs.

Pour optimiser les coûts et les performances, Databricks recommande ce qui suit, en particulier pour les Jobs vacuum de longue durée :

  • Exécutez vacuum sur un cluster avec mise à l'échelle automatique définie pour 1 à 4 Worker, où chaque Worker dispose de 8 cœurs.
  • Sélectionnez un driver avec entre 8 et 32 cœurs. Augmentez la taille du Driver pour éviter les erreurs de mémoire insuffisante (OOM).

Si les VACUUM Opérations suppriment régulièrement plus de 10 000 fichiers ou prennent plus de 30 minutes de temps de traitement, vous pourriez envisager d'augmenter la taille du Driver ou le nombre de Workers.

Si 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 Driver.

Fréquence de vacuum recommandée​

Databricks recommande d'exécuter régulièrement VACUUM sur toutes les tables pour réduire les coûts de stockage de données cloud excessifs. Le threshold de rétention default pour vacuum est de 7 jours. La définition d'un threshold plus élevé vous donne accès à un historique plus complet pour votre table, mais augmente le nombre de fichiers de données stockés et, par conséquent, les coûts de stockage auprès de votre fournisseur cloud.

Vacuum et thresholds de rétention faibles​

attention

Databricks recommande vivement de définir un intervalle de rétention d'au moins 7 jours. Si vous avez des jobs qui s'exécutent pendant plusieurs jours, les jobs de longue durée pourraient é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 que le job ne se termine.

Il existe une vérification de sécurité pour vous empêcher d'exécuter une commande VACUUM dangereuse. Si vous êtes certain qu'aucune opération n'est en cours d'exécution sur cette table qui prendrait 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 configuration Spark retentionDurationCheck sur false:

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

Informations d'audit​

VACUUM commits les informations d'audit dans le journal des transactions. Interroger 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 Unity Catalog. Contrôlez la journalisation d'audit de vacuum avec la configuration vacuum.logging Spark :

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

Pour appliquer cette configuration à un Workspace entier, sur tous les clusters, utilisez une politique de cluster et ajoutez ce qui suit au JSON de la politique :

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

Voir Créer et gérer les politiques de compute.

important

Sur AWS, la journalisation d'audit n'est pas activée par default pour les tables externes stockées sur S3 en raison des garanties de cohérence limitées que S3 offre pour les écritures multi-workspace. Pour capturer les informations d'audit pour les tables externes, vous devez explicitement activer cette configuration. Si vous activez la journalisation d'audit pour les tables sur S3, vérifiez qu'aucun Lakeflow Jobs n'utilise les écritures multi-workspace. Ne pas le faire pourrait entraîner une perte de données.

Sur cette page