Aller au contenu principal
Dernière mise à jour le

Travailler avec le Hive metastore hérité parallèlement à Unity Catalog

Cet article explique une approche pour continuer à utiliser le Hive metastore hérité par workspace lorsque votre Workspace Databricks est activé pour Unity Catalog.

Si votre workspace était en service avant qu'il ne soit activé pour Unity Catalog, il possède probablement un Hive metastore qui contient des données que vous pourriez vouloir continuer à utiliser. Cet article décrit comment continuer à travailler avec des tables enregistrées dans un Hive metastore.

important

Le Hive metastore par Workspace est une fonctionnalité héritée, et les instructions fournies dans cet article représentent des flux de travail hérités.

Les tables du Hive metastore ne bénéficient pas de l'ensemble complet des fonctionnalités de sécurité et de gouvernance fournies par Unity Catalog, telles que l'audit intégré, la traçabilité et le contrôle d'accès. Databricks vous recommande de migrer ces tables et les charges de travail qui les référencent vers Unity Catalog et de désactiver l'accès direct au Hive metastore.

Deux chemins de migration sont disponibles :

  • Mettez à niveau toutes les tables enregistrées dans le Hive metastore vers Unity Catalog.

  • Fédérez votre Hive metastore à Unity Catalog en utilisant la fédération Hive Metastore pour une approche plus progressive. La fédération de Hive metastore crée un catalogue étranger dans Unity Catalog qui reflète le Hive metastore.

Voir Mettre à niveau un Databricks Workspace vers Unity Catalog.

Interroger le Hive metastore hérité dans Unity Catalog​

Le metastore Unity Catalog est additif, ce qui signifie qu'il peut être utilisé avec le Hive metastore par Workspace dans Databricks. Le Hive metastore apparaît comme un catalogue de niveau supérieur appelé hive_metastore dans l'espace de noms à trois niveaux.

Par exemple, vous pouvez faire référence à une table appelée sales_raw dans le schéma sales dans le Hive metastore hérité en utilisant la notation suivante :

SQL
SELECT * from hive_metastore.sales.sales_raw;

Vous pouvez également spécifier le catalogue et le schéma avec une instruction USE :

SQL
USE hive_metastore.sales;
SELECT * from sales_raw;

Contrôle d'accès dans Unity Catalog comparé au Hive metastore hérité​

Si vous avez configuré le contrôle d’accès aux tables héritées sur le Hive metastore, Databricks continue d’appliquer ces contrôles d’accès aux données du catalogue hive_metastore pour les clusters exécutés en mode d’accès standard.

Le modèle d'accès de Unity Catalog diffère légèrement des contrôles d'accès hérités :

  • Metastore : Unity Catalog est un objet au niveau du compte, et Hive metastore est un objet au niveau du Workspace. Les autorisations définies dans le catalogue hive_metastore font toujours référence aux utilisateurs et groupes locaux du Workspace.
  • Groupes de comptes : les politiques de contrôle d’accès dans Unity Catalog s’appliquent aux groupes de comptes, tandis que les politiques de contrôle d’accès pour le Hive metastore s’appliquent aux groupes locaux de workspace. Voir Groupes sources.
  • Les autorisationsUSE CATALOG et USE SCHEMA sont requises sur le catalogue et le schéma pour toutes les opérations sur les objets à l'intérieur du catalogue ou du schéma : Indépendamment des privilèges d'un principal sur une table, le principal doit également disposer du privilège USE CATALOG sur son catalogue parent pour accéder au schéma et du privilège USE SCHEMA pour accéder aux objets au sein du schéma. Avec les contrôles d'accès aux tables au niveau du Workspace, en revanche, accorder USAGE sur le catalogue racine octroie automatiquement USAGE sur toutes les bases de données, mais USAGE sur le catalogue racine n'est pas requis.
  • **Vues** : Dans Unity Catalog, le propriétaire d'une vue n'a pas besoin d'être propriétaire des tables et vues référencées par la vue. Avoir le privilège SELECT est suffisant, ainsi que USE SCHEMA sur le schéma parent des vues et USE CATALOG sur le catalogue parent. Avec les contrôles d'accès aux tables au niveau du Workspace, le propriétaire d'une vue doit être le propriétaire de toutes les tables et vues référencées.
  • Aucun support pour ANY FILE ou ANONYMOUS FUNCTION : Dans Unity Catalog, il n'existe pas de concept de sécurisable ANY FILE ou ANONYMOUS FUNCTION qui pourrait permettre à un utilisateur non privilégié d'exécuter du code privilégié.
  • Aucun support pour DENY : Le modèle de privilèges Unity Catalog est basé sur le principe du moindre privilège. Les privilèges non octroyés sont implicitement refusés.
  • Aucun READ_METADATA privilège : Unity Catalog gère l'accès pour afficher les métadonnées d'une manière différente. Consulter la référence des privilèges Unity Catalog.

Jointures entre Unity Catalog et les objets du Hive metastore​

En utilisant la notation de l'espace de noms à trois niveaux, vous pouvez joindre les données d'un métastore Unity Catalog avec les données du Hive metastore hérité.

remarque

Une jointure avec des données dans le Hive metastore hérité ne fonctionnera que sur le Workspace où résident ces données. Tenter d'exécuter une telle jointure dans un autre Workspace entraîne une erreur. Databricks vous recommande de mettre à niveau les tables et vues héritées vers Unity Catalog.

L'exemple suivant joint les résultats de la table sales_current dans le Hive metastore hérité avec la table sales_historical dans le metastore Unity Catalog lorsque les champs order_id sont égaux.

SQL
SELECT * FROM hive_metastore.sales.sales_current
JOIN main.shared_sales.sales_historical
ON hive_metastore.sales.sales_current.order_id = main.shared_sales.sales_historical.order_id;

default catalog​

Un default catalog est configuré pour chaque Workspace qui est activé pour Unity Catalog.

Si vous omettez le nom du catalogue de niveau supérieur lorsque vous effectuez des opérations sur les données, le catalogue default est utilisé par défaut.

Le catalogue default qui a été initialement configuré pour votre Workspace dépend de la manière dont votre Workspace a été activé pour Unity Catalog :

  • Si votre Workspace a été activé automatiquement pour Unity Catalog, le catalogue de Workspace a été défini comme catalogue default. Consultez start avec Unity Catalog.
  • Si votre Workspace a été activé manuellement pour Unity Catalog, le catalogue hive_metastore a été défini comme catalogue par default.

Si vous passez du Hive metastore à Unity Catalog au sein d’un Workspace existant, il est logique d’utiliser hive_metastore comme catalogue par default pour éviter d’impacter le code existant qui référence le Hive metastore, à moins que vous n’ayez complètement migé du Hive metastore.

Pour savoir comment obtenir et modifier le catalogue default, consultez Gérer le catalogue default

Permissions d'accès aux données de portée au cluster​

Lorsque vous utilisez le Hive metastore conjointement avec Unity Catalog, les informations d'identification d'accès aux données associées au cluster sont utilisées pour accéder aux données du Hive metastore, mais pas aux données enregistrées dans Unity Catalog.

Si les utilisateurs accèdent à des chemins qui sont en dehors de Unity Catalog (comme un chemin non enregistré en tant que table ou emplacement externe), alors les identifiants d'accès attribués au cluster sont utilisés.

Limites de connexion à la base de données Hive metastore​

Le Hive metastore hébergé par Databricks dispose de limites de ressources pour garantir la fiabilité, y compris des limites sur les connexions simultanées (actives) et les connexions par heure. Si les charges de travail dépassent ces limites, les clusters et les Jobs peuvent rencontrer des erreurs de connexion au metastore ou ne pas start.

Pour éviter d’atteindre ces limites :

  • Migrer vers Unity Catalog : l’approche la plus efficace consiste à mettre à niveau les tables et à désactiver l’accès direct au Hive metastore. Unity Catalog n’utilise pas le Hive metastore hérité, de sorte que les limites de connexion de base de données spécifiques au Hive metastore ne s’appliquent plus. Consultez Mettre à niveau un workspace Databricks vers Unity Catalog.
  • Optimiser l'orchestration des charges de travail pour lisser les pics de concurrence : évitez les lancements synchronisés de Jobs et de clusters, limitez la dispersion des rafales et minimisez les pics d'activité transitoires du Hive metastore qui augmentent la probabilité de dépassement des limites de connexion.

Désactivation de l’accès au Hive metastore après la migration​

Après la migration de vos tables vers Unity Catalog, Databricks vous recommande de désactiver explicitement l'accès direct au Hive metastore. By default, les clusters de compute Databricks continuent de se connecter au Hive metastore même après la migration, à moins que vous désactiviez explicitement l'accès au Hive metastore.

Vous pouvez désactiver l’accès direct au Hive metastore sur l’ensemble de votre workspace, ou individuellement par cluster de compute. Voir Désactiver l'accès au Hive metastore utilisé par votre Databricks Workspace.

Sur cette page