- F3 (Future-proof File Format) est un format de stockage colonnaire open source de nouvelle génération, conçu autour de trois principes clés : l’interopérabilité, l’extensibilité et l’efficacité. Il vise à supprimer la nécessité de créer un nouveau format à chaque évolution des environnements de traitement et de calcul des données
- Chaque fichier F3 adopte une structure auto-descriptive (self-describing), intégrant non seulement les données et les métadonnées, mais aussi un décodeur binaire WebAssembly (Wasm), garantissant la compatibilité sur toutes les plateformes même en l’absence de décodeur natif
- Il propose un layout de stockage efficace, incluant des techniques d’encodage modernes (compression en escalier, décodage vectorisé), et améliore les problèmes de layout de Parquet et ORC en séparant les unités d’I/O, d’encodage et de dictionnaire
- Grâce à une API de décodage basée sur des plugins et à un mécanisme d’intégration Wasm, les développeurs peuvent facilement ajouter de nouveaux schémas d’encodage. Tous les fichiers restent lisibles quelle que soit la version de la bibliothèque, ce qui résout les problèmes d’interopérabilité de Parquet
- Les évaluations montrent l’efficacité du layout de stockage de F3 et les avantages du décodage basé sur Wasm. La surcharge de stockage reste négligeable, de l’ordre du kilooctet, et la baisse de performance du décodage Wasm par rapport au natif, de 10 à 30 %, reste acceptable
Contexte et motivation
Les limites des formats colonnaires existants
- Parquet et ORC ont été développés au début des années 2010 pour des systèmes d’analyse de données comme Hive, Impala et Spark, et ont permis le partage de données entre data warehouses et data lakes
- Dix ans plus tard, les recherches montrent que ces formats sont insuffisants pour l’analyse de données moderne, car ils reposaient à l’origine sur des hypothèses dépassées sur les performances matérielles et sur les schémas d’accès des workloads
- Au cours des dix dernières années, les performances du stockage et du réseau ont été multipliées plusieurs fois, contrairement à celles des CPU, si bien que les systèmes sont désormais limités par le calcul plutôt que par l’I/O
- Avec l’essor des data lakes, davantage de données sont stockées sur des stockages cloud à large bande passante mais à forte latence, comme Amazon S3
- Les applications ne stockent plus seulement des données tabulaires avec peu de colonnes. Dans les workloads de ML, il est courant de stocker de très larges tables comptant des milliers de colonnes, des embeddings vectoriels de grande dimension, ainsi que de gros blobs (images, vidéos)
- Les besoins en accès aléatoire et en mises à jour ont également augmenté, mais les formats existants ne sont pas adaptés à ces usages
- Les avancées récentes en compression, indexation et filtrage cherchent à corriger ces défauts, mais les formats de fichiers existants n’ont pas été conçus pour être facilement extensibles
- Même lorsqu’on ajoute de nouvelles fonctionnalités, il existe trop d’implémentations de bibliothèques Parquet et ORC dans trop de langages pour pouvoir compter sur une mise à jour généralisée
- Les systèmes utilisant d’anciennes bibliothèques peuvent ne pas être capables de décoder le contenu des nouveaux fichiers, ce qui pousse la plupart des systèmes à ne prendre en charge que le plus petit dénominateur commun afin d’éviter les problèmes d’interopérabilité
L’émergence de nouveaux formats de fichiers et leurs limites
- Pour dépasser ces limites, de nouvelles propositions de formats de fichiers entièrement repensés ont émergé, comme Meta Nimble, Lance, TSFile, Bullion et BtrBlocks
- Mais eux aussi reproduisent les mêmes erreurs que leurs prédécesseurs
- Ils sont conçus à partir d’hypothèses sur le matériel et les workloads actuels
- Ils ne favorisent pas une extensibilité simple permettant d’ajouter de nouvelles fonctionnalités sans casser l’interopérabilité avec les déploiements existants
- Même si l’un d’eux remplaçait Parquet ou ORC comme format dominant, le même problème réapparaîtrait dans dix ans : il faudrait encore créer un nouveau format pour corriger ses limites
L’approche de F3
- F3 vise à atteindre simultanément interopérabilité, extensibilité et efficacité
- Son cœur repose sur la définition de trois spécifications :
- Les métadonnées du contenu du fichier
- Le layout de regroupement physique des données encodées dans le fichier
- Une API d’accès aux données indépendante du schéma d’encodage des données
- Le schéma de métadonnées de F3 minimise les données nécessaires pour récupérer un sous-ensemble de colonnes d’une table
- F3 supprime le concept global de row group de Parquet et résout les problèmes de layout en séparant les unités d’I/O, d’encodage et de dictionnaire
- Il intègre également des méthodes modernes comme la compression en escalier et le décodage vectorisé
Vue d’ensemble de F3
Structure générale
- Un fichier F3 se compose d’une partie métadonnées et d’une partie données
- Partie métadonnées : OptionalData (OptData), Column Metadata (ColMetadata), Footer, Postscript
- Partie données : composée de Row Groups (RG), qui contiennent les données réelles
- F3 adopte le même layout PAX que Parquet et ORC
- Mais F3 s’en distingue sur plusieurs points essentiels :
- Les métadonnées éliminent la surcharge de désérialisation (un problème de Parquet/ORC)
- L’unité d’I/O physique (IOUnit) est séparée du row group logique, ce qui permet d’ajuster indépendamment la taille des IOUnit selon le support de stockage
- La portée de l’encodage par dictionnaire est dissociée du row group logique, ce qui permet de choisir la portée la plus efficace pour chaque colonne
- Chaque IOUnit est composée de plusieurs Encoding Units (EncUnit), qui constituent l’unité minimale d’encodage et de décodage
Mécanismes d’interopérabilité et d’extensibilité
- F3 expose une API publique qui définit comment une implémentation doit décoder les données compressées présentes dans le fichier
- Les méthodes d’encodage sont traitées comme des plugins, pouvant être installés et mis à jour séparément de la bibliothèque principale
- Pour garantir que toutes les versions des bibliothèques puissent lire tous les fichiers, l’implémentation du décodeur est embarquée directement dans le fichier sous forme de binaire WebAssembly (Wasm)
- Autrement dit, chaque fichier F3 contient à la fois les données et le code nécessaire pour les lire
- L’API de F3 ne nécessite pas d’implémentation distincte pour le code natif et pour la version Wasm : le même code est compilé sans modification vers les deux cibles
- Cette conception rend F3 pérenne, évite les problèmes décrits plus haut et permet une évolution plus rapide que les solutions existantes
- Les développeurs peuvent déployer de futures méthodes d’encodage dans des systèmes de production en incluant le code Wasm dans le fichier, sans se soucier des mises à niveau de version des bibliothèques sur l’ensemble de la flotte
- La surcharge de stockage des binaires Wasm reste minime (de l’ordre du kilooctet), et la baisse de performance du décodage Wasm par rapport à une implémentation native reste faible (10 à 30 %)
Conclusion
- F3 est un format de fichier colonnaire de nouvelle génération qui atteint simultanément interopérabilité, extensibilité et efficacité
- Son design de layout efficace corrige les inefficacités des formats existants
- Grâce à une API de décodage basée sur des plugins et à l’intégration de Wasm, il fournit un mécanisme pérenne permettant de lire tous les fichiers quelle que soit la version de la bibliothèque
- L’évaluation du prototype démontre l’efficacité du design du layout et le caractère pratique du mécanisme Wasm
- La surcharge liée à Wasm reste dans une plage acceptable : quelques kilooctets de stockage et une baisse de performance de 10 à 30 %
1 commentaires
Avis sur Hacker News
Après un rapide coup d’œil, j’ai l’impression que beaucoup des défauts de Parquet ont été corrigés, donc j’en attends beaucoup
Les métadonnées de Parquet sont basées sur Thrift, mais il n’y a en pratique que des commentaires du type « si ce champ est présent, alors tel autre doit aussi l’être », sans vraie logique de validation, donc j’ai l’impression qu’un Thrift invalide peut casser le lecteur
Les métadonnées de Parquet doivent être parsées, ce qui entraîne des allocations de buffers et des allocations dynamiques répétées pour le parsing, donc énormément d’allocations sur le heap. Ce nouveau format, qui adopte l’approche Flatbuffers, résout ce problème car il peut interpréter directement les octets Flatbuffer
L’encodage me semble bien plus puissant. On dirait qu’il devient possible d’utiliser des encodages légers et composables que le secteur des bases de données défend depuis longtemps. Des formats existants comme BtrBlocks ou FastLanes étaient supérieurs à Parquet, donc c’est bien de voir leurs bonnes idées reprises
Le record-shredding de Dremel dans Parquet était trop complexe à mon goût, donc tant mieux s’il disparaît ici
Dans Parquet, comme le nombre de lignes dans une DataPage varie, il faut scanner tout le ColumnChunk pour trouver une ligne donnée, alors qu’avec ce format on peut sauter directement à la DataPage voulue (IOUnit)
Ils ont supprimé la compression lourde et n’ont gardé que Delta/Dictionary/RLE. La compression lourde n’apporte pas de gain réel, complique l’implémentation et ajoute beaucoup de dépendances externes
Globalement, c’est une avancée impressionnante. J’espère que ce format s’imposera dans l’industrie de l’analyse de données
Si par compression lourde on entend zstd ou brotli, c’est pourtant très utile sur des colonnes de chaînes avec peu de répétitions
L’ajout d’un compilateur wasm peut au contraire introduire encore plus de dépendances qu’une compression « heavy »
Discussion StackOverflow sur l’ajout de colonnes à un fichier Parquet
De nos jours, on dirait que les méthodes de compression se sont standardisées autour de zstd, non ?
Parquet est étonnamment complexe. Pour l’utiliser correctement et efficacement, il faut maîtriser beaucoup de détails peu pratiques et mal documentés, donc ce n’est pas simple
Wes McKinney
Pour ceux qui ne connaissent pas Wes McKinney, c’est le créateur de Pandas, la bibliothèque d’analyse tabulaire la plus utilisée en Python
Un format qu’il conçoit peut gagner la confiance du marché très tôt, et comme il s’intéresse à ce problème depuis longtemps, ses intuitions ont un poids particulier
Andy Pavlo mérite aussi d’être mentionné
En tant que fan, je reconnais l’influence de Pandas, mais techniquement, je pense que le format de données Arrow a eu un impact plus grand sur l’ensemble de l’écosystème de la donnée, par exemple avec DataFusion
Wes McKinney est aussi le créateur d’Apache Arrow
Son travail sur Parquet m’inspire même encore plus confiance
Mélanger données et code, c’est une erreur de sécurité classique
Je ne pense pas que cela s’appliquera à l’avenir des physiciens
Les données à l’échelle de l’exaoctet produites au cours des 20 prochaines années par le Large Hadron Collider du CERN utilisent un format développé en interne par le CERN
Documentation sur le format de données du CERN
Le CERN travaille sur les très gros volumes de données depuis bien plus longtemps que la plupart des gens dans ce domaine
Je vous prie de m’excuser si je comprends mal la différence avec le stockage en colonnes
Je me demande pourquoi c’est révolutionnaire : est-ce que l’idée clé est de « transporter une petite base de données vectorielle d’embeddings avec sa sandbox » ?
Le papier m’a donné l’impression de poser une nouvelle base, et même le nom du projet dégage une sorte d’aura française (?)
Je n’ai pas compris la majeure partie du contenu, mais j’ai trouvé les schémas et les couleurs beaux et audacieux. Comme je me laisse facilement convaincre, double pouce levé
Le point clé, c’est la couche de compatibilité
Le vrai avantage du stockage en colonnes, c’est qu’on peut décomposer des schémas imbriqués complexes en valeurs primitives pour les stocker
Le vrai gain du stockage en colonnes, c’est qu’on peut scanner une colonne entière très rapidement d’un seul coup
select a where b = 'x'devient très rapideC’est vraiment dommage qu’un décodeur wasm soit 10 à 30 % plus lent que du natif
Cela revient à accepter dès le départ une perte de performance de 10 à 30 %, tout en renonçant définitivement à toute possibilité d’améliorer le décodeur à l’avenir
On ne peut pas non plus utiliser de fonctions de décodage avancées autres que le « décodage du bloc entier et stockage en mémoire »
Je ne comprends vraiment pas pourquoi ils veulent absolument faire ça
Si la vitesse compte, wasm n’est pas la solution ; et si elle compte peu, alors autant utiliser des encodages bien connus
WASM est fourni comme solution de secours
Je suis d’accord sur certains points, mais la discussion est un peu plus complexe
Je ne comprends pas exactement la relation entre Vortex et F3
Les deux parlent d’une vision où l’on peut ajouter facilement des méthodes d’encodage sans avoir à créer un nouveau format
Dans la présentation, il est dit qu’ils utilisent les implémentations d’encodage de Vortex, mais qu’ils ont un système de types différent
Le contexte du projet est compliqué
Voilà qui me fait déjà attendre l’annonce de F4 l’an prochain
J’ai longtemps cherché où était le code source ; il est publié ici
Le fait qu’il faille obligatoirement exécuter du WebAssembly pour lire les données me fait penser que ce n’est pas adapté aux environnements où l’on cherche à réduire les dépendances ou le bloat
wasm est simple
S’il existe un décodeur natif, il n’y a pas besoin d’utiliser WASM
Cela semble être l’un des premiers formats de fichier à embarquer des modules WebAssembly
Cet aspect m’intéresse particulièrement du point de vue de la compression. Si le préprocesseur WASM est bien conçu, il pourrait améliorer fortement les taux de compression
Moi aussi, je suis en train de créer un format de fichier sur ce concept
Alan Kay a un jour décrit comme « premier système orienté objet » un système de stockage sur bande probablement conçu par un programmeur dans les années 60