Funktionsweise von Lakehouse

Die technische Architektur von Lakehouse for Apache Iceberg unterstützt die Interoperabilität zwischen Engines, indem sie die Metadatenverwaltung zentralisiert und Abfragen über bestimmte Pfade verarbeitet.

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 einzige zuverlässige Informationsquelle 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äftliche Metadaten registriert.

  • Abfrage-Engine: BigQuery und Open-Source-Engines wie Apache Spark, Apache Flink und Trino interagieren nahtlos, indem sie eine Verbindung zum Lakehouse-Laufzeitkatalog herstellen. 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 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 Datenerfassung und -analyse und sorgen so für einen konsistenten 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. 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 , die Ihre Metadaten hostet. 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 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 zur Lakehouse-Architektur migriert 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 in ausführen Google Cloud.

Lakehouse-Laufzeitkatalog

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

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 Informationen zum Lakehouse-Laufzeitkatalog.

Katalog

Ein Katalog ist ein logischer Metastore-Container, der von Cloud Storage-Warehouse-Standorten unterstützt wird. In der Benennungsstruktur 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.

Zu den wichtigsten Merkmalen von Katalogen gehören:

  • 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 Anmeldedatenbereitstellung für den 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. 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, wird automatisch dieselbe Region wie für den übergeordneten Katalog verwendet.
  • Flexibilität des Standorts: Die Optionen zum Angeben benutzerdefinierter Namespace-Standorte werden durch den Warehouse-Typ des Katalogs bestimmt.
  • 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. Damit nicht zwei Tabellen denselben Speicherort belegen, müssen benutzerdefinierte Tabellenpfade unter dem Pfad des übergeordneten Namespace verschachtelt werden. Die resultierenden Tabellenspeicherorte erhalten automatisch ein zufälliges String-Suffix, um Konflikte zu vermeiden.

    Unterstützte Tabellenformate

    Apache Iceberg V2-Tabellen (allgemeine Verfügbarkeit) 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 ein Upgrade auf eine unterstützte Version durchführen. 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. 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. 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 Tabellentypen und -funktionen.

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 Metadatenspeicherort 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 Anmeldedatenbereitstellung aktiviert ist, wird auch ein kurzlebiges Token bereitgestellt, um den sicheren Speicherzugriff zu ermöglichen.
  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, Silver für bereinigte und angepasste Daten und Gold für ausgewählte 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 vermeiden.
  • 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, sodass Sie Job ausführungen in Cloud Logging und der Google Cloud Console filtern und verfolgen können.
  • Diagnoselogging 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 Supportfähigkeit zu verbessern.

Nächste Schritte