Fehlerbehebung beim cloudübergreifenden Datenzugriff

Wenn Sie mit Lakehouse auf cloudübergreifende Daten zugreifen, können Sie Probleme mit der Hintergrundaktualisierung von Metadaten, dem privaten Interconnect-Routing über Cross-Cloud Interconnect und der Auflösung von Service Directory-Endpunkten diagnostizieren und beheben. Durch die Behebung dieser Probleme bleiben die Metadaten der föderierten Tabelle aktuell und die private cloudübergreifende Abfrageausführung wird wiederhergestellt.

Daten und Ressourcen sind veraltet oder werden nicht aktualisiert

Föderierte Lakehouse-Kataloge synchronisieren Metadaten aus einer Remote-Cloud basierend auf einem Aktualisierungsintervall. Die Aktualisierung der Hintergrundmetadaten eines föderierten Katalogs kann länger dauern, wenn der föderierte Katalog viele Ressourcen (Freigaben, Schemas, Namespaces und Tabellen) enthält. Wenn eine vorherige Aktualisierung länger dauert, wird die aktuelle Aktualisierung übersprungen und die nächste Aktualisierung wird im folgenden geplanten Intervall ausgeführt.

Wenn abgefragte Daten veraltet erscheinen, wird die Hintergrundaktualisierung der Metadaten des föderierten Katalogs möglicherweise überschritten oder schlägt fehl. Wenn Sie eine Ressource in der Remote-Cloud löschen, wird sie bei der nächsten abgeschlossenen Hintergrundaktualisierung der Metadaten aus Lakehouse entfernt.

Prüfen Sie den Status der Hintergrundaktualisierung von Metadaten für einen föderierten Katalog auf der Seite Lakehouse in der Google Cloud Console oder mit der Google Cloud CLI:

Zu Lakehouse

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

gcloud biglake delta-sharing catalogs describe FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID"

Fehlerbehebung für AWS Glue Data Catalog

Wenn die Hintergrundaktualisierung von Metadaten fehlschlägt, nachdem Sie --metadata-service-directory-name für einen föderierten AWS Glue-Katalog im Lakehouse-Laufzeitkatalog konfiguriert haben, prüfen Sie Folgendes:

  • Endpunktzuordnung für privaten Katalog prüfen: Bestätigen Sie, dass die Hybrid Connectivity Network Endpoint Group (NEG) oder der Service Directory-Endpunkt für die Hintergrundaktualisierung von Metadaten auf die private IP-Adresse Ihres AWS Glue Interface VPC-Endpunkts (com.amazonaws.AWS_REGION.glue) auf TCP-Port 443 verweist, und nicht auf Ihren Amazon S3 Interface VPC-Endpunkt.
  • IAM-Rollen-Vertrauensrichtlinie und Berechtigungen prüfen: Bestätigen Sie, dass die IAM-Rollen-Vertrauensrichtlinie von Amazon Web Services (AWS) demGoogle Cloud Dienstkonto (biglake-service-account) des föderierten Katalogs erlaubt, die Rolle (sts:AssumeRoleWithWebIdentity) zu übernehmen, und dass die Rolle Berechtigungen zum Lesen Ihrer AWS Glue-Datenbank- und Tabellenmetadaten (glue:GetDatabase, glue:GetDatabases, glue:GetTable, glue:GetTables) hat.
  • Regeln für VPC-Endpunkt-Sicherheitsgruppen prüfen: Prüfen Sie, ob die AWS-Sicherheitsgruppe, die an Ihren AWS Glue-Schnittstellen-VPC-Endpunkt angehängt ist, eingehenden HTTPS-Traffic auf TCP-Port 443 von IhremGoogle Cloud Virtual Private Cloud-Subnetz (VPC) und den CIDR-Bereichen des Nur-Proxy-Subnetzes zulässt.

Fehlerbehebung für Databricks Unity Catalog

Tabellen sind leer oder werden bei der Aktualisierung von Hintergrundmetadaten nicht erkannt

Wenn die Hintergrundaktualisierung der Metadaten des föderierten Katalogs abgeschlossen ist (z. B. Refresh successfully completed), aber keine Tabellen im föderierten Katalog angezeigt werden oder das Auflisten von Tabellen 0 Elemente zurückgibt, prüfen Sie Folgendes:

  • Berechtigung EXTERNAL USE SCHEMA: Prüfen Sie, ob dem Databricks-Diensthauptkonto die Berechtigung EXTERNAL USE SCHEMA für die Zielschemas oder den Zielkatalog in Databricks Unity Catalog gewährt wurde. Ohne diese Berechtigung schlagen die Aktualisierung von Hintergrundmetadaten und die Bereitstellung von Anmeldedaten für Abfragen fehl.
  • Einstellung für externen Datenzugriff: Prüfen Sie, ob Externer Datenzugriff im Databricks Unity Catalog-Metastore aktiviert ist.
  • Externer Speicherort: Prüfen Sie, ob Ihr Databricks Unity Catalog und Ihre Tabellen einen externen Speicherort (z. B. Amazon S3, Microsoft Azure Data Lake Storage Gen2 oder Cloud Storage) anstelle des Standardspeichers verwenden.

Aktualisierung von Metadaten im Hintergrund schlägt über Cross-Cloud Interconnect fehl

Wenn die Hintergrundaktualisierung der Metadaten fehlschlägt, wenn --metadata-service-directory-name für Databricks Unity Catalog im Lakehouse-Laufzeitkatalog konfiguriert ist, prüfen Sie Folgendes:

  • Ziel des privaten Endpunkts des Arbeitsbereichs: Prüfen Sie, ob der Service Directory-Endpunkt für Metadaten oder das Backend des internen regionalen Proxy-Network Load Balancers auf die private IP-Adresse des AWS PrivateLink-Schnittstellenendpunkts Ihres Databricks-Arbeitsbereichs oder des privaten Azure-Endpunkts auf TCP-Port 443 verweist, anstatt auf den Endpunkt Ihres Remote-Speichers, und ob --unity-instance-name mit dem Hostnamen Ihres Arbeitsbereichs übereinstimmt.
  • Einstellungen für den privaten Zugriff auf den Arbeitsbereich: Wenn Ihr Databricks-Arbeitsbereich Einstellungen für den privaten Zugriff oder IP-Zugriffslisten erzwingt, prüfen Sie, ob Anfragen, die über Ihren privaten Endpunkt von Ihrem Google Cloud-VPC-Netzwerk eingehen, zulässig sind.

Die Aktualisierung von Hintergrundmetadaten schlägt fehl oder gibt den Fehler „401 Unauthorized“ zurück

Wenn der Status der Hintergrundaktualisierung der Metadaten einen Fehler meldet (z. B. 401 Unauthorized) oder keine Schemas gefunden werden können, prüfen Sie Folgendes:

  • Föderationsrichtlinie für Diensthauptkonten: Prüfen Sie in der Databricks-Kontokonsole (Kontoeinstellungen > Sicherheit > Einrichtung des Identitätsanbieters > Föderationsrichtlinien), ob die Föderationsrichtlinie für Diensthauptkonten so konfiguriert ist:
    • Aussteller-URL: https://accounts.google.com
    • Subjekt: Die numerische eindeutige ID des biglake-service-account-Dienstkontos des föderierten Katalogs (nicht die E-Mail-Adresse).
    • Zielgruppe: https://accounts.cloud.databricks.com
  • Secret Manager-Berechtigungen: Wenn Sie die Secret-basierte Authentifizierung verwenden, prüfen Sie, ob das Secret am angegebenen regionalen Standort vorhanden ist und ob dem biglake-service-account die Rolle „Secret Manager Secret Accessor“ (roles/secretmanager.secretAccessor) zugewiesen ist.
  • Berechtigungen für Diensthauptkonten: Prüfen Sie, ob das Databricks-Diensthauptkonto Lesezugriff auf den Zielarbeitsbereich und Databricks Unity Catalog hat.

Interaktive Abfrage schlägt mit Fehler „401 Nicht autorisiert“ oder Tokenvalidierungsfehler fehl

Wenn die Nutzeridentitätsföderation aktiviert ist, wird bei interaktiven Abfragen dynamisch ein Endnutzer-Identitätstoken erstellt und anhand einer kontoweiten Föderationsrichtlinie in Databricks validiert. Wenn Abfragen mit 401 Unauthorized- oder Tokenvalidierungsfehlern fehlschlagen, während die Hintergrundaktualisierung der Metadaten fehlerfrei ist, prüfen Sie Folgendes:

  • Kontoweite Föderationsrichtlinie konfiguriert: Achten Sie darauf, dass in der Databricks-Kontokonsole unter Kontoeinstellungen > Sicherheit > Einrichtung des Identitätsanbieters > Föderationsrichtlinien eine kontoweite Föderationsrichtlinie (unterscheidet sich von der Diensthauptrichtlinie) erstellt wurde.
  • Zielgruppenabgleich unter Berücksichtigung der Groß-/Kleinschreibung: Databricks validiert die Anforderung aud (Zielgruppe) strikt unter Berücksichtigung der Groß-/Kleinschreibung. Prüfen Sie, ob die Groß-/Kleinschreibung im Feld Zielgruppen in der kontoweiten Databricks-Föderationsrichtlinie genau mit der Groß-/Kleinschreibung des Metastore-bezogenen audience-Claims (databricks-METASTORE_ID) übereinstimmt, der aus Ihrem föderierten Katalog abgerufen wurde. Bei Abweichungen in der Groß- und Kleinschreibung (z. B. im Präfix databricks- oder in der Metastore-UUID) wird die Abfrage bei der Databricks-Tokenvalidierung mit 401 Unauthorized abgelehnt.
  • Aussteller-URL: Prüfen Sie, ob die Aussteller-URL genau mit der issuer-url-Anforderung aus dem föderierten Katalog übereinstimmt: https://www.gstatic.com/biglake/federation/organizations/ORGANIZATION_ID.
  • Verfügbarkeit der Metastore-Zielgruppe: Die Metastore-bezogene audience-Anforderung wird erst nach Abschluss des ersten Hintergrund-Metadatenaktualisierungszyklus ausgefüllt (normalerweise innerhalb von 5 Minuten). Wenn Sie die Richtlinie mit einem Platzhalterwert oder vor Abschluss des ersten Aktualisierungszyklus konfigurieren, schlagen Abfragen fehl. Führen Sie gcloud biglake iceberg catalogs describe aus, um zu prüfen, ob die audience-Anforderung im föderierten Katalog ausgefüllt wurde, bevor Sie die Richtlinie konfigurieren.

Fehlerbehebung für Snowflake Horizon Catalog

Die Aktualisierung der Hintergrundmetadaten schlägt mit Code 16 (Nicht authentifiziert) fehl.

Wenn die Hintergrundaktualisierung der Metadaten für einen Snowflake Horizon Catalog mit dem Status Code 16 (UNAUTHENTICATED) fehlschlägt, prüfen Sie Folgendes:

  • Formatierung der Secret-Nutzlast: Das Secret-Token in Secret Manager muss die erforderliche JSON-Struktur ({"client_secret": "SNOWFLAKE_PAT_TOKEN", "scope": "session:role:SNOWFLAKE_ROLE"}) enthalten und nicht den Rohstring des programmatischen Zugriffstokens (PAT).
  • Tokenablauf und Berechtigungen: Prüfen Sie, ob das Snowflake-PAT gültig ist und ob der zugehörige Nutzer und die zugehörige Rolle Berechtigungen zum Lesen des Zielkatalogs und der Zieldatenbanken haben.
  • PrivateLink- oder Private Link-Konto-ID: Wenn Sie --metadata-service-directory-name so konfiguriert haben, dass Metadaten über Cross-Cloud Interconnect mit AWS PrivateLink oder Azure Private Link synchronisiert werden, prüfen Sie, ob --snowflake-account-identifier Ihre Snowflake-.privatelink-Konto-ID (z. B. myorg-myaccount.privatelink) anstelle Ihrer öffentlichen Konto-ID angibt.
  • Netzwerkrichtlinie: Wenn die Hintergrundaktualisierung von Metadaten über das öffentliche Internet erfolgt und eine Snowflake-Netzwerkrichtlinie aktiv ist, prüfen Sie, ob die ausgehenden IP-Adressbereiche von Google aus goog.json in der Liste der zulässigen IP-Adressen Ihrer Netzwerkrichtlinie enthalten sind.

Aktualisierung von Metadaten im Hintergrund schlägt über Cross-Cloud Interconnect fehl

Wenn die Aktualisierung der Metadaten im Hintergrund fehlschlägt, wenn --metadata-service-directory-name für Snowflake Horizon Catalog im Lakehouse-Laufzeitkatalog konfiguriert ist, prüfen Sie Folgendes:

  • Privates Snowflake-Endpunktziel: Prüfen Sie, ob der Service Directory-Endpunkt für Metadaten oder das Backend des internen regionalen Proxy-Network Load Balancers auf die private IP-Adresse des AWS PrivateLink-Schnittstellenendpunkts oder des Azure Private Endpoint von Snowflake auf TCP-Port 443 verweist, anstatt auf den Endpunkt des Remote-Objektspeichers.
  • Private Konto-ID: Prüfen Sie, ob --snowflake-account-identifier Ihre .privatelink-Konto-ID verwendet (z. B. myorg-myaccount.privatelink).

Verbindungs- oder Routingprobleme

Wenn beim Weiterleiten von Traffic über Cross-Cloud Interconnect Fehler beim Abfragetransport oder bei der Aktualisierung von Hintergrundmetadaten auftreten, prüfen Sie Folgendes:

  • Routenweitergabe prüfen: Prüfen Sie den Cloud Router inGoogle Cloud , um festzustellen, ob er Ihre AWS-VPC- oder Azure-VNet-Präfixe (Virtual Network) erkannt hat. Prüfen Sie in Ihren AWS- oder Azure-Routentabellen, ob Routen zurück zu Ihrem Google Cloud-VPC-Netzwerk vorhanden sind. Wenn Sie einen internen regionalen Proxy-Network Load Balancer verwenden, prüfen Sie, ob der Cloud Router den CIDR-Bereich Ihres Nur-Proxy-Subnetzes über benutzerdefinierte BGP-Route Advertisements bewirbt.
  • Zustand des internen Load Balancers prüfen: Rufen Sie in der Google Cloud Console Netzwerkdienste > Load Balancing auf und prüfen Sie, ob die Hybrid Connectivity Network Endpoint Group (NEG)-Backends für Ihre Transport- und Metadaten-Backend-Dienste fehlerfrei sind. Wenn ein Backend fehlerhaft ist, prüfen Sie die Private Interconnect-Verbindung und die Remote-Sicherheitsregeln.
  • Konnektivität von Google Cloudtesten: Erstellen Sie eine Test-VM-Instanz im selben Google Cloud VPC-Netzwerk und Subnetz wie der interne Load Balancer oder Service Directory-Endpunkt und testen Sie die Konnektivität zu Ihren AWS Elastic Network Interface (ENI)- oder Azure Private Endpoint-Netzwerkschnittstellen-IP-Adressen (NIC) auf TCP-Port 443 (z. B. mit curl oder nc).
  • Service Directory-Konfiguration und -Berechtigungen prüfen: Bestätigen Sie, dass sich die in --service-directory-name (für den Abfragetransport) und --metadata-service-directory-name (für die Hintergrundaktualisierung von Metadaten) konfigurierten Service Directory-Dienste in derselben Google Cloud Region wie Ihr föderierter Katalog befinden. Wenn eine Hintergrundaktualisierung der Metadaten für einen föderierten Katalog mit dem Fehler Permission 'servicedirectory.services.resolve' denied fehlschlägt, prüfen Sie, ob die eindeutige Dienstkonto-ID des föderierten Katalogs (Feld biglake-service-account) die Rollen roles/servicedirectory.viewer und roles/servicedirectory.pscAuthorizedService für jedes Projekt hat, das einen Service Directory-Dienst hostet.
  • Sicherheitsgruppen und Firewallregeln prüfen: Prüfen Sie, ob die Firewallregeln vonGoogle Cloud , AWS-Sicherheitsgruppen und Azure-Netzwerksicherheitsgruppen (NSGs) TCP-Traffic auf Port 443 zwischen Ihren Google Cloud VPC-CIDR-Bereichen (einschließlich aller CIDR-Bereiche von Nur-Proxy-Subnetzen) und Ihren privaten Remote-Endpunkten zulassen.