Cloudübergreifender Datenzugriff

Mit der Funktion für den cloudübergreifenden Datenzugriff können Sie Daten, die bei anderen Cloud-Anbietern gespeichert sind, direkt über Google Cloud abfragen, ohne Dateien migrieren oder komplexe ETL-Pipelines mit Cross-Cloud Interconnect erstellen zu müssen.

Als Teil von Borderless Lakehouse können Sie mit dieser Funktion einheitliche Analysen durchführen und KI auf Ihre verteilten Datasets anwenden. Dazu können Sie BigQuery, eigenständige Apache Spark-Umgebungen oder Managed Service for Apache Spark verwenden.

Neben Analyseabfragen können Sie Ihre föderierten Daten auch für KI-basierte Statistiken und Governance verwenden:

  • Konversationelle Analyse: Erstellen Sie spezialisierte KI-Agenten, die auf Ihren genauen Datenquellen basieren, einschließlich cloudübergreifender Tabellen, um Daten aus verschiedenen Clouds über eine zentrale Konversation zu analysieren.
  • Knowledge Catalog: Mit Knowledge Catalog-Funktionen können Sie Datenprofiling und Statistiken für föderierte Datenquellen erstellen.

Anwendungsfälle

Lakehouse unterstützt mehrere wichtige Anwendungsfälle für den Zugriff auf Daten bei mehreren Cloud-Anbietern:

  • Weniger Datenübertragung: Sie können Daten, die in anderen Cloud-Umgebungen gespeichert sind, direkt abfragen. Das vereinfacht den Datenzugriff und die Datenverarbeitung.
  • Mit einheitlicher Analytik können Sie erweiterte Analysen mit konsistenten Funktionen und Hardwareoptimierung für alle Ihre Daten durchführen, unabhängig davon, wo sie sich befinden.
  • Mit Borderless AI und ML können Sie KI-Modelle, autonome Agents und maschinelles Lernen direkt auf Ihre Remote-Daten anwenden, ohne sie migrieren zu müssen.

So funktioniert der Zugriff auf cloudübergreifende Daten

Lakehouse-Abfragen rufen Remote-Daten mit dem folgenden Prozess ab:

  1. Metadatenermittlung Google Cloud:Das Lakehouse stellt eine Verbindung zu Remote-Apache Iceberg REST-Katalogen wie Databricks Unity oder AWS Glue her. Lakehouse erkennt die Daten, ohne Dateien zu kopieren. Je nach Remote-Kataloganbieter authentifiziert sich Lakehouse sicher über Secret Manager oder die OpenID Connect-Token-Föderation mit Google als Identitätsanbieter (OIDC-Token-Föderation).
  2. Sichere Übertragung:Wenn Sie den Traffic über eine private Interconnect-Verbindung (z. B. Dedicated CCI oder Partner Interconnect) leiten, 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:Wenn bei Abfragen Daten aus Remote-Clouds gelesen werden, werden diese Datensegmente in Lakehouse temporär lokal in Google Cloud auf spezialisiertem Speicher zwischengespeichert. Bei nachfolgenden Abfragen wird der lokale Cache verwendet, wodurch ein erheblicher Teil der Gebühren für den Cloud-übergreifenden Egress vermieden wird.

Unterstützte Kataloge

Lakehouse unterstützt das Abfragen von Daten aus den folgenden Remote-Kataloganbietern:

Wichtige Konzepte

In diesem Abschnitt werden die wichtigsten Komponenten beschrieben, die für die Verwendung der Funktion für den cloudübergreifenden Datenzugriff erforderlich sind.

Metadatenebene

Die Metadatenebene stellt eine Verbindung zu Remote-Endpunkten des Apache Iceberg-REST-Katalogs her, um Metadaten von Iceberg-Ressourcen (Namespace, Tabelle) basierend auf einem Aktualisierungsintervall zu synchronisieren. Lakehouse authentifiziert sich sicher mit OAuth-Anmeldedaten, die in Secret Manager gespeichert sind, oder mit OIDC-Token-Verbund.

Transportschicht

Die Transportschicht ermöglicht es BigQuery und Open-Source-Engines, die Daten mithilfe der synchronisierten Metadaten aus der Metadatenschicht abzufragen. Bei bestimmten Arten von Remote-Katalogen unterstützt Lakehouse das Abfragen von Daten über das öffentliche Internet oder eine dedizierte private Interconnect-Verbindung.

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

Kundeneigen (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, sodass das öffentliche Internet nicht genutzt wird.
  • Geringere Kosten:Möglicherweise niedrigere Gebühren für ausgehenden Traffic von AWS im Vergleich zu ausgehendem Internet-Traffic, insbesondere in Kombination mit Ihrer privaten Interconnect-Kapazität.
  • Konstante Leistung:Im Vergleich zum öffentlichen Internet sind Netzwerklatenz und Bandbreite besser vorhersagbar.

Architektur

Um private Abfragen zu ermöglichen, konfigurieren Sie einen Pfad von BigQuery zu Ihrem AWS Amazon S3-Bucket über Ihre private Interconnect-Verbindung. Eine Schlüsselkomponente in der Google CloudVirtual Private Cloud (VPC) ist ein Internal Load Balancer (ILB). Der ILB leitet Anfragen von BigQuery an die privaten Endpunkte für Amazon S3 in Ihrer AWS-VPC weiter, die mit AWS PrivateLink bereitgestellt werden.

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

Der Workflow für private Anfragen folgt diesem Prozess:

  1. BigQuery verwendet eine Verbindung, die mit einem Service Directory-Dienst konfiguriert ist.
  2. Service Directory löst den Dienstnamen in die interne IP-Adresse des Google Cloud ILB auf.
  3. Der ILB empfängt die Anfragen von BigQuery und leitet sie an die konfigurierten Back-Ends weiter.
  4. Die ILB-Back-Ends sind Netzwerk-Endpunktgruppen (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, über die private Interconnect-Verbindung 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 (kein CCI)

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

Wenn Sie Daten über das öffentliche Internet abfragen, sollten Sie die folgenden Auswirkungen berücksichtigen:

  • Standardverschlüsselung:Datenzugriffsanfragen und Datenübertragungen werden während 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 Gebühren für ausgehenden Internettraffic von Ihrem Remote-Cloudanbieter (z. B. AWS) an, die in der Regel höher sind als die Preise für ausgehenden Traffic über private Interconnect-Verbindungen.
  • Variable Latenz: Die Netzwerkleistung, Bandbreite und Latenz hängen von der öffentlichen Internetweiterleitung und ‑überlastung ab. Dies führt zu weniger vorhersehbaren Abfrageausführungszeiten als bei einer dedizierten privaten Interconnect-Verbindung.
  • Vereinfachte Einrichtung:Es sind keine zusätzliche Netzwerkinfrastruktur, kein VPC-Peering und keine Service Directory-Konfiguration in Google Cloud oder Ihrem Remote-Cloudanbieter erforderlich.

Architektur

Wenn Sie Daten über das öffentliche Internet abfragen, stellt Lakehouse eine direkte Verbindung zu Ihren Remote-Katalog- und Objektspeicherendpunkten her, ohne dass eine private Google Cloud oder Remote-Cloud-Netzwerkinfrastruktur erforderlich ist.

Der Workflow für öffentliche Internetanfragen folgt diesem Prozess:

  1. BigQuery startet 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 mit OIDC-Token-Fö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 direkt vonGoogle Cloud über das öffentliche Internet mit standardmäßiger TLS-Verschlüsselung gesendet.
  5. Der Remote-Speicherdienst prüft die Anfrage mit temporären, bereichsbezogenen Anmeldedaten, die von Lakehouse bereitgestellt werden, und gibt die angeforderten Datenblöcke über das öffentliche Internet an Google Cloudzurück.

Intelligentes Caching

Wenn Sie Remote-Cloud-Daten abfragen, werden die abgerufenen Datenblöcke automatisch lokal in Google Cloudzwischengespeichert. Das Caching ist für alle cloudübergreifenden Abfragen automatisch aktiviert, um die Gebühren für ausgehenden Traffic von Remote-Cloud-Anbietern zu minimieren. Bei nachfolgenden Abfragen, die auf zwischengespeicherte Daten ausgerichtet sind, werden die Daten direkt aus dem lokalen Google Cloud Speicher gelesen, anstatt sie cloudübergreifend neu abzurufen.

Kosteneinsparungen beim ausgehenden Traffic

Bei der ersten Ausführung der Abfrage ruft Lakehouse die erforderlichen Datenblöcke vom Remote-Cloud-Anbieter ab und füllt den lokalen Cache. Nachfolgende Abfragen, die auf dieselben Datenblöcke abzielen, werden direkt aus dem lokalenGoogle Cloud -Cache gelesen, anstatt die Daten cloudübergreifend neu abzurufen.

Bei Arbeitslasten mit wiederholten Abfragemustern für dasselbe Dataset werden durch das Caching die Gebühren für den Cloud-übergreifenden Egress reduziert, da Datenanfragen aus dem lokalen Speicher bedient werden. Die tatsächlichen Einsparungen bei den Kosten für ausgehenden Traffic hängen von Faktoren wie den Zugriffsmustern für Abfragen, den Raten für Datenänderungen und der Cache-Aufbewahrung in der Zielregion Google Cloudab.

Cache-Nutzung und Einsparungen bei den ausgehenden Traffic-Kosten in Jobstatistiken prüfen

Wenn Sie die Cache-Trefferraten und Kosteneinsparungen für ausgehende Daten für eine Abfrage prüfen möchten, sehen Sie sich die Abfragestatistiken in der BigQuery Console oder API (JobStatistics2) an. Da eine Abfrage Daten von mehreren Anbietern referenzieren kann, enthalten die Jobstatistiken ein wiederholtes object_storage_stats-Feld (objectStorageStats) mit einem Eintrag für jeden Cloud-Anbieter, auf den während der Ausführung zugegriffen wurde.

Für jeden object_storage_stats-Eintrag werden die folgenden Messwerte erfasst:

  • cloud_provider (cloudProvider): Der Cloud-Anbieter, der den Objektspeicher hostet (z. B. AWS oder AZURE).
  • cache_bytes_read (cacheBytesRead): Die Gesamtzahl der Byte, die aus dem lokalen Google Cloud Cache gelesen wurden, wodurch ein Lesezugriff auf den Remote-Objektspeicher vermieden wird.
  • object_storage_bytes_read (objectStorageBytesRead): Die Gesamtzahl der Bytes, die direkt aus dem Objektspeicher des Remote-Cloud-Anbieters gelesen wurden.

Überlegungen zum Datenstandort und zur Gerichtsbarkeit

Wenn Sie einen föderierten Katalog oder eine Verbindung in einer Google Cloud Region erstellen, werden zwischengespeicherte Daten im Ruhezustand lokal in dieser Zielregion gespeichert.

Wenn sich Ihre Remote-Clouddaten in einer anderen geografischen Region oder Gerichtsbarkeit befinden (z. B. AWS Amazon S3 in der Europäischen Union in Kombination mit BigQuery-Berechnungen in us-east4), werden beim cloudübergreifenden Abfragen Kopien der Remote-Daten im Cache im Ruhezustand in der ZielregionGoogle Cloud gespeichert. Der Nutzer oder Administrator, der die Verbindung oder den Katalog erstellt, muss dafür sorgen, dass das Caching über Gerichtsbarkeiten hinweg den Anforderungen seiner Organisation in Bezug auf Datenstandort, Datenhoheit und Compliance entspricht.

Verschlüsselung und CMEK-Unterstützung

Kundenverwaltete Verschlüsselungsschlüssel (CMEK) werden für das Lakehouse-Caching nicht unterstützt. Alle im Cache gespeicherten Datenblöcke werden im Ruhezustand mit der Standardverschlüsselung vonGoogle-owned and Google-managed encryption keysverschlüsselt.

Wenn in Ihrer Organisation die Einschränkung für die Organisationsrichtlinie Restrict Non-CMEK Services (constraints/gcp.restrictNonCmekServices) erzwungen wird, wird das Caching für Abfragen, die auf eingeschränkte Tabellen zugreifen, in Lakehouse automatisch deaktiviert. Die Abfragen werden weiterhin erfolgreich ausgeführt, aber es werden keine Datenblöcke im Cache gespeichert und es gibt keine Einsparungen beim ausgehenden Traffic durch den Cache.

Nächste Schritte