Objets de base de données dans le metastore Hive hérité

La documentation Azure Databricks est centrée sur l’utilisation d’objets de données à l’aide de Unity Catalog. Cependant, la plupart des instructions s’appliquent également à l’utilisation d’objets enregistrés dans l’ancien métastore Hive.

Cet article est axé sur l’utilisation des objets de base de données inscrits dans le metastore Hive hérité. Plus précisément, cet article indique les différences entre l’utilisation des objets du métastore Hive et celle des objets du catalogue Unity. Il décrit également d’autres comportements parfois inattendus.

Databricks recommande de migrer toutes les données du métastore Hive hérité vers Unity Catalog. Consultez Mettre à niveau les tables et les vues Hive vers Unity Catalog.

Comment fonctionne la gouvernance des données du metastore Hive ?

Bien que les espaces de travail Azure Databricks incluent toujours le métastore Hive intégré, la gouvernance des données utilisant le métastore Hive est déconseillée. Databricks recommande d’utiliser Unity Catalog pour toute la gouvernance des données. Consultez Utilisation de Unity Catalog et du metastore Hive hérité.

L’activation d’un espace de travail pour Unity Catalog ne réduit pas votre capacité à l’utilisation de données déjà enregistrées dans le métastore Hive. Tous les objets de données enregistrés dans le métastore Hive hérité sont présentés dans les interfaces Unity Catalog du catalogue hive_metastore. Un metastore Hive hybride et un espace de travail Unity Catalog peuvent être un modèle utile pour la transition d’un espace de travail de metastore Hive existant depuis longtemps. Cependant, les avantages de Unity Catalog en termes de gouvernance des données et de performances sont considérables. Il est donc recommandé de procéder à la transition complète de vos espaces de travail dès que possible.

Le metastore Hive utilise le contrôle d’accès aux tables (ACL de table) pour gérer l’accès aux objets de base de données. Le contrôle d’accès aux tables est encore assuré lorsque vous utilisez le calcul en mode d’accès partagé. Consultez Contrôle d’accès aux tables du metastore Hive (hérité).

Le passage des identifiants est un modèle déconseillé pour la gouvernance des données sur les objets de base de données du métastore Hive. Cet article ne traite pas du passage des identifiants. Consultez Passage des identifiants (hérité).

Qu’est-ce que le catalogue hive_metastore ?

Dans un espace de travail activé pour Unity Catalog, tous les schémas du metastore Hive apparaissent en tant qu’enfants du catalogue hive_metastore dans l’espace de noms de trois niveaux du Unity Catalog. Le metastore Hive n’utilise pas réellement de catalogues. Par ailleurs, cette construction fournit un point d’entrée aux tables du metastore Hive hérité pour les utilisateurs de Unity Catalog. Utilisez la syntaxe suivante pour interroger des tables dans le metastore Hive hérité :

SELECT * FROM hive_metastore.schema_name.table_name

Schémas dans le metastore Hive

Dans le metastore Hive hérité, un schéma est le niveau le plus élevé dans la hiérarchie d’objets de données.

Il existe quelques différences importantes entre le Unity Catalog et le metastore Hive, notamment les points suivants :

• Vous ne pouvez pas créer de schémas dans le metastore Hive à l’aide de l’Explorateur de catalogues. Vous pouvez afficher et modifier des autorisations pour les schémas.
• Les schémas créés dans le metastore Hive peuvent utiliser uniquement des caractères ASCII alphanumériques et des traits de soulignement dans leurs noms.
• Le métastore Hive permet de déclarer un LOCATION pour un schéma lors de sa création. Le fonctionnement est similaire à celui des emplacements de stockage gérés par Unity Catalog, avec les différences de comportement suivantes :
  • Si vous ne fournissez pas d’emplacement, l’emplacement /user/hive/warehouse/<schema-name> par défaut est utilisé. Cet emplacement se trouve sur la racine DBFS. Il n’est pas recommandé pour stocker des données de production.
  • Le chemin d’accès fourni peut être n’importe quel emplacement de stockage cloud disponible pour l’utilisateur qui crée le schéma, notamment les URI cloud, la racine DBFS et les montages DBFS.
  • L’accès à l’emplacement n’est pas managé par le metastore Hive.
  • La suppression d’un schéma dans le métastore Hive entraîne la suppression récursive de tous les fichiers situés dans cet emplacement de schéma, quel que soit le type de table (gérée ou externe).

Pour éviter toute perte accidentelle de données, Databricks recommande ce qui suit lorsque vous utilisez des emplacements de schéma de metastore Hive :

• N’attribuez pas d’emplacement de schéma qui contient déjà des données.
• Ne créez pas de table externe dans un emplacement de schéma.
• Ne partagez pas d’emplacement entre plusieurs schémas.
• N’attribuez pas d’emplacement de schéma qui chevauche un autre emplacement de schéma. En d’autres termes, n’utilisez pas de chemin d’accès enfant d’un autre emplacement de schéma.
• N’attribuez pas d’emplacement de schéma qui chevauche l’emplacement d’une table externe.

Tables managées dans le metastore Hive

Les tables managées dans le metastore Hive ne disposent d’aucun des avantages en matière de performances des tables managées dans Unity Catalog. De même que les tables managées de Unity Catalog, les tables managées du métastore Hive utilisent Delta Lake par défaut. Cependant, dans le métastore Hive, contrairement à Unity Catalog, vous pouvez aussi créer une table managée à l’aide des autres formats de données pris en charge par Azure Databricks.

Les tables managées dans le metastore Hive sont toujours créées dans l’emplacement de stockage du schéma contenant. Le calcul que vous utilisez pour interroger une table managée doit avoir accès à l’emplacement de stockage.

Le métastore Hive ne gère pas la disposition des données des tables managées comme le fait Unity Catalog. Lorsque vous supprimez une table managée dans le metastore Hive, tous les fichiers de données sous-jacents sont tout de suite supprimés. En revanche, dans Unity Catalog, vous pouvez UNDROP une table managée pendant 7 jours, et les données sont définitivement supprimées dans les 30 jours.

Vous pouvez utiliser l’accès basé sur le chemin d’accès pour lire ou écrire des données dans des tables managées par le metastore Hive, tandis que dans Unity Catalog, vous ne pouvez pas et n’avez pas besoin de le faire.

Tables externes dans le metastore Hive

La plupart des tables créées dans Azure Databricks avant l’aperçu de Unity Catalog ont été configurées en tant que tables externes dans le metastore Hive. Les recommandations héritées qui ont favorisé la configuration des tables externes portent généralement sur quelques aspects clés :

• Vous pouvez inscrire une table externe en plus des données existantes dans le stockage d’objets cloud.
• Vous pouvez accéder directement aux fichiers de données dans des tables externes à partir de systèmes externes pour les lectures ou les écritures.
• Les fichiers de données n’ont pas été supprimés en cas d’abandon accidentel de la table.
• Étant donné que les tables externes nécessitent un LOCATION, les données de production sont moins susceptibles de se retrouver accidentellement dans la racine DBFS.

Azure Databricks recommande désormais des tables managées Unity Catalog pour la plupart des stockages de données tabulaires. Consultez Utiliser des tables managées.

Vues dans le metastore Hive

Vous pouvez déclarer une vue dans le metastore Hive sauvegardée par n’importe quelle source de données prise en charge par Azure Databricks. Dans Unity Catalog, vous pouvez uniquement déclarer des vues sur les tables et vues de Unity Catalog, notamment les tables sources contenant une clé étrangère, les vues matérialisées et les tables de partage delta.

En raison de la possibilité de déclarer des vues sur des sources de données non tabulaires, les vues dans le métastore Hive peuvent accorder un accès inattendu ou involontaire aux données en combinaison avec d’autres configurations d’accès dans l’environnement utilisateur.

Prenons l’exemple suivant :

• Une table my_table est définie à l’aide du chemin d’accès de montage DBFS /mnt/my_table.
  • Les identifiants de montage DBFS sont stockés dans l’espace de travail, de sorte que tous les utilisateurs ont accès à ce chemin d’accès par défaut.
• Les ACL de table sont utilisées pour restreindre l’accès à my_table pour un groupe d’utilisateurs.
  • Les ACL de table héritées ne s’appliquent qu’aux calculs configurés en mode d’accès partagé ou aux entrepôts SQL.
• Une vue my_view est définie directement sur l’URI cloud qui sauvegarde les mêmes fichiers de données 'abfss://container-name@storage-account-name.dfs.core.windows.net/my_table'.
  • Les identifiants de l’URI s’appuient sur les stratégies d’accès définies dans la configuration de la session Spark ou du calcul.

La vue my_view présente les propriétés suivantes :

• Elle n’utilise pas les identifiants de montage DBFS utilisés pour monter le stockage d’objets cloud sur /mnt/my_table.
• Elle ne respecte pas les ACL de table définies sur my_table, quelles que soient les configurations de calcul.
• Elle exige une stratégie d’accès aux données configurée pour le calcul qui fournit un accès en lecture à 'abfss://container-name@storage-account-name.dfs.core.windows.net/my_table'.

Tables Hive héritées et prise en charge de HiveQL

Azure Databricks inclut une prise en charge héritée des tables Hive et des fonctionnalités HiveQL. Cette fonctionnalité est un vestige des premières versions d’Azure Databricks et de l’écosystème d’outils Apache Hadoop. Databricks ne recommande pas l’utilisation de tables Hive ou d’autres fonctionnalités Hive, car cette fonctionnalité n’est pas optimisée et ne prend pas en charge certaines configurations de calcul.

Les articles suivants décrivent les fonctionnalités Hive héritées :

• Compatibilité d’Apache Hive
• CREATE TABLE au format Hive
• INSERT OVERWRITE DIRECTORY avec le format Hive
• LOAD DATA
• Intégration avec les fonctions UDF, UDAF et UDTF Hive