Funktionsweise von Lakehouse

Die technische Architektur von Lakehouse for Apache Iceberg unterstützt die Interoperabilität zwischen Engines, indem die Metadatenverwaltung zentralisiert und Abfragen ü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.

  • Katalog:Der Lakehouse-Laufzeitkatalog bietet eine zentrale Quelle für die Verwaltung von Metadaten. Er zentralisiert die Metadatenerkennung über mehrere Engines hinweg mithilfe verschiedener Kompatibilitätsoptionen wie dem Apache Iceberg-REST-Katalogendpunkt. Bei der Registrierung von Tabellen im Katalog werden automatisch Einträge im Knowledge Catalog für Geschäftsmetadaten registriert.

  • Abfrage-Engine:BigQuery und Open-Source-Engines wie Apache Spark, Apache Flink und Trino können nahtlos zusammenarbeiten, indem sie eine Verbindung zum Lakehouse-Laufzeitkatalog herstellen. Compute-Engines wie Managed Service for Apache Spark nutzen Open-Source-Apache Spark mit Ausführungsoptimierungen, um die Übertragbarkeit von Arbeitslasten zu gewährleisten und die Abhängigkeit von einem Anbieter zu vermeiden.

  • Governance:Knowledge Catalog bietet zentralisierte Sicherheits-, Lineage- 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 einheitlichen Datenzugriff für Data Scientists und Analysten.

Ressourcenhierarchie

Das Lakehouse von Google Cloud organisiert Daten mithilfe einer Hierarchie, die den Apache Iceberg-Standards und Standarddatenbankkonzepten entspricht. Diese Struktur ermöglicht es dem Lakehouse-Laufzeitkatalog, logische Identitäten physischen Speicherpfaden zuzuordnen. Um mit dieser Ressourcenhierarchie zu interagieren und Ihre Abfrage-Engines mit dem Katalog zu verbinden, verwenden Sie bestimmte Endpunkte, wie unten beschrieben.

  1. Lakehouse-Laufzeitkatalog: Die regionale Dienstressource der obersten Ebene in Google Cloud , in der Ihre Metadaten gehostet werden. Um Abfrage-Engines mit diesem Dienst zu verbinden und zugrunde liegende Kataloge zu verwalten, konfigurieren Sie Clientanwendungen mit einem bestimmten Katalogendpunkt, z. B. dem Apache Iceberg-REST-Katalogendpunkt.
  2. Katalog: Ein logischer Container im Laufzeitkatalog dienst. In der Benennungsstruktur „Projekt/Katalog/Namespace/Tabelle“ (P.C.N.T) stellt dies die spezifische Kataloginstanz dar, 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 Verweis 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 Standard-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 Interoperabilität 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 zur Lakehouse-Architektur migriert werden.

  • Apache Hive-Katalogendpunkt: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 in Google Cloudausführen.

Lakehouse-Laufzeitkatalog

In der Ressourcenhierarchie dient der Lakehouse-Laufzeitkatalog als regionaler Metadatendienst der obersten Ebene in Google Cloud. Er fungiert als Root-Container, in dem Ihre einzelnen Kataloginstanzen gehostet werden, und zentralisiert die Metadatenerkennung über verschiedene Abfrage-Engines hinweg.

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

Katalog

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

Zu den wichtigsten Merkmalen von Katalogen gehören:

  • Speicherzuordnung:Sie können nur einen Katalog mit einem einzelnen Cloud Storage-Bucket verknüpfen.
  • Regionale Replikation:Die Region eines Katalogs entspricht automatisch der Region des zugrunde liegenden Cloud Storage-Bucket.
  • Zugriffsdelegierung:Administratoren können die Bereitstellung von Anmeldedaten für den Katalog aktivieren, um den Zugriff zu delegieren. So können kurzlebige, eingeschränkte Anmeldedaten 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. Er bietet eine Struktur zum Organisieren und Verwalten von Zugriffssteuerungen für Tabellen.

Zu den wichtigsten Merkmalen von Namespaces gehören:

  • Regionalität:Wenn Sie einen Namespace erstellen, verwendet er automatisch dieselbe Region wie der übergeordnete Katalog.
  • Einschränkungen bei der Verschachtelung:Verschachtelte Namespaces (Sub-Namespaces) werden nicht unterstützt.
  • Sicherheitsgrenzen:Sie können IAM-Rollen auf Namespace-Ebene gewähren, um den Zugriff auf alle darin enthaltenen Tabellen zu verwalten.

Tabellen

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

Vom Lakehouse-Laufzeitkatalog unterstützt

Empfohlen

  • Apache Iceberg-Tabellen:Apache Iceberg-Tabellen, die aus Open-Source-Engines erstellt und in Cloud Storage gespeichert wurden. Diese bieten offene Kompatibilität und Verwaltung über den REST-Endpunkt des Lakehouse-Laufzeitkatalogs.

    Unterstützte Tabellenformate

    Apache Iceberg V2-Tabellen (GA) und V3-Tabellen (Vorschau) werden unterstützt. Iceberg V1-Tabellen werden nicht unterstützt. Bevor Sie vorhandene V1-Tabellen mit Lakehouse for Apache Iceberg verwenden, müssen Sie sie auf eine unterstützte Version aktualisieren. Weitere Informationen finden Sie unter Iceberg V1-Tabellen auf V2 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, während die Tabellendaten und physischen Metadaten in Cloud Storage gespeichert werden.
  • 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. Diese 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 Tabellenübersicht.

Abfolge der Abfrageverarbeitung

Wenn Sie eine Abfrage an eine Lakehouse-Tabelle von Google Cloud senden, folgt die Anfrage einem bestimmten Pfad, um Richtlinien zu erzwingen und Metadaten abzurufen, bevor die 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 vom Lakehouse-Laufzeitkatalog an, um die Tabelle und ihren Metadatenstandort zu identifizieren.
  3. Autorisierung: Wenn der verwendete Endpunkt dies unterstützt, validiert der Katalog die Anfrage anhand von Identity and Access Management (IAM) und detaillierten Sicherheits richtlinien.
  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:

  • Medaillonarchitektur verwenden:Strukturieren Sie Ihr Data Warehouse in progressive logische Ebenen (Bronze für die Rohdatenerfassung, Silber für bereinigte und angepasste Daten und Gold für kuratierte Aggregationen auf Geschäftsebene). Verwenden Sie BigQuery für die Gold-Verbrauchsebene, um die Abfrageleistung und Parallelität zu maximieren.
  • Sitzungsvorlagen für interaktive Arbeitslasten verwenden:Verwenden Sie für explorative Analysen und die Erstellung von Notebooks Sitzungsvorlagen, um die Umgebungskonfigurationen für alle Entwicklungsteams zu standardisieren und wiederholte Einrichtungsschritte zu reduzieren.
  • Benutzerdefinierte Batch-IDs zuweisen:Wenn Sie nicht interaktive serverlose Apache Spark-Batcharbeitslasten senden, weisen Sie benutzerdefinierte Batch- und Jobnamen zu. Dadurch wird die Beobachtbarkeit verbessert und es ist einfacher, Job ausführungen in Cloud Logging und der Google Cloud Console zu filtern und zu verfolgen.
  • Diagnoseprotokollierung aktivieren:Aktivieren Sie für komplexe Data-Engineering-Pipelines Diagnosepakete und sorgen Sie dafür, dass Treiber- und Executor-Logs beibehalten werden, um die Fehlerbehebung und Supportfähigkeit zu vereinfachen.

Nächste Schritte