Seit dem 20. April 2026 heißt BigLake jetzt Lakehouse. BigLake Metastore heißt jetzt Lakehouse-Laufzeitkatalog. Lakehouse-APIs, Clientbibliotheken, CLI-Befehle und IAM-Namen bleiben unverändert und verweisen weiterhin auf BigLake.

Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Cloud-übergreifende Verbindung für Databricks Unity Catalog einrichten

Mit einer cloudübergreifenden Verbindung zu einem Databricks Unity Catalog können Sie Daten aus diesem Katalog direkt in Google Cloudabfragen. Diese Funktion vereinheitlicht Ihre Datenanalysen, indem Ihre externen Datenquellen in Ihre bestehendeGoogle Cloud -Umgebung eingebunden werden.

Nachdem Sie die Verbindung eingerichtet haben, können Sie den Zugriff auf Ihre föderierten Daten im grenzenlosen Lakehouse verwalten.

Hinweis

In der Lakehouse-Übersicht erfahren Sie, wie Lakehouse den Zugriff auf Daten verwaltet.
Informationen zum Zugriff auf cloudübergreifende Daten
Prüfen Sie die unterstützten Kataloge, um die unterstützten Konfigurationen zu ermitteln.
Regionale Secret Manager-Secrets verwenden Dies ist erforderlich, um ein Lakehouse mit Databricks Unity Catalog mithilfe der Secret-basierten Authentifizierung einzurichten.
Optional: Wenn Sie Abfragen über eine private Interconnect-Verbindung zwischen Ihrer Google Cloud -VPC und der VPC Ihres Remote-Cloud-Anbieters (z. B. AWS) weiterleiten möchten, benötigen Sie ein aktives Konto bei Ihrem Remote-Anbieter. Stellen Sie eine Dedicated Cross-Cloud Interconnect- oder Partner Cross-Cloud Interconnect-Verbindung bereit, richten Sie BGP-Sitzungen mit Ihrem Cloud Router ein und prüfen Sie, ob Sie die erforderlichen IAM-Berechtigungen in beiden Cloud-Umgebungen haben.
Optional: Wenn Sie die Nutzeridentitätsföderation verwenden möchten, um Endnutzeridentitäten bei Abfragen weiterzugeben, müssen Sie Folgendes tun:
- Ihr Identitätsanbieter (IdP) ist so konfiguriert, dass er die email-Anforderung des Nutzers als sub-Subjektanforderung in Authentifizierungstokens ausgibt.
- Ihr Databricks-Konto ist so konfiguriert, dass der Endnutzer anhand seiner E-Mail-Adresse erkannt wird, damit Databricks den Nutzer erkennen kann. Nutzer können in Databricks entweder durch Synchronisieren von Nutzern von Ihrem Identitätsanbieter mit SCIM (empfohlen) oder durch manuelles Hinzufügen von Nutzern in der Databricks-Kontokonsole konfiguriert werden.

Melden Sie sich in Ihrem Google Cloud -Konto an. Wenn Sie mit Google Cloudnoch nicht vertraut sind, erstellen Sie einfach ein Konto, um die Leistungsfähigkeit unserer Produkte in der Praxis sehen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.

Verify that billing is enabled for your Google Cloud project.

Enable the BigLake, Secret Manager APIs, if any are not already enabled.

Roles required to enable APIs

To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

Enable the APIs

Verify that billing is enabled for your Google Cloud project.

Enable the BigLake, Secret Manager APIs, if any are not already enabled.

Roles required to enable APIs

Enable the APIs

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für das Projekt zuzuweisen, damit Sie die nötigen Berechtigungen für die Einrichtung des cloudübergreifenden Zugriffs haben:

Lakehouse-Kataloge verwalten: BigLake-Administrator (roles/biglake.admin)
Secrets verwalten (bei Verwendung der Secret-basierten Authentifizierung): Secret Manager-Administrator (roles/secretmanager.admin)
Traffic über Private Interconnect weiterleiten (Nutzer): Compute-Netzwerkadministrator (roles/compute.networkAdmin)
Traffic über Private Interconnect weiterleiten (Katalogdienstkonto):
- Service Directory-Betrachter (roles/servicedirectory.viewer)
- Service Directory PSC Authorized Service (roles/servicedirectory.pscAuthorizedService)

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

Einschränkungen und Überlegungen

In diesem Abschnitt werden die Einschränkungen und Überlegungen für den Zugriff auf cloudübergreifende Daten aufgeführt.

Unterstützte Cloud-Anbieter für Cross-Cloud Interconnect: Die Verwendung einer privaten Interconnect-Verbindung für den Zugriff auf cloudübergreifende Daten wird von den folgenden Remote-Cloud-Anbietern unterstützt: Amazon Web Services (AWS). Sie können entweder Dedicated Cross-Cloud Interconnect oder Cross-Cloud Interconnect für Partner-Ressourcen verwenden.
Netzwerkrouting: Wenn keine private Interconnect-Verbindung (z. B. Dedicated CCI oder Partner CCI) konfiguriert ist, werden Abfragen über das öffentliche Internet weitergeleitet. Dies kann zu höheren Gebühren für ausgehenden Traffic von Ihrem Remote-Cloud-Anbieter und zu einer weniger vorhersehbaren Leistung führen.
Databricks Unity Catalog-Konfiguration:
- Es werden nur Databricks Unity-Kataloge unterstützt, die einen externen Standort in AWS oder einen externen Standort in Google Cloud verwenden. Unity-Kataloge, die Standardspeicher in AWS oder Standardspeicher in Google Cloud verwenden, werden nicht unterstützt.
- Sie müssen den externen Datenzugriff für den von Unity Catalog verwendeten Metastore aktivieren, der standardmäßig deaktiviert ist.
- Sie müssen dem Databricks-Diensthauptkonto die Berechtigung EXTERNAL USE SCHEMA für die Zielschemas oder den Zielkatalog gewähren, um die Bereitstellung von Anmeldedaten für den Zugriff auf externe Daten zu ermöglichen. Ohne diese Berechtigung schlagen die Aktualisierung von Metadaten im Hintergrund und die Bereitstellung von Anmeldedaten für Abfragen fehl.
Lesezugriff: Föderierte Kataloge in Lakehouse sind schreibgeschützte Ansichten des Remote-Katalogs. Ressourcenmanipulationen (z. B. Erstellen, Aktualisieren oder Löschen von Ressourcen) werden nicht unterstützt und müssen direkt im Remote-Katalog ausgeführt werden.
Datenaktualität: Das Flag --refresh-interval für einen föderierten Katalog bestimmt, wie oft Metadaten synchronisiert werden. Der Wert muss 0s (deaktiviert) oder mindestens 300s (5 Minuten) sein. Die Aktualisierung der Hintergrundmetadaten eines Katalogs kann länger dauern, je mehr Namespace- und Tabellenressourcen vorhanden sind. Wenn die vorherige Aktualisierung länger dauert, wird die aktuelle Aktualisierung übersprungen. Die nächste Aktualisierung wird jedoch für das folgende Intervall geplant. Abfragen verwenden die zuletzt synchronisierten Katalogmetadaten. Änderungen im Remote-Katalog, z. B. neue Tabellen, Schemaaktualisierungen oder neu übernommene Daten, sind daher erst nach der nächsten Hintergrundaktualisierung der Metadaten in Lakehouse sichtbar.
Lakehouse-Caching: Lakehouse-Caching wird automatisch für alle cloudübergreifenden Abfragen aktiviert, um Kosten für ausgehenden Traffic zu sparen, indem Datenblöcke lokal in Google Cloudgespeichert werden. Kundenverwaltete Verschlüsselungsschlüssel (CMEK) werden für das Caching nicht unterstützt. Im Cache gespeicherte Daten werden mit Google-owned and Google-managed encryption keysverschlüsselt. Wenn die Einschränkung der Organisationsrichtlinie constraints/gcp.restrictNonCmekServices für eine Tabelle in der Abfrage erzwungen wird, wird das Caching für diese Abfrage automatisch deaktiviert. Weitere Informationen finden Sie unter Intelligentes Caching.
Datenstandort und Compliance: Wenn Sie einen föderierten Katalog oder eine föderierte Verbindung in einer Google Cloud -Region erstellen, werden im Cache gespeicherte Daten im Ruhezustand in dieser Zielregion gespeichert. Wenn sich Ihre Remote-Cloud-Daten in einer anderen Gerichtsbarkeit befinden, achten Sie darauf, dass das regionenübergreifende Caching den Anforderungen Ihrer Organisation an den Datenstandort und die Einhaltung regulatorischer Anforderungen entspricht.

Allgemeiner Workflow

So greifen Sie auf cloudübergreifende Daten zu:

Cross-Cloud Interconnect einrichten (optional): Konfigurieren Sie eine private Verbindung zwischen Ihrer Google Cloud -VPC und Ihrem Remote-Cloud-Anbieter.
Föderation einrichten: Konfigurieren Sie die Authentifizierung und erstellen Sie einen föderierten Katalog in Lakehouse.
- Basisauthentifizierung (erforderlich): Konfigurieren Sie entweder OpenID Connect (OIDC) (empfohlen) oder die Secret-basierte Authentifizierung, damit Lakehouse die Hintergrundsynchronisierung von Schemas und Metadaten über das Dienstkonto des Katalogs durchführen kann.
- Nutzeridentitätsföderation (optional): Aktivieren Sie die Nutzeridentitätsföderation (--federated-catalog-identity-mode="user-identity-federation"), damit Abfragen mit der Identität des authentifizierten Endnutzers ausgeführt werden können. Dadurch kann Databricks Unity Catalog Abfragen Endnutzern zuordnen, Berechtigungen erzwingen und Audit-Logs generieren.
Verbindung prüfen: Prüfen Sie, ob Lakehouse eine Verbindung zu Ihrem Remote-Katalog herstellen kann.
Daten abfragen: Führen Sie Abfragen für Ihre föderierten Daten mit BigQuery oder Managed Service for Apache Spark aus. Lakehouse-Caching wird automatisch für Abfragen aktiviert, um Kosten für ausgehenden Traffic zu sparen. Weitere Informationen finden Sie unter Remote-Daten abfragen.
Berechtigungen konfigurieren: Mit Identity and Access Management (IAM) können Sie festlegen, wer die föderierten Daten ansehen und abfragen darf.

Cross-Cloud Interconnect einrichten (optional)

Abfragen an Ihren Remote-Katalog werden standardmäßig über das öffentliche Internet übertragen. Verwenden Sie eine private Interconnect-Verbindung, um die Sicherheit und Compliance zu verbessern, eine vorhersehbare Leistung zu erzielen und die Kosten für die Datenübertragung zu senken. Dadurch wird eine dedizierte, private Netzwerkverbindung zwischen Ihrer Google CloudVirtual Private Cloud (VPC) und dem Netzwerk Ihres Remote-Cloud-Anbieters (z. B. AWS) hergestellt.

Sie können eine der folgenden privaten Interconnect-Optionen zwischen Ihrer Google Cloud -VPC und der VPC Ihres Remote-Cloud-Anbieters (z. B. AWS) bereitstellen und konfigurieren:

Dedizierter Cross-Cloud Interconnect: Eine dedizierte physische Verbindung.
Partner Cross-Cloud Interconnect: Eine Verbindung über einen unterstützten Dienstanbieter.

Richten Sie BGP-Sitzungen zwischen Ihrem Cloud Router in Google Cloud und der VPC Ihres Remote-Cloud-Anbieters ein, um den Routenaustausch zu ermöglichen.

Wenn Sie private Abfragen aktivieren möchten, müssen Sie über Ihre private Interconnect-Verbindung einen Pfad von Lakehouse zu Ihrem Remote-Speicher-Bucket (z. B. einem AWS Amazon S3-Bucket) konfigurieren. Es gibt zwei Architekturabläufe, die Sie zum Konfigurieren dieses Routings verwenden können:

Routing des internen regionalen Proxy-Network-Load-Balancers: In diesem Ablauf wird ein interner regionaler Proxy-Network-Load-Balancer vonGoogle Cloud verwendet, um Anfragen auf Hybridkonnektivitäts-Netzwerk-Endpunktgruppen (NEGs) zu verteilen, die auf mehrere AWS Elastic Network Interfaces (ENIs) verweisen. Dieser Ablauf ist für Load Balancing, Skalierbarkeit und Hochverfügbarkeit unerlässlich. Sie ist für Partner-CCI erforderlich und wird für Dedicated CCI für Load Balancing, Skalierbarkeit und Hochverfügbarkeit empfohlen.
Direktes Endpunktrouting: Bei diesem Ablauf wird Service Directory direkt mit einer einzelnen AWS-Schnittstellen-VPC-Endpunkt-IP-Adresse verbunden. Dieser Ablauf funktioniert nur für dedizierte CCI und wird für Partner-CCI nicht unterstützt.

Wählen Sie den Konfigurationsablauf aus, der Ihren Architekturanforderungen entspricht:

Interner regionaler Proxy-Network Load Balancer

So konfigurieren Sie einen internen regionalen Proxy-Network-Load-Balancer, um Anfragen zur Hochverfügbarkeit und zum Load Balancing auf mehrere AWS-ENIs zu verteilen:

AWS-Netzwerk konfigurieren

Erstellen Sie zuerst einen Amazon S3-VPC-Schnittstellenendpunkt (AWS PrivateLink):

Erstellen Sie in der AWS-VPC-Konsole einen Schnittstellenendpunkt für Amazon S3.
Geben Sie als Dienstnamen com.amazonaws.AWS_REGION.s3 an.
Wählen Sie die VPC und die Subnetze aus, die über Direct Connect mit Ihrer Google Cloud -VPC verbunden sind.
Hängen Sie Sicherheitsgruppen an den Endpunkt an, um den eingehenden Zugriff zu steuern.
Dadurch werden Elastic Network Interfaces (ENIs) in jedem ausgewählten Subnetz bereitgestellt. Notieren Sie sich die privaten IP-Adressen dieser ENIs.

Konfigurieren Sie als Nächstes Sicherheitsgruppen:

Achten Sie darauf, dass die Sicherheitsgruppe oder die Sicherheitsgruppen, die an die ENIs des Amazon S3-Endpunkts angehängt sind, eingehenden TCP-Traffic auf Port 443 von Ihrer Google Cloud VPC zulassen. Dazu muss der CIDR-Bereich Ihres Nur-Proxy-Subnetzes fürGoogle Cloud gehören, um Systemdiagnosen und weitergeleiteten Traffic zuzulassen.

Google Cloud -Netzwerk konfigurieren

Führen Sie die folgenden Befehle aus, um den internen Load Balancer zu konfigurieren und die Einrichtung zu vereinfachen. Weitere Informationen zu erweiterten Konfigurationen finden Sie unter Internen regionalen Proxy-Network Load Balancer für Hybrid-Endpunkte einrichten.

gcloud compute networks subnets create PROXY_SUBNET_NAME \
    --purpose=REGIONAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=REGION \
    --network=VPC_NETWORK \
    --range=PROXY_SUBNET_RANGE

Ersetzen Sie Folgendes:

PROXY_SUBNET_NAME: ein Name für das Nur-Proxy-Subnetz.
PROXY_SUBNET_RANGE: ein nicht verwendeter CIDR-Bereich in Ihrem VPC-Netzwerk (z. B. 10.129.0.0/23).

Erstellen Sie eine regionale Systemdiagnose.
```
gcloud compute health-checks create tcp HEALTH_CHECK_NAME \
    --region=REGION \
    --port=443
```
Ersetzen Sie Folgendes:
- HEALTH_CHECK_NAME: ein Name für die Systemdiagnose.
- REGION: die Google Cloud -Region (z. B. us-east4).
Erstellen Sie Netzwerk-Endpunktgruppen (NEGs) mit Hybridkonnektivität und fügen Sie Endpunkte hinzu:

Erstellen Sie für jede Zone eine Hybrid-NEG (NON_GCP_PRIVATE_IP_PORT):
```
gcloud compute network-endpoint-groups create NEG_NAME \
    --network-endpoint-type=NON_GCP_PRIVATE_IP_PORT \
    --zone=ZONE \
    --network=VPC_NETWORK
```
Fügen Sie die private IP-Adresse Ihrer AWS-ENI der entsprechenden Hybrid-NEG hinzu:
```
gcloud compute network-endpoint-groups update NEG_NAME \
    --zone=ZONE \
    --add-endpoint="ip=AWS_S3_IP,port=443"
```
Ersetzen Sie Folgendes:
- NEG_NAME: ein Name für die Hybrid-NEG.
- ZONE: die Google Cloud -Zone (z. B. us-east4-a). Diese Zone muss sich in der Region Ihres Cross-Cloud Interconnect-VLAN-Anhang befinden.
- VPC_NETWORK: der Name des VPC-Netzwerks
- AWS_S3_IP: die private IP-Adresse des AWS Amazon S3-VPC-Endpunkts (ENI) in dieser Zone.
Wiederholen Sie diese Befehle, um NEGs zu erstellen und Endpunkte für andere Zonen hinzuzufügen, wenn Ihre AWS-ENIs auf mehrere Zonen verteilt sind.
Erstellen und konfigurieren Sie den Backend-Dienst:

Erstellen Sie einen regionalen Backend-Dienst mit internem verwaltetem Load Balancing:
```
gcloud compute backend-services create BACKEND_SERVICE_NAME \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --protocol=TCP \
    --region=REGION \
    --health-checks=HEALTH_CHECK_NAME \
    --health-checks-region=REGION
```
Fügen Sie dem Backend-Dienst Ihre hybriden NEGs hinzu:
```
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
    --region=REGION \
    --network-endpoint-group=NEG_NAME \
    --network-endpoint-group-zone=ZONE \
    --balancing-mode=CONNECTION \
    --max-connections=MAX_CONNECTIONS
```
Ersetzen Sie Folgendes:
- BACKEND_SERVICE_NAME: ein Name für den Backend-Dienst.
- NEG_NAME: der Name der Hybrid-NEG, die Sie im vorherigen Schritt erstellt haben.
- ZONE: die Google Cloud -Zone (z. B. us-east4-a).
- MAX_CONNECTIONS: die maximale Anzahl gleichzeitiger Verbindungen, die das Backend verarbeiten soll (z. B. 100).
Wiederholen Sie den Befehl add-backend für jede Hybrid-NEG, die Sie erstellt haben.

Load-Balancer-Frontend konfigurieren:

Erstellen Sie einen Ziel-TCP-Proxy:

gcloud compute target-tcp-proxies create TARGET_PROXY_NAME \
    --backend-service=BACKEND_SERVICE_NAME \
    --region=REGION

Erstellen Sie eine Weiterleitungsregel, um Traffic an den Ziel-Proxy weiterzuleiten:

gcloud compute forwarding-rules create FORWARDING_RULE_NAME \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=VPC_NETWORK \
    --subnet=VPC_SUBNET \
    --ports=443 \
    --region=REGION \
    --target-tcp-proxy=TARGET_PROXY_NAME \
    --target-tcp-proxy-region=REGION \
    --allow-global-access

Ersetzen Sie Folgendes:

TARGET_PROXY_NAME: ein Name für den Ziel-Proxy.
FORWARDING_RULE_NAME ist ein Name für die Weiterleitungsregel.
VPC_SUBNET: der Name des VPC-Subnetzwerks.

Notieren Sie sich nach dem Erstellen der Weiterleitungsregel für den Load Balancer die zugewiesene interne IP-Adresse. Das ist dein ILB_IP_ADDRESS.

Service Directory konfigurieren

Registrieren Sie die IP-Adresse des ILB in Service Directory, damit Lakehouse sie finden kann.

Erstellen Sie einen Namespace für Ihre Remote-Cloud:
```
gcloud service-directory namespaces create NAMESPACE \
    --project=PROJECT_ID \
    --location=REGION
```
Ersetzen Sie Folgendes:
- NAMESPACE: Eine eindeutige Kennung für Ihren Namespace.
- PROJECT_ID: Ihre Projekt-ID in Google Cloud .
- REGION: die Google Cloud -Region. Beispiel: us-east4. Dies muss dieselbe Region wie der föderierte Katalog sein.

Erstellen Sie einen Dienst im Service Directory-Namespace:

gcloud service-directory services create SERVICE_NAME \
    --namespace=NAMESPACE \
    --project=PROJECT_ID \
    --location=REGION

Ersetzen Sie Folgendes:

SERVICE_NAME: eine eindeutige Kennung für Ihren Dienst.

Erstellen Sie einen Endpunkt für den ILB im Dienst:

gcloud service-directory endpoints create ENDPOINT_NAME \
    --project=PROJECT_ID \
    --namespace=NAMESPACE \
    --service=SERVICE_NAME \
    --location=REGION \
    --network=projects/PROJECT_NUMBER/global/networks/VPC_NETWORK \
    --address=ILB_IP_ADDRESS \
    --port=443

Ersetzen Sie Folgendes:

ENDPOINT_NAME: Eine eindeutige Kennung für Ihren Endpunkt.
PROJECT_NUMBER: Ihre Google Cloud-Projektnummer Verwenden Sie Ihre Projektnummer im Flag --network.
ILB_IP_ADDRESS: die interne IP-Adresse Ihrer ILB-Weiterleitungsregel.

Direkter Endpunkt

So konfigurieren Sie Service Directory, um Traffic direkt an eine einzelne AWS-Schnittstellen-VPC-Endpunkt-IP-Adresse weiterzuleiten:

Erstellen Sie einen Schnittstellen-VPC-Endpunkt für Amazon S3 in Ihrer AWS-VPC. Notieren Sie sich die IP-Adresse und den Port dieses Endpunkts.
Erstellen Sie einen Namespace für Ihre Remote-Cloud:
```
gcloud service-directory namespaces create NAMESPACE \
    --project=PROJECT_ID \
    --location=REGION
```
Ersetzen Sie Folgendes:
- NAMESPACE: Eine eindeutige Kennung für Ihren Namespace.
- PROJECT_ID: Ihre Projekt-ID in Google Cloud .
- REGION: die Google Cloud -Region. Beispiel: us-east4. Dies muss dieselbe Region wie der föderierte Katalog sein.

Erstellen Sie einen Dienst im Service Directory-Namespace:

gcloud service-directory services create SERVICE_NAME \
    --namespace=NAMESPACE \
    --project=PROJECT_ID \
    --location=REGION

Ersetzen Sie Folgendes:

SERVICE_NAME: eine eindeutige Kennung für Ihren Dienst.

Erstellen Sie im Dienst einen Endpunkt, der die Routinginformationen für Ihren Amazon S3-Schnittstellen-VPC-Endpunkt enthält:
```
gcloud service-directory endpoints create ENDPOINT_NAME \
    --service=SERVICE_NAME \
    --namespace=NAMESPACE \
    --project=PROJECT_ID \
    --location=REGION \
    --address=S3_VPCE_IP_ADDRESS \
    --port=S3_VPCE_PORT \
    --network=projects/PROJECT_NUMBER/global/networks/VPC_NETWORK
```
Ersetzen Sie Folgendes:
- ENDPOINT_NAME: Eine eindeutige Kennung für Ihren Endpunkt.
- S3_VPCE_IP_ADDRESS: die IP-Adresse Ihres Amazon S3-Schnittstellen-VPC-Endpunkts. Beispiel: 10.0.1.45.
- S3_VPCE_PORT: die Portnummer Ihres Amazon S3-Schnittstellen-VPC-Endpunkts. Beispiel: 443.
- PROJECT_NUMBER: Ihre Google Cloud-Projektnummer Verwenden Sie Ihre Projektnummer im Flag --network.
- VPC_NETWORK: der Name des Google Cloud VPC-Netzwerks, das mit Ihrer privaten Interconnect-Verbindung verknüpft ist.

Föderation einrichten

Wenn Sie Ihre Daten abfragen möchten, müssen Sie einen föderierten Lakehouse-Katalog einrichten, der eine Verbindung zu Ihrem Remote-Databricks Unity Catalog herstellt.

Authentifizierung konfigurieren

Für die Föderation ist die Authentifizierung beim Remote-Katalog als Databricks-Diensthauptkonto erforderlich. Wählen Sie eine der folgenden Authentifizierungsoptionen aus:

OIDC

OpenID Connect (OIDC) ermöglicht die Authentifizierung ohne Secrets über die Databricks OAuth-Tokenföderation.

Erstellen Sie in Ihrem Databricks-Konto einen Diensthauptschlüssel, der Lesezugriff auf den Ziel-Unity-Katalog und die Berechtigung EXTERNAL USE SCHEMA für den Katalog und seine Ressourcen hat.
Speichern Sie die Anwendungs-ID (UUID) für das Diensthauptkonto. Sie benötigen diese für einen späteren Schritt.

Secret-basiert

Bei dieser Option werden eine OAuth-Client-ID und ein Clientschlüssel verwendet, die sicher mit regionalen Secret Manager-Secrets gespeichert werden.

Erstellen Sie in Ihrem Databricks-Konto einen Diensthauptschlüssel, der Lesezugriff auf den Ziel-Unity-Katalog und die Berechtigung EXTERNAL USE SCHEMA für den Katalog und seine Ressourcen hat.
Generieren Sie ein OAuth-Geheimnis für das Diensthauptkonto.
Erstellen Sie eine JSON-Datei mit dem Namen credentials.json und Ihrer Nutzlast:
```
{
    "client_id": "CLIENT_ID",
    "client_secret": "CLIENT_SECRET"
}
```
Ersetzen Sie Folgendes:
- CLIENT_ID: Die OAuth-Client-ID für Ihr Databricks-Diensthauptkonto.
- CLIENT_SECRET: Der OAuth-Clientschlüssel für Ihren Databricks-Diensthauptschlüssel.
Konfigurieren Sie den regionalen Endpunkt für Secret Manager:

Secret Manager verwendet standardmäßig einen globalen Endpunkt. Lakehouse erfordert jedoch, dass Ihre Secrets in derselben Region wie Ihr Lakehouse-Katalog gespeichert werden. Wenn Sie mit regionalen Secrets über die gcloud-Befehlszeile interagieren möchten, müssen Sie den Standard-API-Endpunkt für Ihre aktuelle Sitzung oder Ihr aktuelles Profil überschreiben. Beispiel: secretmanager.us-east4.rep.googleapis.com
```
gcloud config set api_endpoint_overrides/secretmanager https://secretmanager.REGION.rep.googleapis.com/
```
Ersetzen Sie Folgendes:
- REGION: Die Google Cloud -Region, in der Ihr Secret Manager-Secret gespeichert ist. Beispiel: us-east4. Um Verbindungsprobleme zu vermeiden, müssen Ihr Secret und Ihr Katalog in derselben Region erstellt werden.
Laden Sie die Nutzlast in Secret Manager hoch:
```
gcloud secrets create DATABRICKS_SECRET_NAME \
  --location="REGION" \
  --project="PROJECT_ID" \
  --data-file=credentials.json
```
Ersetzen Sie Folgendes:
- DATABRICKS_SECRET_NAME: Ein Name für Ihr Databricks-Secret.
- PROJECT_ID: Projekt-ID in Google Cloud .

Föderierten Katalog erstellen

Erstellen Sie den föderierten Katalog mit der Google Cloud -Konsole oder der gcloud-Befehlszeile.

Wichtige Hinweise:

Es werden nur Databricks Unity-Kataloge unterstützt, die einen externen Standort in AWS oder einen externen Standort in Google Cloud verwenden. Databricks Unity Catalogs, die Standardspeicher in AWS oder Standardspeicher in Google Cloud verwenden, werden nicht unterstützt.
Sie müssen den externen Datenzugriff für den von Unity Catalog verwendeten Metastore aktivieren. Dieser ist standardmäßig deaktiviert.
Sie müssen dem Databricks-Diensthauptkonto die Berechtigung EXTERNAL USE SCHEMA für den Katalog und seine Ressourcen gewähren, um die Bereitstellung von Anmeldedaten für den Zugriff auf externe Daten zu ermöglichen. Ohne diese Berechtigung schlagen die Hintergrundaktualisierung von Metadaten und die Bereitstellung von Anmeldedaten für Abfragen fehl.

Console

So erstellen Sie einen föderierten Katalog:

Rufen Sie in der Google Cloud Console Lakehouse auf.

Zu Lakehouse
Klicken Sie auf Katalog erstellen.
Klicken Sie auf Föderierter Katalog.

Der Bereich Katalogkonfiguration wird angezeigt.
Wählen Sie als Quelle des föderierten Katalogs die Option Databricks (Unity) aus.
Wählen Sie unter Speicherort der Daten die Lakehouse-Region aus, in der Sie den föderierten Katalog erstellen möchten. Beispiel: us-east4. So minimieren Sie die Latenz (auch über das öffentliche Internet), wenn Sie eine Region auswählen:
- Wenn sich Ihr Unity Catalog in AWS befindet, wählen Sie dieGoogle Cloud Region aus, die Ihrer AWS-Region am nächsten liegt.
- Wenn sich Ihr Unity Catalog in Google Cloudbefindet, wählen Sie genau dieselbe Region aus.
Klicken Sie auf Weiter.

Der Abschnitt Verbindungsdetails wird angezeigt.
Geben Sie im Abschnitt Details zum Remote-Katalog im Feld Unity-Instanzname den Namen Ihrer Databricks-Zielinstanz ein. Beispiel: abcd.cloud.databricks.com.
Geben Sie im Feld Unity-Katalogname den Namen des Ziel-Databricks Unity Catalog ein, mit dem Sie eine Föderation erstellen möchten.
Wählen Sie eine Option für Authentifizierungsmethode aus:
- Geben Sie unter OIDC die Anwendungs-ID für den Diensthauptschlüssel ein.
- Geben Sie unter Secret den Namen Ihres Secrets ein. Verwenden Sie dieses Format: projects/PROJECT_ID/locations/REGION/secrets/DATABRICKS_SECRET_NAME.
Optional: Wählen Sie im Abschnitt Identitätsmodus eine Option aus:
- Dienstidentität (Standard): Abfragen werden als Lakehouse-Dienstkonto ausgeführt.
- Nutzeridentität: Abfragen werden mit der Identität des authentifizierten Endnutzers ausgeführt und an den Remote-Katalog weitergegeben. Die Identitätsföderation muss im Remote-Katalog konfiguriert sein.
Optional: Geben Sie im Feld Service Directory-Name den Pfad zu Ihrem Service Directory-Dienst ein. Beispiel: projects/PROJECT_ID/locations/REGION/namespaces/SERVICE_DIRECTORY_NAMESPACE/services/SERVICE_NAME Dies ist nur erforderlich, wenn Sie eine private Verbindung (Cross-Cloud Interconnect) konfigurieren.
Klicken Sie auf Erstellen.

gcloud

OIDC

Wenn Sie OIDC verwenden, müssen Sie --unity-service-principal-application-id angeben.

Öffentliches Internet (kein CCI)

Wenn Sie CCI nicht konfigurieren, wird die Verbindung sicher über das öffentliche Internet hergestellt.

gcloud biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="unity" \
    --unity-service-principal-application-id="UNITY_SERVICE_PRINCIPAL_APPLICATION_ID" \
    --unity-instance-name="UNITY_INSTANCE_NAME" \
    --unity-catalog-name="UNITY_CATALOG_NAME" \
    --refresh-interval="REFRESH_INTERVAL" \
    --namespace-filters="NAMESPACE_FILTERS" \
    --federated-catalog-identity-mode="IDENTITY_MODE"

Kundeneigen (CCI)

Wenn Sie eine private Interconnect-Verbindung (z. B. Dedicated CCI oder Partner CCI) konfiguriert haben, geben Sie die Service Directory-Dienstreferenz an, damit Lakehouse den Traffic privat weiterleitet.

gcloud biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="unity" \
    --unity-service-principal-application-id="UNITY_SERVICE_PRINCIPAL_APPLICATION_ID" \
    --unity-instance-name="UNITY_INSTANCE_NAME" \
    --unity-catalog-name="UNITY_CATALOG_NAME" \
    --refresh-interval="REFRESH_INTERVAL" \
    --namespace-filters="NAMESPACE_FILTERS" \
    --federated-catalog-identity-mode="IDENTITY_MODE" \
    --service-directory-name="projects/PROJECT_ID/locations/REGION/namespaces/SERVICE_DIRECTORY_NAMESPACE/services/SERVICE_NAME"

Ersetzen Sie Folgendes:

FEDERATED_CATALOG_NAME: ein Name für Ihren föderierten Katalog.
PROJECT_ID: Projekt-ID in Google Cloud .
REGION: die Lakehouse-Region, in der der föderierte Katalog erstellt wird. Diese muss mit der Region des Service Directory-Namespace und des regionalen Secrets übereinstimmen. So minimieren Sie die Latenz:
- Wenn sich Ihr Unity Catalog in AWS befindet, wählen Sie dieGoogle Cloud Region aus, die Ihrer AWS-Region am nächsten liegt.
- Wenn sich Ihr Unity Catalog in Google Cloudbefindet, wählen Sie genau dieselbe Region aus.
UNITY_SERVICE_PRINCIPAL_APPLICATION_ID: Die Anwendungs-ID (UUID) Ihres Databricks-Diensthauptkontos.
UNITY_INSTANCE_NAME: der Name Ihrer Databricks-Zielinstanz. Beispiel: abcd.cloud.databricks.com
UNITY_CATALOG_NAME: der Name des Ziel-Databricks Unity Catalog, mit dem die Föderation erstellt werden soll.
REFRESH_INTERVAL: Gibt an, wie oft die Metadaten im Hintergrund aktualisiert werden. Legen Sie diesen Wert als Dauer fest, z. B. 330s oder 5m30s.
NAMESPACE_FILTERS: Optional: Eine durch Kommas getrennte Liste von Namespaces, die föderiert werden sollen. Beispiel: ns1,ns2. Wenn keine Angabe erfolgt, werden alle Namespaces einbezogen.
IDENTITY_MODE (optional): Gibt den Identitätsmodus für den Katalog an. Legen Sie user-identity-federation fest, um Endnutzeridentitäten bei Abfragen weiterzugeben, oder service-identity, um Abfragen als Dienstkonto des Katalogs auszuführen. Wenn keine Angabe gemacht wird, lautet der Standardwert service-identity.
Wenn Sie eine private Interconnect-Verbindung (CCI) verwenden:
- SERVICE_DIRECTORY_NAMESPACE: der Service Directory-Namespace, den Sie während der Einrichtung der privaten Interconnect-Verbindung erstellt haben.
- SERVICE_NAME: der Name des Service Directory-Dienstes, den Sie bei der Einrichtung der privaten Interconnect-Verbindung erstellt haben.

Secret-basiert

Wenn Sie die Secret-basierte Authentifizierung verwenden, müssen Sie --secret-name angeben.

Öffentliches Internet (kein CCI)

Wenn Sie CCI nicht konfigurieren, wird die Verbindung sicher über das öffentliche Internet hergestellt.

gcloud biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="unity" \
    --secret-name="projects/PROJECT_ID/locations/REGION/secrets/DATABRICKS_SECRET_NAME" \
    --unity-instance-name="UNITY_INSTANCE_NAME" \
    --unity-catalog-name="UNITY_CATALOG_NAME" \
    --refresh-interval="REFRESH_INTERVAL" \
    --namespace-filters="NAMESPACE_FILTERS" \
    --federated-catalog-identity-mode="IDENTITY_MODE"

Kundeneigen (CCI)

gcloud biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="unity" \
    --secret-name="projects/PROJECT_ID/locations/REGION/secrets/DATABRICKS_SECRET_NAME" \
    --unity-instance-name="UNITY_INSTANCE_NAME" \
    --unity-catalog-name="UNITY_CATALOG_NAME" \
    --refresh-interval="REFRESH_INTERVAL" \
    --namespace-filters="NAMESPACE_FILTERS" \
    --federated-catalog-identity-mode="IDENTITY_MODE" \
    --service-directory-name="projects/PROJECT_ID/locations/REGION/namespaces/SERVICE_DIRECTORY_NAMESPACE/services/SERVICE_NAME"

Ersetzen Sie Folgendes:

FEDERATED_CATALOG_NAME: ein Name für Ihren föderierten Katalog.
PROJECT_ID: Projekt-ID in Google Cloud .
REGION: die Lakehouse-Region, in der der föderierte Katalog erstellt wird. Diese muss mit der Region des Service Directory-Namespace und des regionalen Secrets übereinstimmen. So minimieren Sie die Latenz:
- Wenn sich Ihr Unity Catalog in AWS befindet, wählen Sie dieGoogle Cloud Region aus, die Ihrer AWS-Region am nächsten liegt.
- Wenn sich Ihr Unity Catalog in Google Cloudbefindet, wählen Sie genau dieselbe Region aus.
DATABRICKS_SECRET_NAME: der Name Ihres Databricks-Secrets.
UNITY_INSTANCE_NAME: der Name Ihrer Databricks-Zielinstanz. Beispiel: abcd.cloud.databricks.com
UNITY_CATALOG_NAME: der Name des Ziel-Databricks Unity Catalog, mit dem die Föderation erstellt werden soll.
REFRESH_INTERVAL: Gibt an, wie oft die Metadaten im Hintergrund aktualisiert werden. Legen Sie diesen Wert als Dauer fest, z. B. 330s oder 5m30s.
NAMESPACE_FILTERS: Optional: Eine durch Kommas getrennte Liste von Namespaces, die föderiert werden sollen. Beispiel: ns1,ns2. Wenn keine Angabe erfolgt, werden alle Namespaces einbezogen.
IDENTITY_MODE (optional): Gibt den Identitätsmodus für den Katalog an. Legen Sie user-identity-federation fest, um Endnutzeridentitäten bei Abfragen weiterzugeben, oder service-identity, um Abfragen als Dienstkonto des Katalogs auszuführen. Wenn keine Angabe gemacht wird, lautet der Standardwert service-identity.
Wenn Sie eine private Interconnect-Verbindung (CCI) verwenden:
- SERVICE_DIRECTORY_NAMESPACE: der Service Directory-Namespace, den Sie während der Einrichtung der privaten Interconnect-Verbindung erstellt haben.
- SERVICE_NAME: der Name des Service Directory-Dienstes, den Sie bei der Einrichtung der privaten Interconnect-Verbindung erstellt haben.

Authentifizierungseinrichtung abschließen

Schließen Sie den Authentifizierungsvorgang mit dem ausgewählten Authentifizierungstyp ab.

OIDC

Wenn der Katalog erstellt wird, stellt Lakehouse ein eindeutiges Dienstkonto dafür bereit. Sie müssen die eindeutige numerische ID des Dienstkontos abrufen und damit eine Föderationsrichtlinie für den Databricks-Diensthauptschlüssel konfigurieren.

Rufen Sie die eindeutige numerische ID des Dienstkontos für den Lakehouse-Katalog ab:

gcloud biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --format='value(biglake-service-account-id)'

Konfigurieren Sie in Ihrem Databricks-Konto eine Föderationsrichtlinie für den zuvor erstellten Diensthauptschlüssel. Verwenden Sie die folgenden Werte:
- Aussteller-URL: https://accounts.google.com
- Subjekt: Die numerische eindeutige ID des Dienstkontos für den Lakehouse-Katalog, die im vorherigen Schritt abgerufen wurde.
- Zielgruppe: https://accounts.cloud.databricks.com
Achten Sie darauf, dass der Databricks-Diensthauptschlüssel Lesezugriff auf den Zielkatalog und den Arbeitsbereich sowie die Berechtigung EXTERNAL USE SCHEMA für den Katalog und seine Ressourcen hat.

Secret-basiert

Wenn der Katalog erstellt wird, stellt Lakehouse ein eindeutiges Dienstkonto dafür bereit (in der Ressourcenbeschreibung als biglake-service-account zurückgegeben).

Sie müssen diesem Dienstkonto die Berechtigung für den Zugriff auf das zuvor erstellte Secret gewähren. Beachten Sie, dass die Weitergabe von IAM-Richtlinien einige Minuten dauern kann.

Gewähren Sie dem Dienstkonto des Katalogs die Berechtigung für den Zugriff auf das Secret:

gcloud config set api_endpoint_overrides/secretmanager https://secretmanager.REGION.rep.googleapis.com/
gcloud secrets add-iam-policy-binding DATABRICKS_SECRET_NAME \
  --project="PROJECT_ID" \
  --location="REGION" \
  --member="serviceAccount:$(gcloud biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
      --project="PROJECT_ID" \
      --format='value(biglake-service-account)')" \
  --role="roles/secretmanager.secretAccessor"

Führen Sie den folgenden Befehl aus, um zu prüfen, ob das Dienstkonto für den föderierten Katalog Zugriff auf das Secret hat:

gcloud config set api_endpoint_overrides/secretmanager https://secretmanager.REGION.rep.googleapis.com/
gcloud secrets get-iam-policy DATABRICKS_SECRET_NAME \
     --project="PROJECT_ID" \
     --location="REGION"

Prüfen Sie in der Ausgabe, ob dem Dienstkonto biglake-service-account die Rolle roles/secretmanager.secretAccessor zugewiesen ist.

Achten Sie darauf, dass der Databricks-Diensthauptschlüssel Lesezugriff auf den Zielkatalog und den Arbeitsbereich sowie die Berechtigung EXTERNAL USE SCHEMA für den Katalog und seine Ressourcen hat.

Private Interconnect-Einrichtung abschließen (nur Cross-Cloud Interconnect)

Wenn Sie Traffic über eine private Interconnect-Verbindung (Dedicated oder Partner CCI) weiterleiten, müssen Sie dem Dienstkonto des Lakehouse-Katalogs Berechtigungen erteilen, um Verbindungen über Service Directory zu erkennen und zu autorisieren.

Console

Rufen Sie in der Google Cloud Console die Seite IAM auf.

IAM aufrufen
Klicken Sie auf Zugriff gewähren (oder Hinzufügen).
Geben Sie im Feld Neue Hauptkonten die E-Mail-Adresse des Lakehouse-Katalog-Dienstkontos ein. Sie können diese E-Mail-Adresse abrufen, indem Sie den Katalog beschreiben (siehe Tab gcloud).
Wählen Sie im Menü Rolle die Option Service Directory-Betrachter (roles/servicedirectory.viewer) aus.
Klicken Sie auf Weitere Rolle hinzufügen und wählen Sie Service Directory PSC Authorized Service (roles/servicedirectory.pscAuthorizedService) aus.
Klicken Sie auf Speichern.

gcloud

Weisen Sie dem Dienstkonto des Katalogs die erforderlichen Rollen zu:

# Grant Service Directory Viewer
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:$(gcloud biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --format='value(biglake-service-account)')" \
--role="roles/servicedirectory.viewer"

# Grant Service Directory PSC Authorized Service
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:$(gcloud biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --format='value(biglake-service-account)')" \
--role="roles/servicedirectory.pscAuthorizedService"

Verbindung prüfen

Prüfen Sie, ob der Zyklus zur Aktualisierung der Hintergrundmetadaten des Katalogs erfolgreich abgeschlossen wurde und die Namespaces synchronisiert sind.

Prüfen Sie, ob der Aktualisierungsstatus „Erfolgreich“ lautet:

gcloud biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
  --project="PROJECT_ID"

Prüfen Sie, ob die Namespaces synchronisiert sind:

gcloud biglake iceberg namespaces list \
  --project="PROJECT_ID" \
  --catalog="FEDERATED_CATALOG_NAME"

Nutzeridentitätsföderation konfigurieren (optional)

Wenn Sie die Nutzeridentitätsföderation für Ihren föderierten Katalog konfiguriert haben, müssen Sie in Databricks eine kontoweite Föderationsrichtlinie konfigurieren.

Die Hintergrundaktualisierung von Metadaten wird als Dienstkonto des Katalogs ausgeführt, das mit der Basisauthentifizierung (OIDC oder Secret-basiert) konfiguriert ist. Für die Nutzeridentitätsföderation ist jedoch diese kontoweite Richtlinie erforderlich, damit Databricks die von Google Cloud erstellten Endnutzer-Identitätstokens während interaktiver Abfragen validieren kann. So kann Databricks Abfragen Endnutzern zuordnen, Berechtigungen erzwingen und Audit-Logs generieren.

(Optional) Vorhandenen Katalog aktualisieren:

Wenn Sie einen vorhandenen föderierten Katalog haben, der mit dem Standardmodus für die Dienstidentität konfiguriert ist, können Sie ihn auf die Nutzeridentitätsföderation aktualisieren, ohne den Katalog neu erstellen zu müssen:
Console
1. Rufen Sie in der Google Cloud Console Lakehouse auf.
  
  Zu Lakehouse
2. Klicken Sie in der Liste der Kataloge auf den Namen Ihres föderierten Katalogs.
  
  Die Seite Katalogdetails wird angezeigt.
3. Klicken Sie auf Katalog bearbeiten.
4. Wählen Sie im Abschnitt Identitätsmodus die Option Nutzeridentität aus.
5. Klicken Sie auf Speichern.
gcloud
Führen Sie den Befehl gcloud biglake iceberg catalogs update aus:
gcloud biglake iceberg catalogs update FEDERATED_CATALOG_NAME \ --project="PROJECT_ID" \ --federated-catalog-identity-mode="user-identity-federation"
Rufen Sie die OIDC-Anforderungen aus Ihrem Katalog ab:

Führen Sie den folgenden Befehl aus, um die von Databricks benötigten Token-Ansprüche abzurufen:
```
gcloud biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --format='yaml(federated-catalog-options.user-identity-federation-oidc)'
```
Die Ausgabe sieht dann ungefähr so aus:
```
federated-catalog-options:
  user-identity-federation-oidc:
    audience: databricks-12345678-abcd-1234-efgh-1234567890ab
    issuer-url: https://www.gstatic.com/biglake/federation/organizations/123456789012
```
Beachten Sie Folgendes in Bezug auf die Verfügbarkeit von Ansprüchen:
- issuer-url: Wird von Ihrer Google Cloud Organisation (https://www.gstatic.com/biglake/federation/organizations/ORGANIZATION_ID) abgeleitet und ist sofort nach der Katalogerstellung verfügbar.
- audience: Auf Ihren Ziel-Databricks-Metastore (databricks-METASTORE_ID) beschränkt und vom Unity Catalog-Metastore abgeleitet. Da dieser Wert durch die Aktualisierung von Hintergrundmetadaten ausgefüllt wird, muss die Basisauthentifizierung abgeschlossen und die Aktualisierung von Hintergrundmetadaten aktiv sein (nicht auf 0 festgelegt). Unter Verbindung prüfen können Sie nachsehen, ob die Aktualisierung von Hintergrundmetadaten korrekt eingerichtet ist.
Konfigurieren Sie die kontoweite Databricks-Föderationsrichtlinie:
1. Rufen Sie in der Databricks-Kontokonsole Kontoeinstellungen > Sicherheit > Einrichtung des Identitätsanbieters auf.
2. Klicken Sie im Abschnitt Föderationsrichtlinien auf Richtlinie erstellen.
3. Legen Sie im Dialogfeld für die Richtlinienkonfiguration die folgenden Felder fest:
  - Aussteller-URL: Geben Sie den im vorherigen Schritt abgerufenen issuer-url-Wert ein (z. B. https://www.gstatic.com/biglake/federation/organizations/ORGANIZATION_ID).
  - Zielgruppen: Geben Sie den im vorherigen Schritt abgerufenen Metastore-bezogenen audience-Wert ein (z. B. databricks-METASTORE_ID).
  - Subject Claim: Lassen Sie dieses Feld leer. Databricks verwendet standardmäßig den sub-Claim, der die E-Mail-Adresse des Nutzers enthält. Databricks verwendet diese E-Mail-Adresse, um sie mit Nutzern abzugleichen, die in Ihrem Databricks-Konto konfiguriert sind.
4. Klicken Sie auf Speichern.
Nutzeridentitätsföderation und Audit-Logging prüfen:

So prüfen Sie die nutzerbezogene Abfrageausführung und das Audit-Logging:
1. Folgen Sie der Anleitung unter Remote-Daten abfragen, um eine Abfrage in BigQuery für eine föderierte Tabelle auszuführen.
2. Prüfen Sie in Databricks, ob das Abfragezugriffsereignis in den Databricks-Audit-Logs aufgezeichnet wird. Fragen Sie die Systemtabelle system.access.audit im Databricks SQL-Editor ab (siehe Databricks-Audit-Log-Referenz). Beachten Sie, dass es 15 Minuten oder länger dauern kann, bis prüfbare Ereignisse in den Databricks-Audit-Logs angezeigt werden:
```
SELECT
  *
FROM
  system.access.audit
WHERE
  service_name = 'accounts'
  AND action_name IN ('oidcTokenAuthorization')
  AND event_time >= NOW() - INTERVAL 30 MINUTE
  AND user_identity.email = 'USER_EMAIL'
ORDER BY
  event_time DESC
LIMIT 10;
```

Cloud-übergreifende Verbindung für Databricks Unity Catalog einrichten Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Hinweis

Erforderliche Rollen

Einschränkungen und Überlegungen

Allgemeiner Workflow

Cross-Cloud Interconnect einrichten (optional)

Interner regionaler Proxy-Network Load Balancer

Direkter Endpunkt

Föderation einrichten

Authentifizierung konfigurieren

OIDC

Secret-basiert

Föderierten Katalog erstellen

Console

gcloud

OIDC

Öffentliches Internet (kein CCI)

Kundeneigen (CCI)

Secret-basiert

Öffentliches Internet (kein CCI)

Kundeneigen (CCI)

Authentifizierungseinrichtung abschließen

OIDC

Secret-basiert

Private Interconnect-Einrichtung abschließen (nur Cross-Cloud Interconnect)

Console

gcloud

Verbindung prüfen

Nutzeridentitätsföderation konfigurieren (optional)

Console

gcloud

Nächste Schritte

Cloud-übergreifende Verbindung für Databricks Unity Catalog einrichten