Aller au contenu principal
Dernière mise à jour le

Qu'est-ce que la fédération de catalogues ?

Avec la fédération de catalogues, vous accédez directement à la table étrangère dans le stockage d'objets. La query est exécutée uniquement en utilisant le compute Databricks et est donc plus rentable et optimisée en termes de performances. La fédération de catalogues est utilisée pour se fédérer aux plateformes qui disposent de services de catalogue et prennent en charge les formats de table ouverts comme les métastores Hive externes, les métastores Hive Databricks hérités, AWS Glue, Salesforce Data 360 et Snowflake.

Diagramme de présentation de la fédération de catalogues

Cas d'utilisation courants​

Quelques cas d’usage courants :

  • Dans le cadre de la migration vers Unity Catalog, l’activation de la migration incrémentielle sans adaptation du code permet à certaines de vos charges de travail de continuer à utiliser les données enregistrées dans votre catalogue externe pendant que d’autres sont migrées.
  • Pour offrir un modèle hybride à plus long terme aux organisations qui doivent conserver certaines données dans un catalogue externe, en parallèle de leurs données enregistrées dans Unity Catalog.

Aperçu de la fédération de catalogues​​

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

Les catalogues externes fédérés qui sont externes à votre Workspace Databricks permettent les lectures à l'aide de 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 externes dans un catalogue externe fédéré, Unity Catalog fournit la couche de gouvernance, en effectuant des fonctions telles que les contrôles d’accès et l’audit, tandis que les query sont exécutées selon la sémantique du catalogue externe. 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 par rapport au catalogue externe sous-jacent, en tirant parti des dernières métadonnées et informations de partition qui y sont stockées.

Que sont les chemins autorisés ?​​

Lorsque vous créez un catalogue étranger adossé à la fédération Hive metastore, vous êtes invité à fournir des chemins autorisés vers le stockage cloud où sont stockées les tables Hive metastore. Toute table à laquelle vous souhaitez accéder en utilisant la fédération 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 aux emplacements s3://bucket/table1, s3://bucket/table2 et s3://bucket/table3, vous devez fournir s3://bucket/ comme chemin autorisé.

Les chemins autorisés ajoutent une couche de sécurité supplémentaire aux catalogues externes soutenus 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 des tables, 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.

Exemple : Hive metastore non sécurisé​

L'exemple suivant montre comment un utilisateur malveillant pourrait contourner les autorisations de Unity Catalog et accéder à des données sensibles dans un catalogue fédéré en manipulant des chemins dans un Hive metastore non sécurisé.

Un administrateur configure la fédération Hive metastore et accorde à Paul l'accès au schéma non_sensitive dans Unity Catalog. Paul n'a pas accès au schéma sensitive_table dans Unity Catalog.

Diagramme d’accès au schéma étranger

Bien que Unity Catalog soit sécurisé, le Hive metastore n'est pas sécurisé. Paul peut modifier le chemin de la table non_sensitive_table dans le Hive metastore vers s3://abc/def. Lors du prochain refresh du catalogue fédéré, le chemin de la table fédérée dans Unity Catalog est mis à jour. Comme Unity Catalog dispose déjà d’un identifiant de stockage pour accéder à s3://abc/def, et que Paul a un accès SELECT, Paul peut désormais accéder aux données de la table sensitive_table.

Diagramme du Hive metastore non sécurisé

Pour ajouter des chemins autorisés à grande échelle, vous pouvez utiliser les outils suivants :

Fonctions d’aide pour les chemins autorisés

Ouvrir le notebook dans un nouvel ongletOuvrir dans Databricks

Refresh les métadonnées​

Unity Catalog refresh automatiquement les métadonnées des tables étrangères au moment de la query. Si le schéma du catalogue externe change, Unity Catalog récupère les métadonnées les plus récentes lors de l'exécution de la query. Ce comportement maintient le schéma à jour et est optimal pour la plupart des charges de travail.

Cependant, Databricks recommande d'actualiser manuellement les métadonnées dans les cas suivants :

  • Pour maintenir la cohérence des tables étrangères accédées par des moteurs externes. Les chemins qui contournent Databricks Runtime ne trigger pas d'automatic refresh, ce qui peut entraîner des métadonnées obsolètes.
  • Pour améliorer les performances des charges de travail où vous souhaitez éviter le refresh des métadonnées pendant l'exécution de la query. L'actualisation des métadonnées de manière proactive permet aux requêtes de s'exécuter plus rapidement en utilisant les métadonnées mises en cache. Cette approche est particulièrement utile immédiatement après la création d'un catalogue étranger, car la première query déclenche autrement un refresh complet.

Automatisez les métadonnées refresh avec Lakeflow Jobs​

Planifiez un refresh périodique des métadonnées à l’aide d’un Lakeflow Job avec la commande SQL REFRESH FOREIGN. Par exemple :

SQL
-- Refresh an entire catalog
> REFRESH FOREIGN CATALOG some_catalog;
-- Refresh a specific schema
> REFRESH FOREIGN SCHEMA some_catalog.some_schema;
-- Refresh a specific table
> REFRESH FOREIGN TABLE some_catalog.some_schema.some_table;

Configurez le Job pour qu'il s'exécute à intervalles réguliers, en fonction de la fréquence à laquelle vous anticipez des modifications de schéma externes.

Sources de données prises en charge​

Sur cette page