Découverte de partitions pour les tables externes
Databricks vous recommande d'utiliser le clustering liquide, au lieu du partitionnement, pour simplifier la gestion des tables et optimiser les performances des requêtes. Voir Utiliser le clustering liquide pour les tables.
Unity Catalog découvre automatiquement les partitions pour les tables externes en listant récursivement les répertoires. Pour les grandes tables partitionnées, l'activation de la journalisation des métadonnées de partition réduit la latence de découverte et améliore la cohérence avec le Hive metastore.
Databricks recommande d'activer la journalisation des métadonnées de partition pour améliorer les vitesses de lecture et les performances des query pour les tables externes Unity Catalog partitionnées.
Stratégie de découverte des partitions par default dans Unity Catalog
Par default, Unity Catalog répertorie de manière récursive tous les répertoires de l'emplacement de la table pour découvrir automatiquement les partitions. Pour les grandes tables comportant de nombreux répertoires de partition, cela peut augmenter la latence pour de nombreuses Opérations de table.
Utiliser la journalisation des métadonnées de partition
Dans Databricks Runtime 13.3 LTS et versions ultérieures, vous pouvez éventuellement activer la journalisation des métadonnées de partition, une stratégie de découverte de partition pour les tables externes enregistrées dans Unity Catalog. Ce comportement est cohérent avec la stratégie de découverte de partition utilisée dans Hive metastore. Ce comportement n'affecte que les tables externes de Unity Catalog qui ont des partitions et utilisent Parquet, ORC, CSV, Avro ou JSON. Databricks recommande d'activer le nouveau comportement pour améliorer les vitesses de lecture et les performances des query pour ces tables.
Les tables avec la journalisation des métadonnées de partition activée ont un comportement différent pour la découverte de partition. Au lieu d'analyser automatiquement l'emplacement de la table pour les partitions, Unity Catalog ne respecte que les partitions enregistrées dans les métadonnées de partition. Voir Ajouter, supprimer ou réparer manuellement les métadonnées de partition.
Les tables avec cette fonctionnalité activée ne peuvent être lues ou écrites qu'à l'aide de Databricks Runtime 13.3 LTS et versions ultérieures.
Activer la journalisation des métadonnées de partition
Pour activer la journalisation des métadonnées de partition sur une table, définissez la propriété de la table lorsque vous créez une table externe, comme illustré dans l'exemple suivant :
CREATE OR REPLACE TABLE <catalog>.<schema>.<table-name>
USING <format>
PARTITIONED BY (<partition-column-list>)
TBLPROPERTIES ('partitionMetadataEnabled' = 'true')
LOCATION 's3://<bucket-path>/<table-directory>';
Après avoir créé une table avec la journalisation des métadonnées de partition activée, Databricks utilise les métadonnées de partition pour lire la table dans toutes les charges de travail ultérieures.
Vous pouvez également utiliser les configurations Spark pour activer les métadonnées de partition pour votre SparkSession actuel. Lorsqu'elles sont activées, les tables externes créées dans la SparkSession seront créées avec la propriété de table de métadonnées de partition activée. La configuration Spark est désactivée par default.
La syntaxe suivante montre comment utiliser SQL pour définir une configuration Spark dans un notebook. Vous pouvez également définir les configurations Spark lors de la configuration du compute.
SET spark.databricks.nonDelta.partitionLog.enabled = true;
Vous pouvez remplacer la configuration Spark en activant ou désactivant explicitement la propriété de table lors de la création d'une table.
Vous ne pouvez lire et écrire des tables avec la journalisation des métadonnées de partition activée que dans Databricks Runtime 13.3 LTS et versions supérieures. Pour lire ces tables à l'aide de Databricks Runtime 12,2 LTS, vous devez supprimer et recréer la table avec la propriété de table des métadonnées de partition désactivée.
Les tables externes ne suppriment pas les fichiers de données sous-jacents lorsque vous les supprimez. Databricks recommande d'utiliser la syntaxe CREATE OR REPLACE pour mettre à niveau les tables afin d'utiliser la journalisation des métadonnées de partition, comme dans l'exemple suivant :
CREATE OR REPLACE TABLE <catalog>.<schema>.<table-name>
USING <format>
PARTITIONED BY (<partition-column-list>)
LOCATION 's3://<bucket-path>/<table-directory>';
Vous pouvez vérifier si une table a été créée à l'aide des métadonnées de partition en :
- Vérifiez la section des propriétés du tableau renvoyée par
DESCRIBE EXTENDED table_name. - Vérifiez les métadonnées de la table avec l'Explorateur de catalogues.
Les propriétés du tableau contiennent partitionMetadataEnabled=true.
Unity Catalog applique des règles concernant les chevauchements de chemins pour les tables et les volumes. Vous ne pouvez pas enregistrer une nouvelle table Unity Catalog sur une collection de fichiers de données si une table existe déjà à cet emplacement.
Gérer les tables avec des métadonnées de partition
Databricks recommande d'utiliser les noms de table dans toutes les lectures et écritures pour toutes les tables enregistrées dans Unity Catalog. Pour les tables avec des métadonnées de partition, cela garantit que les nouvelles partitions ajoutées à une table s'enregistrent dans Unity Catalog et que les requêtes effectuées sur la table lisent toutes les partitions enregistrées.
L'utilisation de modèles basés sur le chemin pour les lectures ou les écritures peut entraîner l'ignorance des partitions ou leur non-enregistrement dans le métastore Unity Catalog. Consulter Limitations.
Lister les partitions
Utilisez la commande suivante pour afficher toutes les partitions enregistrées dans Unity Catalog en tant que métadonnées de partition :
SHOW PARTITIONS <table-name>
Pour vérifier si une seule partition est enregistrée dans Unity Catalog, utilisez la commande suivante :
SHOW PARTITIONS <table-name>
PARTITION (<partition-column-name> = <partition-column-value>)
Ajouter, supprimer ou réparer manuellement les métadonnées de partition
Unity Catalog exige que toutes les partitions des tables externes soient contenues dans le répertoire enregistré à l'aide de la clause LOCATION lors de l'enregistrement de la table.
Lorsque les métadonnées de partition sont activées, la découverte automatique des partitions dans l'emplacement de la table est désactivée. Si des systèmes externes écrivent des données à l’emplacement de la table ou si vous utilisez des écritures basées sur le chemin pour ajouter ou écraser des enregistrements dans votre table, vous devez réparer manuellement les métadonnées de la partition.
Databricks utilise le partitionnement de style Hive pour le stockage des tables prises en charge par Parquet, ORC, CSV et JSON. Les partitions de style Hive contiennent des paires clé-valeur connectées par un signe égal dans le répertoire de partition, par exemple : year=2021/month=01/.
Si votre table utilise le partitionnement de style Hive, vous pouvez utiliser MSCK REPAIR pour synchroniser les métadonnées de partition dans Unity Catalog avec les partitions qui existent dans l'emplacement de la table. Les exemples de syntaxe suivants illustrent les opérations courantes :
-- Add and remove partition metadata to match directories in table location
MSCK REPAIR TABLE <table_name> SYNC PARTITIONS;
-- Add partitions in the table location that are not registered as partition metadata
MSCK REPAIR TABLE <table_name> ADD PARTITIONS;
-- Drop partitions registered as partition metadata that are not in the table location
MSCK REPAIR TABLE <table_name> DROP PARTITIONS;
Voir REPAIR TABLE.
Spécifier manuellement les chemins d'accès pour d'autres types de partition
Si votre table n’utilise pas le partitionnement de style Hive, vous devez spécifier manuellement les emplacements de partition lors de l’ajout de partitions. La spécification manuelle des partitions peut également réduire la latence par rapport à la syntaxe MSCK REPAIR, en particulier pour les tables avec un grand nombre de partitions. L'exemple de syntaxe suivant montre l'ajout d'une partition :
ALTER TABLE <table-name>
ADD PARTITION (<partition-column-name> = <partition-column-value>)
LOCATION 's3://<bucket-path>/<table-directory>/<partition-directory>';
Vous pouvez également utiliser la syntaxe ALTER TABLE pour supprimer, renommer, récupérer et définir les emplacements des partitions. Consultez ALTER TABLE … PARTITION.
Limitations
Les limitations suivantes existent :
- La lecture d'une table à l'aide du chemin du répertoire renvoie toutes les partitions, y compris celles qui ont été ajoutées ou supprimées manuellement.
- Si vous insérez ou écrasez des enregistrements dans une table à l'aide d'un chemin au lieu d'un nom de table, les métadonnées de partition ne sont pas enregistrées.