Après dix ans de règne de Parquet, WASM peut-il l’ébranler ?
Vous avez une table Parquet qui existe depuis huit ans, volume ni petit ni grand, environ trois cents Go. Un jour, vous recevez un nouveau besoin : faire des requêtes ponctuelles sur cette table — pas un scan complet, juste extraire quelques dizaines de lignes par clé primaire. Vous essayez, et vous découvrez que Parquet n’est pas incapable de le faire, mais qu’à chaque fois il faut fouiller dans les column chunks des row groups pour trouver les pages cibles, avec une granularité de pages qui se chiffre en centaines de milliers de lignes — le coût I/O ne correspond absolument pas au besoin.
Vous vous dites : les formats de stockage columnar existent depuis plus de dix ans, comment se fait-il qu’ils ne gèrent même pas un accès aléatoire décent ?
C’est précisément le point de départ de F3 (Future File Format), publié par le groupe bases de données de CMU à SIGMOD. Mais c’est aussi précisément ce point de départ qui vient toucher la corde la plus sensible dans la guerre des formats.
Un nouveau format, un vieux problème
Le problème que F3 veut résoudre se résume en une phrase : les formats de stockage columnar existants (Parquet, ORC) sont nés à l’ère Hadoop, leur disposition de stockage et leur mécanisme d’évolution ne sont plus adaptés au matériel et aux charges de travail actuels. La granularité des row groups de Parquet est grossière, la hiérarchie des métadonnées est plate, les encodages de colonnes sont figés dans la spécification — pour qu’un nouvel encodage arrive en production, il faut attendre que tous les readers soient mis à jour. Et l’article de F3 cite un chiffre qui donne à réfléchir : la version de Parquet la plus utilisée aujourd’hui est toujours la v1 de 2013.
Parquet n’a même pas réussi à remplacer Parquet lui-même.
La solution de F3 est une approche sur deux fronts. Au niveau de la disposition, il introduit une structure hiérarchique plus fine : IOUnit (unité de base d’I/O) → EncUnit (unité de base d’encodage, 64K lignes par défaut) → sous-vecteurs EncUnit optionnels. Cette hiérarchie permet au reader de faire une projection plus granuleuse lors de la lecture — vous voulez seulement quelques milliers de lignes d’une colonne ? Parcourez l’index des EncUnit, sautez les blocs non pertinents, c’est fait.
Au niveau de l’extensibilité, l’idée centrale de F3 est d’embarquer le décodeur sous forme de binaire WASM dans le fichier lui-même. Chaque EncUnit peut être marqué d’un identifiant WASM pointant vers un décodeur stocké à la fin du fichier. Si un reader ne reconnaît pas localement cet encodage, il charge simplement le module WASM pour décoder — pas besoin de mettre à jour le reader, pas besoin d’attendre un consensus communautaire. L’article affirme que les décodeurs WASM font quelques Ko, un « coût de stockage négligeable ».
Voilà les deux cartes de F3 : un accès aléatoire plus fin, et contourner l’impasse de compatibilité grâce à WASM.
Ce qu’il y a derrière les chiffres
Les benchmarks de F3 comparent Parquet, ORC, Vortex, Lance et Nimble. Des expériences de l’article, on peut dégager quelques tendances :
- Accès aléatoire : la latence des requêtes ponctuelles de F3 est significativement inférieure à celle de Parquet, surtout dans les scénarios où seules quelques colonnes et peu de lignes sont nécessaires. Ce n’est pas de la magie — la hiérarchie des EncUnit permet naturellement une granularité d’I/O plus fine.
- Taux de compression vs vitesse de décompression : globalement au même niveau que Parquet. F3 utilise par défaut l’encodage Cascade (similaire à l’encodage par défaut de Vortex) pour les EncUnit de 64K lignes, combiné avec la compression Zstd/LZ4. Ni gagnant, ni perdant.
- Surcoût du décodage WASM : utiliser un décodeur WASM est un cran plus lent que le décodage natif, mais l’article s’efforce de démontrer que cet écart reste acceptable. Il faut ici un jugement d’ingénierie : la raison d’être du décodeur WASM est de garantir que « le fichier reste lisible ». C’est un filet de sécurité, pas un accélérateur.
Dans l’ensemble, F3 présente dans les benchmarks une posture de « progrès sur certaines dimensions, pas de défaite globale face à Parquet ». Pour un article SIGMOD, ce résultat est satisfaisant. Pour une guerre de remplacement de format, ce résultat est insuffisant.
La compatibilité : la véritable douve
Le commentaire le plus upvoté de la discussion HN vient de vouwfietsman, qui a dit une chose cruelle mais difficile à réfuter :
Parquet is unfortunately very good just by virtue of being first, and so widely supported.
À quel point la niche écologique de Parquet est-elle solide ? Quelques faits suffisent à le dire : Spark, DuckDB, Pandas, Polars, Snowflake, BigQuery, Redshift Spectrum, AWS Athena, Trino, Presto, ClickHouse (tables externes)… pratiquement tous les outils de données qui ont un nom supportent nativement Parquet. Sa spécification est ouverte, mais après des années de rodage entre plus de vingt implémentations majeures, elle est devenue un standard de fait. Le fichier Parquet que vous générez peut être lu par n’importe quel outil — c’est le produit de dix ans de corrections de bugs et d’adaptations d’interopérabilité par la communauté.
Cela fait émerger un paradoxe : F3 tente de résoudre avec WASM le problème de compatibilité « un nouvel encodage ne peut pas être reconnu par les anciens readers », mais ce qui bloque vraiment un nouveau format, c’est le coût d’adoption par l’écosystème.
Une entreprise qui voudrait passer à F3, que devrait-elle faire ?
- Ajouter un reader F3 à tous les moteurs de requête en aval (le fallback WASM ne peut que décoder un EncUnit, pas remplacer une implémentation complète de reader — parsing d’en-tête, parcours des métadonnées, pushdown de prédicats, élagage de projection, tout cela nécessite du code natif).
- Faire supporter l’écriture F3 par tous les pipelines de données (ETL/ELT).
- Faire en sorte que tous les outils de gouvernance des données (catalogues, registres de schémas, traçabilité de lignage) puissent analyser les métadonnées F3.
- Que les partenaires externes avec qui on partage des données puissent lire le F3.
Ce n’est pas un décodeur WASM qui peut résoudre ça. La douve de Parquet, c’est le tissu écosystémique tissé pendant dix ans.
Les tensions du schéma WASM
Le design WASM de F3 a déclenché une sous-discussion animée sur HN, focalisée sur trois niveaux.
Le premier niveau, c’est la sécurité. Du code exécutable embarqué dans un fichier — même si le bac à sable WASM est mature, cela déclenche naturellement le réflexe sécuritaire des ingénieurs. Certains font l’analogie avec JavaScript dans les PDF — le standard a prévu cette capacité, mais tout visualiseur sensé la désactive par défaut. Les défenseurs de F3 rétorquent que le décodeur WASM n’est qu’une pure function, sans capacité d’I/O, et que le bac à sable peut limiter le nombre d’instructions et la mémoire. Mais les workflows d’ingénierie data impliquent souvent des fichiers de données provenant de sources non fiables, et permettre l’exécution arbitraire de WASM reste une option que beaucoup d’équipes de sécurité n’accepteront pas.
Le deuxième niveau, c’est le positionnement en termes de performance. vouwfietsman le dit avec une acuité chirurgicale : la valeur centrale d’un format de stockage columnar est d’échanger du scan séquentiel contre de la performance analytique, en sacrifiant l’accès aléatoire. F3 met l’amélioration de l’accès aléatoire comme argument de vente principal, mais l’accès aléatoire n’est pas l’objectif de conception du stockage columnar. Si optimiser l’accès aléatoire ralentit le scan complet de table (ne serait-ce que sur le chemin de décodage WASM), c’est troquer un avantage central contre une capacité secondaire.
Le troisième niveau, c’est la cohérence des choix techniques. La couche de métadonnées de F3 utilise FlatBuffers de Google pour sérialiser le schéma et les informations de disposition des fichiers. Le décodeur WASM doit faire passer des données entre le langage hôte et la mémoire WASM, et l’analyse FlatBuffers elle-même a un certain coût. Certains commentateurs estiment qu’introduire la combinaison runtime WASM + sérialisation/désérialisation FlatBuffers revient à ajouter deux couches d’abstraction sur le chemin de lecture — précisément ce que le stockage columnar cherche à réduire autant que possible.
Ces critiques ne signifient pas que la conception de F3 est erronée. Mais elles pointent vers une proposition centrale : F3 tente de résoudre la contradiction secondaire dans l’évolution des formats, pas la contradiction principale. La contradiction principale est « comment faire pour que tout le monde veuille changer », pas « comment faire atterrir un nouvel encodage ».
L’écho de l’histoire
Dans les commentaires HN, certains ont posté le xkcd #927 (« Standards »), d’autres ont évoqué le destin d’OpenDoc — un format de fichier techniquement supérieur mais qui a fini par perdre face aux effets de réseau. D’autres encore pensent qu’il ne faut pas être si pessimiste : si F3 apporte dans certains scénarios de niche une valeur que Parquet ne peut pas fournir (par exemple un stockage de caractéristiques en ligne nécessitant des accès aléatoires fréquents, ou des domaines verticaux nécessitant des encodages personnalisés), il n’a pas besoin de gagner tout le marché, seulement de se stabiliser dans sa propre niche écologique.
J’ai tendance à penser que ces deux jugements ne s’excluent pas mutuellement. L’histoire du remplacement des formats soutient en effet massivement la thèse de la « priorité à la compatibilité », mais il n’y a jamais eu dans l’histoire un design qui « embarque le décodeur dans le fichier ». L’arrivée de WASM a changé la structure de coût du code exécutable multiplateforme — il y a dix ans, embarquer un environnement d’exécution sandboxé dans un fichier était inimaginable, aujourd’hui c’est juste une ligne de wasmtime::Module::new().
F3 ne remplacera probablement pas Parquet, mais le paradigme du décodeur WASM qu’il propose pourrait être absorbé par Parquet ou d’autres formats. La meilleure issue n’est pas le remplacement, c’est la contamination — laisser l’ancien format apprendre tes bonnes idées, et toi, foncer vers le prochain terrain vierge.
Du point de vue des tendances actuelles
F3 reste pour l’instant un prototype de recherche — le README commence par déclarer « ne doit pas être utilisé en production », seulement 4 commits sur GitHub, les scripts de reproduction des benchmarks ne sont pas encore complets. Il lui reste une longue distance d’industrialisation avant de pouvoir être sérieusement évalué comme alternative par des équipes d’ingénierie.
Et du point de vue des tendances de l’industrie, la position de Parquet est quasiment inébranlable à court terme. L’essor des formats de table ouverts comme Iceberg, Delta Lake, Hudi ancre encore plus profondément Parquet dans la couche basse de l’architecture lakehouse — la guerre des formats de table se déplace vers le haut, tandis que le format de fichier en bas se trouve « verrouillé » encore plus fort. Vous n’allez probablement pas changer de format de table ET de format de fichier en même temps, c’est un coût de migration multiplié par deux.
Mais la question posée par F3 est valable. Le goulet d’étranglement de l’évolution de Parquet est réel — la v1 qui n’a pas bougé depuis dix ans domine encore le monde, ce n’est pas un état normal. La piste du décodeur WASM, même si elle ne fait pas aboutir F3, pourrait faire aboutir une future version de spec d’un autre format.
En d’autres termes : ce ne sera pas les funérailles de Parquet, mais c’est peut-être le premier battement de cœur de la prochaine génération de formats de stockage columnar.
Références : Article SIGMOD F3 · Dépôt GitHub · Discussion HN