F3 – Open-Source-Daten-Dateiformat für die Zukunft

• F3 ist ein Daten-Dateiformat, das mit Blick auf Effizienz, Interoperabilität und Skalierbarkeit entwickelt wurde
• Es bietet eine Art der Datenorganisation, die die Layout-Grenzen früherer Generationen von Formaten wie Parquet korrigiert, und bewahrt zugleich Interoperabilität und Erweiterbarkeit durch einen eingebetteten Wasm-Decoder
• Selbstbeschreibende F3-Dateien sind so aufgebaut, dass sie nicht nur Daten und Metadaten, sondern auch die WebAssembly-Binärdatei zum Dekodieren der Daten enthalten
• Der Ansatz, den Decoder in die Datei einzubetten, erfordert minimalen Speicherplatz im Kilobyte-Bereich und ist so konzipiert, dass Kompatibilität auf jeder Plattform gewährleistet ist, auch wenn kein nativer Decoder vorhanden ist
• Es handelt sich um ein Future-proof File Format-Projekt, das eine Datenorganisationsstruktur und eine allgemeine API bereitstellt, damit Entwickler neue Kodierungsverfahren leicht hinzufügen können
• Der aktuelle Stand ist ein Forschungsprototyp, der die Ideen des Papers validiert; für den produktiven Einsatz ist er nicht vorgesehen
• Der Build wurde nur auf Debian 12 auf einer Intel-Maschine getestet; der Build des PoC-Pakets und die Unit-Tests werden mit cargo build -p fff-poc bzw. cargo test -p fff-poc ausgeführt
• Die Definition des Dateiformats basiert auf FlatBuffer; außerdem werden der Hauptcode, die Wasm-Dekodierungsimplementierung sowie Benchmarks und Skripte für die Experimente im Paper bereitgestellt
• Die Lizenz ist die MIT License

[GN⁺]

Hacker-News-Kommentare

• Ich verstehe nicht ganz, warum das so viele Upvotes bekommen hat, und auch die Landingpage ist nicht besonders überzeugend, daher scheint es sinnvoller zu sein, direkt das Paper zu lesen: https://dl.acm.org/doi/epdf/10.1145/3749163
  Es wirkt wie ein spaltenorientiertes Speicherformat, das einige Schwächen von Parquet ausgleichen soll, aber der eigentliche Knackpunkt bei solchen Formaten ist die Kompatibilität, und ein neues Format ist dabei vom ersten Moment an im Nachteil
  Parquet ist allein schon deshalb extrem stark, weil es sich als Erstes breit durchgesetzt hat, und laut dem Paper ist sogar die am häufigsten verwendete Parquet-Version noch immer die älteste von 2013, was bedeutet, dass nicht einmal Parquet Parquet ersetzt hat
  Um das zu übertreffen, bräuchte F3 offenbar sehr starke Ergebnisse, aber danach sieht es nicht aus
  Mein größter persönlicher Kritikpunkt an Parquet, nämlich das Problem eine einzelne Tabelle pro Datei, wird hier auch nicht angegangen, daher wirkt schon der Name etwas übertrieben, und dass man zwar ein Wasm-Binary zum Dekodieren einbettet, zum Parsen dieses Blocks aber trotzdem FlatBuffers braucht, verwässert ebenfalls das Ziel
  Die Hauptleistung scheint ein verbesserter Random Access zu sein, aber spaltenorientierte Speicherung ist ursprünglich entstanden, um auf Random Access zu verzichten und dafür schnelle Analysen zu bekommen, und F3 scheint wegen des Wasm-Decoders eher schnelle Analysen zu opfern, daher ergibt das für mich wenig Sinn

  • Eine einzelne Tabelle pro Datei ist bei Parquet eher eine Erwartung, die Query-Engines an das Dateiformat stellen, als eine Eigenschaft des Dateiformats selbst
    Spark, DataFusion und DuckDB wüssten wahrscheinlich nicht so recht, was sie mit einer Datei mit mehreren Tabellen anfangen sollen
    Parquet macht zwar viele Dinge gut, aber nur weil es zuerst da war, heißt das nicht, dass es für immer das einzige Analyse-Dateiformat sein sollte
    Schnelle Analysen und moderne Machine-Learning-artige Workloads enthalten von Natur aus eine Mischung aus Batch-Scans und Random Access
    Einige der F3-Autoren haben auch ein Paper geschrieben, das die Schwächen von Parquet im Detail behandelt: https://www.vldb.org/pvldb/vol17/p148-zeng.pdf
    Neuere Formate wie Vortex, Lance und F3 versuchen, die in diesem Paper zusammengefassten Probleme zu lösen
    Lance hat einige interessante Ideen, und Vortex ersetzt die Blackbox-Encoder von Parquet durch transparente Encodings und konzentriert sich auf Erweiterbarkeit und Performance
    Dadurch lässt sich der Kompromiss zwischen massivem Dekodieren und elementweisem Dekodieren verringern, sodass man sowohl effiziente Full Scans als auch sehr schnellen Random Access erhält
    LangChain beschreibt zum Beispiel, dass es ein auf Parquet-Dateien basierendes System mit Vortex neu aufgebaut und dabei große Geschwindigkeitsgewinne gesehen hat: https://www.langchain.com/blog/introducing-smithdb
    Zur Einordnung: Ich entwickle selbst an Vortex mit und habe deshalb direkt viel über die Frage „Warum überhaupt ein neues Format bauen?“ nachgedacht
  • Ich halte die Einfachheit von Parquet nicht für einen Nachteil, sondern für einen Vorteil
    Wenn man mehrere Tabellen braucht, kann man einfach mehrere Parquet-Dateien in ein tar packen, und das ist in jeder Sprache mit tar- und Parquet-Bibliotheken leicht lesbar — schön einfach
  • Beim Arbeiten mit Parquet habe ich mir schon einmal ein Format namens .parquetz vorgestellt
    Wenn das eine ZIP-Datei mit mehreren unkomprimierten Parquet-Dateien wäre, könnte man mehrere Tabellen in einer einzelnen Datei transportieren und vermutlich auch per Range Requests darauf zugreifen
  • Im Vergleich zu den meisten Landingpages heutzutage, die mit ChatGPT erzeugtem Rauschen vollgestopft wirken, ist das hier fast schon eine angenehme Abwechslung

• Dass man nicht von sprachspezifischen SDKs oder Bibliotheken abhängt und stattdessen, falls nichts vorhanden ist, auf eine eingebaute Wasm-Methode zurückfallen kann, ist ziemlich clever
  „Jede selbstbeschreibende F3-Datei enthält nicht nur Daten und Metadaten, sondern auch ein WebAssembly- (Wasm-) Binary zum Dekodieren der Daten. Der zusätzliche Speicherbedarf für einen eingebetteten Decoder pro Datei ist gering (im Kilobyte-Bereich) und stellt die Kompatibilität auf allen Plattformen sicher, auch wenn kein nativer Decoder vorhanden ist.“

  • Heißt das, ein Angreifer müsste nicht einmal absichtlich eine beschädigte Datei erzeugen, sondern könnte den Angriffscode direkt in die Datendatei selbst packen?
  • Klingt cool, aber bei Formaten mit hoher Komplexität könnte das auseinanderfallen
    Wie würde wohl ein eingebetteter Decoder für PDF aussehen?
    Da er eng an die Bytes der Datei gekoppelt wäre, könnte der Dateiersteller zwar auswählen, welches Format sinnvoll ist, aber es gibt nicht für jedes Format einen einzigen „richtigen Dekodierungsschritt“
  • Ich verstehe nicht, wie das funktionieren soll
    Wogegen dekodiert der Decoder eigentlich?
    Das hängt doch vollständig von der Datenart ab: Manche Formate sind Byte-Streams, andere eine 2D-Pixelebene, wieder andere brauchen Vertices, eine 2D-Pixelebene und UV-Maps, und in manchen Fällen ist ein Objektgraph die natürlichere Darstellung
  • Sieht aus wie die Rückkehr der Applets
  • Was ist der Vorteil von Wasm gegenüber C-Bindings?

• Ich verstehe nicht, worüber die Leute hier überhaupt reden
  Im README steht fast nichts dazu, was das ist oder welches Problem es lösen soll; ich sehe dort im Wesentlichen nur eine Erklärung zu FlatBuffers und Links zu Quellcode-Verzeichnissen
  Fehlt mir irgendein Kontext?

  • Es gibt ein verlinktes Paper: https://dl.acm.org/doi/epdf/10.1145/3749163

• Es scheint etwas mehr „Warum“ nötig zu sein
  Es heißt, die Nachteile von Parquet würden überwunden, aber ich würde gern wissen, welche Nachteile das genau sind
  Breite Tool-Unterstützung ist es sicher nicht
  Warum sollte man Parquet oder ORC verlassen und diese Struktur verwenden?

  • Das „Warum“ ist mit den Literaturhinweisen am Ende der README verknüpft, und es wirkt nicht so, als sei dieses Repository dafür gedacht, isoliert konsumiert zu werden
    Am besten schaut man zuerst ins Paper: https://doi.org/10.1145/3749163
  • Ich wusste anfangs überhaupt nicht, worum es geht, aber es gibt gute Punkte dazu, dass Parquet die Hardware nicht besonders gut berücksichtigt und dass die Metadaten eher global sind
    Diesen Artikel fand ich interessant: https://medium.com/@reliabledataengineering/f3-the-future-pr...
  • Ein großer Teil davon ließe sich vermutlich auch beheben, wenn man mehr Entwicklungszeit in Parquet investieren würde
  • Im Paper werden Parquet, ORC, Nimble, Lance, TSFile, Bullion, BtrBlocks erwähnt

• Manche nannten es genial, aber wenn ich den nervigen HN-Skeptiker spiele, wirkt es etwas töricht
  Ein Datenkompressionsformat ist zweitrangig im Vergleich zu dem, was man nach dem Dekodieren mit den Daten machen will
  Audiodateien und SVG-Bilder sind völlig verschieden, und nur weil es eine eingebaute VM gibt, die Video in rohe Pixel dekodiert, kann ein Texteditor dieses Video noch lange nicht abspielen; grundsätzlich entsteht dadurch also keine neue Interoperabilität
  Für jedes neue Format braucht man weiterhin formatspezifische Verarbeitung
  Wenn man zum Beispiel eine Videokompression entwickelt, die besser ist als H.265, aber nicht von allen Plattformen unterstützt wird, dann könnte ein eingebauter Decoder immerhin dazu dienen, die Wiedergabe auf älterer Hardware zu ermöglichen
  Aber genau daran zeigt sich auch die Schwäche. Es ist unwahrscheinlich, dass alte Hardware zukünftige Videoformate per Software-Dekodierung gut bewältigt, und selbst wenn diese Idee schon in den 1990ern aufgekommen wäre, hätte man damit auf einem i386 wohl trotzdem kein Netflix schauen können
  Ebenso bezweifle ich, dass sich damit Word-2021-Dateien in Word 97 öffnen ließen, denn zwischen den Datenstrukturen gibt es keine 1:1-Entsprechung
  Wenn diese Kompatibilität also kein klarer Sieg ist, verstehe ich nicht, was das Ziel sein soll
  Die Nachteile liegen auf der Hand. Wenn im Decoder ein zu behebender Bug steckt, wie patcht man dann alle Dateien, die diesen Decoder bereits eingebettet haben?
  Dazu kommen Größen-Overhead und Sicherheitsrisiken, und man vergrößert die erhebliche Angriffsfläche aller Formatparser, also mehr Möglichkeiten für Remote Code Execution, Ressourcenerschöpfungsangriffe usw.
  Es ist nicht immer der falsche Ansatz, aber entscheidend ist, worin der Gewinn besteht

  • Ich glaube, ich bin dem Problem, das diese Formatfamilie löst, bisher einfach noch nicht begegnet
    Wenn man nach spaltenorientierten Speicherformaten sucht, sind Vor- und Nachteile inzwischen recht gut zusammengefasst
    Natürlich nicht für Videodekodierung

• Ein Vorteil mancher moderner Formate ist, dass Tools sie mit sehr hoher gefühlter Geschwindigkeit lesen können
  DuckDB kann zum Beispiel beim Lesen seines eigenen nativen Formats oder von Parquet allerlei Optimierungen anwenden
  Aber ich bin mir nicht sicher, ob man solche Optimierungen noch effektiv anwenden kann, wenn man zum Verständnis des Formats erst einmal einen Wasm-Blob ausführen muss
  Ob SIMD oder nicht: Wenn man die Daten einmal komplett durchläuft und dieser Durchlauf die Query nicht versteht, hat man womöglich schon verloren
  Ich habe nur den Anfang des Papers überflogen, vielleicht ist das tatsächliche Format also weniger allgemein, als es klingt

  • So wie ich es verstehe, ist es ein Fallback-Mechanismus

• Ich kann mir bis zu einem gewissen Grad vorstellen, dass es selbstentpackende EXEs ersetzt, aber ein wesentlicher Grund für die Wahl eines bestimmten Dateiformats sind die konkreten Funktionen, die dieses Format bietet
  Ein selbstbeschreibendes System kann in denselben Zustand geraten wie andere Formate: „zu viele konkurrierende Features, und niemand unterstützt sie alle“
  Kann diese Datei zum Beispiel effizient per mmap eingebunden werden?
  Wenn intern tar nachgeahmt wird, vielleicht, aber bevor man es ausführt, weiß man es nicht
  Kann man zu einer bestimmten Byte-Position springen und nur einen Teil dekomprimieren?
  Vielleicht wird nur eine Vorabversion der ISO-36898533-Navigation unterstützt, und die verwendete Dateibibliothek hat diese Unterstützung schon vor 6 Jahren entfernt
  Wenn man 1 MB in der Mitte neu schreibt, muss dann nur die betreffende Seite auf der Platte geändert werden, oder muss alles neu geschrieben werden?
  Vielleicht unterstützt der Wasm-Blob dafür 97 APIs, von denen 35 nur umbenannte Duplikate sind und am Ende größer als die Daten selbst wurden, aber niemanden hat es interessiert
  Am Ende gibt es vielleicht nur 19 real erkennbare Optionen, von denen die native Wasm-Beschleunigung der CPU nur zwei oder drei abdeckt, sodass man den Code immer noch stark spezialisieren muss
  Bei *.tar.gz kann man zumindest ungefähr ahnen, was möglich ist

• Gut. Die Welt braucht immer bessere Datenformate
  Ich denke nur, die README würde mehr Interesse wecken, wenn dort die Vorteile gegenüber Parquet und anderen Dateiformaten direkt genannt würden
  Wer https://github.com/future-file-format/f3 aufruft, sollte sehen können, warum man es ausprobieren sollte
  Stellt Vorteile und Kennzahlen hinein; bei den Kennzahlen kann man sich meinetwegen auch die vorteilhaften heraussuchen
  Möglicherweise gibt es gute Einsatzfälle, aber nach der aktuellen README ist nicht klar, wer es warum nutzen sollte

• Wenn ich Daten im PB-Bereich über mehr als 10 Jahre aufbewahre, möchte ich mich nicht darauf verlassen, dass es in Zukunft noch einen Wasm-Interpreter gibt und dass er schnell genug ist, um die Dateien zu lesen
  Ich will eine einfache, gut dokumentierte Byte-Spezifikation wie bei Parquet
  Außerdem bedeutet es, die Dekodierlogik in ein Wasm-Binary zu packen, einer Sache, die eigentlich Cold Storage sein sollte, eine aktive Ausführungsschicht hinzuzufügen

  • Das WinRAR-Format enthält ebenfalls RAR-VM-Bytecode als Teil des Archivs, um bei Mediendateien modernere Kompression zu erreichen
    Das läuft in einer Sandbox und wurde breit akzeptiert; Wasm hat dieselbe Sandbox-Fähigkeit
    Für Langzeitarchivierung könnte das sogar besser sein
    Man muss das Entpackprogramm nicht separat mitführen, weil es schon in der Archivdatei selbst steckt
  • Meinst du, dass du nicht jedes Mal eine 10 Jahre alte, maßgeschneiderte Daten-Parsing-Funktion ausführen willst, wenn du einen einzelnen Datensatz liest?

• Wenn das Decoding fehlschlägt, macht mir Sorgen, dass ich dann von jemand anderem eingebrachtes Wasm debuggen muss und darin beliebige Bugs stecken könnten
  Es könnte helfen, wenn es eine standardisierte Decoder-Bibliothek gäbe, die vom Projekt gepflegt und getestet wird, aber ich bin mir nicht sicher, ob das den Vorteil der Flexibilität, den dieser Ansatz bietet, zunichtemachen würde

  • Da Wasm deterministisch ausgeführt wird, hätte es auf der Seite des Erstellers ebenfalls fehlschlagen müssen, wenn das Decoding bei mir fehlgeschlagen ist
    Das heißt, das Problem wurde nicht neu von meinem System erzeugt, und sie sollten es unabhängig von irgendeinem Client reproduzieren können