F3 - Un format de fichier de données open source pour l’avenir

• F3 est un format de fichier de données conçu en privilégiant l’efficacité, l’interopérabilité et l’extensibilité
• Il propose une méthode d’organisation des données qui corrige les limites de mise en page des formats de génération précédente comme Parquet, tout en conservant l’interopérabilité et l’extensibilité grâce à des décodeurs Wasm intégrés
• Les fichiers F3 auto-descriptifs embarquent non seulement les données et les métadonnées, mais aussi le binaire WebAssembly permettant de décoder les données
• L’approche consistant à intégrer le décodeur dans le fichier ne nécessite qu’un espace de stockage minimal de l’ordre du kilooctet et vise à garantir la compatibilité sur n’importe quelle plateforme, même en l’absence de décodeur natif
• Il s’agit du projet Future-proof File Format, qui fournit une structure d’organisation des données et une API générique pour permettre aux développeurs d’ajouter facilement de nouveaux modes d’encodage
• Son état actuel est celui d’un prototype de recherche validant les idées de l’article, et son usage en production est déconseillé
• La compilation n’a été testée que sur Debian 12 sur machine Intel, et la construction du package PoC ainsi que les tests unitaires s’exécutent via cargo build -p fff-poc et cargo test -p fff-poc
• La définition du format de fichier repose sur FlatBuffer, et le projet fournit également le code principal, l’implémentation du décodage Wasm, ainsi que les benchmarks et scripts utilisés pour les expériences de l’article
• La licence est la MIT License

[GN⁺]

Commentaires sur Hacker News

• Je ne vois pas très bien pourquoi cela a reçu autant de recommandations, et la landing page n’est pas terrible, donc il vaut sans doute mieux lire l’article : https://dl.acm.org/doi/epdf/10.1145/3749163
  Cela ressemble à un format de stockage orienté colonnes qui cherche à corriger certaines limites de Parquet, mais le véritable critère décisif pour ce type de format, c’est la compatibilité, et un nouveau format est désavantagé sur ce point dès son apparition
  Parquet est déjà trop fort rien que parce qu’il a été le premier à se diffuser largement, et d’après l’article, la version de Parquet la plus utilisée reste aussi la plus ancienne, celle de 2013, ce qui signifie qu’en un sens même Parquet n’a pas réussi à remplacer Parquet
  Il semble donc qu’il faille des résultats extrêmement solides pour que F3 surmonte cela, et ce n’est pas l’impression que ça donne
  À titre personnel, le point qui me gêne le plus dans Parquet, à savoir le problème d’une seule table par fichier, n’est même pas traité, donc le nom me paraît un peu exagéré, et le fait d’inclure un binaire Wasm pour le décodage tout en exigeant FlatBuffers pour analyser ce bloc brouille aussi l’objectif
  L’apport principal semble être l’amélioration de l’accès aléatoire, mais le stockage orienté colonnes a justement été créé pour renoncer à l’accès aléatoire afin d’obtenir des analyses rapides, et F3 semble sacrifier la rapidité analytique à cause du décodeur Wasm, donc j’ai du mal à comprendre

  • Le fait que Parquet impose une seule table par fichier relève davantage des attentes que les moteurs de requête projettent sur le format de fichier que du format lui-même
    Spark, DataFusion et DuckDB ne sauraient probablement pas trop quoi faire d’un fichier contenant plusieurs tables
    Certes, Parquet fait beaucoup de choses correctement, mais cela ne veut pas dire que, parce qu’il est arrivé en premier, il doive rester pour toujours le seul format de fichier analytique
    Les analyses rapides et les charges de travail modernes liées au machine learning mélangent fondamentalement scans par lots et accès aléatoire
    Certains auteurs de F3 ont aussi rédigé un article qui traite en détail des limites de Parquet : https://www.vldb.org/pvldb/vol17/p148-zeng.pdf
    Des formats récents comme Vortex, Lance et F3 essaient de résoudre les problèmes récapitulés dans cet article
    Lance contient des idées intéressantes, et Vortex remplace les encodeurs boîte noire de Parquet par des encodages transparents en mettant l’accent sur la scalabilité et les performances
    Cela permet de réduire le compromis entre décodage massif et décodage élément par élément, afin d’obtenir à la fois des scans complets efficaces et un accès aléatoire très rapide
    Par exemple, LangChain explique avoir reconstruit avec Vortex un système basé sur des fichiers Parquet et obtenu un important gain de vitesse : https://www.langchain.com/blog/introducing-smithdb
    Pour information, je développe Vortex, donc je me suis moi-même beaucoup posé la question de savoir « pourquoi créer un nouveau format »
  • Je considère que la simplicité de Parquet n’est pas un défaut mais un avantage
    Si l’on a besoin de plusieurs tables, il suffit de regrouper plusieurs fichiers Parquet dans une archive tar, et c’est d’une simplicité élégante, car cela reste facile à lire dans n’importe quel langage disposant de bibliothèques tar et Parquet
  • En travaillant avec Parquet, j’ai déjà imaginé un format appelé .parquetz
    Si c’était un fichier zip contenant plusieurs fichiers Parquet non compressés, on pourrait déplacer plusieurs tables dans un seul fichier et y accéder aussi par requêtes par plage
  • Comparé au bruit généré par ChatGPT qui semble remplir la plupart des landing pages de nos jours, c’est presque un changement bienvenu

• Le fait de ne pas dépendre de SDK ou de bibliothèques propres à chaque langage, avec la possibilité de se rabattre sur une méthode Wasm intégrée en leur absence, est plutôt ingénieux
  « Chaque fichier F3 auto-descriptif contient non seulement les données et les métadonnées, mais aussi un binaire WebAssembly (Wasm) qui décode les données. L’espace de stockage nécessaire pour intégrer un décodeur dans chaque fichier est faible (de l’ordre du kilooctet) et garantit la compatibilité sur toutes les plateformes, même en l’absence de décodeur natif »

  • Donc un attaquant n’aurait même pas besoin de fabriquer délibérément un fichier corrompu, il lui suffirait d’intégrer du code d’attaque directement dans le fichier de données ?
  • Cela semble élégant, mais j’ai l’impression que cela pourrait s’effondrer avec des formats très complexes
    À quoi ressemblerait un décodeur intégré pour un PDF ?
    Puisqu’il est fortement couplé aux octets du fichier, l’auteur du fichier peut certes choisir quel format est raisonnable, mais tous les formats n’ont pas une unique « bonne étape de décodage »
  • Je ne comprends pas comment cela est censé fonctionner
    Avec quoi le décodeur décode-t-il ?
    Cela dépendra entièrement du type de données : certains formats sont des flux d’octets, d’autres des plans de pixels 2D, d’autres encore ont besoin de sommets, d’un plan de pixels 2D et d’une UV map, et dans certains cas un graphe d’objets est plus naturel
  • On dirait le retour des applets
  • En quoi Wasm est-il meilleur que des liaisons C ?

• Je ne comprends pas de quoi les gens parlent
  Le README ne donne quasiment aucune information sur ce que c’est ni sur le problème que cela résout ; je n’y vois qu’une explication de FlatBuffers et des liens vers des répertoires du code source
  Est-ce qu’il me manque un contexte ?

  • Il y a un article lié : https://dl.acm.org/doi/epdf/10.1145/3749163

• Il semble qu’il manque un peu plus de « pourquoi »
  On dit que cela surmonte les inconvénients de Parquet, mais je serais curieux de savoir lesquels
  Ce ne sera certainement pas une large prise en charge par les outils
  Pourquoi faudrait-il abandonner Parquet ou ORC pour cette structure ?

  • Le « pourquoi » renvoie aux références à la fin du README, et il ne semble pas que ce dépôt soit conçu pour être consommé seul
    Mieux vaut commencer par l’article : https://doi.org/10.1145/3749163
  • Au début, je ne comprenais absolument pas de quoi il s’agissait, mais il y a de bons points sur le fait que Parquet prend mal en compte le matériel et que ses métadonnées sont plutôt globales
    J’ai trouvé cet article intéressant : https://medium.com/@reliabledataengineering/f3-the-future-pr...
  • Une bonne partie de cela semble pouvoir être traitée en investissant davantage de temps de développement dans Parquet
  • L’article mentionne Parquet, ORC, Nimble, Lance, TSFile, Bullion, BtrBlocks

• Certains ont dit que c’était génial, mais si je joue l’éternel sceptique de HN, ça me paraît plutôt idiot
  Le format de compression des données est secondaire par rapport à ce que l’on veut faire avec ces données après décodage
  Un fichier audio et une image SVG sont complètement différents, et le fait d’avoir une VM embarquée qui décompresse une vidéo en pixels bruts ne crée pas une interopérabilité fondamentalement nouvelle, pas plus que cela ne permettrait de lire la vidéo dans un éditeur de texte
  Chaque nouveau format nécessite toujours un traitement spécifique au format
  Par exemple, si l’on créait une meilleure méthode de compression vidéo que H.265 mais qu’elle n’était pas prise en charge sur toutes les plateformes, il pourrait y avoir un intérêt à embarquer un décodeur pour la lire sur du matériel plus ancien
  Mais cela montre aussi la faiblesse de l’idée. Il est peu probable qu’un ancien matériel gère correctement par décodage logiciel un format vidéo du futur, et même si cette idée était née dans les années 1990, elle n’aurait sans doute pas permis de regarder Netflix sur un i386
  De la même façon, je doute que cela aurait permis d’ouvrir un fichier Word 2021 dans Word 97, car il n’existe pas de correspondance 1:1 entre les structures de données
  Si cette compatibilité n’est pas une victoire évidente, alors je ne vois pas bien quel est l’objectif
  Les inconvénients, eux, sont clairs. Si un bug du décodeur doit être corrigé, comment patcher tous les fichiers qui embarquent déjà ce décodeur ?
  Il y a aussi un surcoût en taille et des risques de sécurité, puisqu’on ajoute une surface d’attaque considérable à tous les parseurs de formats, avec davantage d’occasions d’exécution de code à distance, d’attaques par épuisement des ressources, etc.
  Ce n’est pas forcément une mauvaise approche dans tous les cas, mais tout dépend du bénéfice apporté

  • J’ai l’impression que vous n’avez pas encore rencontré le problème que cette famille de formats cherche à résoudre
    Si vous regardez les formats de stockage orientés colonnes, leurs avantages et inconvénients sont aujourd’hui assez bien documentés
    Ce n’est évidemment pas fait pour le décodage vidéo

• L’un des avantages de certains formats modernes est que les outils peuvent les lire avec une vitesse perçue très élevée
  Par exemple, DuckDB peut appliquer toutes sortes d’optimisations lorsqu’il lit son propre format natif ou Parquet
  En revanche, je ne vois pas très bien s’il pourra appliquer efficacement ce type d’optimisations à un format qui exige d’exécuter un bloc de Wasm pour en comprendre la structure
  Que ce soit avec ou sans optimisation SIMD, si ce passage ne comprend pas la requête pendant qu’il parcourt les données une première fois, la perte est peut-être déjà là
  Je n’ai parcouru que le début de l’article, donc le format réel est peut-être moins générique qu’il n’en a l’air

  • Si j’ai bien compris, c’est un mécanisme de repli

• J’arrive à imaginer en partie un remplacement des EXE auto-extractibles, mais une grande partie des raisons pour lesquelles on choisit un format de fichier précis tient aux fonctionnalités spécifiques qu’il offre
  Un système auto-descriptif peut très bien tomber dans le même travers que les autres formats : « trop de fonctionnalités concurrentes, et personne ne les prend toutes en charge »
  Par exemple, ce fichier peut-il être mmap de façon efficace ?
  Peut-être, s’il imite tar en interne, mais impossible de le savoir avant de l’essayer
  Peut-on aller directement à un emplacement précis en octets et ne décompresser qu’une partie ?
  Il se peut qu’il ne prenne en charge que la préversion publique de l’exploration ISO-36898533, alors que la bibliothèque de fichiers utilisée a supprimé cette prise en charge il y a 6 ans
  Si l’on réécrit 1 Mo au milieu, suffit-il de modifier les pages concernées sur le disque, ou faut-il tout réécrire ?
  Le bloc Wasm prend peut-être en charge 97 API pour cela, dont 35 ne sont que des copies sous des noms différents ; il est peut-être devenu plus gros que les données elles-mêmes, mais personne ne s’en est soucié
  Au final, il n’y a peut-être que 19 choix réellement identifiables, et l’accélération Wasm native du CPU n’en traite que deux ou trois, ce qui pourrait quand même obliger à fortement spécialiser le code
  Au moins, avec *.tar.gz, on a une idée approximative de ce qui est possible

• C’est bien. Le monde a toujours besoin de meilleurs formats de données
  Cela dit, le README susciterait sans doute plus d’intérêt s’il exposait directement les avantages par rapport à Parquet et aux autres formats de fichiers
  Quand quelqu’un arrive sur https://github.com/future-file-format/f3, il devrait pouvoir voir pourquoi cela vaut la peine d’être essayé
  Mettez en avant les avantages et les métriques, quitte à ne choisir que les métriques favorables
  Il y a peut-être de bons cas d’usage, mais à l’heure actuelle, le README ne dit pas clairement qui devrait l’utiliser ni pourquoi

• Si je stockais des données à l’échelle du PB pendant plus de 10 ans, je n’aurais pas envie de dépendre du fait qu’un interpréteur Wasm existera encore dans le futur et sera suffisamment rapide pour lire les fichiers
  Je préférerais une spécification binaire simple et bien documentée, comme Parquet
  En plus, mettre la logique de décodage dans un binaire Wasm revient à ajouter une couche d’exécution active à ce qui devrait relever du stockage à froid

  • Le format WinRAR inclut lui aussi du bytecode RAR VM dans certaines archives pour atteindre une compression plus récente sur les fichiers multimédias
    C’est sandboxé et largement accepté, et Wasm offre les mêmes capacités de sandbox
    On peut même considérer que c’est mieux pour l’archivage de long terme
    Il n’est pas nécessaire de transporter séparément le programme de décompression, puisqu’il est intégré au fichier d’archive lui-même
  • Vous voulez dire que vous n’auriez pas envie d’exécuter une fonction de parsing de données personnalisée vieille de 10 ans chaque fois que vous lisez un enregistrement de données unique ?

• Si le décodage échoue, il faut déboguer le Wasm ajouté par quelqu’un d’autre, et il est inquiétant de penser qu’il peut contenir des bugs arbitraires
  Il pourrait être utile d’avoir une bibliothèque de décodeur standard maintenue et testée par le projet, mais je ne sais pas si cela tuerait l’avantage de flexibilité qu’apporte cette approche

  • Le Wasm a une exécution déterministe, donc si le décodage a échoué de mon côté, il aurait aussi dû échouer du côté de son auteur
    Autrement dit, ce n’est pas un nouveau problème créé par mon système, et ils devraient pouvoir le reproduire indépendamment de n’importe quel client