In der Welt der Datenverarbeitung und -analyse sind kontinuierliche Innovationen und Verbesserungen gefragt, um mit den rasant wachsenden Datenmengen und Anforderungen an Geschwindigkeit und Skalierbarkeit Schritt zu halten. Eine der jüngsten und vielversprechendsten Entwicklungen ist die Kombination aus dem spaltenbasierten Speicherformat Parquet mit dem Open-Source-Tabellenformat Iceberg. Dieses Duo bietet eine beeindruckende Performance, die in manchen Szenarien sogar die bewährte MergeTree-Engine von ClickHouse übertrifft. Das hat erhebliche Auswirkungen auf die Gestaltung moderner Datenplattformen, besonders wenn Objekt-Storage wie Amazon S3 zum Einsatz kommt. Werfen wir zunächst einen Blick darauf, warum Parquet auf Iceberg solch großes Potenzial entfaltet und wo die Grenzen von MergeTree liegen. MergeTree wurde von vornherein für die Arbeit mit Block-Storage konzipiert, bei dem das Öffnen von Dateien schnell und nahezu kostenlos ist.
In lokalen oder blockbasierten Dateisystemen ist MergeTree dadurch äußerst effizient. Die Engine basiert auf der Aufteilung von Daten in viele kleine Teile, sogenannte Parts, und verwaltet diese konsistent durch eine ausgeklügelte, automatische Zusammenführung und Kompression. Doch mit dem Wechsel zu objektbasiertem Speicher wie S3 ergeben sich neue Herausforderungen. Objektspeicher zeichnen sich durch eine höhere Latenz bei Zugriffen aus, da jede Datei in diesem Fall einem Objekt entspricht, der per HTTPS-Aufruf angesprochen werden muss. Das verursacht signifikante Verzögerungen und stellt eine Einschränkung dar, weil häufig eine sehr große Anzahl an Dateien beziehungsweise Objekten parallel gelesen werden muss. Die Anzahl der Objekte kann bei großen MergeTree-Tables leicht in die Hunderttausende gehen, was selbst hoch skalierte Systeme belastet und teuer wird, da Cloud-Anbieter für jeden Zugriff Gebühren erheben. Hier setzt Parquet auf Iceberg an.
Iceberg ist ein Offenes-Tabellenformat, das zur Organisation großer Datenmengen auf Objektspeichern dient. Es erlaubt die Verwaltung von Metadaten in einer Weise, die die Anzahl der Objektaufrufe minimiert und somit die Abfrageeffizienz deutlich erhöht. Parquet wiederum ist ein spaltenbasiertes Speicherformat, das eine hohe Kompressionsrate und effizientes Lesen einzelner Spalten ermöglicht. Diese Vorteile kombiniert Iceberg mit intelligentem Partitioning, Dateimanagement und ausgefeiltem Metadaten-Handling, um so die Performance deutlich zu verbessern. Ein weiterer Aspekt ist die Offenheit und Interoperabilität der Iceberg-Tabellen. MergeTree ist eng an ClickHouse gebunden und dessen Datenformate sind proprietär. Das schränkt den Einsatz in heterogenen Systemlandschaften ein. Iceberg und Parquet hingegen können problemlos von unterschiedlichen Systemen gelesen und beschrieben werden, was beim Aufbau moderner Data Lakes und hybrider Datenarchitekturen ein großer Vorteil ist.
Die Praxisuntersuchungen, die unter dem Namen Altinity Antalya Projekt durchgeführt wurden, zeigen beeindruckende Benchmark-Ergebnisse mit dem realistischen New York Taxi Rides Datensatz, welcher 1,3 Milliarden Zeilen umfasst. Bei der Ausführung verschiedener analytischer Abfragen konnten Parquet auf Iceberg Tabellen mitunter deutlich bessere Antwortzeiten erzielen als ein mit herkömmlichen Einstellungen betriebener MergeTree-Tisch. Besonders bei komplexeren Gruppierungen und Joins entfaltet die Iceberg-Implementierung ihre Stärken. Ursprünglich überraschten insbesondere langsame Ergebnisse bei einigen Abfragen mit MergeTree, bis Optimierungen wie die Verwendung des ZSTD-Kompressionsverfahrens, Deaktivierung eines bestimmten Query-Analysators und die Anpassung der Lese-Methoden vorgenommen wurden. Nach diesen Anpassungen konnte MergeTree zwar wieder seine Schnelligkeit unter Beweis stellen, allerdings auf Kosten von höherem administrativem Aufwand und technischem Fachwissen.
Für Anwender, die „Out of the Box“-Performance erwarten, ist die Iceberg-Lösung bereits jetzt deutlich anwenderfreundlicher. Ein weiterer faszinierender Entwicklungsstrang ist die sogenannte „Swarm Execution“. Dabei wird die Trennung von Compute und Storage konsequent umgesetzt, indem rechenintensive Abfragen nicht lokal, sondern durch zusätzliche, schnelle, zustandslose Rechenknoten (Swarm-Knoten) ausgeführt werden. Diese Knoten lesen direkt vom Objektspeicher und können flexibel skaliert werden. Das erhöht nicht nur die Performance, sondern auch die Kosten-Effizienz, da teure on-premise Serverressourcen geschont werden und bei Bedarf kostengünstige Cloud Spot-Instanzen verwendet werden können. Gerade Iceberg mit Parquet profitiert von diesem Modell, da die Metadatenstruktur den Swarm-Knoten eine effiziente Aufteilung der Arbeit ermöglicht. Paradigmatisch zeigt sich, wie die Verteilung der Abfragen auf mehrere Knoten die Antwortzeiten nahezu linear verbessert.
Die Ergebnisse der Swarm-Benchmarks verdeutlichen, dass mit zunehmender Anzahl der aktiven Knoten, die Zeit für komplexe Analysen deutlich sinkt – und zwar schneller als bei einem vergleichbaren Konzept mit MergeTree. Trotz der vielen Vorteile ist die Kombination aus Parquet auf Iceberg nicht ohne Herausforderungen. Einige Datentypen und Funktionen werden vom Parquet-Format oder der Iceberg-Implementierung noch nicht vollumfänglich unterstützt. Enums beispielsweise sind eine Schwäche, ebenso wie native Unterstützung für bestimmte Unsigned Integer Typen. Außerdem arbeiten Entwickler weiter daran, die Effizienz beim Caching, bei der Metadatenverwaltung und beim Ausbalancieren der Last auf Swarm-Knoten zu verbessern. Joins innerhalb von Swarm-Abfragen sind derzeit noch in der Erprobung und werden stetig weiterentwickelt.
Langfristig wird die Integration von Iceberg in ClickHouse möglicherweise eine duale Speicherstrategie ermöglichen, bei der „heiße“ Daten in lokalen MergeTree-Tabellen verbleiben, während ältere oder historische Daten in Parquet-Form auf Iceberg gespeichert und von Swarm-Clustern effizient abgefragt werden. Diese Trennung bietet enormes Potenzial zur Kosteneinsparung und Skalierungsfähigkeit, ohne dabei Nachteile bei der Performance zu riskieren. Im Kern verspricht die Verbindung aus Parquet und Iceberg eine neue Ära für analytische Datenbanken, bei der Open-Format-Prinzipien, Cloud-Konnektivität, Skalierbarkeit und Performance harmonisch zusammenspielen. Für Unternehmen, die auf wachsende Datenmengen reagieren müssen und nach effizienten Wegen suchen, Analyse-Workloads zu flexibilisieren und zu beschleunigen, ist dieser Ansatz wegweisend.
Die Ergebnisse des Altinity Antalya Projekts machen Mut, dass diese Technologie praktikabel und messbar besser ist – gerade in einer Zeit, in der Datenökosysteme immer heterogener und verteilt werden. Zusammenfassend bedeutet Parquet auf Iceberg in der Praxis weniger Aufwand für die Administration, bessere Möglichkeiten zur Datenfreigabe und -integration mit anderen Systemen und nicht zuletzt konkurrenzfähige oder sogar bessere Performance gegenüber traditionellen MergeTree-Tabellen, insbesondere im Cloud- und Objekspeicher-Setup. Die laufenden Entwicklungen und die aktive Community hinter Iceberg, unterstützt von großen Namen wie AWS, Databricks und Cloudflare, sichern eine kontinuierliche Weiterentwicklung und Integration in unterschiedlichste Datenplattformen.
Mit Iceberg als zukunftsweisendem Metadaten-Manager und Parquet als bewährtes spaltenbasiertes Speicherformat eröffnet sich für moderne Data Plattformen ein großer Spielraum, um den Herausforderungen des Datenzeitalters gerecht zu werden. Das Zusammenspiel von Storagekosteneffizienz, schneller Abfrageverarbeitung und nahtloser Skalierbarkeit wird neue technologische Standards setzen, die die bisherigen Grenzen von Datenbankspeicherformaten wie MergeTree erweitern oder sogar überwinden. Die Evolution hin zu flexiblen, offenen und hochperformanten Datenarchitekturen ist in vollem Gange – und Parquet auf Iceberg ist ein wichtiger Meilenstein auf diesem Weg.
