Fédération Hive metastore : activez Unity Catalog pour régir les tables enregistrées dans un Hive metastore

Cet article présente la fédération Hive metastore, une fonctionnalité qui permet à Unity Catalog de gérer les tables stockées dans un Hive metastore. Vous pouvez fédérer un externe Hive metastore, AWS Glue ou un interne Databricks Hive metastore hérité.

La fédération Hive metastore peut être utilisée pour les cas d'utilisation suivants :

• Dans le cadre de la migration vers Unity Catalog, cela permet une migration incrémentielle sans adaptation du code, une partie de vos charges de travail continuant d'utiliser les données enregistrées dans votre Hive metastore tandis que d'autres sont migrées.

  Ce cas d'utilisation est plus adapté aux organisations qui utilisent aujourd'hui un Hive metastore Databricks interne hérité, car les Hive metastores internes fédérés autorisent les charges de travail en lecture et en écriture.

• Pour fournir un modèle hybride à plus long terme aux organisations qui doivent conserver certaines données dans un Hive metastore, parallèlement à leurs données enregistrées dans Unity Catalog.

  Ce cas d'utilisation est le plus adapté aux organisations qui utilisent un Hive metastore externe ou AWS Glue aujourd'hui, car les catalogues étrangers pour ces Hive metastores sont en lecture seule.

Présentation de la fédération du Hive metastore

Dans la fédération Hive metastore, vous créez une connexion de votre workspace Databricks à votre Hive metastore, et Unity Catalog explore le Hive metastore pour remplir un catalogue étranger, parfois appelé catalogue fédéré , qui permet à votre organisation de travailler avec vos tables Hive metastore dans Unity Catalog, offrant des contrôles d'accès centralisés, la lignée, la recherche, et plus encore.

Les métastores Hive fédérés externes à votre Databricks Workspace, y compris AWS Glue, permettent les lectures à l'aide d'Unity Catalog. Les metastores Hive internes permettent les lectures et les écritures, mettant à jour les métadonnées du metastore Hive ainsi que les métadonnées de Unity Catalog lorsque vous modifiez les métadonnées.

Lorsque vous interrogez des tables étrangères dans un Hive metastore fédéré, Unity Catalog fournit la couche de gouvernance, effectuant des fonctions telles que les contrôles d'accès et l'audit, tandis que les requêtes sont exécutées à l'aide de la sémantique du Hive metastore. Par exemple, si un utilisateur interroge une table stockée au format Parquet dans un catalogue étranger :

• Unity Catalog vérifie si l’utilisateur a accès à la table et déduit la lignée pour la query.
• La query elle-même s'exécute sur le Hive metastore sous-jacent, tirant parti des dernières métadonnées et informations de partition qui y sont stockées.

Comment la fédération du Hive metastore se compare-t-elle à l'utilisation de tables externes Unity Catalog ?

Unity Catalog a la capacité de créer des tables externes, en prenant des données qui existent déjà dans un emplacement de stockage cloud arbitraire et en les enregistrant dans Unity Catalog en tant que table. Cette section explore les différences entre les tables externes et étrangères dans un Hive metastore fédéré.

Les deux types de table possèdent les propriétés suivantes :

• Peut être utilisé pour enregistrer un emplacement arbitraire dans le stockage cloud comme table.
• Peut appliquer les autorisations Unity Catalog et les contrôles d'accès précis.
• Peut être affiché dans la traçabilité pour les queries qui les référencent.

Les tables externes dans un Hive metastore fédéré ont les propriétés suivantes :

• Sont automatiquement découverts sur la base de l'exploration d'un Hive metastore. Dès que les tables sont créées dans le Hive metastore, elles sont exposées et disponibles pour la query dans le catalogue externe de Unity Catalog.
• Autoriser la définition de tables avec la sémantique Hive, telle que les Hive SerDes et les partitions.
• Autoriser les tables à avoir des chemins qui se chevauchent avec d'autres tables dans des catalogues étrangers.
• Autorisez le placement des tables dans des emplacements racine DBFS.
• Inclure les vues définies dans Hive metastore.

De cette manière, vous pouvez considérer les tables étrangères dans un Hive metastore fédéré comme offrant une compatibilité descendante avec le Hive metastore, permettant aux charges de travail d'utiliser une sémantique Hive uniquement, mais avec une gouvernance fournie par Unity Catalog.

Cependant, certaines fonctionnalités de Unity Catalog ne sont pas disponibles sur les tables externes, par exemple :

• Fonctionnalités disponibles uniquement pour les tables gérées par Unity Catalog, telles que l'optimisation prédictive.
• Recherche par IA, OpenSharing, monitoring de la qualité des données et tables en ligne.
• Certaines fonctionnalités du Magasin de fonctionnalités, y compris la création de Magasin de fonctionnalités, la création de services de modèles, la création de spécifications de fonctionnalités, la journalisation de modèles et le scoring par batch.

La performance peut être légèrement inférieure à celle des charges de travail sur Unity Catalog ou Hive metastore, car Hive metastore et Unity Catalog se trouvent tous deux sur le chemin de requête d'une table externe.

Pour plus d'informations sur les fonctionnalités prises en charge, voir Exigences et prise en charge des fonctionnalités.

Que signifie écrire dans un catalogue étranger dans un Hive metastore fédéré ?

Les écritures ne sont prises en charge que pour les métastores Hive internes fédérés, et non pour les métastores Hive externes ou AWS Glue.

Les écritures vers les métastores fédérés sont de deux types :

• Opérations DDL telles que CREATE TABLE, ALTER TABLE et DROP TABLE.

  Les opérations DDL sont répercutées de manière synchrone dans le Hive metastore sous-jacent. Par exemple, l'exécution d'une instruction CREATE TABLE crée la table à la fois dans le Hive metastore et le catalogue étranger.

attention

Cela signifie également que les commandes DROP sont reflétées dans le Hive metastore. Par exemple, DROP SCHEMA mySchema CASCADE supprime toutes les tables du schéma Hive metastore sous-jacent, sans option UNDROP, car Hive metastore ne prend pas en charge UNDROP.

• Opérations DML telles que INSERT, UPDATE et DELETE.

  Les opérations DML sont également reflétées de manière synchrone dans la table sous-jacente du Hive metastore. Par exemple, l'exécution de INSERT INTO ajoute des enregistrements à la table dans le Hive metastore.

  La prise en charge de l'écriture est essentielle pour permettre une transition transparente pendant la migration du Hive metastore vers Unity Catalog. Consultez Comment utilisez-vous la fédération du Hive metastore pendant la migration vers Unity Catalog ?

Comment configurez-vous la fédération du métastore Hive ?

Pour configurer la fédération Hive metastore, procédez comme suit :

1. Créez une *connexion* dans Unity Catalog qui spécifie le chemin et les informations d'identification pour l'accès au Hive metastore.

   La fédération de Hive metastore utilise cette connexion pour explorer le Hive metastore. Pour la plupart des systèmes de base de données, vous fournissez un nom d'utilisateur et un mot de passe. Pour AWS Glue, vous fournissez un rôle IAM. Pour une connexion à un Hive metastore de Workspace Databricks interne hérité, la fédération du Hive metastore gère l'autorisation.

2. Créez un *crédentiel de stockage* et un *emplacement externe* dans Unity Catalog pour les chemins d'accès aux tables enregistrées dans le Hive metastore.

   Les emplacements externes contiennent les chemins d'accès et les identifiants de stockage requis pour accéder à ces chemins. Les identifiants de stockage sont des objets sécurisables Unity Catalog qui spécifient des identifiants, tels que les rôles IAM, pour l'accès au stockage cloud. Selon le workflow que vous choisissez pour créer des emplacements externes, vous devrez peut-être créer des identifiants de stockage avant de créer l'emplacement externe.

3. Créer un catalogue étranger dans Unity Catalog, en utilisant la connexion que vous avez créée à l'étape 1.

   C'est le catalogue que les utilisateurs du Workspace et les workflows utilisent pour travailler avec les tables du Hive metastore en utilisant Unity Catalog. Une fois le catalogue externe créé, Unity Catalog le remplit avec les tables enregistrées dans le Hive metastore.

4. Accorder des privilèges aux tables du catalogue étranger à l'aide d'Unity Catalog.

   Vous pouvez également utiliser les filtres de ligne et de colonne d'Unity Catalog pour un contrôle d'accès précis.

5. start à interroger les données.

   L'accès aux tables étrangères utilisant Unity Catalog est en lecture seule pour les métastores Hive externes et les métastores AWS Glue, et en lecture-écriture pour les métastores Hive internes.

   Pour les métastores Hive internes, les métastores Hive externes et les métastores Glue, Unity Catalog met à jour en continu les métadonnées de table à mesure qu'elles changent dans le métastore Hive. Pour les Hive metastore internes, les nouvelles tables et les mises à jour de table validées depuis le catalogue étranger sont réécrites dans le Hive metastore, maintenant une interopérabilité totale entre les catalogues Unity Catalog et Hive metastore.

Pour des instructions détaillées, voir :

• Activez la fédération Hive metastore pour un Hive metastore de Workspace hérité.
• Activer la fédération Hive metastore pour un Hive metastore externe.
• Activer la fédération Hive metastore pour les metastores AWS Glue

Comment utilisez-vous la fédération Hive metastore lors de la migration vers Unity Catalog ?

La fédération du Hive metastore vous permet de migrer vers Unity Catalog de manière incrémentielle en réduisant le besoin de coordination entre les équipes et les charges de travail. En particulier, si vous migrez depuis le Hive metastore interne de votre workspace Databricks, la capacité de lire et d'écrire à la fois dans le Hive metastore et le Unity Catalog metastore signifie que vous pouvez maintenir des metastores « miroirs » pendant votre migration, offrant les avantages suivants :

• Les charges de travail exécutées sur des catalogues étrangers s'exécutent en mode de compatibilité Hive metastore, réduisant ainsi le coût de l'adaptation du code pendant la migration.
• Chaque charge de travail peut choisir de migrer indépendamment des autres, sachant que, pendant la période de migration, les données seront disponibles à la fois dans Hive metastore et Unity Catalog, ce qui atténue la nécessité de coordonner les charges de travail qui dépendent les unes des autres.

Cette section décrit un workflow typique pour la migration du Hive metastore hérité interne d’un Databricks Workspace vers Unity Catalog, la fédération du Hive metastore facilitant la transition. Il ne s'applique pas à la migration d'un métastore Hive ou AWS Glue externe. Les catalogues externes pour les Hive metastores externes ne prennent pas en charge les écritures.

Étape 1 : Fédérer le Hive metastore interne

Dans cette étape, vous créez un catalogue externe qui reflète votre Hive metastore dans Unity Catalog. Appelons-le hms_in_uc.

remarque

Dans le cadre du processus de fédération, vous configurez des emplacements externes pour fournir l'accès aux données dans le stockage cloud. Dans les scénarios de migration où certaines charges de travail interrogent les données à l'aide de mécanismes d'accès existants et d'autres charges de travail interrogent les mêmes données dans Unity Catalog, les contrôles d'accès gérés par Unity Catalog sur les emplacements externes peuvent empêcher les charges de travail existantes d'accéder aux chemins de stockage à partir du compute compatible avec Unity Catalog. Vous pouvez activer le « mode fallback » sur ces emplacements externes pour revenir aux informations d'identification étendues au cluster ou au notebook qui ont été définies pour la charge de travail héritée. Une fois votre migration terminée, vous désactivez le mode fallback. Voir Qu'est-ce que le mode fallback ?.

Pour plus de détails, consultez Activer la fédération de Hive metastore pour un Hive metastore de workspace hérité.

Étape 2. Exécutez de nouvelles charges de travail par rapport au catalogue étranger dans Unity Catalog

Lorsque vous disposez d'un catalogue étranger, vous pouvez accorder aux analystes SQL et aux consommateurs Data Science l'accès à celui-ci et **start** à développer de nouvelles charges de travail qui y sont liées. Les nouvelles charges de travail bénéficient de l'ensemble de fonctionnalités supplémentaires d'Unity Catalog, y compris les contrôles d'accès, la recherche et la traçabilité.

Au cours de cette étape, vous effectuez généralement les opérations suivantes :

• Choisissez un compute compatible Unity Catalog (c'est-à-dire les modes d'accès de compute standard ou dédié, les SQL Warehouses ou le compute serverless). Consultez les exigences et la prise en charge des fonctionnalités.
• Faites du catalogue étranger le catalogue par default sur la ressource compute ou ajoutez USE CATALOG hms_in_uc en haut de votre code. Parce que les schémas et les noms de table dans le catalogue étranger sont des miroirs exacts de ceux du Hive metastore, votre code commencera à faire référence au catalogue étranger.

Étape 3. Migrez les jobs existants pour qu’ils s’exécutent par rapport au catalogue étranger

Pour migrer les jobs existants afin d'interroger le catalogue étranger :

1. Modifiez le catalogue default sur le cluster Job en hms_in_uc, soit en définissant une propriété sur le cluster lui-même, soit en ajoutant USE CATALOG hms_in_uc en haut de votre code.
2. Basculez le job vers un compute en mode d'accès standard ou dédié et mettez à niveau vers l'une des versions de Databricks Runtime qui prend en charge la fédération Hive metastore. Consultez les exigences et la prise en charge des fonctionnalités.
3. Demandez à un administrateur Databricks d’accorder les privilèges Unity Catalog corrects sur les objets de données dans hms_in_uc et sur tous les chemins de stockage cloud (inclus dans les emplacements externes Unity Catalog) auxquels le Job accède. Voir Gérer les privilèges dans Unity Catalog.

Étape 4. Désactiver l'accès direct au Hive metastore

Une fois que vous avez migré toutes vos charges de travail pour interroger le catalogue externe, vous n'avez plus besoin du Hive metastore.

1. Désactiver l'accès direct au Hive metastore.

   Voir Désactiver l'accès au Hive metastore utilisé par votre Workspace Databricks.

2. Empêcher les utilisateurs de créer et d’utiliser des clusters qui contournent le contrôle d’accès aux tables (clusters qui utilisent le mode d’accès partagé sans isolation ou un type de cluster personnalisé hérité) à l’aide des stratégies de compute et du paramètre de workspace Appliquer l’isolation des utilisateurs .

   Voir configurations de compute et types de clusters d'isolation utilisateur sur un Workspace.

3. Faites du catalogue fédéré le catalogue default du workspace.

   Consulter Gérer le catalogue default.

Questions fréquemment posées

Les sections suivantes fournissent des informations plus détaillées sur la fédération du Hive metastore.

Qu'est-ce que le mode Fallback ?

Le mode fallback est un paramètre des emplacements externes que vous pouvez utiliser pour contourner les vérifications d'autorisations Unity Catalog lors de la migration vers Unity Catalog. Le paramétrage garantit que les charges de travail qui n'ont pas encore été migrées ne sont pas impactées pendant la phase de configuration.

Unity Catalog accède au stockage cloud en utilisant des emplacements externes, qui sont des objets sécurisables qui définissent un chemin et un identifiant pour accéder à votre compte de stockage cloud. Vous pouvez émettre des autorisations sur ceux-ci, comme READ FILES, pour régir qui peut utiliser le chemin d'accès. Un défi pendant le processus de migration est que vous pourriez ne pas vouloir qu'Unity Catalog start à régir immédiatement tout accès au chemin, par exemple, lorsque vous avez des charges de travail existantes et non migrées qui référencent le chemin.

Le mode fallback vous permet de retarder l'application stricte du contrôle d'accès de Unity Catalog sur les emplacements externes. Lorsque le mode fallback est activé, les charges de travail qui accèdent à un chemin sont d'abord vérifiées par rapport aux permissions d'Unity Catalog, et si elles échouent, elles reviennent à utiliser des identifiants de cluster ou de Notebook, tels que les profils d'instance ou les propriétés de configuration Apache Spark. Cela permet aux charges de travail existantes de continuer à utiliser leur identifiant actuel.

Le mode Fallback est destiné uniquement à être utilisé pendant la migration. Vous devez le désactiver lorsque toutes les charges de travail ont été migrées et que vous êtes prêt à appliquer les contrôles d'accès Unity Catalog.

Query le journal d'audit pour l'utilisation du fallback

Utilisez la query suivante pour vérifier si un accès à l’emplacement externe a utilisé le mode fallback au cours des 30 derniers jours. S'il n'y a pas d'accès au mode fallback dans votre compte, Databricks vous recommande de désactiver le mode fallback.

SQL

SELECT event_time, user_identity, action_name, request_params, response, identity_metadata
FROM system.access.audit
WHERE
request_params.fallback_enabled = 'true' AND
request_params.path LIKE '%some-path%' AND
event_time >= current_date() - INTERVAL 30 DAYS
LIMIT 10

Que sont les chemins autorisés ?

Lorsque vous créez un catalogue externe qui est soutenu par la fédération du Hive metastore, vous êtes invité à fournir des chemins autorisés vers le stockage cloud où les tables du Hive metastore sont stockées. Toute table à laquelle vous souhaitez accéder en utilisant la fédération du Hive metastore doit être couverte par ces chemins. Databricks recommande que vos chemins autorisés soient des sous-chemins communs à un grand nombre de tables. Par exemple, si vous avez des tables à s3://bucket/table1, s3://bucket/table2 et s3://bucket/table3, vous devriez fournir s3://bucket/ comme chemin autorisé.

Vous pouvez modifier les chemins d'accès autorisés pour un catalogue existant si vous êtes le propriétaire du catalogue, ou si vous disposez des autorisations MANAGE et USE CATALOG.

Pour modifier les chemins d'accès autorisés pour un catalogue existant :

1. Dans votre workspace Databricks, cliquez sur Catalogue .
2. Dans le volet Catalogue , recherchez et cliquez sur le catalogue fédéré.
3. Sur la page des détails du catalogue, cliquez sur l’icône et sélectionnez Modifier les chemins d’accès autorisés .
4. Ajoutez ou supprimez des chemins selon les besoins.
5. Cliquez sur Enregistrer .

Vous pouvez utiliser UCX pour vous aider à identifier les chemins présents dans votre Hive metastore.

Les chemins autorisés ajoutent une couche de sécurité supplémentaire sur les catalogues étrangers qui sont pris en charge par la fédération Hive metastore. Ils permettent au propriétaire du catalogue d'appliquer des garde-fous aux données auxquelles les utilisateurs peuvent accéder à l'aide de la fédération. Ceci est utile si votre Hive metastore permet aux utilisateurs de mettre à jour les métadonnées et de modifier arbitrairement les emplacements de table, des mises à jour qui seraient autrement synchronisées dans le catalogue étranger. Dans ce scénario, les utilisateurs pourraient potentiellement redéfinir des tables auxquelles ils ont déjà accès afin qu'elles pointent vers de nouveaux emplacements auxquels ils n'auraient autrement pas accès.

Puis-je fédérer les métastores Hive à l'aide d'UCX ?

UCX, le projet Databricks Labs pour la migration des Workspaces Databricks vers Unity Catalog, comprend des infrastructures publiques pour l'activation de la fédération du Hive metastore :

• enable-hms-federation
• create-federated-catalog

Voir le README du projet dans GitHub. Pour une introduction à UCX, consultez Utilisez les utilitaires UCX pour mettre à niveau votre Workspace vers Unity Catalog.

Pour des informations sur l'actualisation des métadonnées pour tous les types de fédération de catalogues, consultez Qu'est-ce que la fédération de catalogues ?.

Exigences et prise en charge des fonctionnalités

Le tableau suivant répertorie les services et fonctionnalités pris en charge par la fédération Hive metastore. Dans certains cas, les services ou fonctionnalités non pris en charge sont également répertoriés. Dans ces tableaux, « HMS » signifie Hive metastore.

Catégorie	Pris en charge	Non pris en charge
Métastores	Métastores Hive Legacy Workspace (internes à Databricks) Metastores externes sur Apache Hive version 0,13, 2,3 et 3,1 MySQL, SQL Server ou Postgres AWS Glue
Opérations	HMS Databricks interne : prend en charge les opérations de lecture et d'écriture pour OPTIMIZE, VACUUM et ANALYZE TABLE. HMS externe : prend en charge les opérations en lecture seule pour OPTIMIZE et VACUUM. ANALYZE TABLE n'est pas pris en charge. AWS Glue : prend en charge les opérations en lecture seule pour OPTIMIZE et VACUUM. ANALYZE TABLE n'est pas pris en charge.
Assets de données du Hive metastore	Tables gérées et externes dans Hive metastore Cela inclut les tables dans tous les formats de données répertoriés dans Formats de fichiers pour les tables externes, avec l'ajout de tables Apache Iceberg (uniquement dans les métastores Hive externes fédérés et AWS Glue). La prise en charge d'Iceberg est en aperçu public. Consultez les Limitations. Schémas Vues L'accès aux tables et vues créées par d'autres systèmes, tels qu'AWS Athena ou Presto, pourrait ne pas fonctionner dans Databricks Runtime ou Spark, en particulier si elles ne sont pas créées avec la syntaxe Spark SQL. Consultez Accéder aux tables et vues créées dans un autre système. Tables Hive SerDe Accès aux clones superficiels enregistrés dans le Hive metastore via un catalogue externe (Aperçu public). Consultez Utilisation des clones superficiels. Définition de nouveaux clones superficiels dans le catalogue étranger (aperçu public)	Fonctions Hive et UDF Tables basées sur JDBC Tables partagées OpenSharing
Stockage	AWS S3 Tables qui référencent les emplacements de montage DBFS, y compris la racine DBFS Tables dont les chemins chevauchent d'autres chemins de table HMS définis dans des emplacements externes	Tables HMS dont les chemins d'accès chevauchent les chemins d'objets natifs du Unity Catalog Accès aux tables dans la racine DBFS ou les emplacements de montage enregistrés dans un HMS externe ou AWS Glue Accès aux tables dans la racine DBFS ou aux emplacements de montage depuis tout Workspace autre que celui dans lequel le HMS interne est défini Données stockées dans des clusters on-premise Hadoop Distributed File System (HDFS). Le mode distant pour HMS via Apache Thrift n'est pas non plus pris en charge, vous devez donc fournir des configurations en mode local à la place.
Types de compute	Compute en mode d'accès standard (anciennement mode d'accès partagé) Compute en mode d'accès dédié (anciennement mode d'accès utilisateur unique) Serverless (tout) SQL warehouses (tous) Databricks Container Services (DCS) : Nécessite de définir spark.databricks.unityCatalog.hms.federation.enabled true dans la configuration Spark	Clusters sans isolation
Versions de compute	Tous les canaux de distribution Databricks SQL Tous les canaux de distribution LakeFlow Pipelines Databricks Runtime 13.3 LTS Databricks Runtime 14.3 LTS Databricks Runtime 15,1 et versions ultérieures Databricks Runtime 16.2 et versions ultérieures pour le support d’Iceberg (Public Preview)
Fonctionnalités de Unity Catalog	Modèle de privilèges Unity Catalog Filtres de lignes et masques de colonne Audit Traçabilité en aval Recherche de tables Accès inter-Workspace (sauf la racine et les montages DBFS) Accès aux données limité aux emplacements externes définis.	OpenSharing Contrôle qualité des données Recherche IA Tables en ligne Certaines fonctionnalités du magasin de fonctionnalités, y compris la création de magasin de fonctionnalités, la création de service de modèles, la création de spécifications de fonctionnalités, la journalisation de modèles et le scoring par batch Vous ne pouvez pas écrire de vues matérialisées LakeFlow Pipelines et de tables de streaming dans un catalogue étranger, mais vous pouvez utiliser des tables et des vues étrangères comme source pour les vues matérialisées LakeFlow Pipelines et les tables de streaming. Migration automatique des ACL de table héritées vers les privilèges Unity Catalog pour le catalogue externe. UCX peut vous aider.

Catégorie	Pris en charge	Non pris en charge
Métastores	Métastores Hive Legacy Workspace (internes à Databricks) Metastores externes sur Apache Hive version 0,13, 2,3 et 3,1 MySQL, SQL Server ou Postgres AWS Glue
Opérations	HMS Databricks interne : prend en charge les opérations de lecture et d'écriture pour OPTIMIZE, VACUUM et ANALYZE TABLE. HMS externe : prend en charge les opérations en lecture seule pour OPTIMIZE et VACUUM. ANALYZE TABLE n'est pas pris en charge. AWS Glue : prend en charge les opérations en lecture seule pour OPTIMIZE et VACUUM. ANALYZE TABLE n'est pas pris en charge.
Assets de données du Hive metastore	Tables gérées et externes dans Hive metastore Cela inclut les tables dans tous les formats de données répertoriés dans Formats de fichiers pour les tables externes, avec l'ajout de tables Apache Iceberg (uniquement dans les métastores Hive externes fédérés et AWS Glue). La prise en charge d'Iceberg est en aperçu public. Consultez les Limitations. Schémas Vues L'accès aux tables et vues créées par d'autres systèmes, tels qu'AWS Athena ou Presto, pourrait ne pas fonctionner dans Databricks Runtime ou Spark, en particulier si elles ne sont pas créées avec la syntaxe Spark SQL. Consultez Accéder aux tables et vues créées dans un autre système. Tables Hive SerDe Accès aux clones superficiels enregistrés dans le Hive metastore via un catalogue externe (Aperçu public). Consultez Utilisation des clones superficiels. Définition de nouveaux clones superficiels dans le catalogue étranger (aperçu public)	Fonctions Hive et UDF Tables basées sur JDBC Tables partagées OpenSharing
Stockage	AWS S3 Tables qui référencent les emplacements de montage DBFS, y compris la racine DBFS Tables dont les chemins chevauchent d'autres chemins de table HMS définis dans des emplacements externes	Tables HMS dont les chemins d'accès chevauchent les chemins d'objets natifs du Unity Catalog Accès aux tables dans la racine DBFS ou les emplacements de montage enregistrés dans un HMS externe ou AWS Glue Accès aux tables dans la racine DBFS ou aux emplacements de montage depuis tout Workspace autre que celui dans lequel le HMS interne est défini Données stockées dans des clusters on-premise Hadoop Distributed File System (HDFS). Le mode distant pour HMS via Apache Thrift n'est pas non plus pris en charge, vous devez donc fournir des configurations en mode local à la place.
Types de compute	Compute en mode d'accès standard (anciennement mode d'accès partagé) Compute en mode d'accès dédié (anciennement mode d'accès utilisateur unique) Serverless (tout) SQL warehouses (tous) Databricks Container Services (DCS) : Nécessite de définir spark.databricks.unityCatalog.hms.federation.enabled true dans la configuration Spark	Clusters sans isolation
Versions de compute	Tous les canaux de distribution Databricks SQL Tous les canaux de distribution LakeFlow Pipelines Databricks Runtime 13.3 LTS Databricks Runtime 14.3 LTS Databricks Runtime 15,1 et versions ultérieures Databricks Runtime 16.2 et versions ultérieures pour le support d’Iceberg (Public Preview)
Fonctionnalités de Unity Catalog	Modèle de privilèges Unity Catalog Filtres de lignes et masques de colonne Audit Traçabilité en aval Recherche de tables Accès inter-Workspace (sauf la racine et les montages DBFS) Accès aux données limité aux emplacements externes définis.	OpenSharing Contrôle qualité des données Recherche IA Tables en ligne Certaines fonctionnalités du magasin de fonctionnalités, y compris la création de magasin de fonctionnalités, la création de service de modèles, la création de spécifications de fonctionnalités, la journalisation de modèles et le scoring par batch Vous ne pouvez pas écrire de vues matérialisées LakeFlow Pipelines et de tables de streaming dans un catalogue étranger, mais vous pouvez utiliser des tables et des vues étrangères comme source pour les vues matérialisées LakeFlow Pipelines et les tables de streaming. Migration automatique des ACL de table héritées vers les privilèges Unity Catalog pour le catalogue externe. UCX peut vous aider.

Travailler avec des clones superficiels

info

Aperçu

La prise en charge du clone superficiel est en aperçu public.

La fédération Hive metastore prend en charge la création de clones superficiels à partir de tables enregistrées dans Hive metastore, avec les mises en garde suivantes :

• Lorsque vous lisez le clone léger d'un catalogue fédéré Hive metastore, le clone a un état de provisionnement DEGRADED. Ceci indique que le clone léger utilise le modèle d'autorisations Hive, ce qui exige que l'utilisateur qui lit à partir de la table de clone léger ait le privilège SELECT sur le clone léger et la table de base.

  Pour mettre à niveau le clone superficiel afin qu'il soit cohérent avec le modèle d'autorisations Unity Catalog, le propriétaire de la table doit exécuter REPAIR TABLE <table> SYNC METADATA. Une fois la commande exécutée, l'état de provisionnement de la table passe à ACTIVE et les autorisations sont ensuite contrôlées par Unity Catalog. Les lectures ultérieures sur le clone superficiel ne nécessitent SELECT que sur le clone superficiel lui-même, tant que la commande est exécutée sur un compute qui prend en charge Unity Catalog.

• Les clones superficiels créés dans DBFS ou basés sur des tables montées dans DBFS ne sont pas pris en charge.

Limitations

• Vous ne pouvez pas effectuer de query sur les tables fédérées lorsque les fichiers de table sont stockés en dehors de l'emplacement de la table fédérée. Cela peut inclure des tables où les partitions sont stockées en dehors de l'emplacement de la table, ou, dans le cas des tables Avro, où le schéma est référencé à l'aide de la propriété de table avro.schema.url. Lors de la query de ces tables, une exception UNAUTHORIZED_ACCESS ou AccessDeniedException peut être levée.