Cloudübergreifender Datenzugriff

Mit der Funktion für cloudübergreifenden Datenzugriff können Sie Daten, die bei anderen Cloud-Anbietern gespeichert sind, direkt von Google Cloud aus abfragen, ohne Dateien migrieren oder komplexe ETL-Pipelines erstellen zu müssen. Abfragen können über das öffentliche Internet weitergeleitet werden oder Cross-Cloud Interconnect für den privaten Netzwerktransport verwenden.

Der cloudübergreifende Datenzugriff in Lakehouse vereinheitlicht Analyse- und KI-Arbeitslasten über Ihre verteilten Datasets hinweg über BigQuery, eigenständige Apache Spark-Umgebungen oder Managed Service for Apache Spark.

Sie können nicht nur analytische Abfragen ausführen, sondern auch Konversationsanalyse-Agenten erstellen, die auf Ihren verteilten Tabellen basieren, einschließlich cloudübergreifender Quellen, um Daten aus verschiedenen Clouds in einer einzigen Unterhaltung zu analysieren. Sie können auch Knowledge Catalog für Datenprofilerstellung und Statistiken auf Remote-Plattformen verwenden.

Wann sollte der cloudübergreifende Datenzugriff verwendet werden?

Im Folgenden sind einige gängige Anwendungsfälle aufgeführt:

  • Multi-Cloud-Tabellen direkt abfragen: Führen Sie BigQuery SQL- und Managed Service for Apache Spark-Analysen direkt auf externen Apache Iceberg-Tabellen in Amazon Web Services (AWS) und Microsoft Azure aus, ohne Dateien migrieren oder ETL-Pipelines verwalten zu müssen.
  • Private cloudübergreifende Netzwerkisolation erzwingen: Sowohl das Lesen von Abfragedaten als auch die Aktualisierung von Hintergrundmetadaten werden über Cross-Cloud Interconnect weitergeleitet, um Sicherheits- und Compliance-Richtlinien zu erfüllen, die den öffentlichen Internettraffic einschränken.
  • Wiederkehrende Kosten für die cloudübergreifende Datenübertragung reduzieren: Kombinieren Sie vorhersehbare ausgehende Traffic-Raten für Private Interconnect mit automatischem lokalem Block-Caching inGoogle Cloud für wiederholte BI-Dashboards und analytische Arbeitslasten.
  • Cloudübergreifende Governance und KI-Agenten vereinheitlichen: Fundieren Sie konversationelle Analyse-Agenten in verteilten Tabellen und wenden Sie Knowledge Catalog-Erkennung, -Profilierung und -Herkunft cloudübergreifend an.

Architektur

Das folgende Diagramm veranschaulicht die cloudübergreifende Datenzugriffsarchitektur von Lakehouse:

Architektur des cloudübergreifenden Lakehouse-Datenzugriffs über Google Cloud, Amazon Web Services (AWS) und SaaS-Partner hinweg.
Die Architektur von Lakehouse verbindet Google Cloud KI- und Analyse-Engines mit externen Cloud-Katalogen, Objektspeichern und SaaS-Partnern.

Das vorherige Diagramm veranschaulicht die Architektur in Google Cloud und externen Cloud- und SaaS-Umgebungen:

  • Google Cloud: bietet KI, Governance, Analysen und cloudübergreifenden Datenzugriff für Remote-Datasets:
    • KI-Agenten und ‑Anwendungen: Erstellt autonome Agenten in Conversational Analytics und Gemini Enterprise, die im Knowledge Catalog nach Daten und semantischer Bedeutung suchen und Abfragen über Analyse- und Verarbeitungs-Engines ausführen.
    • Knowledge Catalog: bietet eine einheitliche Governance und Datenherkunft sowie Dateneinblicke, Profilerstellung und Datenprodukte, indem Metadaten und Herkunft aus Lakehouse synchronisiert werden.
    • Analyse- und Verarbeitungs-Engines: Führt BigQuery SQL-, BigQuery AI- und Looker-Arbeitslasten aus oder verarbeitet Remote-Daten mit Managed Service for Apache Spark und offenen Engines (Apache Spark, Apache Flink und Trino), indem Metadaten aufgelöst und Tabellen über Lakehouse gelesen werden.
    • Cloudübergreifender Lakehouse-Datenzugriff: Fragt Remote-Daten direkt ab, ohne dass eine Dateimigration oder ETL-Pipelines erforderlich sind:
      • Metadatensynchronisierung: Ermittelt und synchronisiert Tabellenmetadaten über Apache Iceberg REST und Delta Sharing mithilfe des Lakehouse-Laufzeitkatalogs, authentifiziert sich über OpenID Connect (OIDC) oder Secret Manager und stellt temporäre Anmeldedaten mit eingeschränktem Zugriff bereit.
      • Cloudübergreifende Funktionen (AWS): Liest Datenblöcke in Google Cloud mit einem Read-Through-Cache auf Blockebene (Intelligentes Caching (lokaler Cache)) und leitet Traffic über Dedicated Cross-Cloud Interconnect (CCI), Partner Interconnect oder das Internet (mit TLS) mithilfe des cloudübergreifenden Netzwerktransports weiter.
  • Externe Cloud- und SaaS-Datenquellen: Hostet die Remote-Kataloge, SaaS-Daten-Clouds und Objektspeicher:
    • Externe Cloud- und SaaS-Kataloge: Synchronisiert Metadaten aus Cloud-Datenkatalogen (AWS Glue Data Catalog in AWS sowie Databricks Unity Catalog und Snowflake Horizon Catalog in AWS oder Google Cloud) und SaaS-Daten-Clouds (Salesforce Data Cloud, Workday Data Lake in AWS oderGoogle Cloudund SAP Business Data Cloud (BDC)) über die Iceberg REST API und Delta Sharing (für SAP BDC).
    • Externer Cloud-Objektspeicher (AWS): Speichert Apache Iceberg-Tabellen (Parquet-Datendateien) und Amazon S3-Tabellen in Amazon S3 für direkte Blocklesevorgänge über CCI oder das Internet (mit TLS).

So funktioniert der Zugriff auf cloudübergreifende Daten

Lakehouse fragt Remote-Daten mit dem folgenden Prozess ab:

  1. Metadatenerkennung: Der Lakehouse-Laufzeitkatalog stellt eine Verbindung zu Remote-Apache Iceberg-REST-Katalogendpunkten wie Databricks Unity Catalog, AWS Glue Data Catalog oder Snowflake Horizon Catalog her, um Tabellenmetadaten zu erkennen, ohne Dateien zu kopieren. Je nach Remote-Kataloganbieter authentifiziert sich Lakehouse über Secret Manager oder die OIDC-Token-Föderation mit Google als Identitätsanbieter.
  2. Sicherer Transport: Wenn Sie den Traffic über eine private Interconnect-Verbindung (z. B. Dedicated CCI oder Partner Interconnect) weiterleiten, werden die Kosten für die Datenübertragung im Vergleich zum öffentlichen Internet erheblich reduziert und die Latenz ist sehr vorhersehbar.
  3. Optimierte Ausführung: Wenn Sie cloudübergreifendes Caching für Ihren föderierten Katalog oder Ihre föderierte Verbindung aktivieren, speichert Lakehouse abgerufene Dateiblöcke lokal in der Region der Google Cloud -Abfrageausführung. Nachfolgende Abfragen, die auf dieselben Dateiblöcke abzielen, werden direkt aus dem lokalen Cache gelesen, anstatt die Dateien noch einmal aus der Remote-Cloud abzurufen. Dadurch werden die Kosten für cloudübergreifenden ausgehenden Traffic reduziert und die Abfrageleistung verbessert.

Unterstützte Kataloge

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

Wichtige Konzepte

Beim cloudübergreifenden Datenzugriff wird die Aktualisierung von Hintergrundmetadaten vom Transport von Abfragedaten getrennt. So können Sie eine oder beide Traffic-Ebenen basierend auf Ihren Sicherheits- und Kostenanforderungen privat weiterleiten.

Metadatenebene

Die Metadatenebene im Lakehouse-Laufzeitkatalog stellt eine Verbindung zu Remote-Apache Iceberg-REST-Katalogendpunkten her, um Apache Iceberg-Namespace- und Tabellenmetadaten basierend auf einem Aktualisierungsintervall zu synchronisieren. Lakehouse authentifiziert sich mit Anmeldedaten, die in Secret Manager oder der OIDC-Token-Föderation gespeichert sind.

Standardmäßig werden Hintergrundmetadatenaktualisierungen und Authentifizierungsanfragen über das öffentliche Internet mit TLS übertragen. Wenn Ihr Remote-Katalog den Zugriff über öffentliche Netzwerke einschränkt oder Ihre Sicherheitsrichtlinie privaten Traffic auf der Steuerungsebene erfordert, können Sie einen Metadaten-Service Directory-Dienst (--metadata-service-directory-name) für AWS Glue Data Catalog (auf AWS), Databricks Unity Catalog (auf AWS und Azure) und Snowflake Horizon Catalog (auf AWS und Azure) konfigurieren. Bei dieser Konfiguration werden Metadaten und Authentifizierungstraffic privat über Dedicated Cross-Cloud Interconnect oder Partner Cross-Cloud Interconnect (für AWS) weitergeleitet, unabhängig von oder zusammen mit dem privaten Abfragetransport (--service-directory-name).

Transportschicht

Über die Transportschicht können BigQuery und Open-Source-Engines Remote-Tabellendateien mithilfe der synchronisierten Metadaten aus der Metadatenschicht abfragen. Für unterstützte Remote-Kataloge 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 oder Azure Data Lake Storage Gen2-Containern (ADLS Gen2) 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 eines privaten Interconnect bietet folgende Vorteile:

  • Erhöhte Sicherheit: Daten werden über eine private Netzwerkverbindung zwischen Google Cloud und AWS oder Azure übertragen, ohne das öffentliche Internet zu nutzen.
  • Geringere Kosten: Potenziell niedrigere Gebühren für ausgehenden Traffic von AWS oder Azure im Vergleich zu ausgehendem Internet-Traffic, insbesondere in Kombination mit Ihrer privaten Interconnect-Kapazität.
  • Konsistente Leistung: Vorhersehbarere Netzwerklatenz und Bandbreite im Vergleich zum öffentlichen Internet.

Architektur

Wenn Sie private Abfragen aktivieren möchten, konfigurieren Sie einen Pfad von BigQuery zu Ihrem Amazon S3-Bucket oder ADLS Gen2-Container über Ihre private Interconnect-Verbindung. Eine Schlüsselkomponente in derGoogle Cloud Virtual Private Cloud (VPC) ist ein interner Load Balancer (ILB). Der ILB verteilt Anfragen von BigQuery an die privaten Endpunkte für Amazon S3 in Ihrer AWS-VPC (bereitgestellt mit AWS PrivateLink) oder für ADLS Gen2 in Ihrem Azure Virtual Network (VNet), bereitgestellt mit Azure Private Link.

Die Verwendung eines ILB mit mehreren elastischen Netzwerkschnittstellen (ENIs) oder Netzwerkkarten (NICs) als Backends 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 Abfragen sieht so aus:

  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 verteilt sie an konfigurierte Back-Ends.
  4. Die ILB-Backends sind Netzwerk-Endpunktgruppen (NEGs) für Hybridkonnektivität, die jeweils auf die private IP-Adresse einer ENI in Ihrer AWS-VPC oder einer NIC in Ihrem Azure-VNet verweisen.
  5. Der Traffic fließt vom ILB über die NEGs und die private Interconnect-Verbindung zu den AWS-ENIs oder Azure-NICs.
  6. Die AWS-ENIs, die Teil eines Amazon S3-VPC-Schnittstellenendpunkts (AWS PrivateLink) sind, oder die Azure-NICs, die Teil eines privaten ADLS Gen2-Endpunkts (Azure Private Link) sind, bieten privaten Zugriff auf den Amazon S3- oder ADLS Gen2-Dienst.

Öffentliches Internet (kein CCI)

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

Beachten Sie beim Abfragen von Daten über das öffentliche Internet die folgenden Auswirkungen:

  • 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 die standardmäßigen Gebühren für ausgehenden Internettraffic Ihres Remote-Cloud-Anbieters (z. B. AWS oder Azure) an. Diese sind in der Regel höher als die Gebühren für ausgehenden Traffic über eine private Interconnect-Verbindung.
  • Variable Latenz: Netzwerkleistung, Bandbreite und Latenz hängen vom Routing und der Überlastung im öffentlichen Internet ab. Das führt im Vergleich zu einer dedizierten privaten Verbindung zu weniger vorhersehbaren Abfrageausführungszeiten.
  • Vereinfachte Einrichtung: Es ist keine zusätzliche Netzwerkinfrastruktur, kein VPC-Peering und keine Service Directory-Konfiguration in Google Cloud oder bei Ihrem Remote-Cloud-Anbieter erforderlich.

Architektur

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

Der Workflow für Abfragen im öffentlichen Internet sieht so aus:

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

Intelligentes Caching

Um die Kosten für ausgehenden Traffic zwischen Clouds zu senken und Abfragen zu beschleunigen, die dieselben Dateiblöcke lesen, können Sie das cloudübergreifende Caching für Ihre föderierten Lakehouse-Kataloge und cloudübergreifenden BigQuery-Verbindungen ohne zusätzliche Kosten aktivieren.

Wenn Sie cloudübergreifendes Caching aktivieren, speichert Lakehouse abgerufene Dateiblöcke aus Amazon S3 oder Azure Blob Storage lokal in der Google Cloud -Abfrageausführungsregion im Cache. Nachfolgende Abfragen, einschließlich anderer Abfragen, die auf dieselben Dateiblöcke abzielen, werden direkt aus dem lokalen Cache gelesen, anstatt die Dateien noch einmal aus der Remote-Cloud abzurufen.

Google verwaltet die Cache-Kapazität, die Aufbewahrung und die Bereinigung automatisch. Ihre tatsächlichen Einsparungen bei den Kosten für ausgehenden Traffic hängen von Ihren Abfragemustern, der Häufigkeit, mit der sich Ihre Quelldateien ändern, und der Cache-Aufbewahrung in der Zielregion von Google Cloudab. Bevor im Cache gespeicherte Daten bereitgestellt werden, werden bei jeder Abfrage Metadaten und Zugriffsberechtigungen mit der Remote-Speicherquelle überprüft. So wird verhindert, dass veraltete Daten gelesen oder widerrufene Berechtigungen umgangen werden.

Cloudübergreifendes Caching ist standardmäßig deaktiviert. Sie können das Caching aktivieren oder deaktivieren, wenn Sie einen föderierten Lakehouse-Katalog oder eine cloudübergreifende BigQuery-Verbindung erstellen oder aktualisieren. Eine Konfigurationsanleitung finden Sie im Einrichtungsleitfaden für Ihren unterstützten Kataloganbieter oder unter Cloudübergreifende Verbindungen erstellen.

Cache-Nutzung und Kosteneinsparungen bei ausgehendem Traffic prüfen

Wenn Sie die Cache-Trefferraten prüfen und die Einsparungen bei den Kosten für ausgehenden Traffic messen möchten, sehen Sie sich die Jobdetails in der BigQuery-Konsole an oder prüfen Sie das Feld objectStorageStats (object_storage_stats) in den JobStatistics2-Abfragejobstatistiken von BigQuery:

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

Eine Anleitung zum Abrufen dieser Messwerte mit dem bq-Befehlszeilentool finden Sie unter Cache-Nutzung und Kosteneinsparungen bei ausgehendem Traffic überwachen.

Überlegungen zum Datenstandort und zur Gerichtsbarkeit

Wenn Sie das cloudübergreifende Caching aktivieren, speichert Lakehouse vorübergehend im Ruhezustand befindliche Kopien Ihrer Remotedateien in der Google Cloud -Region, in der die Abfrage ausgeführt wird. Bevor Sie das Caching für Dateien aktivieren, die sich in einer anderen geografischen Region oder Gerichtsbarkeit befinden (z. B. Amazon S3 oder Azure Blob Storage in der Europäischen Union, die von us-east4 abgefragt werden), prüfen Sie, ob das Speichern temporärer Cache-Kopien in der ZielregionGoogle Cloud den Anforderungen Ihrer Organisation an den Datenstandort und die Compliance entspricht.

Verschlüsselung und CMEK-Unterstützung

Im Cache gespeicherte Daten werden im Ruhezustand mit der Standard-Google-owned and Google-managed encryption keysverschlüsselt. Kundenverwaltete Verschlüsselungsschlüssel (CMEK) werden für cloudübergreifendes Caching nicht unterstützt.

Wenn Ihre Organisation die Einschränkung der Organisationsrichtlinie Nicht-CMEK-Dienste einschränken (constraints/gcp.restrictNonCmekServices) erzwingt, deaktiviert Lakehouse automatisch das Caching für Abfragen, die auf eingeschränkte Tabellen zugreifen. Ihre Abfragen werden weiterhin ausgeführt, aber sie lesen direkt aus dem Remotespeicher, ohne Dateiblöcke im Cache zu speichern.

Identitätsmodus

Lakehouse unterstützt zwei Identitätsmodi für den cloudübergreifenden Datenzugriff:

  • Dienstidentität (Standard): Sowohl die Hintergrundaktualisierung von Metadaten als auch Abfragen werden mit dem Dienstkonto des Katalogs ausgeführt, das entweder mit OIDC (empfohlen) oder mit geheimnisbasierter Authentifizierung konfiguriert werden kann.

  • Nutzeridentitätsföderation: Die Aktualisierung der Metadaten im Hintergrund erfolgt über das Dienstkonto des Katalogs. Abfragen werden jedoch mit der Identität des Endnutzers ausgeführt und an den Remote-Katalog weitergegeben. Dadurch kann der Remote-Katalog Abfragen von Google Cloud Endnutzern zuordnen, was die Durchsetzung von Berechtigungen und die Erstellung von Audit-Logs ermöglicht. Die Identitätsföderation muss im Remote-Katalog konfiguriert werden.

Nächste Schritte