Cloud-übergreifendes Lakehouse für AWS Glue einrichten

In diesem Dokument wird beschrieben, wie Sie ein cloudübergreifendes Lakehouse für Apache Iceberg einrichten, um Daten aus einem AWS Glue-Katalog 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 Lakehouse den Zugriff auf Ihre föderierten Daten verwalten.

Hinweis

1. Lesen Sie sich den Lakehouse-Überblick durch, um zu verstehen, wie der Zugriff auf Daten in Lakehouse verwaltet wird.
2. Weitere Informationen zur Funktionsweise finden Sie unter Cross-Cloud-Lakehouse.
3. Sehen Sie sich die unterstützten Katalogs an, um die Anforderungen an das Tabellenformat und die unterstützten Konfigurationen zu prüfen.
4. Ihr AWS-Administrator muss Berechtigungen zum Erstellen von IAM-Rollen (Identity and Access Management) und zum Konfigurieren von Berechtigungsrichtlinien haben.
5. Optional: Wenn Sie Anfragen über eine private Interconnect-Verbindung zwischen Ihrer Google Cloud VPC und der VPC Ihres Remote-Cloud-Anbieters (z. B. AWS) weiterleiten möchten, müssen Sie ein aktives Konto bei Ihrem Remote-Anbieter haben, eine Cross-Cloud Interconnect-Verbindung oder Partner Interconnect-Verbindung bereitstellen, BGP-Sitzungen mit Ihrem Cloud Router einrichten und prüfen, ob Sie in beiden Cloud-Umgebungen die erforderlichen IAM-Berechtigungen haben.
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.

Verify that billing is enabled for your Google Cloud project.

Enable the BigLake API.

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

Enable the API

Verify that billing is enabled for your Google Cloud project.

Enable the BigLake API.

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

Enable the API

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

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 eine Cross-Cloud Interconnect- oder eine Partner Interconnect-Verbindung verwenden.
• Netzwerkrouting:Wenn keine private Interconnect-Verbindung (z. B. eine vom Kunden betriebene CCI- oder Partner Interconnect-Verbindung) 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.
• Datenaktualität:Das --refresh-interval-Flag für den föderierten Katalog bestimmt, wie oft Metadaten synchronisiert werden. Ein kürzeres Intervall liefert aktuellere Daten, kann aber zusätzliche API-Kosten beim Remote-Kataloganbieter verursachen.

• Berichterstellung für Iceberg-Messwerte: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, indem Sie eine IAM-Rolle mit einer Platzhalter-Vertrauensrichtlinie mit Ihrem Remote-Anbieter erstellen. Erstellen Sie dann einen föderierten Katalog in Lakehouse und aktualisieren Sie die Vertrauensrichtlinie.
• Verbindung prüfen:Achten Sie darauf, dass 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 gesendet. 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 Interconnect-Verbindung verwenden. Dadurch wird eine dedizierte private Netzwerkverbindung zwischen Ihrer Google CloudVPC (Virtual Private Cloud) und dem Netzwerk Ihres Remote-Cloudanbieters (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:

• Cross-Cloud Interconnect: Eine dedizierte physische Verbindung.
• Partner 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 Verbindung einen Pfad vom Lakehouse zu Ihrem Remote-Speicher-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 Interconnect erforderlich und wird für Cross-Cloud Interconnect für Lastenausgleich, 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 Cross-Cloud Interconnect und wird für Partner Interconnect nicht unterstützt.

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

Cloud-übergreifende Föderation einrichten

Wenn Sie Ihre Daten abfragen möchten, richten Sie einen föderierten Lakehouse-Katalog ein, der eine Verbindung zu Ihrem Remote-AWS-Katalog herstellt.

AWS-IAM-Rolle mit einer Platzhalter-Vertrauensrichtlinie erstellen

Lakehouse stellt nach der Katalogerstellung eine Google-Dienstkonto-ID bereit. Erstellen Sie die AWS-IAM-Rolle mit einer Platzhalter-Vertrauensrichtlinie.

1. Erstellen Sie eine Datei mit dem Namen trust_policy.json:

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
           "Federated": "accounts.google.com"
         },
         "Action": "sts:AssumeRoleWithWebIdentity",
         "Condition": {
           "StringEquals": {
             "accounts.google.com:aud": [
               "PLACEHOLDER_VALUE"
             ],
             "accounts.google.com:sub": [
               "PLACEHOLDER_VALUE"
             ]
           }
         }
       }
     ]
   }

2. Führen Sie den AWS CLI-Befehl aus, um die Rolle mit der Platzhalter-Vertrauensrichtlinie zu erstellen. Wir empfehlen, die maximale Sitzungsdauer auf 12 Stunden (43200 Sekunden) festzulegen, um zu verhindern, dass Anmeldedaten bei lang andauernden Jobs ablaufen:

   aws iam create-role \
     --role-name AWS_ROLE_NAME \
     --assume-role-policy-document file://trust_policy.json \
     --max-session-duration 43200

   Ersetzen Sie Folgendes:

   • AWS_ROLE_NAME: Ein Name für Ihre AWS-IAM-Rolle. Beispiel: biglake_glue_federation_role

Berechtigungsrichtlinie anhängen

Hängen Sie eine Berechtigungsrichtlinie an Ihre IAM-Rolle an, damit Lakehouse auf den Glue Data Catalog und die S3-Buckets der AWS-Region zugreifen kann. Diese Richtlinie gewährt auch Zugriff auf S3-Tabellen-Buckets, wenn Sie die AWS Lake Formation S3 Tables-Integration verwenden. Wenn Sie von den standardmäßigen AWS Glue-Datenberechtigungen auf das AWS Lake Formation-Modell aktualisiert haben, müssen Sie möglicherweise stattdessen zusätzliche Berechtigungen in Lake Formation erteilen.

1. Erstellen Sie eine Datei mit dem Namen permissions_policy.json und der folgenden Richtlinienkonfiguration.

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Sid": "GlueRead",
         "Effect": "Allow",
         "Action": [
           "glue:GetCatalog",
           "glue:GetDatabase",
           "glue:GetDatabases",
           "glue:GetTable",
           "glue:GetTables"
         ],
         "Resource": "arn:aws:glue:AWS_REGION:AWS_ACCOUNT_ID:*"
       },
       {
         "Sid": "S3Read",
         "Effect": "Allow",
         "Action": [
           "s3:ListBucket",
           "s3:GetObject"
         ],
         "Resource": [
           "arn:aws:s3:::*"
         ]
       },
       {
         "Sid": "S3TablesRead",
         "Effect": "Allow",
         "Action": [
           "s3tables:GetTableBucket",
           "s3tables:ListNamespaces",
           "s3tables:GetNamespace",
           "s3tables:ListTables",
           "s3tables:GetTable",
           "s3tables:GetTableMetadataLocation",
           "s3tables:GetTableData"
         ],
         "Resource": [
           "arn:aws:s3tables:AWS_REGION:AWS_ACCOUNT_ID:*"
         ]
       }
     ]
   }

2. Hängen Sie diese Berechtigungsrichtlinie an Ihre IAM-Rolle an:

   aws iam put-role-policy \
     --role-name AWS_ROLE_NAME \
     --policy-name AWS_POLICY_NAME \
     --policy-document file://permissions_policy.json

   Ersetzen Sie Folgendes:

   • AWS_ROLE_NAME: Der Name Ihrer AWS-IAM-Rolle. Beispiel: biglake_glue_federation_role
   • AWS_POLICY_NAME: ein Name für Ihre Berechtigungsrichtlinie. Beispiel: biglake_glue_permissions.
   • AWS_REGION: Die AWS-Region, in der sich Ihr Glue-Katalog oder Ihre S3-Tabellen befinden. Beispiel: us-east-1.
   • AWS_ACCOUNT_ID: Ihre 12-stellige AWS-Konto-ID. Beispiel: 123456789012.

Föderierten Katalog erstellen

Richten Sie den föderierten Katalog auf Google Cloud mit der gcloud CLI oder REST API ein.

Um vorzeitige Fehler bei der Metadatensynchronisierung zu vermeiden, während AWS-Vertrauensbeziehungen weitergegeben werden, initialisieren Sie den Katalog, ohne einen Aktualisierungszeitplan anzugeben (der standardmäßig auf 0s festgelegt ist).

gcloud alpha biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="glue" \
    --glue-warehouse="GLUE_OR_S3_TABLE_BUCKET_WAREHOUSE" \
    --glue-aws-region="AWS_REGION" \
    --glue-aws-role-arn="arn:aws:iam::AWS_ACCOUNT_ID:role/AWS_ROLE_NAME"

gcloud alpha biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="glue" \
    --glue-warehouse="GLUE_OR_S3_TABLE_BUCKET_WAREHOUSE" \
    --glue-aws-region="AWS_REGION" \
    --glue-aws-role-arn="arn:aws:iam::AWS_ACCOUNT_ID:role/AWS_ROLE_NAME" \
    --service-directory-name="projects/PROJECT_ID/locations/REGION/namespaces/NAMESPACE/services/SERVICE_NAME"

curl -s -X POST \
  -H "x-goog-user-project: PROJECT_ID" \
  -H "Accept: application/json" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  "https://biglake.googleapis.com/iceberg/v1/restcatalog/extensions/projects/PROJECT_ID/catalogs?iceberg_catalog_id=FEDERATED_CATALOG_NAME&primary_location=REGION" \
  -d '{
    "catalog_type": "CATALOG_TYPE_FEDERATED",
    "storage_regions": ["'"REGION"'"],
    "federated_catalog_options": {
      "glue_catalog_info": {
        "warehouse": "'"GLUE_OR_S3_TABLE_BUCKET_WAREHOUSE"'",
        "aws_region": "'"AWS_REGION"'",
        "aws_role_arn": "arn:aws:iam::'"AWS_ACCOUNT_ID"':role/'"AWS_ROLE_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. Beispiel: us-east4.
• GLUE_OR_S3_TABLE_BUCKET_WAREHOUSE: die Kennung Ihres Zielkatalog für das Data Warehouse. Geben Sie für den Glue Data Catalog einer AWS-Region Ihre 12‑stellige AWS-Konto-ID ein. Beispiel: 123456789012 Wenn Sie einen S3-Tabellenbucket in der Region verwenden möchten, geben Sie AWS_ACCOUNT_ID:s3tablescatalog/S3_TABLE_BUCKET ein. Beispiel: 123456789012:s3tablescatalog/my-table-bucket
• AWS_ACCOUNT_ID: Ihre 12-stellige AWS-Konto-ID. Beispiel: 123456789012.
• AWS_REGION: Die AWS-Region, in der sich Ihr Glue-Katalog oder Ihr S3-Tabellen-Bucket befindet. Beispiel: us-east-1.
• AWS_ROLE_NAME: der Name Ihrer AWS-IAM-Rolle. Beispiel: biglake_glue_federation_role.
• NAMESPACE: (Optional) Der Service Directory-Namespace, den Sie bei der Einrichtung der privaten Interconnect-Verbindung erstellt haben.
• SERVICE_NAME: (Optional) Der Name des Service Directory-Dienstes, den Sie bei der Einrichtung der privaten Interconnect-Verbindung erstellt haben.

Vertrauensrichtlinie aktualisieren

Wenn der Katalog erstellt wird, stellt Lakehouse ein eindeutiges Dienstkonto dafür bereit, das in der Antwort auf die Katalogerstellung als Feld biglake-service-account-id zurückgegeben wird. Sie verwenden dieses Dienstkonto, um die Vertrauensbeziehung herzustellen.

1. Führen Sie den folgenden Befehl aus, um den biglake-service-account-id-Wert in eine aktive Bash-Variable zu extrahieren:

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

2. Aktualisieren Sie die Vertrauensrichtlinie Ihrer AWS-IAM-Rolle, um den Platzhalter durch Ihre bestätigte Google-Dienst-Agent-ID zu ersetzen. Der Bedingungsblock prüft, ob sowohl sub als auch aud übereinstimmen. Schreiben Sie die Richtlinie in eine Datei mit dem Namen trust_policy_comprehensive.json:

   cat > trust_policy_comprehensive.json << EOF
   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
           "Federated": "accounts.google.com"
         },
         "Action": "sts:AssumeRoleWithWebIdentity",
         "Condition": {
           "StringEquals": {
             "accounts.google.com:aud": [
               "$BIGLAKE_SA_ID"
             ],
             "accounts.google.com:sub": [
               "$BIGLAKE_SA_ID"
             ]
           }
         }
       }
     ]
   }
   EOF

3. Wenden Sie die endgültige Richtlinie auf Ihre AWS-Rolle an:

   aws iam update-assume-role-policy \
     --role-name AWS_ROLE_NAME \
     --policy-document file://trust_policy_comprehensive.json

Hintergrundaktualisierung aktivieren

Nachdem sichere Vertrauensstellungen auf beiden Plattformen erfolgreich eingerichtet wurden, aktualisieren Sie Ihren Katalog, um die Hintergrundaktualisierung zu aktivieren (alle 5 Minuten oder 300s oder mehr).

gcloud alpha biglake iceberg catalogs update FEDERATED_CATALOG_NAME \
  --project="PROJECT_ID" \
  --refresh-interval="300s"

curl -s -X PATCH \
-H "x-goog-user-project: PROJECT_ID" \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
"https://biglake.googleapis.com/iceberg/v1/restcatalog/extensions/projects/PROJECT_ID/catalogs/FEDERATED_CATALOG_NAME?updateMask=federated_catalog_options.refresh_options.refresh_schedule" \
-d '{
  "federated_catalog_options": {
    "refresh_options": {
      "refresh_schedule": {
        "refresh_interval": "300s"
      }
    }
  }
}'

Verbindung prüfen

Prüfen Sie, ob der Hintergrundaktualisierungszyklus des Katalogs erfolgreich abgeschlossen wurde und die Namespaces synchronisiert werden.

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-Datenbanken als synchronisierte Namespaces angezeigt werden:

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

Nächste Schritte

• Cloud-übergreifende Lakehouse- und Abfragetabellen verwenden.
• Probleme mit Cross-Cloud-Lakehouses beheben