Funktionsweise von Borderless Lakehouse

Die technische Architektur des grenzenlosen Lakehouse unterstützt die Interoperabilität zwischen Engines, indem die Metadatenverwaltung zentralisiert und Anfragen über bestimmte Pfade verarbeitet werden.

Architektur

Das Lakehouse von Google Cloud besteht aus den folgenden technischen Komponenten:

  • Speicher:Cloud Storage und BigQuery-Speicher dienen als Speicherebene. Apache Iceberg ist das empfohlene offene Tabellenformat für leistungsstarken, interoperablen Speicher in Cloud Storage. Mit dem grenzenlosen Lakehouse müssen Ihre Daten nicht in Google Cloudgespeichert werden. Wenn Sie cloudübergreifende Verbindungen (Vorschau) zu unterstützten Remote-Katalogen einrichten, können Sie Ihre Daten in anderen Cloud-Speichersystemen wie Amazon S3 speichern und abfragen, ohne Dateien migrieren oder ETL-Pipelines erstellen zu müssen.

  • Katalog:Der Lakehouse-Laufzeitkatalog bietet eine einzige zuverlässige Informationsquelle für die Verwaltung von Metadaten. Er zentralisiert die Metadatenermittlung über mehrere Engines hinweg mithilfe verschiedener Kompatibilitätsoptionen, z. B. des Apache Iceberg-REST-Katalogendpunkts. Durch die Registrierung von Tabellen im Katalog werden automatisch Einträge im Wissenskatalog für Geschäftsmetadaten registriert.

  • Abfrage-Engine:BigQuery und Open-Source-Engines wie Apache Spark, Apache Flink und Trino lassen sich nahtlos in den Lakehouse-Laufzeitkatalog einbinden. Compute-Engines wie Managed Service for Apache Spark verwenden Open-Source-Apache Spark mit Ausführungsoptimierungen, um die Portabilität von Arbeitslasten zu gewährleisten und Vendor Lock-in zu vermeiden.

  • Governance:Knowledge Catalog bietet zentralisierte Sicherheits-, Herkunfts- und Governance-Richtlinien für Ihr gesamtes Lakehouse.

  • Tools zum Schreiben und Analysieren von Daten:Integrierte Engines und Tools bieten mehrere Möglichkeiten für die Datenaufnahme und -analyse und sorgen für einen konsistenten Datenzugriff für Data Scientists und Analysten.

Ressourcenhierarchie

Im Lakehouse von Google Cloud werden Daten in einer Hierarchie organisiert, die den Apache Iceberg-Standards und Standarddatenbankkonzepten entspricht. Mit dieser Struktur kann der Lakehouse-Laufzeitkatalog logische Identitäten physischen Speicherpfaden zuordnen. Um mit dieser Ressourcenhierarchie zu interagieren und Ihre Abfrage-Engines mit dem Katalog zu verbinden, verwenden Sie bestimmte Endpunkte, wie in der folgenden Liste beschrieben.

  1. Lakehouse-Laufzeitkatalog: Die regionale Dienstressource der obersten Ebene in Google Cloud , in der Ihre Metadaten gehostet werden. Wenn Sie Abfrage-Engines mit diesem Dienst verbinden und die zugrunde liegenden Kataloge verwalten möchten, konfigurieren Sie Clientanwendungen mit einem bestimmten Katalogendpunkt, z. B. dem Apache Iceberg REST-Katalogendpunkt.
  2. Katalog: Ein logischer Container im Laufzeitkatalogdienst. In der Namensstruktur „Projekt/Katalog/Namespace/Tabelle“ (P.C.N.T) steht dies für die spezifische Kataloginstanz, die Sie abfragen.
  3. Namespace: Eine logische Gruppierung von Tabellen in einem Katalog. Für Nutzer, die mit BigQuery vertraut sind, ist ein Namespace funktional ähnlich einem Dataset.
  4. Tabelle: Die spezifische Entität, die auf Daten in Cloud Storage verweist. Die Tabellenmetadaten enthalten das Schema, Partitionierungsinformationen und einen Zeiger auf den aktuellen Tabellenstatus über eine Apache Iceberg-Datei metadata.json.

Unterstützte Endpunkte

Der Lakehouse-Laufzeitkatalog bietet mehrere Endpunkte, um Ihre Daten in Cloud Storage und BigQuery zu verbinden.

  • Apache Iceberg REST-Katalogendpunkt:Bietet eine standardmäßige REST-Schnittstelle für eine breite Kompatibilität mit Open-Source-Engines wie Apache Spark, Apache Flink und Trino. Dies ist die empfohlene Schnittstelle für neue Arbeitslasten und bietet vollständige Lese- und Schreibinteroperabilität.

  • Benutzerdefinierter Apache Iceberg-Katalog für BigQuery-Endpunkt:Ermöglicht die direkte Interaktion von Engines mit dem BigQuery-Katalog. Diese Schnittstelle wird hauptsächlich für Apache Iceberg-Tabellen verwendet, die von BigQuery verwaltet werden, und für vorhandene Arbeitslasten, die auf die Lakehouse-Architektur umgestellt werden.

  • Apache Hive-Katalogendpunkt (Vorschau): Bietet Kompatibilität für Open-Source-Arbeitslasten, die von der Apache Hive Metastore-Schnittstelle (HMS) abhängen. So können Sie Apache Hive- oder Spark-Arbeitslasten für einen vollständig verwalteten Metastore-Dienst auf Google Cloudausführen.

Lakehouse-Laufzeitkatalog

In der Ressourcenhierarchie dient der Lakehouse-Laufzeitkatalog als regionaler Metadatendienst der obersten Ebene in Google Cloud. Er fungiert als Stammcontainer für Ihre einzelnen Kataloginstanzen und zentralisiert die Metadatenerkennung über verschiedene Abfrage-Engines hinweg.

Er implementiert die Open-Source-Apache Iceberg REST Catalog API zum Verwalten von Namespaces und Tabellen und bietet Erweiterungen speziell für die Katalogverwaltung.

Weitere Informationen zum Metastore-Dienst, einschließlich der wichtigsten Funktionen, unterstützten Engines, Endpunktkonfiguration und Einschränkungen, finden Sie unter Lakehouse-Laufzeitkatalog.

Katalog

Ein Katalog ist ein logischer Metastore-Container, der durch Cloud Storage-Warehouse-Standorte unterstützt wird. In der Namensstruktur Project.Catalog.Namespace.Table (P.C.N.T) stellt der Katalog die eindeutige Metastore-Instanz dar, die Ihre Metadaten für offene Tabellen mit Abfrage-Engines verbindet.

Hier sind einige wichtige Merkmale von Katalogen:

  • Speicherzuordnung:Die Beziehung zwischen einem Katalog und dem zugrunde liegenden Speicher hängt vom konfigurierten Katalogtyp ab.
  • Regionale Replikation:Die Region eines Katalogs entspricht automatisch der Region des zugrunde liegenden Buckets.
  • Zugriffsdelegierung:Administratoren können die Bereitstellung von Anmeldedaten im Katalog aktivieren, um den Zugriff zu delegieren. So können kurzlebige Anmeldedaten mit eingeschränktem Umfang automatisch generiert werden, anstatt Nutzern direkte Bucket-Berechtigungen zu gewähren.

Namespace

Ein Namespace ist eine logische Gruppierung von Tabellen in einem Katalog, die ähnlich wie eine Datenbank, ein Schema oder ein BigQuery-Dataset funktioniert. Sie bietet eine Struktur zum Organisieren und Verwalten von Zugriffssteuerungen für Tabellen.

Wichtige Merkmale von Namespaces:

  • Regionalität:Wenn Sie einen Namespace erstellen, wird automatisch dieselbe Region wie für den übergeordneten Katalog verwendet.
  • Standortflexibilität:Die Optionen zum Angeben benutzerdefinierter Namespace-Standorte hängen vom Warehouse-Typ des Katalogs ab.
  • Einschränkungen bei der Verschachtelung:Verschachtelte Namespaces (Unter-Namespaces) werden nicht unterstützt.
  • Sicherheitsgrenzen:Sie können IAM-Rollen auf Namespace-Ebene zuweisen, um den Zugriff auf alle darin enthaltenen Tabellen zu verwalten.

Tabellen

Wenn Sie mit dem Lakehouse von Google Cloud arbeiten, können Sie aus den folgenden Tabellentypen auswählen:

Unterstützt vom Lakehouse-Laufzeitkatalog

Empfohlen

  • Apache Iceberg-Tabellen:Apache Iceberg-Tabellen, die mit Open-Source-Engines erstellt und in Cloud Storage gespeichert werden. Sie bieten offene Kompatibilität und Verwaltung über den REST-Endpunkt des Lakehouse-Laufzeitkatalogs. Damit nicht zwei Tabellen denselben Speicherort belegen, müssen benutzerdefinierte Tabellenpfade im übergeordneten Namespace-Pfad verschachtelt werden. Die resultierenden Tabellenspeicherorte erhalten automatisch ein zufälliges String-Suffix, um Konflikte zu vermeiden.

    Unterstützte Tabellenformate

    Apache Iceberg-Tabellen der Version 2 (allgemein verfügbar) und Version 3 (Vorschau) werden unterstützt. Iceberg V1-Tabellen werden nicht unterstützt. Bevor Sie vorhandene V1-Tabellen mit Lakehouse verwenden, müssen Sie sie auf eine unterstützte Version aktualisieren. Weitere Informationen finden Sie unter Iceberg-Tabellen der Version 1 auf Version 2 aktualisieren.

Von BigQuery unterstützt

  • Apache Iceberg-Tabellen:Apache Iceberg-Tabellen, die von BigQuery erstellt und verwaltet werden. Die Metadaten für diese Tabellen werden im BigQuery-Katalog gespeichert. Tabellendaten und physische Metadaten werden in Cloud Storage gespeichert.
  • Native Tabellen:Tabellen, die vollständig von BigQuery verwaltet werden und mit dem Lakehouse-Laufzeitkatalog verbunden werden können, um die Interoperabilität mit Open-Source-Engines zu ermöglichen.
  • Externe Tabellen:Tabellen außerhalb des Lakehouse-Laufzeitkatalogs, in denen Daten und Metadaten selbst verwaltet werden. Sie unterstützen den delegierten Zugriff über Verbindungen für Daten, die in Cloud Storage, Amazon S3 oder Azure Blob Storage gespeichert sind.

Einen detaillierten Vergleich dieser Optionen finden Sie unter Tabellentypen und ‑funktionen.

Reihenfolge der Abfrageverarbeitung

Wenn Sie eine Anfrage an eine von Lakehouse verwaltete Apache Iceberg-Tabelle senden, folgt die Anfrage einem bestimmten Pfad, um Richtlinien zu erzwingen und Metadaten abzurufen, bevor Daten verarbeitet werden.

  1. Übermittlung:Sie senden eine SQL-Abfrage an eine kompatible Engine wie Apache Spark, Trino oder BigQuery.
  2. Metadatenanfrage:Die Engine fordert Tabellenmetadaten aus dem Lakehouse-Laufzeitkatalog an, um die Tabelle und ihren Metadatenspeicherort zu ermitteln.
  3. Autorisierung:Wenn der von Ihnen verwendete Endpunkt dies unterstützt, wird die Anfrage im Katalog anhand von IAM-Richtlinien (Identity and Access Management) und detaillierten Sicherheitsrichtlinien validiert.
  4. Metadatenantwort:Der Katalog gibt die Metadaten zurück. Wenn die Bereitstellung von Anmeldedaten aktiviert ist, wird auch ein kurzlebiges Token für den sicheren Speicherzugriff bereitgestellt.
  5. Datenabruf:Die Engine verwendet die Metadaten und das optionale Token, um Datendateien direkt aus Cloud Storage zu lesen.
  6. Ausführung:Die Engine verarbeitet die Daten und gibt die Ergebnisse zurück.

Best Practices

Beachten Sie beim Entwerfen und Betreiben eines Data Lakehouse in Google Cloud die folgenden Best Practices:

  • Medallion-Architektur einführen:Strukturieren Sie Ihr Data Warehouse in progressive logische Ebenen (Bronze für die Rohdatenaufnahme, Silber für bereinigte und angepasste Daten und Gold für kuratierte Aggregationen auf Geschäftsebene). Verwenden Sie BigQuery für die Gold-Consumption-Ebene, um die Abfrageleistung und ‑nebenläufigkeit zu maximieren.
  • Sitzungsvorlagen für interaktive Workloads verwenden:Für explorative Analysen und das Erstellen von Notebooks sollten Sie Sitzungsvorlagen verwenden, um Umgebungskonfigurationen für Entwicklungsteams zu standardisieren und sich wiederholende Einrichtungsschritte zu vermeiden.
  • Benutzerdefinierte Batch-IDs zuweisen:Wenn Sie nicht interaktive serverlose Apache Spark-Batcharbeitslasten senden, weisen Sie benutzerdefinierte Batch- und Jobnamen zu. Dies verbessert die Beobachtbarkeit, sodass Sie Jobausführungen in Cloud Logging und der Google Cloud Console filtern und verfolgen können.
  • Diagnoseprotokollierung aktivieren:Aktivieren Sie für komplexe Data-Engineering-Pipelines Diagnosepakete und sorgen Sie dafür, dass Treiber- und Executor-Logs aufbewahrt werden, um die Fehlerbehebung und den Support zu erleichtern.

Nächste Schritte