Taille de la table sur Databricks
La taille de la table signalée pour les tables Delta Lake et Apache Iceberg diffère de la taille totale des répertoires de fichiers correspondants dans le stockage d'objets cloud. Ces formats de données conservent les versions précédentes des fichiers de données pour permettre les queries time travel. Les fichiers de données ne sont supprimés que lorsque VACUUM s'exécute après le dépassement du threshold de rétention. Voir Supprimer les fichiers de données inutilisés avec vacuum.
Pourquoi la taille de la table diffère de celle du répertoire
Les tailles de table signalées dans Databricks via les interfaces utilisateur et les commandes DESCRIBE font référence à la taille totale des fichiers de données en stockage pour les fichiers référencés dans la version actuelle de la table. La plupart des opérations qui écrivent dans des tables nécessitent la réécriture des fichiers de données sous-jacents et conservent les anciens fichiers de données pour permettre les requêtes Time Travel.
Si vous supprimez ou mettez à jour régulièrement des enregistrements dans les tables, les vecteurs de suppression peuvent accélérer les query et réduire la taille totale des fichiers de données. Découvrir les vecteurs de suppression dans Databricks.
Compute storage metrics for a table
S'applique à : 
Databricks Runtime 18.0 et versions ultérieures
Pour comprendre pourquoi la taille totale du stockage diffère de la taille de la table, utilisez ANALYZE TABLE … COMPUTE STORAGE METRICS. Cette commande affiche une répartition détaillée de l’allocation de stockage, ce qui vous aide :
- Identifier les opportunités d'optimisation des coûts : Voir la quantité de stockage pouvant être récupérée avec
VACUUM - Analysez le surcoût lié au time travel : comprenez le coût de la conservation des données historiques.
- **Suivre les modèles de stockage** : surveillez l'évolution du stockage des tables au fil du temps en exécutant la commande périodiquement.
- Auditez le stockage sur toutes les tables : exécutez la commande en boucle pour analyser l'intégralité de votre patrimoine de données
La commande renvoie des métriques complètes, y compris :
- Taille totale du stockage : empreinte complète incluant toutes les données, métadonnées et Logs
- Données actives : Taille de la version actuelle de la table
- Données récupérables : Espace pouvant être récupéré
- **time travel data** : Données historiques pour les restaurations
Ceci est particulièrement utile pour les tables gérées par Unity Catalog où Databricks gère automatiquement le stockage grâce à l'optimisation prédictive.
Voir ANALYZE TABLE … COMPUTE STORAGE METRICS pour la syntaxe complète et des exemples.
Utilisez l'optimisation prédictive pour contrôler la taille des données
Databricks recommande d'utiliser les tables gérées par Unity Catalog avec l'optimisation prédictive activée. Avec les tables gérées et l'optimisation prédictive, Databricks exécute automatiquement les commandes OPTIMIZE et VACUUM pour empêcher l'accumulation de fichiers de données inutilisés. Attendez-vous à ce qu'il y ait toujours une différence de taille entre la version actuelle d'une table et la taille totale des fichiers de données dans le stockage objet cloud. Les fichiers de données non référencés dans la version actuelle sont nécessaires pour prendre en charge les queries time travel. Voir Optimisation prédictive pour les tables gérées par Unity Catalog.
Métriques de stockageVACUUM
Lorsque vous nettoyez les fichiers de données inutilisés avec VACUUM ou utilisez DRY RUN pour prévisualiser les fichiers configurés pour la suppression, les métriques indiquent le nombre de fichiers et la taille des données supprimées. La taille et le nombre de fichiers supprimés par VACUUM varient considérablement, mais il est courant que la taille des fichiers supprimés dépasse la taille totale de la version actuelle de la table.
Métriques de stockageOPTIMIZE
Lorsque OPTIMIZE s'exécute sur une table cible, les nouveaux fichiers de données combinent les enregistrements des fichiers de données existants. Les modifications effectuées pendant OPTIMIZE n'affectent que l'organisation des données, et aucune modification n'est apportée au contenu des données sous-jacentes. La taille totale des fichiers de données sous-jacents de la table augmente après l'exécution de OPTIMIZE, car les nouveaux fichiers compactés coexistent dans le répertoire conteneur avec les anciens fichiers de données non optimisés.
La taille de la table signalée après OPTIMIZE est généralement inférieure à la taille avant l'exécution de OPTIMIZE, car la taille totale des fichiers de données référencés par la version actuelle de la table diminue avec la compaction des données. Pour supprimer les fichiers de données sous-jacents, VACUUM doit être exécuté après le dépassement du threshold de rétention.
Vous pourriez voir des métriques similaires pour des opérations telles que REORG TABLE ou DROP FEATURE. Toutes les opérations qui nécessitent la réécriture de fichiers de données augmentent la taille totale des données dans le répertoire conteneur jusqu’à ce que VACUUM supprime les fichiers de données qui ne sont plus référencés dans la version actuelle de la table.