Lakehouse-Laufzeitkatalog

Borderless Lakehouse ist eine verwaltete Data-Lakehouse-Plattform auf der Google Cloud. Das Herzstück ist der Lakehouse-Laufzeitkatalog, ein vollständig verwalteter, serverloser Metastore-Dienst, der als einzige verlässliche Informationsquelle für Ihre Daten dient. Durch die Zentralisierung dieser Metadaten können mehrere Verarbeitungs-Engines, darunter Apache Spark, Apache Flink, Apache Hive und BigQuery, Tabellen nahtlos gemeinsam nutzen, ohne Dateien zu duplizieren.

Um Ihre Abfrage-Engines mit dem Metastore zu verbinden, konfigurieren Sie einen Client mit einem Endpunkt wie dem Apache Iceberg REST-Katalog. Dieser dient als Verwaltungsoberfläche im Lakehouse-Laufzeitkatalog zum Verarbeiten von Tabellenmetadaten, während Cloud Storage zum Speichern der zugrunde liegenden Metadaten und Datendateien verwendet wird.

Hauptfunktionen

Als Schlüsselkomponente von Lakehouse bietet der Lakehouse-Laufzeitkatalog mehrere Vorteile für die Daten verwaltung und -analyse, darunter eine serverlose Architektur, Engine Interoperabilität mit offenen APIs, eine einheitliche Nutzererfahrung und leistungsstarke Analysen, Streaming und KI, wenn Sie ihn mit BigQuery verwenden. Weitere Informationen zu diesen Vorteilen finden Sie unter Was ist Borderless Lakehouse?

Einbindung von Lakehouse in Google Cloud

Informationen dazu, wie Lakehouse Ihre Daten verwaltet, finden Sie unter Einbindung der Lakehouse-Architektur in Google Cloud Dienste. In Apache Iceberg werden Daten nicht in monolithischen Tabellen gespeichert. Stattdessen wird eine mehrschichtige Architektur von Metadatendateien verwendet, um Datendateien in einer zusammenhängenden Tabellenstruktur mit ACID-Transaktionsunterstützung zu organisieren.

Das folgende Diagramm zeigt, wie Compute-Engines wie Managed Service for Apache Spark den Lakehouse-Laufzeitkatalog verwenden, um Tabellenmetadaten zu verwalten und zugrunde liegende Parquet-Datendateien direkt in Cloud Storage zu lesen und zu schreiben.

Komponenten einer Lakehouse-Architektur, einschließlich Managed Service for Apache Spark, Cloud Storage und Lakehouse REST-Katalog.
Diagramm der Lakehouse-Architektur.

Bei der Verwendung von Lakehouse besteht die technische Architektur aus drei verschiedenen Ebenen:

  1. Katalogebene:

    • Wichtiges Iceberg-Konzept: Der Katalog speichert den aktuellen Status der Tabelle, indem er einen Zeiger auf die neueste Metadatendatei verwaltet. Diese Ebene erleichtert die ACID-Compliance und die Transaktionsisolation, um zu verhindern, dass sich gleichzeitige Schreibvorgänge gegenseitig stören.
    • Lakehouse-Implementierung: Der Lakehouse-Laufzeitkatalog dient als regionaler Metastore-Dienst der obersten Ebene. In diesem Dienst erstellen Sie einzelne Kataloge, um Ihre Datenhierarchie zu verwalten. Client-Abfrage-Engines stellen über bestimmte Endpunkt-Katalogtypen eine Verbindung zu diesen Katalogen her, wie den Endpunkt Apache Iceberg REST-Katalog. Der Metastore verwaltet Transaktions-Commits, die Bereitstellung von Anmeldedaten für die Speicherzugriffs delegation und die Zeigerverwaltung für Ihre Kataloge.

  2. Metadatenebene:

    • Wichtiges Iceberg-Konzept: Auf dieser Ebene werden die Tabellenstruktur, Snapshots und Dateispeicherorte mithilfe einer Hierarchie von drei Dateitypen verfolgt:
      • Metadatendateien: Speichern das Schema der Tabelle, die Partition spezifikation und ein Log mit Snapshot-Zeigern.
      • Manifestlisten: Stellen einen einzelnen Snapshot der Tabelle dar, indem sie eine Sammlung von Manifestdateien gruppieren.
      • Manifestdateien: Verfolgen Daten auf der Ebene einzelner Dateien, speichern Dateipfade, Partitionierungsinformationen und Statistiken auf Spaltenebene, z. B. Zeilenanzahl sowie Mindest- und Höchstwerte, die zur Abfrageoptimierung und zum Partitionieren verwendet werden.
    • Lakehouse-Implementierung: In einem Katalogcontainer organisieren Sie Ihre Daten in logischen Namespaces (ähnlich wie Datasets) und Tabellen. Für jede Tabelle generiert und verwaltet der Lakehouse-Laufzeitkatalog die zugrunde liegende Iceberg-Metadatenhierarchie, beginnend mit einer metadata.json-Stammdatei, die auf die Manifestlisten und Manifestdateien verweist. Der Lakehouse-Laufzeitkatalog speichert diese Dateien direkt am angegebenen Speicherort des Data Warehouse.

  3. Datenebene:

    • Wichtiges Iceberg-Konzept: Diese Komponente ist der zugrunde liegende Speicher, in dem sich die eigentlichen Rohdatensätze befinden, in der Regel in optimierten spaltenbasierten oder zeilenbasierten offenen Dateiformaten wie Parquet, ORC oder Avro.
    • Lakehouse-Implementierung: Wenn Sie Cloud Storage-Speicherorte für Data Warehouses (gs://) konfigurieren, werden die von Ihren Tabellen referenzierten physischen Datendateien sicher in Ihren Buckets gespeichert. Der Lakehouse-Laufzeitkatalog verwaltet den Zugriff über die Speicherzugriffsdelegation (Bereitstellung von Anmeldedaten) und stellt kurzlebige Zugriffstokens direkt für Client-Engines bereit. So können Engines Datendateien sicher lesen und schreiben, ohne dass umfassende, direkte IAM Berechtigungen für die zugrunde liegenden Buckets erforderlich sind.

Implementierung der Apache Iceberg REST Catalog API durch Lakehouse

Der Lakehouse-Laufzeitkatalog implementiert die Open-Source- API Apache Iceberg REST Catalog zum Verwalten von Namespaces und Tabellen. Außerdem wird eine Erweiterungs API speziell für die Katalogverwaltung bereitgestellt.

Client-Abfrage-Engines interagieren über diese Standard-REST-Katalog-APIs mit dem Metastore. Weitere Informationen zu Google Cloud-Ressourcen und -Endpunkten finden Sie in der Referenz zur Lakehouse REST API.

Sie können diese Ressourcen über die Google Cloud Console, die gcloud CLI, die REST API oder Terraform erstellen, konfigurieren und verwalten. Weitere Informationen finden Sie auf den folgenden Seiten:

Kompatibilität und Konfiguration von Abfrage-Engines

Um Daten im Lakehouse-Laufzeitkatalog zu analysieren und zu verwalten, können Sie verschiedene Open-Source- und Enterprise-Abfrage-Engines verbinden. Je nach vorhandener Architektur und Arbeitslastanforderungen können Sie aus mehreren unterstützten Engines auswählen und den entsprechenden Katalogendpunkt konfigurieren.

Unterstützte Engines

Der Lakehouse-Laufzeitkatalog ist mit mehreren Abfrage-Engines kompatibel, darunter Apache Spark, Apache Flink, Apache Hive und Trino. Die folgende Tabelle enthält Links zur Dokumentation für jede Engine:

Engine Dokumentation
Apache Spark Mit Apache Spark verwenden
Apache Hive Mit Spark und dem Hive-Katalog verwenden
Apache Flink Mit Apache Flink verwenden
Trino Mit Trino verwenden

Katalogtypen und Endpunktkonfiguration

Wenn Sie Client-Engines für die Verbindung mit dem Metastore des Lakehouse-Laufzeitkatalogs konfigurieren, wählen Sie einen bestimmten Katalogendpunkt aus, z. B. den Endpunkt Apache Iceberg REST-Katalog oder den Apache Hive-Endpunkt. Die beste Option hängt von Ihrem Anwendungsfall ab, wie in der folgenden Tabelle dargestellt:

Anwendungsfall Empfehlung
Neue Nutzer des Lakehouse-Laufzeitkatalogs, die mit ihrer Open Source-Engine auf Daten in Cloud Storage zugreifen möchten und Interoperabilität mit anderen Engines benötigen, darunter BigQuery und AlloyDB for PostgreSQL. Verwenden Sie den Endpunkt des Apache Iceberg REST-Katalogs.
Nutzer, die Apache Hive- oder Spark Arbeitslasten ausführen, die von der Hive Metastore-Schnittstelle abhängen und einen vollständig verwalteten Metastore-Dienst benötigen. Verwenden Sie den Endpunkt des Apache Hive-Katalogs.
Vorhandene Nutzer des Lakehouse-Laufzeitkatalogs, die aktuelle Tabellen mit dem benutzerdefinierten Apache Iceberg-Katalog für den BigQuery-Endpunkt erstellt haben. Verwenden Sie weiterhin den benutzerdefinierten Apache Iceberg-Katalog für den BigQuery-Endpunkt, aber verwenden Sie den Apache Iceberg REST-Katalog für neue Arbeitsabläufe.

Einschränkungen des Lakehouse-Laufzeitkatalogs

Die folgenden allgemeinen Einschränkungen gelten für Tabellen im Lakehouse-Laufzeitkatalog, wenn sie über BigQuery abgefragt werden. Für einzelne Katalogendpunkte (z. B. Apache Iceberg REST oder Apache Hive) gelten möglicherweise zusätzliche endpunktspezifische Einschränkungen.

Tabellenverwaltung

  • Apache Iceberg V2-Tabellen (allgemeine Verfügbarkeit) und V3-Tabellen (Vorabversion) werden unterstützt. Iceberg V1-Tabellen werden nicht unterstützt. Bevor Sie vorhandene V1-Tabellen mit dem Lakehouse-Laufzeitkatalog verwenden, müssen Sie sie auf eine unterstützte Version aktualisieren. Weitere Informationen finden Sie unter Iceberg V1 Tabellen auf V2 aktualisieren.
  • Tabellen im Lakehouse-Laufzeitkatalog unterstützen keine Umbenennungsvorgänge oder die ALTER TABLE ... RENAME TO Spark SQL-Anweisung.
  • Tabellen im Lakehouse-Laufzeitkatalog unterstützen kein Clustering.
  • Tabellen im Lakehouse-Laufzeitkatalog unterstützen keine flexiblen Spaltennamen.

  • Der Lakehouse-Laufzeitkatalog unterstützt keine Datenbank- oder Metastore-Ansichten.

    flexible Spaltennamen.

  • Der Lakehouse-Laufzeitkatalog unterstützt keine Apache Iceberg-Ansichten.

Abfragen

  • Die Abfrageleistung für Tabellen im Lakehouse-Laufzeitkatalog über die BigQuery-Engine ist möglicherweise langsamer als bei der Abfrage von Daten in Standard-BigQuery-Tabellen. Im Allgemeinen sollte die Abfragegeschwindigkeit dem Lesen von Daten aus Cloud Storage entsprechen.
  • Ein BigQuery-Probelauf einer Abfrage, die eine Tabelle im Lakehouse-Laufzeitkatalog verwendet, kann eine Untergrenze von 0 Byte an Daten melden, auch wenn Zeilen zurückgegeben werden. Dieses Ergebnis tritt auf, weil die von der Tabelle verarbeitete Datenmenge erst nach Ausführung der vollständigen Abfrage bestimmt werden kann. Für die Ausführung der Abfrage fallen Kosten für die Verarbeitung dieser Daten an.
  • Sie können in einer Abfrage mit einer Platzhaltertabelle keine Tabelle im Lakehouse-Laufzeitkatalog referenzieren.

API und Metadaten

  • Sie können die tabledata.list Methode nicht verwenden, um Daten aus Tabellen im Lakehouse-Laufzeitkatalog abzurufen. Stattdessen können Sie Abfrageergebnisse in einer BigQuery-Tabelle speichern und dann die Methode tabledata.list für diese Tabelle verwenden.
  • Die Anzeige von Tabellenspeicherstatistiken für Tabellen im Lakehouse-Laufzeitkatalog wird nicht unterstützt.

Kontingente und Limits

  • Für Tabellen im Lakehouse-Laufzeitkatalog in BigQuery gelten die gleichen Kontingente und Limits wie für Standardtabellen.

Unterschiede zum BigLake-Metastore (klassisch)

Die wichtigsten Unterschiede zwischen dem Lakehouse-Laufzeitkatalog und dem BigLake-Metastore (klassisch) sind:

  • Der Lakehouse-Laufzeitkatalog unterstützt eine direkte Einbindung in Open-Source-Engines wie Spark, was die Redundanz beim Speichern von Metadaten und Ausführen von Jobs reduziert. Auf Tabellen im Lakehouse-Laufzeitkatalog kann direkt über mehrere Open-Source-Engines und BigQuery zugegriffen werden.
  • Der Lakehouse-Laufzeitkatalog unterstützt den Endpunkt des Apache Iceberg REST-Katalogs, der BigLake-Metastore (klassisch) jedoch nicht.

Nächste Schritte