Qu'est-ce que la fédération de catalogues ?
Avec la fédération de catalogue, vous accédez directement à la table étrangère dans le stockage objet. La query est uniquement exécutée à l'aide du compute Databricks et est donc plus rentable et optimisée en termes de performances. La fédération de catalogue est utilisée pour fédérer des plateformes disposant de services de catalogue et prenant en charge des formats de table ouverts tels que les métastores Hive externes, les métastores Hive Databricks hérités, Salesforce Data 360, Snowflake et Google Cloud Lakehouse.
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.
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.
Pour ajouter des chemins autorisés à grande échelle, vous pouvez utiliser les outils suivants :
-
Assistant de migration Unity Catalog fonctions d'assistance intégrées
-
Outils d'automatisation comme Terraform
-
Fonctions d'assistance prédéfinies dans le Notebook suivant :