Eisberg-Kataloge: Ein Leitfaden für Dateningenieure

Apache Iceberg ist zu einer beliebten Wahl für das Verwalten großer Datensätze mit Flexibilität und Skalierbarkeit geworden. Kataloge sind zentral für die Funktionalität von Iceberg, was bei der Organisation von Tabellen, Konsistenz und Metadatenverwaltung wichtig ist. Dieser Artikel wird erkunden, was Iceberg-Kataloge sind, ihre verschiedenen Implementierungen, Anwendungsfälle und Konfigurationen, um ein Verständnis für die am besten geeigneten Kataloglösungen für verschiedene Anwendungsfälle zu vermitteln.

Was ist ein Iceberg-Katalog?

In Iceberg ist ein Katalog dafür verantwortlich, Tabellenpfade zu verwalten, die auf die aktuellen Metadatendateien verweisen, die den Zustand einer Tabelle darstellen. Diese Architektur ist wichtig, da sie Atomizität, Konsistenz und effiziente Abfragen ermöglicht, indem sichergestellt wird, dass alle Leser und Schreiber auf den gleichen Zustand der Tabelle zugreifen. Unterschiedliche Katalogimplementierungen speichern diese Metadaten auf verschiedene Weisen, von Dateisystemen bis hin zu spezialisierten Metastore-Diensten.

Kernverantwortlichkeiten eines Iceberg-Katalogs

Die grundlegenden Verantwortlichkeiten eines Iceberg-Katalogs sind:

1. Zuordnung von Tabellenpfaden: Verknüpfung eines Tabellenpfades (z. B. „db.table“) mit der entsprechenden Metadatendatei.
2. Unterstützung für atomare Operationen: Sicherstellung eines konsistenten Tabellenzustands während gleichzeitiger Lese-/Schreibzugriffe.
3. Metadatenverwaltung: Speicherung und Verwaltung der Metadaten, um Zugänglichkeit und Konsistenz sicherzustellen.

Eisberg-Kataloge bieten verschiedene Implementierungen, um unterschiedlichen Systemarchitekturen und Speicheranforderungen gerecht zu werden. Lassen Sie uns diese Implementierungen und ihre Eignung für verschiedene Umgebungen untersuchen.

Arten von Eisberg-Katalogen

1. Hadoop-Katalog

Der Hadoop-Katalog ist in der Regel am einfachsten einzurichten und benötigt nur ein Dateisystem. Dieser Katalog verwaltet Metadaten, indem er die aktuellste Metadatendatei im Verzeichnis einer Tabelle basierend auf Dateistempeln abruft. Aufgrund seiner Abhängigkeit von dateibezogenen atomaren Operationen (die einige Speichersysteme wie S3 nicht bieten), ist der Hadoop-Katalog möglicherweise nicht für Produktionsumgebungen geeignet, in denen gleichzeitige Schreibvorgänge häufig sind.

Konfigurationsbeispiel

Um den Hadoop-Katalog mit Apache Spark zu konfigurieren:

spark-sql --packages org.apache.iceberg:iceberg-spark-runtime-3.3_2.12:0.14.0 \

  --conf spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions \

  --conf spark.sql.catalog.my_catalog=org.apache.iceberg.spark.SparkCatalog \

  --conf spark.sql.catalog.my_catalog.type=hadoop \

  --conf spark.sql.catalog.my_catalog.warehouse=file:///D:/sparksetup/iceberg/spark_warehouse

Eine andere Möglichkeit, den Katalog direkt im Spark-Job einzustellen:

SparkConf sparkConf = new SparkConf()

        .setAppName("Example Spark App")

        .setMaster("local[*]")

        .set("spark.sql.extensions","org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions")

        .set("spark.sql.catalog.local","org.apache.iceberg.spark.SparkCatalog")

        .set("spark.sql.catalog.local.type","hadoop")

        .set("spark.sql.catalog.local.warehouse", "file:///D:/sparksetup/iceberg/spark_warehouse")

Im obigen Beispiel haben wir den Katalognamen auf „local“ gesetzt, wie in spark „spark.sql.catalog.local„ konfiguriert. Dies kann ein frei gewählter Name sein.

Vorteile:

• Einfaches Setup, kein externes Metastore erforderlich.
• Ideal für Entwicklungs- und Testumgebungen.

Nachteile:

• Begrenzt auf einzelne Dateisysteme (z.B. einen einzigen S3-Bucket).
• Nicht für die Produktion empfohlen.

2. Hive-Katalog

Der Hive-Katalog nutzt den Hive Metastore zur Verwaltung des Metadatenstandorts und macht ihn mit zahlreichen Big-Data-Tools kompatibel. Dieser Katalog wird aufgrund seiner Integration in bestehende, auf Hive basierende Infrastruktur und Kompatibilität mit mehreren Abfrage-Engines häufig in der Produktion verwendet.

Konfigurationsbeispiel

Um den Hive-Katalog in Spark zu verwenden:

spark-sql --packages org.apache.iceberg:iceberg-spark-runtime-3.3_2.12:0.14.0 \

  --conf spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions \

  --conf spark.sql.catalog.my_catalog=org.apache.iceberg.spark.SparkCatalog \

  --conf spark.sql.catalog.my_catalog.type=hive \

  --conf spark.sql.catalog.my_catalog.uri=thrift://<metastore-host>:<port>

Vorteile:

• Hohe Kompatibilität mit bestehenden Big-Data-Tools.
• Cloud-unabhängig und flexibel sowohl in lokalen als auch in Cloud-Setups.

Nachteile:

• Erfordert die Wartung eines Hive Metastore, was die operationale Komplexität erhöhen kann.
• Fehlende Unterstützung für Transaktionen über mehrere Tabellen, was die Atomarität für Operationen über Tabellen einschränkt

3. AWS Glue-Katalog

Der AWS Glue-Katalog ist ein verwalteter Metadatenkatalog, der von AWS bereitgestellt wird und sich ideal für Organisationen eignet, die stark in das AWS-Ökosystem investiert sind. Er verwaltet Iceberg-Tabellenmetadaten als Tabellenattribute innerhalb von AWS Glue und ermöglicht eine nahtlose Integration mit anderen AWS-Diensten.

Konfigurationsbeispiel

Um AWS Glue mit Iceberg in Spark einzurichten:

spark-sql --packages org.apache.iceberg:iceberg-spark-runtime-x.x_x.xx:x.x.x,software.amazon.awssdk:bundle:x.xx.xxx \

  --conf spark.sql.catalog.my_catalog=org.apache.iceberg.spark.SparkCatalog \

  --conf spark.sql.catalog.my_catalog.catalog-impl=org.apache.iceberg.aws.glue.GlueCatalog \

  --conf spark.sql.catalog.my_catalog.io-impl=org.apache.iceberg.aws.s3.S3FileIO \

  --conf spark.hadoop.fs.s3a.access.key=$AWS_ACCESS_KEY \

  --conf spark.hadoop.fs.s3a.secret.key=$AWS_SECRET_ACCESS_KEY

Vorteile:

• Verwalteter Dienst, der Infrastruktur- und Wartungsaufwand reduziert.
• Starke Integration mit AWS-Diensten.

Nachteile:

• AWS-spezifisch, was die Flexibilität über verschiedene Clouds einschränkt.
• Keine Unterstützung für Transaktionen über mehrere Tabellen

4. Projekt Nessie-Katalog

Projekt Nessie bietet einen „Daten als Code“-Ansatz, der die Versionskontrolle von Daten ermöglicht. Mit seinen Git-ähnlichen Branching- und Tagging-Funktionen ermöglicht Nessie den Benutzern, Datenzweige ähnlich wie Quellcode zu verwalten. Es bietet ein robustes Framework für Transaktionen mit mehreren Tabellen und mehreren Anweisungen.

Konfigurationsbeispiel

Um Nessie als Katalog zu konfigurieren:

spark-sql --packages "org.apache.iceberg:iceberg-spark-runtime-x.x_x.xx:x.x.x" \

  --conf spark.sql.catalog.my_catalog=org.apache.iceberg.spark.SparkCatalog \

  --conf spark.sql.catalog.my_catalog.catalog-impl=org.apache.iceberg.nessie.NessieCatalog \

  --conf spark.sql.catalog.my_catalog.uri=http://<host>:<port>

Vorteile:

• Stellt Funktionen „Daten als Code“ mit Versionskontrolle bereit.
• Unterstützt Transaktionen mit mehreren Tabellen.

Nachteile:

• Erfordert Self-Hosting, was die Infrastrukturkomplexität erhöht.
• Begrenzte Werkzeugunterstützung im Vergleich zu Hive oder AWS Glue

5. JDBC-Katalog

Der JDBC-Katalog ermöglicht es Ihnen, Metadaten in jeder JDBC-kompatiblen Datenbank zu speichern, wie PostgreSQL oder MySQL. Dieser Katalog ist cloudunabhängig und gewährleistet hohe Verfügbarkeit durch die Nutzung zuverlässiger RDBMS-Systeme.

Konfigurationsbeispiel

spark-sql --packages org.apache.iceberg:iceberg-spark-runtime-x.x_x.xx:x.x.x \

  --conf spark.sql.catalog.my_catalog=org.apache.iceberg.spark.SparkCatalog \

  --conf spark.sql.catalog.my_catalog.catalog-impl=org.apache.iceberg.jdbc.JdbcCatalog \

  --conf spark.sql.catalog.my_catalog.uri=jdbc:<protocol>://<host>:<port>/<database> \

  --conf spark.sql.catalog.my_catalog.jdbc.user=<username> \

  --conf spark.sql.catalog.my_catalog.jdbc.password=<password>

Vorteile:

• Einfach einzurichten mit vorhandener RDBMS-Infrastruktur.
• Hohe Verfügbarkeit und cloudunabhängig.

Nachteile:

• Keine Unterstützung für Transaktionen mit mehreren Tabellen.
• Erhöht die Abhängigkeiten von JDBC-Treibern für alle zugreifenden Tools

6. Snowflake-Katalog

Snowflake bietet umfassende Unterstützung für Apache Iceberg-Tabellen und ermöglicht es den Nutzern, die Snowflake-Plattform als Iceberg-Katalog zu nutzen. Diese Integration vereint die Leistung und Abfragesemantik von Snowflake mit der Flexibilität des offenen Tabellenformats von Iceberg und ermöglicht eine effiziente Verwaltung großer Datensätze, die in externem Cloud-Speicher gespeichert sind. Weitere Konfigurationsdetails finden Sie in der Snowflake-Dokumentation unter dem Link

Vorteile:

• Nahtlose Integration: Vereint die Leistung und Abfragefähigkeiten von Snowflake mit dem offenen Tabellenformat von Iceberg und erleichtert somit die effiziente Datenverwaltung.
• Umfassende Plattformunterstützung: Bietet umfassenden Lese- und Schreibzugriff sowie Funktionen wie ACID-Transaktionen, Schema-Evolution und Zeitreisen.
• Vereinfachte Wartung: Snowflake übernimmt Lebenszyklusaufgaben wie Komprimierung und reduziert den operativen Aufwand.

Nachteile:

• Cloud- und Regionsbeschränkungen: Das externe Volumen muss sich beim gleichen Cloud-Anbieter und in der gleichen Region wie das Snowflake-Konto befinden, was die Konfiguration über verschiedene Clouds oder Regionen hinweg einschränkt.
• Datenformatbeschränkung: Unterstützt nur das Apache Parquet-Dateiformat, das möglicherweise nicht mit den Datenformatpräferenzen aller Organisationen übereinstimmt.
• Drittanbieter-Client-Beschränkungen: Verhindert, dass Drittanbieter-Clients Daten in von Snowflake verwalteten Iceberg-Tabellen ändern, was potenziell Workflows beeinträchtigen kann, die auf externen Tools basieren.

7. REST-basierte Kataloge

Iceberg unterstützt REST-basierte Kataloge, um mehrere Herausforderungen im Zusammenhang mit traditionellen Katalogimplementierungen anzugehen.

Herausforderungen mit traditionellen Katalogen

1. Komplexität auf Client-Seite: Traditionelle Kataloge erfordern oft Konfigurationen und Abhängigkeiten auf Client-Seite für jede Sprache (Java, Python, Rust, Go), was zu Inkonsistenzen zwischen verschiedenen Programmiersprachen und Verarbeitungsmaschinen führt. Lesen Sie hier mehr darüber hier.
2. Skalierbarkeitsbeschränkungen: Die Verwaltung von Metadaten und Tabellenoperationen auf Client-Ebene kann Engpässe verursachen, die die Leistung und Skalierbarkeit in datenintensiven Umgebungen beeinträchtigen können.

Vorteile der Übernahme des REST-Katalogs

• Vereinfachte Client-Integration: Clients können mit dem REST-Katalog über Standard-HTTP-Protokolle interagieren, ohne komplexe Konfigurationen oder Abhängigkeiten zu benötigen.
• Skalierbarkeit: Die serverseitige Architektur des REST-Katalogs ermöglicht eine skalierbare Metadatenverwaltung, die wachsende Datensätze und gleichzeitige Zugriffsmuster berücksichtigt.
• Flexibilität: Organisationen können benutzerdefinierte Kataloglogik auf der Serverseite implementieren, um den REST-Katalog an spezifische Anforderungen anzupassen, ohne Client-Anwendungen zu ändern.

Es sind verschiedene Implementierungen des REST-Katalogs entstanden, die jeweils auf spezifische organisatorische Anforderungen zugeschnitten sind:

• Gravitino: Ein Open-Source Iceberg REST-Katalogdienst, der die Integration mit Spark und anderen Verarbeitungsmotoren erleichtert und eine unkomplizierte Einrichtung für das Management von Iceberg-Tabellen bietet.
• Tabular: Ein verwalteter Dienst, der eine REST-Katalogschnittstelle bereitstellt und Organisationen ermöglicht, die Fähigkeiten von Iceberg ohne den Aufwand des Managements der Kataloginfrastruktur zu nutzen. Weitere Informationen finden Sie unter Tabular.
• Apache Polaris: Ein Open-Source, voll ausgestatteter Katalog für Apache Iceberg, der die REST-API implementiert, um eine nahtlose Multi-Engine-Interoperabilität über Plattformen wie Apache Doris, Apache Flink, Apache Spark, StarRocks und Trino zu gewährleisten. Weitere Informationen finden Sie auf GitHub.

Eine meiner Lieblings- und einfachen Möglichkeiten, den REST-Katalog mit Iceberg-Tabellen auszuprobieren, besteht darin, die einfache Java-REST-Implementierung zu verwenden. Bitte überprüfen Sie den GitHub-Link hier.

Fazit

Die Auswahl des geeigneten Apache Iceberg-Katalogs ist entscheidend für die Optimierung Ihrer Datenmanagementstrategie. Hier ist eine kurze Übersicht, die Ihnen bei Ihrer Entscheidung hilft:

• Hadoop-Katalog: Am besten geeignet für Entwicklungs- und Testumgebungen aufgrund seiner Einfachheit. In Produktionsszenarien mit gleichzeitigen Schreibvorgängen können jedoch Konsistenzprobleme auftreten.
• Hive Metastore-Katalog: Ideal für Organisationen mit bestehender Hive-Infrastruktur. Er bietet Kompatibilität mit einer Vielzahl von Big-Data-Tools und unterstützt komplexe Datenoperationen. Die Wartung eines Hive Metastore-Dienstes kann jedoch zusätzliche betriebliche Komplexität mit sich bringen.
• AWS Glue-Katalog: Optimal für diejenigen, die stark in das AWS-Ökosystem investiert sind. Er bietet nahtlose Integration mit AWS-Diensten und verringert die Notwendigkeit für selbstverwaltete Metadatendienste. Allerdings ist er spezifisch für AWS, was die Flexibilität über mehrere Clouds hinweg einschränken kann.
• JDBC-Katalog: Geeignet für Umgebungen, die relationale Datenbanken zur Speicherung von Metadaten bevorzugen, und ermöglicht die Verwendung jeder JDBC-kompatiblen Datenbank. Dies bietet Flexibilität und nutzt bestehende RDBMS-Infrastrukturen, kann jedoch zusätzliche Abhängigkeiten einführen und erfordert eine sorgfältige Verwaltung der Datenbankverbindungen.
• REST-Katalog: Ideal für Szenarien, die eine standardisierte API für Katalogoperationen erfordern, um die Interoperabilität zwischen verschiedenen Verarbeitungsengines und -sprachen zu verbessern. Er entkoppelt die Implementierungsdetails des Katalogs von den Clients, erfordert jedoch die Einrichtung eines REST-Dienstes zur Handhabung von Katalogoperationen, was die anfängliche Einrichtungskomplexität erhöhen kann.
• Projekt Nessie Katalog: Dies ist ideal für Organisationen, die eine Versionskontrolle über ihre Daten benötigen, ähnlich wie bei Git. Es unterstützt Branching, Tagging und Transaktionen über mehrere Tabellen. Es bietet robuste Datenmanagement-Funktionen, erfordert jedoch die Bereitstellung und Verwaltung des Nessie-Dienstes, was zusätzlichen operativen Aufwand mit sich bringen kann.

Das Verständnis dieser Katalogoptionen und ihrer Konfigurationen ermöglicht es Ihnen, informierte Entscheidungen zu treffen und Ihr Data Lake oder Lakehouse-Setup zu optimieren, um die spezifischen Bedürfnisse Ihrer Organisation zu erfüllen.