Lakehouse-Laufzeitkatalog

Lakehouse for Apache Iceberg ist eine verwaltete Data-Lakehouse-Plattform auf Google Cloud. Auf dieser Plattform fungiert der Lakehouse-Laufzeitkatalog als vollständig verwalteter, serverloser Metastore-Dienst. Er bietet eine zentrale Informationsquelle für Ihr Data Lakehouse, sodass mehrere Engines – darunter Apache Spark, Apache Flink, Apache Hive und BigQuery – Tabellen und Metadaten gemeinsam nutzen können, ohne Dateien zu kopieren.

Um Abfrage-Engines mit dem Metastore zu verbinden, konfigurieren Sie einen Client mit einem bestimmten Katalogtyp, z. B. dem Endpunkt Apache Iceberg REST-Katalog. Dieser Endpunkt verwaltet Tabellenmetadaten und verwendet ein Warehouse für Speicherorte, das von einem Cloud Storage-Bucket unterstützt wird, um die zugrunde liegenden Metadaten und Datendateien zu speichern. Weitere Informationen zur Auswahl eines Katalogtyps finden Sie unter Katalogtypen und Endpunkt konfiguration.

Der Lakehouse-Laufzeitkatalog unterstützt die Delegierung des Speicherzugriffs, auch als Bereitstellung von Anmeldedaten bezeichnet. Dies verbessert die Sicherheit, da kein direkter Zugriff auf Cloud Storage-Bucket erforderlich ist. Außerdem ist er in Knowledge Catalog eingebunden, um eine einheitliche Governance, Datenherkunft und Datenqualität zu ermöglichen.

Hauptfunktionen

Als wichtige Komponente von Lakehouse for Apache Iceberg 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 bei Verwendung mit BigQuery. Weitere Informationen zu diesen Vorteilen finden Sie unter Was ist Lakehouse?

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	Kurzanleitung: Mit Spark und dem Iceberg REST-Katalogendpunkt 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 Apache Iceberg REST-Katalog.
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 Apache Hive-Katalogendpunkt.
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. Tabellen, die mit dem benutzerdefinierten Apache Iceberg-Katalog für den BigQuery-Endpunkt erstellt wurden, sind über den Apache Iceberg REST-Katalogendpunkt durch die BigQuery-Katalogföderation sichtbar.

Einbindung der Lakehouse-Architektur in Google Cloud Dienste

Informationen dazu, wie Lakehouse Ihre Daten verwaltet, finden Sie unter Einbindung der Lakehouse for Apache Iceberg-Architektur in Google Cloud Dienste. Apache Iceberg speichert keine Daten in monolithischen Tabellen. 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.

Diagramm der Lakehouse-Architektur.

Bei der Verwendung von Lakehouse for Apache Iceberg besteht die technische Architektur aus drei verschiedenen Schichten:

1. Katalogschicht:

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

2. Metadatenschicht:

   • Wichtiges Iceberg-Konzept: Diese Schicht verfolgt die Tabellenstruktur, Snapshots und Dateispeicherorte mithilfe einer Hierarchie von drei Dateitypen:
     • Metadatendateien: Speichern das Tabellenschema, die Partitionsspezifikation, und ein Logbuch 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 und speichern Dateipfade, Partitionierungsinformationen und Statistiken auf Spaltenebene, z. B. Zeilenanzahl und Mindest- und Höchstwerte, die für die Abfrageoptimierung und das Partition Pruning 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 Warehouse.

3. Datenschicht:

   • 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 einen Cloud Storage-Bucket (gs://) als Speicherort für Ihr Warehouse konfigurieren, werden die physischen Datendateien, auf die in Ihren Tabellen verwiesen wird, sicher in Ihrem Bucket gespeichert. Der Lakehouse-Laufzeitkatalog verwaltet den Zugriff über die Delegierung des Speicherzugriffs (Bereitstellung von Anmeldedaten), indem er kurzlebige Zugriffstokens direkt an Client-Engines bereitstellt. So können Engines Datendateien sicher lesen und schreiben, ohne dass umfassende, direkte IAM-Berechtigungen für den zugrunde liegenden Bucket erforderlich sind.

Einschränkungen des Lakehouse-Laufzeitkatalogs

Für Tabellen im Lakehouse-Laufzeitkatalog gelten die folgenden Einschränkungen:

Tabellenverwaltung

• Sie können keine Tabellen mit dem Apache Iceberg REST-Katalogendpunkt erstellen oder ändern, indem Sie DDL-Anweisungen (Datendefinitionssprache) oder DML-Anweisungen (Datenbearbeitungssprache) von BigQuery verwenden. Sie können diese Tabellen mit der BigQuery API (mit dem bq-Befehlszeilentool oder Clientbibliotheken) ändern. Dabei besteht jedoch das Risiko, dass Änderungen vorgenommen werden, die mit der externen Engine nicht kompatibel sind.
• 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 Apache Iceberg-Ansichten.

Abfragen

• Die Abfrageleistung für Tabellen im Lakehouse-Laufzeitkatalog aus der BigQuery-Engine ist mitunter langsamer als bei der Abfrage von Daten in BigQuery-Standardtabellen. 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 nicht auf eine Tabelle im Lakehouse-Laufzeitkatalog verweisen.

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)

Warnung: Der BigLake Metastore (klassisch) ist eine Legacy-Funktion und wird nicht mehr empfohlen. Verwenden Sie den Lakehouse-Laufzeitkatalog als empfohlenen Metastore auf Google Cloud.

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 von mehreren Open-Source-Engines und BigQuery aus zugegriffen werden.
• Der Lakehouse-Laufzeitkatalog unterstützt den Apache Iceberg REST-Katalogendpunkt, der BigLake Metastore (klassisch) jedoch nicht.

Nächste Schritte

• Informationen zum Apache Iceberg REST-Katalog endpunkt.