Parquet, Iceberg und Data Lakehouses verstehen

Verstehen: Parquet, Iceberg und BroadIns Data Lakehouse

• Methoden der Datenspeicherung (Dateien und im Arbeitsspeicher)

  • Es gibt verschiedene Dateiformate für den Zugriff auf und die Speicherung von Daten
  • Einige Systeme verwenden hauptsächlich geschlossene Datenformate, aber die meisten Systeme unterstützen offene Datenformate
  • Zu den wichtigsten Open-Source-Dateiformaten gehören Apache Avro, Parquet, ORC, Arrow, Feather und Protobuf
  • Diese Formate liefern Spezifikationen dafür, wie Daten im tatsächlichen Binärlayout angeordnet werden
  • Parquet unterstützt Komprimierung gut, während sich Avro gut zum Lesen bestimmter Zeilenblöcke eignet
  • Sie unterstützen Schema-Evolution und Dateiaufteilung, was für die Parallelverarbeitung essenziell ist
  • Mit verschiedenen Programmiersprachen und Tools kann in diesen Formaten gearbeitet werden

• Verwaltung großer Datenmengen – Iceberg und Delta Lake

  • Es wird eine Methode benötigt, um verschiedene Tabellen zu speichern, einzelne Schemata weiterzuentwickeln, Daten effizient zu partitionieren und externen Tools das einfache Lesen des Schemas zu ermöglichen
  • Hive, Iceberg und Delta Lake unterstützen alle ein Schema-Register oder Metastore
  • Iceberg und Delta Lake verwenden Parquet als einzelnes Dateiformat
  • Iceberg und Delta Lake sind keine Query- oder Storage-Engines, sondern offene Spezifikationen, die es Query-Engines ermöglichen, die Arbeit auszuführen
  • Sie ermöglichen Funktionen wie Partitionierungs-Evolution, Schema-Evolution, Datenkomprimierung, ACID-Transaktionen, effiziente Query-Optimierung und Time Travel

• Was sind Data Lakes und Data Lakehouses?

  • Ein Data Lake ist ein Ort, an dem Unternehmen große Datenmengen in Rohformaten wie OCR-, Parquet- oder CSV-Dateien speichern
  • Ein Data Lakehouse ist eine Kombination von Funktionen auf einem Data Lake, die unter anderem die Ausführung von SQL-Abfragen, das Einrichten von Batch-Jobs und die Konfiguration von Data Governance ermöglichen
  • Ein Data Lakehouse kann als Version eines offenen Data Warehouse betrachtet werden
  • Da Data Warehouses wie Snowflake und BigQuery offene Datenformate wie Iceberg unterstützen, verschwimmt die Grenze zwischen Data Warehouses und Data Lakehouses zunehmend

Die Meinung von GN⁺

• Iceberg und Delta Lake spielen als Metadaten-Layer für die Verwaltung großer Datensätze eine wichtige Rolle. Sie ermöglichen effizientes Datenmanagement und Query-Optimierung und sind daher für Data Scientists und Engineers nützlich.
• Data Lakehouses verbinden die Vorteile von Data Lakes und Data Warehouses und stellen damit ein neues Paradigma für Datenmanagement und Analyse vor. Das bietet die Möglichkeit, datengestützte Entscheidungen weiter zu stärken.
• Mit der wachsenden Unterstützung für Iceberg ist zu erwarten, dass Systeme für Datenmanagement und Analyse schrittweise standardisierter und interoperabler werden. Das dürfte mehr Flexibilität und Effizienz bei der Auswahl und Nutzung von Datenplattformen bringen.

[happing94]

Ich habe Iceberg und Delta Lake verglichen; hier ist das wirklich übersichtlich zusammengefasst.
Das entspricht fast genau meiner eigenen Einschätzung und Meinung.
Der online durchgeführte Benchmark wurde mit Spark ausgeführt, und der Head of DevRel von Tabular schrieb, dass der Benchmark zwar als Referenz dienen könne, aber keine große Bedeutung habe.
Wenn man sich für Open Source entscheiden will, scheint iceberg die einzige Wahl zu sein.
Die Zusammenfassung ist gut, aber es wäre noch besser, wenn es auch Links zu den verwendeten Referenzen gäbe.

[GN⁺]

Hacker-News-Kommentar

• Apache Iceberg und Delta Lake werden oft als offene Tabellenformate bezeichnet, aber tatsächlich gibt es Unterschiede.

  • Die Spezifikation des Apache-Iceberg-Tabellenformats ist so klar, dass jemand, der mit Datenbanksystemen vertraut ist, ohne große Schwierigkeiten eine Iceberg-Tabelle aufbauen und abfragen kann.
  • Im Gegensatz dazu ist es bei der Delta-Lake-Spezifikation schwer abzuschätzen, welcher Aufwand nötig ist, um die aktuelle Spezifikation vollständig zu implementieren oder laufend aktuell zu halten.
  • Die Delta-Lake-Spezifikation wirkt, als wäre sie aus einer Implementierung rückentwickelt worden, die Databricks intern festgelegt hat, um Lakehouses für Fortune-1000-Unternehmen zu bauen, die von Hadoop enttäuscht waren.
  • Ich bin nicht überzeugt, dass Delta Lake als wirklich offenes Ökosystem von echtem Wert ist.

• In der Datenbankwelt ist es ein großer Wandel, dass Delta, Iceberg und Hudi Daten in Open-Source-Formaten auf Storage wie S3 speichern.

  • Das bedeutet, dass Storage und große Teile der Verarbeitung standardisiert werden, Daten leichter zwischen Datenbanken bewegt werden können und die meisten Tools auf transaktionssichere Weise mit demselben Dateisatz arbeiten können.
  • Zum Beispiel kann ein Data Scientist Daten in Echtzeit in einem Jupyter-Notebook abfragen, während Snowflake in die Dateien schreibt, und ClickHouse kann auf denselben Daten nutzerzentrierte Analysen liefern.
  • Selbst wenn sich ein Unternehmen entscheidet, von Snowflake zu Databricks zu wechseln, ist das kein großes Problem.
  • Derzeit ist das Abfragen dieser Formate auf S3 noch nicht so schnell wie native Ingestion, aber der Marktdruck wird alle Datenbankanbieter dazu bringen, die Performance zu optimieren.
  • Das ist ein großer Sieg für Open Source und Offenheit, weil Unternehmen ihre Daten in offenen und portablen Formaten halten können.
  • Lakehouses haben eine ähnliche Wirkung. Viele Unternehmen haben sowohl einen Data Lake als auch ein Data Warehouse und müssen Daten zwischen beiden Systemen kopieren. Dasselbe Dataset abfragen zu können und nur ein System verwalten zu müssen, ist ebenso wichtig.

• Ich habe jahrelang mit Parquet-Dateien auf S3 gearbeitet, aber nicht genau verstanden, was Iceberg ist. Der Artikel erklärt Iceberg jedoch gut.

  • Iceberg ist ein Datenbank-Metadatenformat für ein zugrunde liegendes Dataset und beschreibt Schema, Partitionierung usw.
  • In traditionellen DBMS werden Schema, Query Engine und Storage-Format als ein Paket geliefert.
  • Im Big-Data-Bereich kann man Datenbankkomponenten jedoch von Grund auf zusammensetzen und frei kombinieren. Man kann Iceberg als Metadatenformat, DuckDB als Query Engine, Parquet als Storage-Format und S3 als Speichermedium verwenden.

• Die beste Methode, Apache-Arrow-DataFrames als Dateien auf der Festplatte zu speichern, ist Feather, aber man kann sie auch in das Apache-Parquet-Format umwandeln.

  • Wenn man ein eigenes nicht auf der JVM basierendes Lakehouse bauen will, kann man Iceberg für die Metadaten und Parquet für die Daten verwenden, mit Arrow-Tabellen über DuckDB abfragen und die Daten über Arrow->Pandas oder Polars verarbeiten.
  • Wenn man Feather dazumischt, funktioniert der aktuelle Python-Lakehouse-Stack nicht.

• Ich habe schon von Data Lakes gehört, aber „Data Lakehouse“ klingt nach einem Ort, an dem wohlhabende Daten im Sommer mit Datenbooten zum Datenangeln fahren.

• Ich arbeite auf GCP mit etwa 100 TB Daten, nutze BigQuery als Query Engine und einfache Hive-Partitionierung. Ich bin zufrieden damit, dass ich alle Abfragen ausführen kann und die Kosten sehr niedrig sind, aber die Latenz ist ziemlich hoch geworden (für das Unternehmen kein großes Problem).

  • Ich frage mich, ob die Einführung von Iceberg das verbessern könnte. Hat jemand Erfahrung mit Iceberg?

• Ich bin sehr begeistert von Iceberg, aber als ich es zuletzt untersucht habe, war nur die Spark-Bibliothek eine Implementierung, und Trinos Iceberg-Connector war stark von Hive abhängig.

  • Die gesamte Branche tut sich schwer damit, sich von Legacy-Technologien wie MapReduce, Hive und Spark zu lösen.
  • Ich plane, mir Iceberg noch einmal anzusehen, und hoffe, dass sich dieser Bereich weiterentwickelt. Heute haben wir Tools und Rechenleistung, um Daten ohne Legacy-Technologien zu verarbeiten, und nicht alle Daten sind Big Data.
  • Dadurch wird „Data Engineering“ zunehmend allgemeiner Backend-Entwicklung ähnlich, und übliche Entwicklungspraktiken finden Anwendung.
  • Ich hoffe sehr, dass bald eine reine Python-Iceberg-Bibliothek erscheint.

• Ich frage mich, warum niemand all das anhand konkreterer Beispiele erklären kann. Man sollte erklären, wie Daten gespeichert werden, wie man sie verbindet und abfragt und wie schnell die Abfragen sind (Transaktionsgeschwindigkeit versus „Analyse“-Geschwindigkeit).

• In allen Benchmarks, die ich online gesehen habe, zeigt das Delta-Lake-Format eine deutlich bessere Performance als Iceberg.

  • Die Frage ist, ob das etwas Grundsätzliches an der Spezifikation ist oder ob Iceberg die Lücke noch schließen kann.

• Es wird eingeräumt, dass der Blogpost weder zu 100 % umfassend ist noch für die meisten Menschen der beste Einstiegspunkt sein dürfte.

  • Mir gefällt die Haltung, dass man etwas Neues am besten lernt, indem man es anderen wieder erklärt, und ich habe damit begonnen, das auch in den Notizen auf meiner Website anzuwenden.