Taille de table sur Azure Databricks

La taille de 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 des requêtes de voyage dans le temps. Les fichiers de données ne sont supprimés que lorsque VACUUM s’exécute une fois le seuil de rétention dépassé. Consultez Supprimer les fichiers de données inutilisés avec le nettoyage.

Pourquoi la taille de la table diffère de la taille du répertoire

Les tailles de table indiquées dans Azure Databricks dans les interfaces utilisateur et via les commandes DESCRIBE font référence à la taille totale des fichiers de données stockés 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 des requêtes de voyage dans le temps.

Remarque

Si vous supprimez ou mettez à jour régulièrement des enregistrements dans des tables, il est possible que des vecteurs de suppression permettent d’accélérer les requêtes et de réduire la taille totale des fichiers de données. Consultez les vecteurs de suppression dans Databricks.

Calcul des métriques de stockage pour une 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 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 à récupérer avec VACUUM
• Analyser la surcharge de voyage dans le temps : comprendre le coût de conservation des données historiques
• Suivre les modèles de stockage : surveillez l’évolution du stockage de tables au fil du temps en exécutant régulièrement la commande
• Auditer le stockage entre les tables : exécutez la commande dans une boucle pour analyser l’ensemble de votre patrimoine de données

La commande retourne des métriques complètes, notamment :

• Taille totale du stockage : empreinte complète, y compris toutes les données, métadonnées et journaux
• Données actives : taille de la version actuelle de la table
• Données vides : espace pouvant être récupéré
• Données temporelles : données historiques pour les restaurations

Cela est particulièrement utile pour les tables gérées par le catalogue Unity où Azure Databricks gère automatiquement le stockage par le biais de l’optimisation prédictive.

Voir ANALYZE TABLE ... COMPUTE STORAGE METRICS pour obtenir une syntaxe complète et des exemples.

Utiliser l’optimisation prédictive pour contrôler la taille des données

Databricks recommande d’utiliser des tables gérées par Unity Catalog avec l’optimisation prédictive activée. Avec les tables managées et l’optimisation prédictive, Databricks exécute OPTIMIZE et VACUUM commandes automatiquement pour empêcher la génération de fichiers de données inutilisés. Vous pouvez vous attendre à 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 d’objets cloud. Les fichiers de données non référencés dans la version actuelle sont nécessaires pour prendre en charge les requêtes de voyage dans le temps. Consultez Optimisation prédictive pour les tables managées Unity Catalog.

VACUUM Métriques de stockage

Lorsque vous nettoyez les fichiers de données inutilisés avec VACUUM ou utilisez DRY RUN pour afficher un aperçu des fichiers à supprimer, les métriques signalent la taille des données et le nombre de fichiers supprimés. La taille et le nombre de fichiers supprimés 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.

OPTIMIZE Métriques de stockage

Quand 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 apportées pendant OPTIMIZE n’affectent que l’organisation des données, et le contenu des données sous-jacentes n’est pas modifié. La taille totale des fichiers de données sous-jacents pour la table augmente après OPTIMIZE l’exécution, 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 d’OPTIMIZE, car la taille totale des fichiers de données référencés par la version actuelle de la table diminue avec le compactage des données. Pour supprimer les fichiers de données sous-jacents, VACUUM doit s’exécuter une fois le seuil de rétention dépassé.

Remarque

Vous pouvez 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.