Iceberg-Tabellenformat, gute Idee – schlecht definierte Spezifikation – Teil 2 von 2

Probleme der Iceberg-Spezifikation

• Schwerwiegende Probleme der Iceberg-Spezifikation: Die Iceberg-Spezifikation ist kein ernsthafter Versuch, die Metadatenprobleme großer Data Lakes zu lösen.
• Historische Lehren: Im ersten Teil wurde ein Blick in die Geschichte geworfen, um aus den Lehren der Vergangenheit zu lernen, und das „Space-Management-Problem“ eingeführt, das Datenbanken lösen müssen.
  • Bestandteile des Problems:
    1. Fragmentierung des Speicherplatzes
    2. Fein granularisierte Nebenläufigkeitskontrolle
    3. Atomarität über mehrere Objekte hinweg
    4. Impedanzfehlanpassung zwischen Zeilen und Dateien
    5. Zugriff auf Metadaten mit niedriger Latenz und hohem Durchsatz
• Bedeutung offener Formate: Der Einsatz offener Formate im gesamten Stack wird zu 100 % befürwortet, und besonders vielversprechend erscheint die Nutzung von Parquet als gemeinsames Speicherformat für tabellarisch strukturierte Daten.
• Unterschied zwischen Parquet-Dateien und Datenbanktabellen: Nur weil Parquet-Dateien zusammen vorliegen, werden sie noch nicht zu einer Datenbanktabelle. Eine Datenbanktabelle ist mehr als nur eine einfache Menge von Zeilen.

Zusammenfassung des Metadatenproblems

• Space-Management-Problem: Es wird erneut betont, welche verschiedenen Probleme Datenbanken lösen müssen.
• Notwendigkeit von Metadaten: Damit mehrere Parquet-Dateien wie eine Datenbanktabelle erscheinen, werden folgende Metadaten benötigt:
  1. Eine Liste der Speicherorte aller Dateien, aus denen die Tabelle besteht
  2. Grobe Metadaten zu jeder Datei
  3. Ein Mechanismus zur Transaktionskontrolle für das Hinzufügen oder Entfernen von Dateien
  4. Eine Möglichkeit, das Tabellenschema weiterzuentwickeln
• Dateispeicherorte finden: Um eine Menge von Parquet-Dateien als einzelne Tabelle zu behandeln, ist ein Mechanismus zum Auffinden der Dateien erforderlich.
• Wichtigkeit von Metadaten: Jede Datei benötigt zusätzliche Metadaten, damit interessante Zeilen schnell gefunden werden können.

Parquet-Dateien und Datenbanktabellen

• Definition von Parquet-Dateien: Parquet bietet ein selbstbeschreibendes, tabellarisches Datenformat.
• Definition von Datenbanktabellen: Eine Datenbanktabelle ist nicht einfach nur eine Menge von Zeilen, sondern benötigt verschiedene Metadaten und Transaktionskontrolle.
• Voraussetzungen, um Parquet-Dateien wie Tabellen zu verwenden:
  1. Eine Liste der Dateispeicherorte
  2. Metadaten zu jeder Datei
  3. Ein Mechanismus zur Transaktionskontrolle für das Hinzufügen und Entfernen von Dateien
  4. Eine Methode zur Weiterentwicklung des Tabellenschemas
• Unterschied zwischen Dateien und Tabellen: Nur weil Parquet-Dateien dasselbe Spaltenlayout haben, wirken sie noch nicht wie eine Datenbanktabelle.

Manifestdateien und Listen

• Ablauf beim Hinzufügen von Daten: Wenn ein Iceberg-Client Daten zu einer Tabelle hinzufügen will, muss er die folgenden Schritte ausführen:
  1. Eine oder mehrere Parquet-Dateien an einen bestimmten Ort schreiben, z. B. S3.
  2. Eine Manifestdatei schreiben, die auf die in Schritt 1 geschriebenen Dateien verweist.
  3. Eine neue Manifestliste schreiben.
• Format der Manifestdateien: Manifestdateien und -listen liegen im AVRO-Format vor, das komprimiert und selbstbeschreibend ist.
• Inhalt der Manifestdateien: Manifestdateien enthalten Pointer auf Parquet-Dateien sowie Metadaten zu jeder Spalte.
• Problem mit der Größe der Metadaten: Werden Metadaten auf diese Weise gespeichert, werden sie größer als nötig, weil gemeinsame String-Werte zwischen Dateien nicht erkannt und komprimiert werden können.

Zunehmende Last für den Client

• Verantwortung des Clients: In der gesamten Iceberg-Spezifikation muss der Client für einfache Änderungen eine enorme Menge an Verwaltungsarbeit übernehmen.
• Problem der Metadatengenauigkeit: Wenn der Client Teile davon falsch schreibt, muss der Commit des neuen Snapshots gründlich geprüft werden, einschließlich der Frage, ob die Manifestdaten korrekt geschrieben wurden.
• Sicherheitsproblem: Da der Client eine Manifestliste schreiben muss, die auf alle Manifestdateien verweist, werden die Speicherorte aller S3-Dateien offengelegt.
• Bedeutung von Datensicherheit: Weil der Wert der Daten hoch ist, sollte man hinterfragen, warum die Spezifikation Sicherheit nicht als oberste Priorität behandelt.

Mängel bei der Zeilensicherheit

• Notwendigkeit von Zeilensicherheit: Selbst in locker regulierten Ländern wie den USA ist Sicherheit auf Zeilenebene nötig, um sensible Daten zu schützen.
• GDPR in der EU: In Europa muss wegen Gesetzen wie der GDPR noch sensibler mit dem Datenzugriff umgegangen werden.
• Problem beim Datenzugriff durch Clients: Ein Client kann zwar Daten zur Tabelle hinzufügen, aber der Zugriff auf bereits vorhandene Daten kann nicht eingeschränkt werden.
• Schwere des Sicherheitsproblems: Dass die Spezifikation Sicherheit nicht priorisiert, sollte Fragen über den Wert von Data-Lake-Informationen aufwerfen.

Die Rolle der Metadatendatei

• Erstellung der Metadatendatei: Nachdem der Client Parquet-Dateien geschrieben hat, muss er die zugehörige Manifestdatei erzeugen, die bestehende Manifestliste lesen, eine neue Manifestliste erzeugen und dann die Daten committen.
• Commit-Prozess: Der Commit erfolgt durch das Schreiben einer Metadatendatei (<prefix>.metadata.json).
• Wahl des JSON-Formats: Warum die Metadatendatei im JSON-Format vorliegt, ist unklar, und es vermittelt den Eindruck von „Design by Committee“.
• Wiederholung in den Metadaten: Die Metadatendatei listet alle Snapshots auf, was wegen der Wiederholung von Informationen Speicherplatz verschwendet.

Komplexität des Commit-Prozesses

• Problem der Atomarität: Eine neue Metadatendatei muss zur aktuellen Datei gemacht und atomar gegen die vorherige Metadatendatei ausgetauscht werden.
• Komplexität des Commit-Verfahrens: Um eine neue Metadataversion V+1 zu committen, müssen folgende Schritte ausgeführt werden:
  1. Eine neue Tabellen-Metadatendatei auf Basis der aktuellen Metadaten erzeugen.
  2. Die neuen Tabellenmetadaten in eine eindeutige Datei schreiben.
  3. Im Metastore anfordern, den Metadaten-Pointer der Tabelle von V auf V+1 umzuschalten.
• Umgang mit fehlgeschlagenem Swap: Wenn der Swap fehlschlägt, hat bereits ein anderer Writer V+1 erzeugt, und der Client muss wieder zu Schritt 1 zurückkehren.
• Problem von Race Conditions: Wenn Clients konkurrieren, müssen sie die vom vorherigen Client geschriebenen Metadatendateien erneut lesen und Manifestlisten sowie Metadatendateien neu erzeugen.

Probleme der optimistischen Nebenläufigkeitskontrolle

• Realität von Nebenläufigkeit: Wenn kein Wettbewerb um eine Ressource zu erwarten ist, spielt es keine Rolle, welche Art von Nebenläufigkeit verwendet wird.
• Wenn Wettbewerb zu erwarten ist: Wenn zwei Clients denselben Wert ändern wollen, muss ein Sperrmechanismus eingesetzt werden.
• Grenzen der optimistischen Nebenläufigkeitskontrolle: In Iceberg kollidieren zwei gleichzeitige Schreibvorgänge immer, und das liegt an der Art, wie die Spezifikation entworfen ist.
• Schlechteste Lock-Semantik: Es wird die schlechteste mögliche Lock-Semantik für Metadaten verwendet, obwohl zwischen Clients keine Koordination nötig wäre, wenn sie nur Daten hinzufügen wollen.

Grenzen des Metadaten-Swaps

• Zentralisierung der Metadaten: Durch die Zentralisierung der Tabellenmetadaten in einer einzigen Datei wurde ein einzelner Contention-Point für alle Schreibvorgänge geschaffen.
• Zusätzliche Last bei Wiederholungen: Wenn ein Client scheitert, muss er die vom vorherigen Client geschriebenen Daten lesen und Manifestlisten sowie Metadatendateien neu erzeugen.
• Geschwindigkeit des Metadaten-Swaps: Der Dienst, der den Metadaten-Swap ausführt, muss auch Wiederholungen behandeln, was zu Leistungseinbußen führt.
• Begrenzte Zahl von Commits: Aufgrund der einfachen Implementierung der Nebenläufigkeit ist die Zahl der Commits begrenzt, und zwar durch die Zeit für den atomaren Austausch der Metadatendatei.

Warum eine Datenbank nötig ist

• Auffinden der Metadatendatei: Ein Iceberg-Tabellen-Snapshot wird vollständig durch die Datei metadata.json beschrieben.
• Widerspruch der Idee: Iceberg versucht, ein Metadatenformat nur mit Dateien zu spezifizieren, braucht am Ende aber doch eine Datenbank.
• Vorteile einer Datenbank: Moderne Datenbanken können Hunderttausende Schreibvorgänge verarbeiten und lassen sich verteilt skalieren.
• Vergleich zwischen Dateisystem und Datenbank: Es ist effizienter, Metadaten in einer Datenbank als in Dateien zu speichern.

Fragmentierung und Aufblähung der Metadaten

• Wachstum der Datei metadata.json: Die Datei metadata.json verweist auf den neuesten Snapshot, und jede Metadatendatei enthält einen Rückverweis auf den vorherigen Snapshot.
• Kontinuierliches Anwachsen der Metadaten: Die Metadaten wachsen ständig weiter, was sich negativ auf die Performance des Data Lake auswirkt.
• Notwendigkeit regelmäßiger Metadatenbereinigung: Wenn fortlaufend Daten in den Data Lake geschrieben werden, müssen die Metadaten bereinigt werden.
• Kosten von HTTP-Anfragen: Beim Löschen von Metadatendateien fallen HTTP-Anfragen an, die Kosten verursachen können.

Datenlesen und Query-Planung

• Rolle der Manifestdateien: Manifestdateien enthalten Metadaten zu den Parquet-Dateien.
• Komplexität der Query-Planung: Um eine Query auszuführen, müssen Manifestlisten und Manifestdateien nacheinander gelesen werden.
• Kostenproblem: Beim Lesen aus S3 entstehen Kosten, die sich auf die Geschwindigkeit der Query-Ausführung auswirken.
• Problem fragmentierter Metadaten: Wenn Metadaten fragmentiert sind, wird die Query-Planung komplexer und der Datenzugriff schwieriger.

Caching und die Schwierigkeiten der Query-Planung

• Caching von Manifesten: Manifeste können zwischengespeichert werden, das ist aber ineffizient, weil die Metadatenmenge zu groß wird.
• Aktualität des Caches sicherstellen: Es muss geprüft werden, ob der Cache aktuell ist, was zusätzliche Kosten und Komplexität verursacht.
• Last für Clients: Alle Clients müssen Metadaten cachen, was Millionen von HTTP-Anfragen erzeugt.
• Zunehmende Komplexität: Die Nutzung des Data Lake wird immer komplexer, und es sind zusätzliche Lösungen nötig, um das zu bewältigen.

Fazit der Idee

• Kritik an der Idee: Die Iceberg-Spezifikation ist keine ernsthafte Spezifikation für Data-Lake-Metadaten und hat zahlreiche Probleme.
• Zusammenfassung der Probleme: Iceberg fügt Metadaten mit O(n)-Operationen hinzu, kann tabellenübergreifende Commits nicht verarbeiten und löst das Problem aufgeblähter Metadaten nicht.
• Grenzen bei der Skalierung: Iceberg eignet sich nicht gut für Skalierung und verlagert übermäßige Komplexität auf den Client.
• Frage an die Branche: Es wird die Frage aufgeworfen, warum solche Probleme in der IT-Industrie überhaupt entstehen.