Cross-Cloud-Verbindung für Snowflake Horizon Catalog einrichten

Mit einer cloudübergreifenden Verbindung zu einem Snowflake Horizon 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 in Borderless Lakehouse verwalten.

Hinweis

  1. In der Lakehouse-Übersicht erfahren Sie, wie Lakehouse den Zugriff auf Daten verwaltet.
  2. Informationen zum Zugriff auf cloudübergreifende Daten
  3. Prüfen Sie die unterstützten Kataloge, um die unterstützten Konfigurationen zu ermitteln.
  4. Regionale Secret Manager-Secrets verwenden Dies ist erforderlich, um Lakehouse mit Snowflake Horizon Catalog mithilfe der Secret-basierten Authentifizierung einzurichten.
  5. 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.
  6. 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.

  7. Verify that billing is enabled for your Google Cloud project.

  8. 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

  9. Verify that billing is enabled for your Google Cloud project.

  10. 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

    11.

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:

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 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.
  • Unterstützte Tabellen für Snowflake Horizon Catalog: Nur Snowflake Iceberg-Tabellen werden mit Lakehouse synchronisiert. Native Snowflake-Tabellen werden bei der Metadatenaktualisierung ignoriert.
  • Netzwerkrichtlinie und IP-Adressen für ausgehenden Traffic: Beim Abfragen eines Snowflake-Kontos verwendet Lakehouse IP-Adressen für ausgehenden Traffic der globalen Infrastruktur, um den internetseitigen Snowflake-Endpunkt zu erreichen. Ausgehender Traffic stammt aus breiten Google-Infrastrukturbereichen. Verwenden Sie in Ihrer Remote-Cloud goog.json, um die ausgehenden IP-Adressbereiche von Google in Ihrer Snowflake-Netzwerkrichtlinie auf die Zulassungsliste zu setzen.
  • 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, wird die aktuelle Aktualisierung übersprungen. Die nächste Aktualisierung wird jedoch für das folgende Intervall geplant. Bei Abfragen werden die zuletzt synchronisierten Katalogmetadaten verwendet. Ä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 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.
    • Secret-basierte Authentifizierung (PAT): Erstellen Sie in Secret Manager ein Secret mit Ihren Remote-Katalog-Anmeldedaten. Erstellen Sie dann einen föderierten Katalog in Lakehouse und gewähren Sie dem Dienstkonto des Katalogs Zugriff auf das Secret.
    • Workload Identity-Föderation (WIF): Erstellen Sie einen föderierten Katalog in Lakehouse und geben Sie die erforderliche Snowflake-Rolle an. Verknüpfen Sie dann die Dienstkonto-ID des Katalogs mit einem Dienstnutzer in Snowflake. Der Snowflake-Dienstnutzer sollte Nutzungsberechtigungen für den Remote-Snowflake Horizon Catalog haben.
  • 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 IAM können Sie verwalten, 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:

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-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 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 auf mehrere AWS-ENIs für Hochverfügbarkeit und Load Balancing zu verteilen:

AWS-Netzwerk konfigurieren

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

  1. Erstellen Sie in der AWS-VPC-Konsole einen Schnittstellenendpunkt für Amazon S3.
  2. Geben Sie als Dienstnamen com.amazonaws.AWS_REGION.s3 an.
  3. Wählen Sie die VPC und die Subnetze aus, die über Direct Connect mit Ihrer Google Cloud -VPC verbunden sind.
  4. Hängen Sie Sicherheitsgruppen an den Endpunkt an, um den eingehenden Zugriff zu steuern.
  5. 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.

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 und erweiterte 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).

  1. 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).

  2. 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.

  3. 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.

  4. Konfigurieren Sie das Load-Balancer-Frontend:

    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.

  1. 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.

  2. 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.

  3. 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:

  1. 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.

  2. 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.

  3. 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.

  4. 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-Snowflake Horizon Catalog herstellt.

Authentifizierung konfigurieren

Für die Föderation sind Anmeldedaten oder eine Rollenkonfiguration erforderlich, um auf den Remote-Snowflake Horizon Catalog zuzugreifen. Wählen Sie eine der folgenden Methoden aus.

Secret-basiert (PAT)

Bei dieser Option wird ein programmatisches Zugriffstoken (PAT) verwendet, das sicher mit regionalen Secret Manager-Secrets gespeichert wird.

  1. Generieren Sie ein programmatisches Zugriffstoken (PAT) mit Lesezugriff auf den Zielkatalog.

  2. Erstellen Sie eine JSON-Datei mit dem Namen credentials.json und Ihrer Nutzlast:

    {
  "client_secret": "SNOWFLAKE_PAT_TOKEN",
  "scope": "session:role:SNOWFLAKE_ROLE"
}

    Ersetzen Sie Folgendes:

    • SNOWFLAKE_PAT_TOKEN: Ihr Snowflake-PAT (Programmatic Access Token).
    • SNOWFLAKE_ROLE: Die spezifische Snowflake-Rolle, die für die Sitzung erforderlich ist. Beispiel: ICEBERG_VIEW.

  3. 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-CLI interagieren möchten, müssen Sie den Standard-API-Endpunkt für Ihre aktuelle Sitzung oder Ihr aktuelles Profil überschreiben.

    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.

  4. Laden Sie die Nutzlast in Secret Manager hoch:

    gcloud secrets create SNOWFLAKE_SECRET_NAME \
  --location="REGION" \
  --project="PROJECT_ID" \
  --data-file=credentials.json

    Ersetzen Sie Folgendes:

    • SNOWFLAKE_SECRET_NAME: Ein Name für Ihr Snowflake-Secret.
    • PROJECT_ID: Projekt-ID in Google Cloud .

Workload Identity-Föderation

Die Workload Identity-Föderation (WIF) vermeidet die Verwendung langlebiger Secrets, indem ein Lakehouse-Katalogdienstkonto direkt mit einem Snowflake-Dienstnutzer verknüpft wird. Es sind keine Voraussetzungen erforderlich. Fahren Sie mit dem Erstellen des föderierten Katalogs fort.

Föderierten Katalog erstellen

Erstellen Sie den föderierten Katalog mit der Google Cloud Console oder der gcloud CLI.

Console

So erstellen Sie einen föderierten Katalog:

  1. Rufen Sie in der Google Cloud Console Lakehouse auf.

    Zu Lakehouse

  2. Klicken Sie auf Katalog erstellen.

  3. Klicken Sie auf Föderierter Katalog.

    Der Bereich Katalogkonfiguration wird angezeigt.

  4. Wählen Sie für Quelle des föderierten Katalogs die Option Snowflake (Horizon) aus.

  5. 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 Snowflake Horizon-Katalog in AWS befindet, wählen Sie dieGoogle Cloud -Region aus, die Ihrer AWS-Region am nächsten liegt.
    • Wenn sich Ihr Snowflake Horizon Catalog in Google Cloudbefindet, wählen Sie genau dieselbe Region aus.

  6. Klicken Sie auf Weiter.

    Der Bereich Verbindungsdetails wird angezeigt.

  7. Geben Sie im Abschnitt Details zum Remote-Katalog im Feld Snowflake-Konto-ID Ihre Snowflake-Konto-ID ein. Beispiel: my_org-my_account.

  8. Geben Sie im Feld Snowflake-Warehouse den Namen Ihres Snowflake-Warehouse ein. Dies wird auch als Datenbankname in Snowflake Horizon Catalog bezeichnet.

  9. Wählen Sie eine Option für Authentifizierungsmethode aus:

    • Geben Sie unter Secret den Namen Ihres Secrets für Secret-basiert (PAT) ein. Verwenden Sie dieses Format: projects/PROJECT_ID/locations/REGION/secrets/SNOWFLAKE_SECRET_NAME.
    • Geben Sie für OIDC Ihre Snowflake-Rolle für die Workload Identity-Föderation ein. Beispiel: ICEBERG_VIEW.

  10. 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.

  11. Klicken Sie auf Erstellen.

gcloud

Secret-basiert (PAT)

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="snowflake" \
    --secret-name="projects/PROJECT_ID/locations/REGION/secrets/SNOWFLAKE_SECRET_NAME" \
    --snowflake-account-identifier="SNOWFLAKE_ACCOUNT_IDENTIFIER" \
    --snowflake-warehouse="SNOWFLAKE_WAREHOUSE" \
    --refresh-interval="REFRESH_INTERVAL" \
    --namespace-filters="NAMESPACE_FILTERS"

Kundeneigen (CCI)

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

gcloud alpha biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="snowflake" \
    --secret-name="projects/PROJECT_ID/locations/REGION/secrets/SNOWFLAKE_SECRET_NAME" \
    --snowflake-account-identifier="SNOWFLAKE_ACCOUNT_IDENTIFIER" \
    --snowflake-warehouse="SNOWFLAKE_WAREHOUSE" \
    --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.
  • SNOWFLAKE_SECRET_NAME: der Name Ihres Snowflake-Secrets.
  • SNOWFLAKE_ACCOUNT_IDENTIFIER: Ihre Snowflake-Konto-ID.
  • SNOWFLAKE_WAREHOUSE: das Snowflake-Warehouse, mit dem Sie eine föderierte Verbindung herstellen möchten. Dies wird auch als Datenbankname in Snowflake Horizon Catalog bezeichnet.
  • REFRESH_INTERVAL: Optional: 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 während 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.

Workload Identity-Föderation

Wenn Sie die Workload Identity-Föderation verwenden, müssen Sie --snowflake-role 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="snowflake" \
    --snowflake-account-identifier="SNOWFLAKE_ACCOUNT_IDENTIFIER" \
    --snowflake-warehouse="SNOWFLAKE_WAREHOUSE" \
    --snowflake-role="SNOWFLAKE_ROLE" \
    --refresh-interval="REFRESH_INTERVAL" \
    --namespace-filters="NAMESPACE_FILTERS"

Kundeneigen (CCI)

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

gcloud alpha biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="snowflake" \
    --snowflake-account-identifier="SNOWFLAKE_ACCOUNT_IDENTIFIER" \
    --snowflake-warehouse="SNOWFLAKE_WAREHOUSE" \
    --snowflake-role="SNOWFLAKE_ROLE" \
    --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.
  • SNOWFLAKE_ACCOUNT_IDENTIFIER: Ihre Snowflake-Konto-ID.
  • SNOWFLAKE_WAREHOUSE: das Snowflake-Warehouse, mit dem Sie eine föderierte Verbindung herstellen möchten. Dies wird auch als Datenbankname in Snowflake Horizon Catalog bezeichnet.
  • SNOWFLAKE_ROLE: die spezifische Snowflake-Rolle, die für die Sitzung erforderlich ist. Beispiel: ICEBERG_VIEW.
  • 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 während 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.

Secret-basiert (PAT)

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 SNOWFLAKE_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 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 SNOWFLAKE_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.

Workload Identity-Föderation

Nachdem Sie den Katalog erstellt haben, müssen Sie die Dienstkontoidentität mit einem Dienstnutzer in Snowflake verknüpfen.

  1. Extrahieren Sie die Lakehouse-Dienstkonto-ID (Subject) aus den Katalogdetails.

    Sie finden sie in der JSON-Antwort des Erstellungsbefehls (Feld biglake-service-account-id).

    Alternativ können Sie den Befehl „describe“ für den Katalog ausführen, um den Wert abzurufen:

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

    Suchen Sie in der Ausgabe nach dem biglake-service-account-id.

  2. Melden Sie sich in Ihrer Snowflake-Verwaltungsinstanz an und führen Sie das folgende Script aus, um die Vertrauensstellung mit der Lakehouse-Dienstidentität herzustellen:

    USE ROLE ACCOUNTADMIN;

CREATE USER SNOWFLAKE_SERVICE_USER
  TYPE = SERVICE
  WORKLOAD_IDENTITY = (
    TYPE = GCP
    SUBJECT = 'LAKEHOUSE_SERVICE_ACCOUNT_ID'
  )
  DEFAULT_ROLE = SNOWFLAKE_ROLE
  COMMENT = 'Service user for Lakehouse federation over WIF';

-- Also explicitly GRANT permissions to the role
GRANT ROLE SNOWFLAKE_ROLE TO USER SNOWFLAKE_SERVICE_USER;

    Ersetzen Sie Folgendes:

    • SNOWFLAKE_SERVICE_USER: ein Name für den neuen Dienstnutzer in Snowflake.
    • LAKEHOUSE_SERVICE_ACCOUNT_ID: die im vorherigen Schritt extrahierte Dienstkonto-ID.
    • SNOWFLAKE_ROLE: die Snowflake-Rolle (muss mit der bei der Katalogerstellung angegebenen Rolle übereinstimmen).

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, um Verbindungen über Service Directory zu erkennen und zu autorisieren.

Console

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

    IAM aufrufen

  2. Klicken Sie auf Zugriff gewähren (oder Hinzufügen).

  3. 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).

  4. Wählen Sie im Menü Rolle die Option Service Directory-Betrachter (roles/servicedirectory.viewer) aus.

  5. Klicken Sie auf Weitere Rolle hinzufügen und wählen Sie Service Directory PSC Authorized Service (roles/servicedirectory.pscAuthorizedService) aus.

  6. 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 Hintergrundaktualisierungszyklus für Katalogmetadaten erfolgreich abgeschlossen wurde und Namespaces und Tabellen synchronisiert sind.

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

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

  2. Prüfen Sie, ob die Namespaces synchronisiert sind:

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

  3. Prüfen Sie, ob die Tabellen in einem Namespace synchronisiert sind:

    gcloud alpha biglake iceberg tables list \
  --project="PROJECT_ID" \
  --catalog="FEDERATED_CATALOG_NAME" \
  --namespace="NAMESPACE_ID"

Nächste Schritte