Cloud-übergreifendes Lakehouse für Snowflake einrichten

In diesem Dokument wird beschrieben, wie Sie ein cloudübergreifendes Lakehouse einrichten, um Daten aus einem Snowflake-Katalog (Snowflake Horizon) direkt inGoogle 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 Lakehouse den Zugriff auf Ihre föderierten Daten verwalten.

Hinweis

  1. Lesen Sie den Lakehouse-Überblick, um zu verstehen, wie der Zugriff auf Daten verwaltet wird.
  2. Informationen zu Cross-Cloud-Lakehouse
  3. Sehen Sie sich die unterstützten Kataloge an, um die Anforderungen für externe Standorte und die unterstützten Konfigurationen zu prüfen.
  4. Regionale Secrets von Secret Manager verwenden Dies ist erforderlich, um ein cloudübergreifendes Lakehouse mit Snowflake mithilfe der geheimnisbasierten Authentifizierung einzurichten.
  5. Wenn Sie die geheimnisbasierte Authentifizierung verwenden, generieren Sie in Ihrer Snowflake Horizon-Umgebung ein persönliches Zugriffstoken (Personal Access Token, PAT), das Lesezugriff auf den Zielkatalog hat. Dieser Vorgang wird in dieser Dokumentation nicht behandelt.
  6. Wenn Sie die Workload Identity Federation verwenden, müssen Sie mit ACCOUNTADMIN-Berechtigungen auf die Snowflake-Konto-UI zugreifen können, um Dienstnutzer bereitzustellen.
  7. Optional: Wenn Sie Anfragen über eine private Interconnect-Verbindung zwischen Ihrer Google Cloud VPC und der VPC Ihres Remote-Cloudanbieters (z. B. AWS) weiterleiten möchten, müssen Sie ein aktives Konto bei Ihrem Remote-Anbieter haben, eine Dedicated Cross-Cloud Interconnect-Verbindung oder Partner Cross-Cloud Interconnect-Verbindung bereitstellen, BGP-Sitzungen mit Ihrem Cloud Router einrichten und prüfen, ob Sie in beiden Cloud-Umgebungen die erforderlichen IAM-Berechtigungen (Identity and Access Management) haben.
  8. Melden Sie sich in Ihrem Google Cloud -Konto an. Wenn Sie mit Google Cloudnoch nicht vertraut sind, erstellen Sie 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.

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

  10. Enable the BigLake, Secret Manager APIs.

    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. Verify that billing is enabled for your Google Cloud project.

  12. Enable the BigLake, Secret Manager APIs.

    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

    13.

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für das Projekt zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Einrichten eines cloudübergreifenden Lakehouse benötigen:

  • Lakehouse-Kataloge verwalten: BigLake-Administrator (roles/biglake.admin)
  • Secrets verwalten: Secret Manager-Administrator (roles/secretmanager.admin)
  • Traffic über Private Interconnect weiterleiten: Compute-Netzwerkadministrator (roles/compute.networkAdmin), Service Directory-Betrachter (roles/servicedirectory.viewer) und autorisierter Service für Service Directory PSC (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.

Unterstützte Katalogdetails

In dieser Anleitung wird beschrieben, wie Sie ein cloudübergreifendes Lakehouse mit einem Snowflake-Katalog (Snowflake Horizon) auf Amazon Web Services (AWS) und Google Cloudeinrichten. Ausführliche Informationen zu den Anforderungen an externe Speicherorte und zu unterstützten Konfigurationen finden Sie unter Unterstützte Kataloge.

Einschränkungen und Überlegungen

In diesem Abschnitt werden die Einschränkungen und Überlegungen für die Verwendung von Cross-Cloud-Lakehouse aufgeführt.

  • Unterstützte Cloud-Anbieter:Die Verwendung einer privaten Interconnect-Verbindung mit Ihrem cloudübergreifenden Lakehouse wird für die folgenden Remote-Cloud-Anbieter 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 einer weniger vorhersehbaren Leistung führen.
  • Datenaktualität:Das --refresh-interval-Flag für den föderierten Katalog bestimmt, wie oft Metadaten synchronisiert werden. Ein kürzeres Intervall sorgt für aktuellere Daten, kann aber zusätzliche API-Kosten beim Remote-Kataloganbieter verursachen.
  • Berichterstellung für Iceberg-Messwerte:Die Berichterstellung für Iceberg-Messwerte ist für föderierte Kataloge nicht verfügbar. Legen Sie die Eigenschaft rest-metrics-reporting-enabled in Ihrem Iceberg-Client auf false fest, wenn Sie auf einen föderierten Katalog zugreifen.

Allgemeiner Workflow

So richten Sie ein cloudübergreifendes Lakehouse ein und verwenden es:

  • 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 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.
    • 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-Katalog haben.
  • 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. Weitere Informationen finden Sie unter Cross-Cloud-Lakehouse verwenden.
  • Berechtigungen konfigurieren:Mit IAM können Sie verwalten, wer die föderierten Daten ansehen und abfragen kann.

Cross-Cloud Interconnect einrichten (optional)

Abfragen an Ihren Remote-Katalog werden standardmäßig über das öffentliche Internet geleitet. Um die Sicherheit und Compliance zu verbessern, eine vorhersehbare Leistung zu erzielen und die Kosten für die Datenübertragung zu senken, sollten Sie eine private Verbindung verwenden. 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-Cloudanbieters (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 Verbindung einen Pfad vom Lakehouse zu Ihrem Remotespeicher-Bucket (z. B. einem AWS Amazon S3-Bucket) konfigurieren. Es gibt zwei Architekturabläufe, die Sie für die Konfiguration dieses Routings verwenden können:

  • Routing mit internem regionalen Proxy-Network-Load-Balancer:Bei diesem Ablauf wird einGoogle Cloud interner regionaler Proxy-Network-Load-Balancer verwendet, um Anfragen auf Hybridkonnektivitäts-NEGs (Network Endpoint Groups) 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 für Load-Balancing, Skalierbarkeit und Hochverfügbarkeit empfohlen.
  • Direktes Endpunktrouting:Bei diesem Ablauf wird Service Directory direkt mit einer einzelnen IP-Adresse des AWS-Schnittstellen-VPC-Endpunkts verbunden. Dieser Ablauf funktioniert nur für Dedicated CCI und wird nicht für Partner CCI 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):

  1. Erstellen Sie in der AWS-VPC-Konsole einen Schnittstellenendpunkt für Amazon S3.
  2. Geben Sie als Dienstname 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(n), die an die Amazon S3-Endpunkt-ENIs angehängt sind, eingehenden TCP-Traffic auf Port 443 aus Ihrer Google Cloud VPC zulassen. Dazu muss der CIDR-Bereich IhresGoogle Cloud Nur-Proxy-Subnetzes gehören, damit Systemdiagnosen und weitergeleiteter Traffic zugelassen werden.

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.

  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 hybride 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:

    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 hybriden 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. 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 Zielproxy 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 Zielproxy.
    • 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 ihm zugewiesene interne IP-Adresse. Das ist dein ILB_IP_ADDRESS.

Service Directory konfigurieren

Registrieren Sie die IP-Adresse des internen Lastenausgleichs in Service Directory, damit Lakehouse sie erkennen 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 Google Cloud Projekt-ID.
    • REGION: die Google Cloud Region. Beispiel: us-east4. Diese muss mit der Region des föderierten Katalogs übereinstimmen.

  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 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 IP-Adresse eines AWS-Schnittstellen-VPC-Endpunkts weiterzuleiten:

  1. Erstellen Sie einen Interface VPC Endpoint 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 Google Cloud Projekt-ID.
    • REGION: die Google Cloud Region. Beispiel: us-east4. Diese muss mit der Region des föderierten Katalogs übereinstimmen.

  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 einen Endpunkt im Dienst, 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 CloudProjektnummer. 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 mit Ihrem Remote-Snowflake-Katalog verbunden ist. Wählen Sie Ihre Authentifizierungsmethode aus:

Secret-basiert (PAT)

Authentifizierung konfigurieren

Für die Föderation sind Anmeldedaten für den Zugriff auf den Remote-Snowflake-Katalog erforderlich. Für Snowflake Horizon müssen Sie ein persönliches Zugriffstoken (Personal Access Token, PAT) verwenden. Das ist ein von Snowflake generiertes Token mit langer Gültigkeitsdauer, das zusammen mit der für die Sitzung erforderlichen spezifischen Snowflake-Rolle verwendet wird.

Erstellen Sie ein Secret im regionalen Secret Manager, um die Anmeldedaten zu speichern:

  1. 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 persönliches Snowflake-Zugriffstoken (Personal Access Token, PAT).
    • SNOWFLAKE_ROLE: Die spezifische Snowflake-Rolle, die für die Sitzung erforderlich ist. Beispiel: ICEBERG_VIEW.

  2. Konfigurieren Sie den regionalen Endpunkt für Secret Manager:

    Standardmäßig verwendet Secret Manager einen globalen Endpunkt. Für Cross-Cloud-Lakehouse müssen Ihre Secrets jedoch in derselben Region wie Ihr Lakehouse-Katalog gespeichert werden. Wenn Sie mit der gcloud CLI mit regionalen Secrets interagieren möchten, müssen Sie den Standard-API-Endpunkt für Ihre aktuelle Sitzung oder Ihr Profil überschreiben. Um Verbindungsprobleme zu vermeiden, müssen Ihr Secret und Ihr Katalog in derselben Region erstellt werden.

      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.

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

    Föderierten Katalog erstellen

    Erstellen Sie den föderierten Katalog mit dem Befehl gcloud alpha biglake iceberg catalogs create.

    Öffentliches Internet (kein CCI)

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

      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"

    Ersetzen Sie Folgendes:

    • PROJECT_ID: Projekt-ID in Google Cloud .
    • REGION: Die Lakehouse-Region, in der der föderierte Katalog erstellt wird. Beispiel: us-east4. Um die Latenz zu minimieren, wählen Sie die Google Cloud Region aus, die Ihrer Snowflake-Region am nächsten ist.
    • SNOWFLAKE_SECRET_NAME: der Name Ihres Snowflake-Secrets.
    • SNOWFLAKE_ACCOUNT_IDENTIFIER: Ihre Snowflake-Konto-ID (z. B. my_org-my_account).
    • SNOWFLAKE_WAREHOUSE: Der Snowflake-Katalognamen, den Sie föderieren möchten.
    • REFRESH_INTERVAL (optional): Gibt an, wie oft die Informationen des Katalogs aktualisiert werden sollen. Legen Sie diesen Wert als Dauer fest, z. B. 330s oder 5m30s. Bei kürzeren Intervallen werden Daten häufiger aktualisiert, was jedoch mehr API-Aufrufe erfordert und somit teurer sein kann. Längere Intervalle können weniger kosten, aber die abgefragten Daten spiegeln möglicherweise nicht Ihren aktuellen Datensatz wider. Wenn dieser Parameter ausgelassen wird oder der Wert auf 0s festgelegt ist, wird die Aktualisierung der Hintergrundmetadaten nicht gestartet. Sie bleibt deaktiviert, bis das Aktualisierungsintervall auf einen positiven Wert aktualisiert wird.
    • NAMESPACE_FILTERS: Optional: Eine durch Kommas getrennte Liste der zu föderierenden Namespaces. Beispiel: ns1,ns2. Wenn diese Option weggelassen wird, werden alle Namespaces berücksichtigt.

    Kundeneigen (CCI)

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

      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/NAMESPACE/services/SERVICE_NAME/endpoints/ENDPOINT_NAME"

    Ersetzen Sie Folgendes:

    • PROJECT_ID: Projekt-ID in Google Cloud .
    • REGION: Die Lakehouse-Region, in der der föderierte Katalog erstellt wird. Hinweis: 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: Der Name des Snowflake-Katalogs, mit dem Sie eine Föderation durchführen möchten.
    • REFRESH_INTERVAL (optional): Gibt an, wie oft die Informationen des Katalogs aktualisiert werden sollen.
    • NAMESPACE_FILTERS: Optional: Eine durch Kommas getrennte Liste der zu föderierenden Namespaces.
    • NAMESPACE: der Service Directory-Namespace, den Sie bei 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.
    • ENDPOINT_NAME: Der Name des Service Directory-Endpunkts, den Sie bei der Einrichtung der privaten Interconnect-Verbindung erstellt haben.

    Authentifizierung einrichten

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

    Sie müssen diesem Dienstkonto die Berechtigung für den Zugriff auf das Secret erteilen, das Sie zuvor erstellt haben. Das Übertragen von IAM-Richtlinien kann einige Minuten dauern.

    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" \
      --location="REGION" \
      --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 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

Bei der Workload Identity-Föderation (WIF) werden keine langlebigen Secrets verwendet, da ein Lakehouse-Dienstkonto direkt mit einem Snowflake-Dienstnutzer verknüpft wird.

Föderierten Katalog erstellen

Erstellen Sie den föderierten Katalog mit der Google Cloud Console, der Lakehouse REST API oder dergcloudCLI. Sie müssen die zu verwendende Snowflake-Rolle angeben.

Console

So erstellen Sie einen föderierten Katalog mit Secret-basierter Authentifizierung:

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

    Lakehouse aufrufen

  2. Klicken Sie auf Katalog erstellen.

  3. Klicken Sie auf Föderierter Katalog.

    Die Details zur Katalogkonfiguration werden angezeigt.

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

  5. Wählen Sie bei Data location (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-Katalog in AWS befindet, wählen Sie dieGoogle Cloud -Region aus, die Ihrer AWS-Region am nächsten ist.

  6. Klicken Sie auf Weiter.

    Die Verbindungsdetails werden 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.

  9. Geben Sie für Secret den Namen Ihres Secrets ein. Verwenden Sie das folgende Format: projects/PROJECT_ID/locations/REGION/secrets/SNOWFLAKE_SECRET_NAME.

  10. Optional: Geben Sie im Feld Service Directory-Name den Pfad zu Ihrem Service Directory-Endpunkt oder -Dienst ein. Dies ist nur erforderlich, wenn Sie eine private Verbindung (Cross-Cloud Interconnect) konfigurieren.

  11. Klicken Sie auf Erstellen.

REST API 

curl -X POST \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  -H "x-goog-user-project: PROJECT_ID" \
  -d '{
    "catalog-type": "CATALOG_TYPE_FEDERATED",
    "federated-catalog-options": {
      "snowflake-catalog-info": {
        "account-identifier": "SNOWFLAKE_ACCOUNT_IDENTIFIER",
        "warehouse": "SNOWFLAKE_WAREHOUSE",
        "snowflake-role": "SNOWFLAKE_ROLE"
      },
      "refresh-options": {
        "refresh-schedule": {
          "refresh-interval": "REFRESH_INTERVAL"
        }
      }
    }
}' \
  "https://biglake.googleapis.com/iceberg/v1/restcatalog/extensions/projects/PROJECT_ID/catalogs?iceberg_catalog_id=FEDERATED_CATALOG_NAME&primary_location=REGION"

gcloud-CLI

Öffentliches Internet (kein CCI)

    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, geben Sie die Service Directory-Dienstreferenz an, damit Lakehouse den Traffic privat weiterleitet.

    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/NAMESPACE/services/SERVICE_NAME/endpoints/ENDPOINT_NAME"

Ersetzen Sie Folgendes:

  • PROJECT_ID: Projekt-ID in Google Cloud .
  • SNOWFLAKE_ACCOUNT_IDENTIFIER: Ihre Snowflake-Konto-ID.
  • SNOWFLAKE_WAREHOUSE: Der Snowflake-Katalognamen, den Sie föderieren möchten.
  • SNOWFLAKE_ROLE: Die spezifische Snowflake-Rolle, die für die Sitzung erforderlich ist. Beispiel: ICEBERG_VIEW.
  • FEDERATED_CATALOG_NAME: Ein Name für den föderierten Lakehouse-Katalog.
  • REGION: Die Lakehouse-Region, in der der föderierte Katalog erstellt wird.
  • REFRESH_INTERVAL (optional): Gibt an, wie oft die Informationen des Katalogs aktualisiert werden sollen. Beispiel: 300s.
  • NAMESPACE_FILTERS: Optional: Eine durch Kommas getrennte Liste der zu föderierenden Namespaces. Beispiel: ns1,ns2. Wenn diese Option weggelassen wird, werden alle Namespaces berücksichtigt.
  • NAMESPACE: der Namespace für Ihren Service Directory-Dienst.
  • SERVICE_NAME: der Name Ihres Service Directory-Dienstes.
  • ENDPOINT_NAME: der Name Ihres Service Directory-Endpunkts.

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

  1. Extrahieren Sie die Lakehouse Service Account ID (Subject) aus den Katalogdetails.

    Sie können sie aus der JSON-Antwort des Erstellungsbefehls abrufen (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 biglake-service-account-id.

  2. Melden Sie sich in Ihrer Snowflake-Verwaltungsinzanz an und führen Sie das folgende Skript 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 Dienstkonto-ID, die im vorherigen Schritt extrahiert wurde.
    • SNOWFLAKE_ROLE: Die Snowflake-Rolle (muss mit der Rolle übereinstimmen, die beim Erstellen des Katalogs angegeben wurde).

Verbindung prüfen

Prüfen Sie, ob der Aktualisierungszyklus für die Hintergrundmetadaten des Katalogs erfolgreich abgeschlossen wurde und die Namespaces synchronisiert sind.

gcloud-CLI

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

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

  2. Prüfen Sie, ob Remote-Datenbankschemas als synchronisierte Namespaces angezeigt werden:

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

REST API

  1. Synchronisierungsstatus der Katalogföderation prüfen:

    curl -X GET \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  -H "x-goog-user-project: PROJECT_ID" \
  "https://biglake.googleapis.com/iceberg/v1/restcatalog/extensions/projects/PROJECT_ID/catalogs/FEDERATED_CATALOG_NAME"

  2. Synchronisierte Namespaces auflisten:

    curl -X GET \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  -H "x-goog-user-project: PROJECT_ID" \
  "https://biglake.googleapis.com/iceberg/v1/restcatalog/v1/projects/PROJECT_ID/catalogs/FEDERATED_CATALOG_NAME/namespaces"

  3. Tabellen in einem synchronisierten Namespace auflisten:

    curl -X GET \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  -H "x-goog-user-project: PROJECT_ID" \
  "https://biglake.googleapis.com/iceberg/v1/restcatalog/v1/projects/PROJECT_ID/catalogs/FEDERATED_CATALOG_NAME/namespaces/NAMESPACE_NAME/tables"

Nächste Schritte