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

In diesem Dokument wird beschrieben, wie Sie eine cloudübergreifende Verbindung einrichten, um Daten aus einem Databricks Unity Catalog direkt in Google Cloudabzufragen. Mit dieser Funktion können Sie Ihre Datenanalysen vereinheitlichen, indem Sie Ihre externen Datenquellen in Ihre bestehende Google Cloud -Umgebung einbinden.

Anschließend können Sie mit dem grenzenlosen Lakehouse den Zugriff auf Ihre föderierten Daten verwalten.

Hinweis

Lesen Sie den Lakehouse-Überblick, um zu verstehen, wie der Zugriff auf Daten in Lakehouse verwaltet wird.
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.

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 mit Ihrem grenzenlosen Lakehouse wird bei den folgenden Remote-Cloud-Anbietern unterstützt: Amazon Web Services (AWS). Sie können entweder Dedicated Cross-Cloud Interconnect oder Partner Cross-Cloud Interconnect verwenden.
Netzwerkrouting:Wenn keine private Interconnect-Verbindung (z. B. Dedicated CCI oder Partner CCI) konfiguriert ist, werden Anfragen ü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 Catalogs 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. Dieser ist standardmäßig deaktiviert.
- 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 durchgefü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 als erwartet, wird die aktuelle Aktualisierung übersprungen. Die nächste Aktualisierung wird dann im nächsten Intervall geplant.
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 in dieser Zielregion gespeichert. Wenn sich Ihre Remote-Clouddaten in einer anderen Gerichtsbarkeit befinden, achten Sie darauf, dass das regionsü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.
- OpenID Connect (OIDC) (empfohlen): Erstellen Sie den föderierten Katalog in Lakehouse und geben Sie die Anwendungs-ID des Remote-Dienstprinzipals an. Konfigurieren Sie dann eine Föderationsrichtlinie in Databricks mit der eindeutigen ID des Dienstkontos des Lakehouse-Katalogs.
- Secret-basierte Authentifizierung:Erstellen Sie in Secret Manager ein Secret mit den Anmeldedaten für Ihren Remote-Katalog. Erstellen Sie dann einen föderierten Katalog in Lakehouse und gewähren Sie dem Dienstkonto des Katalogs Zugriff auf das Secret.
Verbindung prüfen: Prüfen Sie, ob Lakehouse eine Verbindung zu Ihrem Remote-Katalog herstellen kann.
Daten abfragen:Führen Sie mit BigQuery oder Managed Service for Apache Spark Abfragen für Ihre föderierten Daten aus. Lakehouse-Caching wird automatisch für Abfragen aktiviert, um die Kosten für ausgehenden Traffic zu senken. Weitere Informationen finden Sie unter Remotedaten 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:

Dedicated 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-Storage-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 Hybrid Connectivity Network Endpoint Groups (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-CCIs erforderlich und wird für dedizierte CCIs aus Gründen des Load-Balancing, der Skalierbarkeit und der 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 Dedicated 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 für Hochverfügbarkeit und Lastenausgleich 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 Console 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 -gruppen, 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 vonGoogle Cloud gehören, um Systemdiagnosen und weitergeleiteten Traffic zuzulassen.

Netzwerk Google Cloud konfigurieren

Führen Sie die folgenden Befehle aus, um die Einrichtung zu vereinfachen und den internen Load Balancer zu konfigurieren. Weitere Informationen finden Sie unter Regionalen internen Proxy-Network Load Balancer für Hybridendpunkte 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:

So erstellen Sie einen regionalen Backend-Dienst mit intern 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 add-backend-Befehl für jedes erstellte Hybrid-NEG.

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 ihr 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 Google Cloud Projekt-ID.
- 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 CloudProjektnummer. 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 Google Cloud -Projekt-ID.
- 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 eine Authentifizierung beim Remote-Katalog als Databricks-Dienstprinzipal erforderlich. Wählen Sie eine der folgenden Authentifizierungsoptionen aus:

OIDC

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

Erstellen Sie in Ihrem Databricks-Konto einen Dienstprinzipal mit Lesezugriff auf den Ziel-Unity Catalog und der Berechtigung EXTERNAL USE SCHEMA für die Zielschemata oder den Zielkatalog.
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 in regionalen Secret Manager-Secrets gespeichert sind.

Erstellen Sie in Ihrem Databricks-Konto einen Dienstprinzipal mit Lesezugriff auf den Ziel-Unity-Katalog.
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 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 Console oder der gcloudCLI.

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-Kataloge, die Standard-Speicher in AWS oder Standard-Speicher 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-Dienstprinzipal das EXTERNAL USE SCHEMA-Privileg für die Zielschemas oder den Zielkatalog gewähren, um die Bereitstellung von Anmeldedaten für den externen Datenzugriff zu ermöglichen. Ohne dieses Recht schlagen die Aktualisierung von Hintergrundmetadaten 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 Abschnitt 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 ist.
- Wenn sich Ihr Unity Catalog in Google Cloudbefindet, wählen Sie genau dieselbe Region aus.
Klicken Sie auf Weiter.

Der Bereich Verbindungsdetails wird angezeigt.
Geben Sie im Bereich Details zum Remote-Katalog im Feld Name der Unity-Instanz den Namen Ihrer Ziel-Databricks-Instanz 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 Dienstprinzipal ein.
- Geben Sie unter Secret den Namen Ihres Secrets ein. Verwenden Sie dieses Format: projects/PROJECT_ID/locations/REGION/secrets/DATABRICKS_SECRET_NAME.
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 alpha 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"

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 Traffic privat weiterleitet.

gcloud alpha 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" \
    --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 Ihr Unity-Katalog auf Google Cloudist, 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 eine 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 berücksichtigt.
Wenn Sie eine private Interconnect-Verbindung (CCI) verwenden:
- SERVICE_DIRECTORY_NAMESPACE: der Service Directory-Namespace, den Sie bei der Einrichtung von Private Interconnect erstellt haben.
- SERVICE_NAME: Der Name des Service Directory-Dienstes, den Sie bei der Einrichtung von Private Interconnect 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 alpha 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"

Kundeneigen (CCI)

gcloud alpha 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" \
    --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. Dies muss dieselbe Region wie der Service Directory-Namespace und das regionale Secret sein. 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 Ihr Unity-Katalog auf Google Cloudist, 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 eine 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 berücksichtigt.
Wenn Sie eine private Interconnect-Verbindung (CCI) verwenden:
- SERVICE_DIRECTORY_NAMESPACE: der Service Directory-Namespace, den Sie bei der Einrichtung von Private Interconnect erstellt haben.
- SERVICE_NAME: der Name des Service Directory-Dienstes, den Sie bei der Einrichtung von Private Interconnect 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 alpha 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 eindeutige numerische 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 die Zielschemas oder den Zielkatalog 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 alpha 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 des föderierten Katalogs 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 die Zielschemas oder den Zielkatalog hat.

Einrichtung der privaten Verbindung 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, damit Verbindungen über Service Directory ermittelt und autorisiert werden können.

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 alpha 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 alpha 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 Aktualisierungszyklus für die Hintergrundmetadaten des Katalogs erfolgreich abgeschlossen wurde und die Namespaces synchronisiert sind.

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

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

Prüfen Sie, ob die Namespaces synchronisiert sind:

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

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

Einrichtung der privaten Verbindung abschließen (nur Cross-Cloud Interconnect)

Console

gcloud

Verbindung prüfen

Nächste Schritte

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