Taille de table sur Azure Databricks

La taille de table signalée pour les tables Azure Databricks diffère de la taille totale des répertoires de fichiers correspondants dans le stockage d’objets cloud. Cette page explique pourquoi cette différence existe et des recommandations pour contrôler les coûts.

Pourquoi ma taille de table ne correspond-elle pas à la taille du répertoire ?

Les tailles de table indiquées par les interfaces utilisateur et les commandes DESCRIBE dans Azure Databricks font référence à la taille totale des fichiers de données sur disque pour ces 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, mais les anciens fichiers de données sont conservés pendant un certain temps pour prendre en charge les 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 fournit 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 annulations

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.

Pour obtenir des exemples et des syntaxes complètes, consultez COMPUTE STORAGE METRICS .

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. Cela est dû au fait que des fichiers de données non référencés dans la version actuelle sont requis pour prendre en charge les requêtes de voyage dans le temps. Consultez Optimisation prédictive pour les tables managées Unity Catalog.

Quelles sont les métriques de fichiers signalées par VACUUM ?

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 par VACUUM varient considérablement, mais il peut arriver que la taille des fichiers supprimés dépasse la taille totale de la version actuelle de la table.

Quelles sont les métriques de fichiers signalées par OPTIMIZE ?

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 validées durant OPTIMIZE impactent uniquement l’organisation des données, et aucune modification du contenu des données sous-jacentes n’est apportée. La taille totale des fichiers de données associés à la table augmente après l’exécution d’OPTIMIZE, car les nouveaux fichiers compactés coexistent dans le répertoire conteneur avec les fichiers de données qui ne sont plus référencé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. VACUUM doit s’exécuter une fois le seuil de rétention dépassé pour supprimer les fichiers de données sous-jacents.

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.