Nach einem Jahrzehnt Parquet-Herrschaft — kann WASM daran rütteln?
Du hast eine Parquet-Tabelle, die seit acht Jahren mitwächst — nicht riesig, nicht winzig, etwa dreihundert GB. Eines Tages kommt eine neue Anforderung: Punktabfragen auf dieser Tabelle — kein Full Table Scan, nur ein paar Dutzend Zeilen nach Primärschlüssel. Du probierst es und stellst fest: Parquet kann das zwar, aber jedes Mal muss aus den Column Chunks der Row Groups die Zielseite herausgesucht werden, die Seitengranularität liegt bei Hunderttausenden von Zeilen, und der I/O-Overhead passt überhaupt nicht zur Anforderung.
Du denkst dir: Spaltenorientierte Speicherformate gibt es seit über zehn Jahren — wie kann es sein, dass sie nicht einmal einen vernünftigen wahlfreien Zugriff hinbekommen?
Genau das ist der Ausgangspunkt, von dem aus die CMU Database Group F3 (Future File Format) auf der SIGMOD vorgestellt hat. Aber genau dieser Ausgangspunkt berührt die empfindlichste Stelle im Formatkrieg.
Ein neues Format, ein altes Problem
Das Problem, das F3 lösen will, lässt sich in einem Satz zusammenfassen: Die bestehenden spaltenorientierten Speicherformate (Parquet, ORC) wurden in der Hadoop-Ära geboren — ihr Speicherlayout und ihre Evolutionsmechanismen sind der heutigen Hardware und den heutigen Workloads nicht mehr angemessen. Parquets Row Groups sind grob granulat, die Metadaten-Hierarchie ist flach, und die Spaltenkodierungen sind in der Spezifikation festgeschrieben — eine neue Kodierung einzuführen erfordert, dass alle Reader-Implementierungen aktualisiert werden. Eine in der F3-Veröffentlichung zitierte Zahl ist bemerkenswert: Die am weitesten verbreitete Parquet-Version ist nach wie vor v1 aus dem Jahr 2013.
Parquet hat es nicht einmal geschafft, Parquet selbst abzulösen.
F3s Ansatz ist zweigleisig. Auf der Layout-Ebene führt es eine feinere hierarchische Struktur ein: IOUnit (grundlegende I/O-Einheit) → EncUnit (grundlegende Kodierungseinheit, standardmäßig 64K Zeilen) → optionale Sub-EncUnit-Vektoren. Diese Hierarchie erlaubt es Readern, beim Lesen feingranularer zu projizieren — nur ein paar tausend Zeilen aus einer Spalte? EncUnit-Index durchlaufen, irrelevante Blöcke überspringen, fertig.
Auf der Erweiterbarkeitsebene ist F3s Kernidee: Decoder als WASM-Binärcode in die Datei selbst einbetten. Jede EncUnit kann eine WASM-ID tragen, die auf einen am Dateiende gespeicherten Decoder verweist. Erkennt der Reader diese Kodierung lokal nicht, lädt er einfach das WASM-Modul und dekodiert damit — kein Reader-Update nötig, kein Warten auf Community-Konsens. Das Paper beziffert das Volumen der WASM-Decoder im KB-Bereich: „vernachlässigbare Speicherkosten” (negligible storage cost).
Das sind F3s zwei Trümpfe: feinerer wahlfreier Zugriff und WASM als Ausweg aus der Kompatibilitäts-Sackgasse.
Was hinter den Daten steckt
F3s Benchmarks vergleichen Parquet, ORC, Vortex, Lance und Nimble. Aus den Experimenten des Papers lassen sich mehrere Trends ablesen:
- Wahlfreier Zugriff: F3s Punktabfrage-Latenz liegt signifikant unter der von Parquet, besonders in Szenarien mit wenigen Spalten und wenigen Zeilen. Keine Magie — die EncUnit-Hierarchie ermöglicht von Natur aus kleinere I/O-Granularität.
- Kompressionsrate und Dekompressionsgeschwindigkeit: In etwa auf demselben Niveau wie Parquet. F3 verwendet standardmäßig Cascade-Kodierung (ähnlich der Default-Kodierung von Vortex) für EncUnits mit je 64K Zeilen, kombiniert mit Zstd/LZ4-Kompression. Nicht gewonnen, aber auch nicht verloren.
- WASM-Dekodierungs-Overhead: Die Nutzung des WASM-Decoders ist eine Stufe langsamer als natives Dekodieren, aber das Paper argumentiert ausführlich, dass dieser Abstand im akzeptablen Bereich liegt. Hier ist ein Engineering-Urteil gefragt: Der Existenzzweck des WASM-Decoders ist „die Datei bleibt lesbar”. Er ist ein Fallback, kein Beschleuniger.
Insgesamt präsentiert F3 in den Benchmarks die Haltung eines Formats, das „in manchen Dimensionen besser, insgesamt nicht schlechter als Parquet” ist. Für eine SIGMOD-Veröffentlichung ist das ein valides Ergebnis. Für einen Format-Ablösungskrieg reicht das noch nicht.
Kompatibilität: der wahre Burggraben
Der höchstbewertete Kommentar in der HN-Diskussion stammt von vouwfietsman, und er sagt etwas Brutales, das schwer zu widerlegen ist:
Parquet is unfortunately very good just by virtue of being first, and so widely supported.
Wie gefestigt ist Parquets ökologische Nische? Ein paar Fakten genügen: Spark, DuckDB, Pandas, Polars, Snowflake, BigQuery, Redshift Spectrum, AWS Athena, Trino, Presto, ClickHouse (externe Tabellen) … nahezu jedes Datenwerkzeug mit Namensnennung unterstützt Parquet nativ. Seine Spezifikation ist offen, aber durch die wiederholte Reibung in über zwanzig großen Implementierungen hat sich ein De-facto-Standard herausgebildet. Eine von dir erzeugte Parquet-Datei kann von jedem Werkzeug gelesen werden — das ist das Ergebnis von zehn Jahren Bugfixes und Interoperabilitätsanpassungen durch die Community.
Daraus ergibt sich ein Paradoxon: F3 versucht, das Kompatibilitätsproblem „neue Kodierungen können von alten Readern nicht erkannt werden” mit WASM zu lösen, aber das, was ein neues Format wirklich blockiert, sind die ökologischen Zugangskosten.
Was müsste ein Unternehmen tun, um auf F3 umzusteigen?
- Allen nachgelagerten Query-Engines einen F3-Reader hinzufügen (WASM-Fallback kann nur EncUnits dekodieren, ersetzt aber keine vollständige Reader-Implementierung — Dateikopf-Parsing, Metadaten-Traversierung, Prädikat-Pushdown, Projektionsbeschneidung, all das braucht nativen Code).
- Alle Datenpipelines (ETL/ELT) müssen F3-Writer unterstützen.
- Alle Data-Governance-Werkzeuge (Catalog, Schema Registry, Lineage Tracking) müssen F3-Metadaten parsen können.
- Externe Partner für den Datenaustausch müssen F3 lesen können.
Das löst kein WASM-Decoder. Parquets Burggraben ist das in zehn Jahren gewobene ökologische Netz.
Die Spannungen des WASM-Ansatzes
F3s WASM-Design löste in den HN-Kommentaren eine heftige Subdiskussion aus, die sich auf drei Ebenen zuspitzte.
Erste Ebene: Sicherheit. Ausführbarer Code, eingebettet in Dateien — mag die WASM-Sandbox noch so ausgereift sein, der Sicherheitsnerv von Ingenieuren wird dadurch unweigerlich gereizt. Manche ziehen den Vergleich zu JavaScript in PDFs — der Standard hat diese Fähigkeit vorgesehen, aber jeder vernünftige Viewer schaltet sie standardmäßig ab. F3-Befürworter entgegnen, WASM-Decoder seien reine Pure Functions ohne I/O-Fähigkeit und die Sandbox könne Instruktionsanzahl und Speicherobergrenze beschränken. Doch Data-Engineering-Workflows beinhalten häufig Daten aus nicht vertrauenswürdigen Quellen — beliebige WASM-Ausführung zuzulassen bleibt für viele Sicherheitsteams eine inakzeptable Option.
Zweite Ebene: Performance-Positionierung. vouwfietsman bringt es auf den Punkt: Der Kernwert spaltenorientierter Speicherformate liegt darin, sequenzielle Scans gegen analytische Performance zu tauschen — wahlfreien Zugriff opfert man bewusst. F3 setzt verbesserten wahlfreien Zugriff als Hauptverkaufsargument ein, aber wahlfreier Zugriff selbst ist nicht das Designziel spaltenorientierter Formate. Wenn der wahlfreie Zugriff optimiert wird, dafür aber Full-Table-Scans langsamer werden (und sei es nur auf dem WASM-Dekodierpfad), dann wird eine Kernfähigkeit gegen eine Nebenfähigkeit eingetauscht.
Dritte Ebene: Technische Stimmigkeit. F3s Metadatenschicht verwendet Googles FlatBuffers zur Serialisierung von Schema und Dateilayout-Informationen. WASM-Decoder müssen Daten zwischen der Hostsprache und dem WASM-Speicher hin- und herbewegen, und das FlatBuffers-Parsing selbst verursacht ebenfalls Overhead. Einige Kommentatoren sehen in der Kombination WASM-Laufzeit + FlatBuffers-Serialisierung/Deserialisierung zwei Abstraktionsebenen auf dem Lesepfad — genau das, was spaltenorientierte Speicherformate möglichst minimieren wollen.
Diese Einwände bedeuten nicht, dass F3s Design falsch ist. Aber sie deuten auf eine Kernfrage: F3 versucht den Nebenwiderspruch der Format-Evolution zu lösen, nicht den Hauptwiderspruch. Der Hauptwiderspruch ist: „Wie bringt man alle dazu, wechseln zu wollen?” — nicht: „Wie bringt man neue Kodierungen zum Laufen?”
Echos der Geschichte
In den HN-Kommentaren postete jemand xkcd #927 („Standards”), andere erinnerten an das Schicksal von OpenDoc — ein technisch überlegenes Dateiformat, das letztlich gegen den Netzwerkeffekt verlor. Wieder andere meinten, man müsse nicht so pessimistisch sein: Wenn F3 in bestimmten Nischenszenarien einen Mehrwert bietet, den Parquet nicht liefern kann (etwa Feature Stores mit häufigen wahlfreien Zugriffen oder vertikale Domänen mit benutzerdefinierten Kodierungen), dann muss es nicht den gesamten Markt gewinnen — es reicht, sich in der eigenen Nische zu etablieren.
Ich neige zur Ansicht, dass sich beide Urteile nicht ausschließen. Die Geschichte der Formatablösung spricht in der Tat überwältigend für die „Kompatibilität zuerst”-These, aber in der Geschichte gab es noch nie das Designprinzip, „Decoder in die Datei einzubetten”. WASM hat die Kostenstruktur für plattformübergreifend ausführbaren Code verändert — vor zehn Jahren war die Vorstellung, eine Sandbox-Ausführungsumgebung in eine Datei einzubetten, undenkbar. Heute ist es eine Zeile wasmtime::Module::new().
F3 wird Parquet vielleicht nicht ersetzen, aber das von ihm vorgeschlagene WASM-Decoder-Paradigma könnte von Parquet oder anderen Formaten absorbiert werden. Das beste Ergebnis ist nicht die Ablösung, sondern die Ansteckung — das alte Format lernt von deinem guten Design, und du ziehst weiter ins nächste Niemandsland.
Aus heutiger Trendperspektive
F3 ist derzeit noch ein Forschungsprototyp — das README beginnt mit dem Hinweis „sollte nicht in Produktionsumgebungen verwendet werden”, das GitHub-Repository zählt lediglich 4 Commits, und die Benchmark-Reproduktionsskripte sind noch unvollständig. Bis F3 von Engineering-Teams ernsthaft als Alternative evaluiert werden kann, liegt noch ein erheblicher Weg der Produktionsreife vor ihm.
Aus Branchentrends betrachtet ist Parquets Position kurzfristig kaum zu erschüttern. Der Aufstieg offener Tabellenformate wie Iceberg, Delta Lake und Hudi hat Parquet noch tiefer im Fundament der Lakehouse-Architektur verankert — der Formatkrieg wandert nach oben, das Dateiformat wird dadurch eher noch weiter „festgeschrieben”. Man kann kaum gleichzeitig auf Iceberg umsteigen und das darunterliegende Dateiformat wechseln — das wäre die doppelten Migrationskosten.
Dennoch ist die von F3 aufgeworfene Frage wertvoll. Parquets Evolutionsengpass ist real — dass die seit zehn Jahren unveränderte Version 1 immer noch den Markt dominiert, ist kein Normalzustand. Der WASM-Decoder-Gedanke könnte, selbst wenn er letztlich nicht F3 zum Erfolg verhilft, die nächste Spezifikationsversion eines anderen Formats beflügeln.
Anders gesagt: Das hier wird nicht Parquets Begräbnis, aber es könnte der erste Herzschlag des nächsten spaltenorientierten Speicherformats sein.
Referenzen: F3 SIGMOD Paper · GitHub Repository · HN Diskussion