- F3 (Future-proof File Format) ist ein Open-Source-Storage-Format der nächsten Generation für spaltenorientierte Daten, das Interoperabilität, Erweiterbarkeit und Effizienz als zentrale Designprinzipien verfolgt und so die Notwendigkeit beseitigt, bei jedem Wandel von Datenverarbeitungs- und Computing-Umgebungen neue Formate zu entwickeln
- Jede F3-Datei besitzt eine selbstbeschreibende (self-describing) Struktur und enthält neben Daten und Metadaten sogar einen WebAssembly-(Wasm)-Binärdecoder, wodurch auch ohne nativen Decoder plattformübergreifende Kompatibilität gewährleistet ist
- Das Format bietet ein effizientes Storage-Layout mit modernen Encoding-Verfahren wie stufenweiser Kompression und vektorisiertem Decoding und verbessert Layout-Probleme von Parquet und ORC, indem es I/O-, Encoding- und Dictionary-Einheiten voneinander trennt
- Über eine pluginbasierte Decoding-API und einen Wasm-Einbettungsmechanismus können Entwickler neue Encoding-Schemata leicht ergänzen; zudem lassen sich unabhängig von der Bibliotheksversion alle Dateien lesen, womit Interoperabilitätsprobleme von Parquet gelöst werden
- Die Evaluierung belegt die Effizienz des F3-Storage-Layouts und die Vorteile des Wasm-basierten Decodings; der Storage-Overhead liegt nur im Kilobyte-Bereich und der Performance-Verlust beim Wasm-Decoding beträgt gegenüber nativem Decoding akzeptable 10–30 %
Hintergrund und Motivation
Grenzen bestehender spaltenorientierter Formate
- Parquet und ORC wurden Anfang der 2010er Jahre für Datenanalysesysteme wie Hive, Impala und Spark entwickelt und ermöglichten den Datenaustausch zwischen Data Warehouses und Data Lakes
- Zehn Jahre später zeigen Untersuchungen, dass diese Formate für moderne Datenanalyse nicht mehr ausreichen, weil sie auf veralteten Annahmen über Hardwareleistung und Zugriffsmuster von Workloads beruhen
- In den vergangenen zehn Jahren haben sich Storage- und Netzwerkleistung um ein Vielfaches verbessert, die CPU-Leistung jedoch nicht im gleichen Maß, sodass Systeme nicht mehr durch I/O, sondern durch Compute limitiert werden
- Mit dem Aufstieg von Data Lakes werden mehr Daten in Cloud-Storage mit hoher Bandbreite und hoher Latenz (z. B. Amazon S3) gespeichert
- Anwendungen speichern nicht mehr nur tabellarische Daten mit wenigen Spalten. In ML-Workloads sind breite Tabellen mit Tausenden von Spalten, hochdimensionale Vektor-Embeddings und große Blobs (Bilder, Videos) üblich
- Auch der Bedarf an Random Access und Updates ist gestiegen, doch bestehende Formate eignen sich nicht für diese Nutzungsmuster
- Fortschritte bei Kompression, Indexierung und Filtermethoden versuchen diese Schwächen zu beheben, doch bestehende Dateiformate wurden nicht für einfache Erweiterbarkeit entworfen
- Selbst wenn neue Funktionen ergänzt werden, gibt es zu viele Sprachimplementierungen der Parquet- und ORC-Bibliotheken, als dass überall aktuelle Versionen zu erwarten wären
- Systeme mit älteren Bibliotheken können Inhalte neuer Dateien möglicherweise nicht decodieren, weshalb die meisten Systeme nur den kleinsten gemeinsamen Funktionsumfang unterstützen, um Interoperabilitätsprobleme zu vermeiden
Das Aufkommen neuer Dateiformate und ihre Grenzen
- Um diese Probleme zu überwinden, wurden völlig neue Dateiformate wie Meta Nimble, Lance, TSFile, Bullion und BtrBlocks vorgeschlagen
- Doch auch sie begehen dieselben Fehler wie ihre Vorgänger
- Sie wurden auf Basis heutiger Hardware- und Workload-Annahmen entworfen
- Sie fördern keine einfache Erweiterbarkeit, die neue Funktionen unterstützt, ohne die Interoperabilität mit bestehenden Deployments zu zerstören
- Selbst wenn eines davon Parquet oder ORC als dominantes Format ablösen sollte, würde in zehn Jahren dasselbe Problem auftreten: Es müsste wieder ein neues Format entwickelt werden, um seine Mängel zu beheben
Der Ansatz von F3
- F3 zielt darauf ab, Interoperabilität, Erweiterbarkeit und Effizienz gleichzeitig zu erreichen
- Im Kern definiert F3 drei Spezifikationen:
- die Metadaten des Dateiinhalts
- das physische Gruppierungs-Layout der in der Datei codierten Daten
- eine Datenzugriffs-API, die vom Encoding-Schema der Daten unabhängig ist
- Das Metadatenschema von F3 minimiert die Datenmenge, die nötig ist, um Teilmengen von Spalten einer Tabelle abzurufen
- F3 beseitigt das umfassende „row group“-Konzept von Parquet und behebt Layout-Probleme, indem es I/O-, Encoding- und Dictionary-Einheiten trennt
- Zudem integriert es moderne Methoden wie stufenweise Kompression und vektorisiertes Decoding
Überblick über F3
Gesamtstruktur
- Eine F3-Datei besteht aus einem Metadatenbereich und einem Datenbereich
- Metadatenbereich: OptionalData (OptData), Column Metadata (ColMetadata), Footer, Postscript
- Datenbereich: besteht aus Row Groups (RG) und enthält die eigentlichen Daten
- F3 verwendet wie Parquet und ORC dasselbe PAX-Layout
- Dennoch gibt es mehrere zentrale Unterschiede zu bestehenden Formaten:
- Die Metadaten eliminieren Deserialisierungs-Overhead (und lösen damit ein Problem von Parquet/ORC)
- Die physische I/O Unit (IOUnit) wird von der logischen Row Group getrennt, sodass die Größe der IOUnit je nach Storage-Medium unabhängig angepasst werden kann
- Der Gültigkeitsbereich des Dictionary-Encoding wird von der logischen Row Group getrennt, sodass für jede Spalte der effektivste Bereich gewählt werden kann
- Jede IOUnit besteht aus mehreren Encoding Units (EncUnit), wobei eine EncUnit die kleinste Einheit für Encoding und Decoding ist
Mechanismen für Interoperabilität und Erweiterbarkeit
- F3 stellt eine öffentliche API bereit, über die Implementierungen definieren, wie die komprimierten Daten in der Datei decodiert werden
- Encoding-Methoden werden als Plugins behandelt und können getrennt von der Kernbibliothek installiert und aktualisiert werden
- Damit jede Bibliotheksversion jede Datei lesen kann, wird die Decoder-Implementierung als WebAssembly-(Wasm)-Binärdatei in die Datei selbst eingebettet
- Das heißt: Jede F3-Datei enthält sowohl die Daten als auch den Code, um diese Daten zu lesen
- Die API von F3 erfordert keine getrennte Implementierung für nativen Code und Wasm-Versionen; derselbe Code wird ohne Änderungen für beide Ziele kompiliert
- Dieses Design macht F3 zukunftssicher, vermeidet die zuvor beschriebenen Probleme und ermöglicht eine schnellere Evolution als bestehende Lösungen
- Entwickler können zukünftige Encoding-Methoden als Wasm-Code in Dateien einbetten und in Produktionssystemen einsetzen, ohne sich um Bibliotheks-Upgrades über die gesamte Flotte hinweg kümmern zu müssen
- Der Storage-Overhead von Wasm-Binärdateien ist gering (im Kilobyte-Bereich), und der Performance-Verlust beim Wasm-Decoding gegenüber nativen Implementierungen ist minimal (10–30 %)
Fazit
- F3 ist ein Dateiformat der nächsten Generation für spaltenorientierte Daten, das Interoperabilität, Erweiterbarkeit und Effizienz gleichzeitig erreicht
- Das effiziente Dateilayout beseitigt Ineffizienzen bestehender Formate
- Mit pluginbasierter Decoding-API und Wasm-Einbettung bietet es einen zukunftssicheren Mechanismus, mit dem unabhängig von der Bibliotheksversion alle Dateien gelesen werden können
- Die Auswertung des Prototyps bestätigt die Effizienz des Layout-Designs und die Praxistauglichkeit des Wasm-Mechanismus
- Der Wasm-Overhead bleibt mit Storage im Kilobyte-Bereich und 10–30 % Performance-Verlust in einem akzeptablen Rahmen
1 Kommentare
Hacker-News-Kommentare
Nach einem schnellen Blick scheint vieles von den Schwächen von Parquet deutlich verbessert worden zu sein, daher sind die Erwartungen hoch
Obwohl die Parquet-Metadaten auf Thrift basieren, gibt es nur Anmerkungen im Stil von „Wenn dieses Feld vorhanden ist, muss auch jenes Feld vorhanden sein“, aber keine echte Validierungslogik. Ich denke daher, dass ein Reader kaputtgehen kann, wenn man fehlerhaftes Thrift hineingibt
Parquet-Metadaten müssen geparst werden, daher wiederholen sich Buffer-Allokation und dynamische Allokation zum Parsen der Metadaten, was zu sehr vielen Heap-Allokationen führt. Das neue Format setzt auf Flatbuffers, sodass die Flatbuffer-Bytes direkt interpretiert werden können und dieses Problem gelöst wird
Das Encoding wirkt deutlich leistungsfähiger. Es scheint nun möglich zu sein, leichtgewichtige und kombinierbare Encodings zu nutzen, wie sie in der Datenbankbranche schon lange propagiert werden. Bestehende Formate wie BtrBlocks und FastLanes waren Parquet überlegen, daher ist es gut zu sehen, dass ihre guten Ideen übernommen wurden
Das Dremel-Record-Shredding von Parquet war mir zu komplex, daher bin ich froh, dass es diesmal verschwunden ist
Bei Parquet variiert die Anzahl der Rows innerhalb einer DataPage, sodass man zum Finden einer gewünschten Row den gesamten ColumnChunk scannen muss. In diesem Format kann man dagegen direkt zur gewünschten DataPage (IOUnit) springen
Schwergewichtige Kompression wurde entfernt, übrig geblieben sind nur Delta/Dictionary/RLE. Schwergewichtige Kompression bringt in der Praxis wenig, ist umständlich zu implementieren und bringt viele externe Abhängigkeiten mit sich
Insgesamt ein gewaltiger Fortschritt. Ich hoffe, dass dieses Format die Datenanalysebranche erobert
Falls mit schwergewichtiger Kompression zstd oder brotli gemeint ist, dann ist das bei String-Spalten mit wenig Wiederholung sehr nützlich
Wenn ein wasm-Compiler dazukommt, kann das am Ende sogar mehr Abhängigkeiten mit sich bringen als „heavy“ compression
StackOverflow-Diskussion zum Hinzufügen einer Spalte zu einer Parquet-Datei
Heutzutage scheint sich zstd als Kompressionsmethode etabliert zu haben?
Parquet ist überraschend komplex. Um es wirklich effizient zu nutzen, muss man viele unbequeme und schlecht dokumentierte Details kennen, daher ist es nicht einfach
Wes McKinney
Für diejenigen, die Wes McKinney nicht kennen: Er ist der Gründer von Pandas, der in Python am weitesten verbreiteten Bibliothek für tabellarische Analysen
Ein von ihm entwickeltes Format kann sich schon früh Vertrauen am Markt sichern, und da er sich dem Problem über lange Zeit mit großer Leidenschaft gewidmet hat, werden seine Einsichten als besonders wichtig angesehen
Auch Andy Pavlo ist erwähnenswert
Als Fan stimme ich der Wirkung von Pandas zu, aber technisch gesehen hatte das Arrow-Datenformat meiner Meinung nach größeren Einfluss auf das gesamte Datenökosystem, zum Beispiel bei DataFusion
Wes McKinney ist auch der Gründer von Apache Arrow
Ich denke, dass gerade seine Arbeit an Parquet zusätzliches Vertrauen schafft
Daten und Code zu vermischen, ist ein klassischer Sicherheitsfehler
Für die Zukunft der Physiker scheint das nicht zu gelten
In den nächsten 20 Jahren werden die Exabyte-Daten, die am Large Hadron Collider des CERN erzeugt werden, in einem von CERN selbst entwickelten Format gespeichert
Material zum CERN-Datenformat
CERN arbeitet in diesem Bereich schon viel länger mit großen Datenmengen als die meisten anderen
Ich hoffe, man verzeiht mir, dass ich den Unterschied zu spaltenorientierter Speicherung nicht ganz verstehe
Ich frage mich, warum das revolutionär sein soll. Geht es im Kern darum, „eine kleine Vektor-Embedding-Datenbank zusammen mit einer Sandbox zu übertragen“?
Das Paper vermittelt den Eindruck, eine neue Grundlage zu sein, und selbst der Projektname hat irgendwie eine französische Aura(?)
Ich verstehe den Großteil des Inhalts nicht, aber die Abbildungen und Farben wirken hübsch und mutig. Als jemand, der leicht zu überzeugen ist, gebe ich zwei Daumen hoch
Der Kern ist die Kompatibilitätsschicht
Der eigentliche Vorteil spaltenorientierter Speicherung ist, dass sich komplexe verschachtelte Schemata in primitive Werte zerlegen und so speichern lassen
Der wahre Gewinn spaltenorientierter Speicherung besteht darin, dass man eine gesamte Column auf einmal sehr schnell scannen kann
select a where b = 'x'sehr schnellEs ist wirklich enttäuschend, dass ein wasm-Decoder gegenüber nativ 10–30 % langsamer ist
Das heißt letztlich, dass man von Anfang an 10–30 % Performanceverlust in Kauf nimmt und jede künftige Gelegenheit zur Verbesserung des Decoders dauerhaft aufgibt
Auch fortgeschrittene Decoding-Funktionen jenseits von „gesamten Block decodieren und im Speicher ablegen“ kann man dann nicht nutzen
Ich verstehe wirklich nicht, warum man es unbedingt so bauen sollte
Wenn Geschwindigkeit wichtig ist, ist wasm nicht die Lösung, und wenn Geschwindigkeit nicht so wichtig ist, kann man auch bekannte Encodings verwenden
WASM wird als Fallback bereitgestellt
In Teilen stimme ich zu, aber die Sache ist etwas komplizierter
Mir ist die Beziehung zwischen Vortex und F3 nicht ganz klar
Beide sprechen von der Vision, „Encoding-Methoden leicht ergänzen zu können, ohne ein neues Format zu schaffen“
In der Einführung steht, dass die Encoding-Implementierung von Vortex verwendet wird, aber zugleich, dass sich das Typsystem unterscheidet
Der Hintergrund des Projektverlaufs ist kompliziert
Jetzt freue ich mich schon auf die Vorstellung von F4 im nächsten Jahr
Ich habe lange nach dem Quellcode gesucht, aber hier wird er veröffentlicht
Wenn man zum Lesen der Daten zwingend WebAssembly ausführen muss, scheint das für Umgebungen ungeeignet zu sein, in denen man Abhängigkeiten oder Bloat reduzieren möchte
wasm ist einfach
Wenn es einen nativen Decoder gibt, muss man WASM nicht verwenden
Es scheint eines der ersten Dateiformate zu sein, die ein WebAssembly-Modul einbetten
Gerade im Hinblick auf Kompression finde ich das besonders interessant. Wenn man einen WASM-Preprocessor gut entwirft, könnte sich die Kompressionsrate deutlich verbessern
Ich selbst entwickle ebenfalls ein Dateiformat mit diesem Konzept
Alan Kay beschrieb einmal ein bandbasiertes Speichersystem, das vermutlich in den 60ern von einem Programmierer entwickelt wurde, als „erstes objektorientiertes System“