Supprimer les fichiers de données inutilisés avec le nettoyage
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.
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.
Mises en garde pour vacuum
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.
Databricks recommande d’utiliser l’optimisation prédictive afin d’exécuter automatiquement VACUUM
pour les tables Delta. Consultez Optimisation prédictive pour les tables managées Unity Catalog.
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émantique
VACUUM
des 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
.- Les données du flux des changements de données sont gérées par Delta Lake dans le répertoire
_change_data
et supprimées avecVACUUM
. Consultez Utiliser le flux des changements de données Delta Lake sur Azure Databricks. - Les index de filtre Bloom utilisent le répertoire
_delta_index
géré par Delta Lake.VACUUM
nettoie les fichiers de ce répertoire. Consultez Index de filtre Bloom.
- Les données du flux des changements de données sont gérées par Delta Lake dans le répertoire
- 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 deVACUUM
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 table_name -- vacuum files not required by versions older than the default retention period
VACUUM table_name RETAIN 100 HOURS -- vacuum files not required by versions more than 100 hours old
VACUUM table_name 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 :
- 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. - 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 :
- 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.
- 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
.