Aller au contenu principal
Dernière mise à jour le

Objets de base de données dans l'ancien Hive metastore

La documentation Databricks se concentre sur l'utilisation d'objets de données avec Unity Catalog, mais la plupart des instructions s'appliquent également à l'utilisation d'objets enregistrés dans le Hive metastore hérité.

Cet article explique comment travailler avec des objets de base de données enregistrés dans le Hive metastore hérité. Plus précisément, cet article indique en quoi le travail avec les objets du Hive metastore diffère du travail avec les objets Unity Catalog. Il décrit également d'autres comportements qui pourraient être inattendus.

Databricks vous recommande de migrer toutes les données de l'ancien Hive metastore vers Unity Catalog. Consultez Mettre à niveau les tables et vues Hive vers Unity Catalog.

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

Bien que les workspaces Databricks continuent d’inclure le Hive metastore intégré, la gouvernance des données utilisant Hive metastore est obsolète. Databricks recommande d’utiliser Unity Catalog pour toute la gouvernance des données. Consultez Utiliser le Hive metastore hérité avec Unity Catalog.

L'activation d'un workspace pour Unity Catalog ne réduit pas votre capacité à travailler avec les données déjà enregistrées dans Hive metastore. Tous les objets de données enregistrés dans le Hive metastore hérité sont affichés dans les interfaces Unity Catalog dans le catalogue hive_metastore. Un workspace hybride Hive metastore et Unity Catalog peut être un modèle utile pour la transition d'un ancien workspace Hive metastore. Cependant, les avantages de Unity Catalog en matière de gouvernance des données et de performances sont considérables, et vous devriez entièrement faire la transition de vos Workspaces dès que possible.

Le Hive metastore 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. Un certain support demeure pour le contrôle d'accès aux tables lorsque vous utilisez compute en mode d'accès standard. Consulter le contrôle d'accès aux tables du Hive metastore (hérité).

La transmission des informations d'identification est un modèle obsolète pour la gouvernance des données sur les objets de base de données Hive metastore. Cet article ne traite pas de la transmission des identifiants. Voir Transmission des identifiants (hérité).

remarque

Lorsque cet article fait référence au contrôle d'accès aux données dans le Hive metastore, il fait référence au contrôle d'accès aux tables hérité.

Qu'est-ce que le catalogue hive_metastore ?​

Dans un Workspace activé pour Unity Catalog, tous les schémas du Hive metastore apparaissent comme des enfants du catalogue hive_metastore dans l'espace de noms à trois niveaux de Unity Catalog. Le Hive metastore n'utilise pas réellement de catalogues, et ce concept offre un point d'entrée aux tables du Hive metastore hérité pour les utilisateurs de Unity Catalog. Utilisez la syntaxe suivante pour interroger les tables du Hive metastore hérité :

SQL
SELECT * FROM hive_metastore.schema_name.table_name
remarque

Vous pouvez définir facultativement le catalogue hive_metastore comme default du Workspace dans les workspaces compatibles Unity Catalog. Voir Gérer le catalogue default.

Schémas dans Hive metastore​

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

Il existe d'importantes différences entre Unity Catalog et Hive metastore, notamment les suivantes :

  • Vous ne pouvez pas créer de schémas dans le Hive metastore à l'aide de Catalog Explorer. Vous pouvez afficher et modifier les autorisations pour les schémas.
  • Les schémas créés dans le Hive metastore peuvent utiliser uniquement des caractères ASCII alphanumériques et des tirets bas dans leurs noms.
  • Hive metastore vous permet de déclarer un LOCATION pour un schéma lors de la création. Ceci fonctionne de manière similaire aux 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 default /user/hive/warehouse/<schema-name> est utilisé. Cet emplacement se trouve dans la racine DBFS, ce qui n'est pas recommandé pour stocker des données de production.
    • Le chemin fourni peut être n'importe quel emplacement de stockage cloud accessible à l'utilisateur qui crée le schéma, y compris les URI cloud, la racine DBFS et les montages DBFS.
    • L'accès à l'emplacement n'est pas géré par Hive metastore.
    • La suppression d'un schéma dans le Hive metastore entraîne la suppression récursive de tous les fichiers situés à cet emplacement de schéma, quel que soit le type de table (gérée ou externe).

Pour éviter toute perte de données accidentelle, Databricks vous recommande ce qui suit lorsque vous travaillez avec les emplacements de schémas Hive metastore :

  • N'attribuez pas un 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 un emplacement entre plusieurs schémas.
  • N’attribuez pas d’emplacement de schéma qui chevauche un autre emplacement de schéma. Autrement dit, n’utilisez pas un chemin qui est un 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 gérées dans Hive metastore​

Les tables gérées dans Hive metastore n'ont aucun des avantages de performance des tables gérées dans Unity Catalog. Comme les tables gérées par Unity Catalog, les tables gérées par le Hive metastore utilisent Delta Lake par default. Cependant, dans le Hive metastore, contrairement à Unity Catalog, vous pouvez également créer une table gérée en utilisant la plupart des autres formats de données pris en charge par Databricks.

Les tables gérées dans Hive metastore sont toujours créées à l’emplacement de stockage du schéma conteneur. Le compute que vous utilisez pour query une table gérée doit avoir accès à l’emplacement de stockage.

Le Hive metastore ne gère pas la disposition des données des tables gérées de la même manière que Unity Catalog. Lorsque vous supprimez une table gérée dans le Hive metastore, tous les fichiers de données sous-jacents sont immédiatement supprimés. En revanche, dans Unity Catalog, vous pouvez UNDROP une table gérée pendant 7 jours, et les données sont définitivement supprimées dans un délai de 30 jours.

Vous pouvez utiliser l'accès basé sur les chemins pour lire ou écrire des données dans les tables gérées du Hive metastore, tandis que dans Unity Catalog, vous ne pouvez pas et n'avez pas besoin de le faire.

Tables externes dans le Hive metastore​

La plupart des tables créées dans Databricks avant l'introduction de Unity Catalog étaient configurées comme des tables externes dans le Hive metastore. Les recommandations héritées qui privilégiaient les tables externes se concentraient généralement sur quelques aspects clés :

  • Vous pouvez enregistrer une table externe sur des données existantes dans le stockage d'objets cloud.
  • Vous pourriez accéder directement aux fichiers de données dans les tables externes à partir de systèmes externes pour la lecture ou l'écriture.
  • Les fichiers de données n'ont pas été supprimés si la table a été accidentellement abandonnée.
  • Puisque les tables externes nécessitent un LOCATION, les données de production avaient moins de chances de se retrouver accidentellement dans la racine DBFS.

Databricks recommande désormais les tables gérées par Unity Catalog pour la plupart du stockage de données tabulaires. Consultez les tables gérées Unity Catalog pour Delta Lake et Apache Iceberg.

Vues dans le Hive metastore​

Vous pouvez déclarer une vue dans le Hive metastore, prise en charge par n'importe quelle source de données prise en charge par Databricks. Dans Unity Catalog, vous ne pouvez déclarer des vues que sur les tables et vues Unity Catalog, y compris les tables étrangères, les vues matérialisées et les tables OpenSharing.

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

Par exemple, considérez ce qui suit :

  • Une table my_table est définie à l'aide du chemin de montage DBFS /mnt/my_table.

    • Les informations d’identification de montage DBFS sont stockées dans le workspace, de sorte que tous les utilisateurs ont accès à ce chemin par default.

  • Les ACL de table sont utilisées pour restreindre l'accès à my_table à un groupe d'utilisateurs.

    • Les ACL de table héritées s'appliquent uniquement au compute configuré en mode d'accès standard ou aux SQL Warehouse.

  • Une vue my_view est définie directement par rapport à l'URI cloud qui prend en charge les mêmes fichiers de données 's3://bucket/path/to/my_table'.

    • Les identifiants URI reposent sur les politiques d'accès définies dans la session Spark ou la configuration de compute.

La vue my_view a les propriétés suivantes :

  • Il n'utilise pas les informations d'identification de montage DBFS utilisées pour monter le stockage d'objets cloud sur /mnt/my_table.
  • Il ne respecte pas les ACLs de table définies sur my_table, quelles que soient les configurations de compute.
  • Il nécessite une politique d'accès aux données configurée pour le compute qui fournit un accès en lecture à 's3://bucket/path/to/my_table'.
remarque

Il s'agit d'un exemple de comportement inattendu que vous pourriez rencontrer, et non d'une liste exhaustive de tous les pièges potentiels présentés par les vues dans le Hive metastore hérité. Databricks recommande d'utiliser Unity Catalog pour toutes les définitions de vue.

Prise en charge des tables Hive et de HiveQL hérités​

Databricks inclut une prise en charge héritée pour les tables Hive et la fonctionnalité HiveQL. Cette fonctionnalité est un vestige des premières versions de 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 manque de support dans certaines configurations de compute.

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

Sur cette page