Fourniture d'informations d'identification Unity Catalog pour l'accès aux systèmes externes
Cette page décrit comment la fonctionnalité de distribution d'identifiants Unity Catalog prend en charge l'accès aux données dans Databricks à partir de moteurs de traitement externes.
La distribution des identifiants prend en charge les systèmes externes qui se connectent à Unity Catalog à l'aide de l'API REST Unity et du catalogue REST Apache Iceberg. Consultez Accéder aux tables Databricks depuis les clients Delta et Accéder aux données Databricks à l'aide de systèmes externes.
Qu'est-ce que la fourniture d'identifiants Unity Catalog ?
Le Credential vending accorde des identifiants de courte durée à l'aide de l'API REST de Unity Catalog. Les identifiants accordés héritent des privilèges du principal Databricks utilisé pour configurer l'intégration. Il existe deux types de distribution d'identifiants :
- La fourniture d’informations d’identification de table permet d'accéder aux données enregistrées dans votre métastore Unity Catalog.
- L'attribution d'informations d'identification de chemin d'accès fournit l'accès aux emplacements externes dans votre metastore Unity Catalog.
Exigences
- L'accès externe doit être configuré sur le metastore avec
EXTERNAL USE SCHEMAaccordé au principal demandeur. Consultez Activer l'accès aux données externes sur le métastore. - L'URL du Workspace doit être accessible au moteur demandeur, y compris les moteurs derrière les listes d'accès IP ou l'AWS Private Link.
- Les URL de stockage Cloud doivent être accessibles via le pare-feu et les contrôles réseau.
Fourniture d'identifiants de table
Les identifiants de la table incluent une chaîne de jeton d'accès de courte durée et l'URL de l'emplacement de stockage cloud que le moteur externe peut utiliser pour accéder aux données et métadonnées de la table depuis l'emplacement de stockage cloud.
Types d'accès pris en charge
La fourniture d'identifiants de table prend en charge les types de table et les opérations suivants :
Type de table | Lire l'article | Écriture | Créer |
|---|---|---|---|
Delta managé | Oui | Oui * | Oui * |
Delta externe | Oui | Oui | Oui |
Géré Iceberg | Oui | Oui | Oui |
Iceberg étranger | Oui | Non | Non |
Delta avec lectures Iceberg (UniForm) | Oui | Oui** | Non |
* La création et l'écriture dans des tables gérées par Unity Catalog à partir de clients Delta sont en Aperçu public.
** Après avoir écrit en externe dans une table UniForm à partir d'un client Delta, exécutez MSCK REPAIR TABLE pour générer les métadonnées Iceberg.
Certains clients prennent en charge l'accès aux tables gérées par Delta Lake, tandis que d'autres exigent que vous activiez les lectures Iceberg (UniForm) sur les tables. Consultez lire les tables Delta Lake avec des clients Iceberg à l'aide de UniForm.
Demander des identifiants de table temporaires pour l’accès aux données externes
La prise en charge de la distribution des identifiants varie selon le client externe. Lorsque pris en charge, le client devrait automatiquement utiliser les informations d'identification fournies lorsqu'une connexion est configurée.
Cette section fournit un exemple d’appel explicite de l’endpoint de l’API de distribution d’identifiants. Certains clients externes peuvent exiger que vous définissiez explicitement des configurations pour accéder aux données et aux métadonnées dans le stockage d'objets cloud qui prend en charge vos tables Unity Catalog. Vous pouvez utiliser les valeurs renvoyées par la distribution d’identifiants pour configurer l’accès.
Vous pouvez récupérer une liste de tables qui prennent en charge l'émission d'informations d'identification en appelant l'API ListTables avec l'option include_manifest_capabilities activée. Seules les tables marquées HAS_DIRECT_EXTERNAL_ENGINE_READ_SUPPORT ou HAS_DIRECT_EXTERNAL_ENGINE_WRITE_SUPPORT sont éligibles pour référence dans l'API temporary-table-credentials. Consultez GET /api/2.1/unity-catalog/tables.
L'exemple curl suivant demande explicitement un identifiant temporaire pour l'accès aux données externes. Cette demande doit être complétée par un principal Workspace suffisamment privilégié.
curl -X POST -H "Authorization: Bearer $OAUTH_TOKEN" \
https://<workspace-instance>/api/2.1/unity-catalog/temporary-table-credentials \
-d '{"table_id": "<string>", "operation": "<READ|READ_WRITE>"}'
Pour plus de détails, consultez POST /api/2.1/unity-catalog/temporary-table-credentials dans la référence de l'API REST Databricks.
Limitations
Les limitations suivantes existent :
-
Tous les clients externes ne prennent pas en charge la fourniture d'informations d'identification, et la prise en charge peut varier en fonction du stockage d'objets cloud sous-jacent.
-
Les clients lecteurs Delta Lake peuvent uniquement lire les tables prises en charge par Delta Lake et doivent prendre en charge tous les protocoles lecteurs ou writers activés sur la table. Consultez la compatibilité des fonctionnalités et protocoles Delta Lake.
-
Les tables externes qui n'utilisent pas Delta Lake n'offrent pas de garanties transactionnelles.
-
Les types de table suivants ou les tables avec fonctionnalités activées ne sont pas pris en charge :
- Tables avec des filtres de lignes ou des masques de colonnes.
- Tables partagées à l'aide d'OpenSharing.
- Vues.
- Vues matérialisées.
- Tables de streaming des LakeFlow Pipelines.
- Tables en ligne.
- Index de recherche IA.
-
Le refresh des informations d’identification n’est pas pris en charge sur Iceberg 1.9.0. Utilisez la dernière version d'Iceberg pour le refresh des informations d'identification.
Fourniture d'informations d'identification de chemin
Les identifiants émis permettent un accès direct à l'emplacement de stockage cloud, limité au chemin d'accès pertinent. Elles sont valides pour une durée limitée et n'accordent pas d'accès plus large au-delà de l'emplacement ou de la table définis.
Demander des informations d'identification de chemin d'accès temporaire pour l'accès aux données externes
La prise en charge de la distribution des identifiants varie selon le client externe. Lorsque pris en charge, le client devrait automatiquement utiliser les informations d'identification fournies lorsqu'une connexion est configurée.
Cette section fournit un exemple d’appel explicite de l’endpoint de l’API de distribution d’identifiants. Certains clients externes peuvent exiger que vous définissiez explicitement des configurations pour accéder aux données et aux métadonnées dans le stockage d'objets cloud qui prend en charge vos tables Unity Catalog. Vous pouvez utiliser les valeurs renvoyées par la distribution d’identifiants pour configurer l’accès.
L'exemple curl suivant demande explicitement un identifiant temporaire pour l'accès aux données externes. Cette demande doit être complétée par un principal Workspace suffisamment privilégié.
curl -X POST -H "Authorization: Bearer $OAUTH_TOKEN" \
https://<workspace-instance>/api/2.1/unity-catalog/temporary-path-credentials \
-d '{"url": "<string>", "operation": "<PATH_READ|PATH_READ_WRITE|PATH_CREATE_TABLE>"}'
Pour plus de détails, consultez Générer un identifiant de chemin d'accès temporaire dans la référence de l'API REST Databricks.
Fourniture d'identifiants de volume
Aperçu public
Cette fonctionnalité est en aperçu public.
La distribution de justificatifs d'identité de volume permet aux moteurs externes d'accéder aux fichiers stockés dans les volumes Unity Catalog avec des justificatifs d'identité temporaires et ciblés. Le principal demandeur doit disposer de EXTERNAL USE SCHEMA sur le schéma contenant le volume, ainsi que de READ VOLUME pour l’accès en lecture ou de READ VOLUME et WRITE VOLUME pour l’accès en écriture. Consultez Que sont les volumes Unity Catalog ?.
Unity Catalog valide les autorisations et renvoie des identifiants de stockage cloud de courte durée et délimités liés au chemin de stockage du volume. Les identifiants expirent automatiquement et n'accordent pas l'accès au-delà du volume spécifié.
Exigences
- L'accès externe doit être activé sur le métastore. Voir Activer l'accès aux données externes sur le métastore.
- Le mandant demandeur doit disposer de
EXTERNAL USE SCHEMAsur le schéma contenant le volume, plusREAD VOLUMEpour l'accès en lecture ouREAD VOLUMEetWRITE VOLUMEpour l'accès en écriture. - Le moteur externe doit pouvoir atteindre l’URL du Workspace.
- Les URL de stockage Cloud doivent être accessibles via le pare-feu et les contrôles réseau.
Demander un identifiant de volume temporaire pour l'accès aux données externes
L'exemple curl suivant demande explicitement un identifiant temporaire pour l'accès aux données externes.
curl -X POST -H "Authorization: Bearer $OAUTH_TOKEN" \
https://<workspace-instance>/api/2.0/unity-catalog/temporary-volume-credentials \
-d '{"volume_id": "<volume-id>", "operation": "<READ_VOLUME|WRITE_VOLUME>"}'
Ou utilisez le SDK Python Databricks :
from databricks.sdk.service.catalog import VolumeOperation
creds = w.temporary_volume_credentials.generate_temporary_volume_credentials(
volume_id=volume_id,
operation=VolumeOperation.READ_VOLUME,
)
Pour plus de détails, consultez POST /api/2.0/unity-catalog/temporary-volume-credentials dans la référence de l'API REST de Databricks.
Limitations
- Les volumes gérés ne sont pris en charge que pour l'accès en lecture seule. Les volumes externes prennent en charge les accès en lecture et en écriture.