Cloudübergreifendes Lakehouse

Mit dem cloudübergreifenden Lakehouse für Apache Iceberg können Sie Daten, die bei anderen Cloud Anbietern gespeichert sind, direkt abfragen, ohne Dateien migrieren oder komplexe ETL-Pipelines erstellen zu müssen. Google Cloud

Mit dieser Funktion können Sie im Rahmen von Lakehouse einheitliche Analysen durchführen und KI auf Ihre verteilten Datensätze anwenden. Dazu können Sie BigQuery, eigenständige Apache Spark-Umgebungen oder den Managed Service for Apache Spark verwenden.

Anwendungsfälle

Das cloudübergreifende Lakehouse unterstützt mehrere wichtige Anwendungsfälle für den Zugriff auf Daten bei verschiedenen Cloudanbietern:

  • Weniger Datenverschiebung : Sie können Daten, die in anderen Cloudumgebungen gespeichert sind, direkt abfragen. Das vereinfacht den Datenzugriff und die Datenverarbeitung.
  • Einheitliche Analysen : Sie können erweiterte Analysen mit einheitlichen Funktionen und Hardwareoptimierung für alle Ihre Daten durchführen, unabhängig davon, wo sie sich befinden.
  • Cloudübergreifende KI und ML : Sie können KI-Modelle, autonome Agents und Machine Learning direkt auf Ihre Remote-Daten anwenden, ohne sie zu migrieren.

Funktionsweise des cloudübergreifenden Lakehouse

Beim cloudübergreifenden Lakehouse werden Remote-Daten mit dem folgenden Verfahren abgefragt:

  1. Metadatenerkennung: Google Cloud's Lakehouse stellt eine Verbindung zu Remote-Apache Iceberg-REST-Katalogen her, z. B. Databricks Unity oder AWS Glue. Lakehouse erkennt die Daten, ohne Dateien zu kopieren. Je nach Remote-Kataloganbieter erfolgt die sichere Authentifizierung von Lakehouse über Secret Manager oder die OpenID Connect-Tokenföderation mit Google als Identitätsanbieter (OIDC-Tokenföderation).
  2. Sichere Übertragung:Wenn Sie den Traffic über eine private Interconnect-Verbindung weiterleiten (z. B. Dedicated CCI oder Partner Interconnect), werden die Kosten für die Datenübertragung im Vergleich zum öffentlichen Internet erheblich gesenkt und die Latenz ist sehr gut vorhersagbar.
  3. Optimierte Ausführung: Da Abfragen Daten aus Remote-Clouds lesen, werden diese Datensegmente von Lakehouse vorübergehend lokal in einem Google Cloud speziellen Speicher zwischengespeichert. Bei nachfolgenden Abfragen wird der lokale Cache verwendet, wodurch ein erheblicher Teil der Kosten für ausgehenden Traffic zwischen Clouds vermieden wird.

Unterstützte Kataloge

Mit dem cloudübergreifenden Lakehouse können Sie Daten von den folgenden Remote-Kataloganbietern abfragen:

  • Databricks Unity Catalog:Wird in Amazon Web Services (AWS) und Google Cloudunterstützt.
  • AWS Glue:Wird in Amazon Web Services (AWS) unterstützt.

Wichtige Konzepte

In diesem Abschnitt werden die wichtigsten Komponenten beschrieben, die für die Verwendung des cloudübergreifenden Lakehouse erforderlich sind.

Remote-Apache Iceberg-REST-Kataloge

Dies ist die Metadatenebene. Sie stellen eine Verbindung zu Remote-Apache Iceberg-REST-Katalogen her. Lakehouse erkennt die Daten, ohne Dateien zu kopieren. Über die OIDC-Tokenföderation oder OAuth-Anmeldedaten erfolgt die sichere Authentifizierung von Lakehouse, ohne dass langlebige Zugriffsschlüssel erforderlich sind.

Transportschicht

Dies ist die Transportschicht. Sie können Lakehouse so konfigurieren, dass Daten, die bei Remote-Cloudanbietern gespeichert sind, entweder über das öffentliche Internet oder eine dedizierte private Interconnect-Verbindung abgefragt werden.

Wählen Sie die Transportmethode aus, die Ihren Architektur- und Sicherheitsanforderungen entspricht:

Kundeneigene Interconnect-Verbindung (Customer-owned Interconnect, CCI)

Sie können BigQuery so konfigurieren, dass Daten, die in Amazon S3-Buckets von Amazon Web Services (AWS) gespeichert sind, über eine private Cross-Cloud Interconnect-Verbindung abgefragt werden. Dazu können Sie entweder Dedicated Cross-Cloud Interconnect oder Partner Cross-Cloud Interconnect verwenden.

Die Verwendung einer privaten Interconnect-Verbindung bietet folgende Vorteile:

  • Erweiterte Sicherheitsfunktionen: Daten werden über eine private Netzwerkverbindung zwischen Google Cloud und AWS übertragen, ohne das öffentliche Internet zu nutzen.
  • Geringere Kosten:Möglicherweise niedrigere Kosten für ausgehenden Traffic von AWS im Vergleich zu ausgehendem Internet-Traffic, insbesondere in Kombination mit Ihrer privaten Interconnect-Kapazität.
  • Konstante Leistung:Vorhersagbarere Netzwerklatenz und Bandbreite im Vergleich zum öffentlichen Internet.

Architektur

Um private Abfragen zu aktivieren, konfigurieren Sie einen Pfad von BigQuery zu Ihrem AWS Amazon S3-Bucket über Ihre private Interconnect-Verbindung. Eine wichtige Komponente in der Google Cloud Virtual Private Cloud (VPC) ist ein interner Load-Balancer (Internal Load Balancer, ILB). Der ILB verteilt Anfragen von BigQuery an die privaten Endpunkte für Amazon S3 in Ihrer AWS VPC, die mit AWS PrivateLink bereitgestellt werden.

Die Verwendung eines ILB mit mehreren Elastic Network Interfaces (ENIs) als Back-Ends ist für den Lastenausgleich, die Skalierbarkeit und die Hochverfügbarkeit unerlässlich. Dies gilt unabhängig davon, ob Sie Dedicated CCI oder Partner Interconnect verwenden.

Der Workflow für private Abfragen folgt diesem Prozess:

  1. BigQuery verwendet eine Verbindung, die mit einem Service Directory-Dienst konfiguriert wurde.
  2. Service Directory löst den Dienstnamen in die interne IP-Adresse des ILB Google Cloud auf.
  3. Der ILB empfängt die Anfragen von BigQuery und verteilt sie an die konfigurierten Back-Ends.
  4. Die ILB-Back-Ends sind Netzwerk-Endpunktgruppen (Network Endpoint Groups, NEGs) mit Hybridkonnektivität, die jeweils auf die private IP-Adresse einer ENI in Ihrer AWS VPC verweisen.
  5. Der Traffic fließt vom ILB über die NEGs, die private Interconnect-Verbindung und zu den AWS-ENIs.
  6. Die AWS-ENIs, die Teil eines Amazon S3 VPC-Schnittstellenendpunkts (AWS PrivateLink) sind, ermöglichen den privaten Zugriff auf den Amazon S3-Dienst.

Öffentliches Internet (keine CCI)

Wenn Sie keine private Interconnect-Verbindung konfigurieren, werden Abfragen an Ihren Remote-Katalog standardmäßig über das öffentliche Internet übertragen.

Beachten Sie bei der Abfrage von Daten über das öffentliche Internet Folgendes:

  • Standardverschlüsselung:Datenzugriffsanfragen und Datenübertragungen werden bei der Übertragung über das öffentliche Internet mit Standard-TLS-Protokollen verschlüsselt.
  • Kosten für ausgehenden Traffic:Für die Datenübertragung fallen standardmäßige Kosten für ausgehenden Internet-Traffic von Ihrem Remote-Cloudanbieter (z. B. AWS) an, die in der Regel höher sind als die Kosten für ausgehenden Traffic über eine private Interconnect-Verbindung.
  • Variable Latenz:Die Netzwerkleistung, Bandbreite und Latenz hängen von der Routing- und Überlastungssituation im öffentlichen Internet ab. Daher sind die Ausführungszeiten von Abfragen weniger vorhersagbar als bei einer dedizierten privaten Interconnect-Verbindung.
  • Einfache Einrichtung: Es ist keine zusätzliche Netzwerkinfrastruktur, kein VPC-Peering und keine Service Directory-Konfiguration in Google Cloud oder bei Ihrem Remote-Cloudanbieter erforderlich.

Architektur

Bei der Abfrage von Daten über das öffentliche Internet stellt Lakehouse direkt eine Verbindung zu Ihren Remote-Katalog- und Objektspeicherendpunkten her, ohne dass eine private Google Cloud oder Remote-Cloud-Netzwerkinfrastruktur erforderlich ist.

Der Workflow für Abfragen über das öffentliche Internet folgt diesem Prozess:

  1. BigQuery initiiert eine Abfrage für eine föderierte Tabelle, die in Ihrem Lakehouse-Katalog definiert ist.
  2. Lakehouse authentifiziert sich sicher bei Ihrem Remote-Apache Iceberg-Katalog mit Anmeldedaten, die in Secret Manager gespeichert sind, oder über die OIDC-Tokenföderation.
  3. Lakehouse ruft die Tabellenmetadaten und Manifestdateien über das öffentliche Internet ab, um die relevanten zugrunde liegenden Datendateien zu identifizieren (z. B. in AWS Amazon S3).
  4. Datenzugriffsanfragen für die zugrunde liegenden Objekte werden über das öffentliche Internet mit der Standard-TLS-Verschlüsselung direkt von Google Cloud gesendet.
  5. Der Remote-Speicherdienst überprüft die Anfrage mit temporären, eingeschränkten Anmeldedaten, die von Lakehouse bereitgestellt werden, und gibt die angeforderten Datenblöcke über das öffentliche Internet an zurück Google Cloud.

Nächste Schritte