OpenZL : un framework open source de compression capable de reconnaître les formats de fichiers

• OpenZL, publié par Meta, est un nouveau framework open source de compression qui fournit une compression sans perte pour les données structurées en reconnaissant leur format afin d’exécuter un processus de transformation efficace
• Il applique des étapes de transformation différentes selon chaque format de fichier, tout en étant conçu pour que tous les fichiers puissent être décompressés avec un unique décompresseur universel
• En transmettant explicitement la structure des données au compresseur, il optimise le processus de transformation et permet de choisir différents compromis entre vitesse et taux de compression via des configurations (config) de compression apprises
• Il se distingue aussi par son intégration avec le système Managed Compression interne de Meta, qui permet un réentraînement et une mise à jour automatiques en fonction de l’évolution des données
• Il affiche de hautes performances sur les jeux de données à structure claire, avec le potentiel d’améliorer l’efficacité de traitement dans les datacenters et de simplifier l’écosystème de compression autour d’un décodeur unique

---

Présentation d’OpenZL

• OpenZL est un framework de compression de données sensible au format publié par Meta, qui offre une efficacité de compression spécialisée pour les données structurées
  • Si l’on indique explicitement le format des données, il exploite son graphe de transformation interne pour repérer les régularités et répétitions et compresser plus efficacement
• Conçu comme un successeur conceptuel de Zstandard, il combine les performances de la compression optimisée par format et la maintenabilité d’un exécutable unique
  • Zstandard a constitué une avancée majeure dans les datacenters en répondant à la fois aux exigences de vitesse et de taux de compression, mais sa nature généraliste impose des limites aux améliorations progressives
• Pour les données structurées, une compression sur mesure adaptée à la forme des données est plus avantageuse que les méthodes généralistes, à la fois en taux de compression et en vitesse
• Mais construire et exploiter un compresseur/décompresseur dédié pour chaque format de fichier représente une lourde charge
• OpenZL cherche à réunir à la fois les performances de compresseurs spécialisés et la simplicité d’exploitation d’un binaire unique

Compression fondée sur la structure

• Là où un compresseur classique traite les données de manière heuristique, OpenZL reçoit explicitement la structure des données en entrée
  • L’utilisateur peut décrire la forme des données (lignes, colonnes, énumérations, structures imbriquées, etc.) via Simple Data Description Language (SDDL)
  • À partir de ces informations, OpenZL génère, via un apprentissage offline (trainer), une séquence optimale de transformations (Plan)
  • Lors de la compression, il construit ensuite le graphe de décodage réel (Resolved Graph) sur cette base et l’intègre dans la frame

Exemple : compression des données SAO

• En prenant comme exemple le fichier SAO du Silesia Compression Corpus, OpenZL sépare chaque champ pour les transformer en flux de données homogènes, puis applique une optimisation spécifique à chacun
  • La coordonnée de l’axe X (SRA0) présente une tendance ordonnée, d’où l’application d’une transformation delta
  • La coordonnée de l’axe Y (SDEC0) exploite une plage de valeurs limitée via une transformation transpose
  • Les autres champs, avec peu de valeurs distinctes, utilisent une transformation tokenize pour une compression fondée sur dictionnaire
• Au final, OpenZL obtient plus du double du taux de compression de zstd, avec une vitesse supérieure (340 MB/s)

Génération automatique du compresseur et apprentissage

• Le trainer d’OpenZL explore et apprend automatiquement des stratégies de compression à partir d’échantillons de données
  • Processus d’apprentissage : describe(SDDL) → train(génération du Plan) → compress(intégration du graphe) → decode(restauration avec un binaire unique)
  • Il utilise des control points pour sélectionner à l’exécution le chemin optimal à partir d’informations statistiques
  • Même si un nouveau plan est appliqué, les anciennes données restent décompressables, ce qui préserve la rétrocompatibilité

Les avantages d’un décompresseur unique

• Quel que soit le format utilisé pour la compression, OpenZL permet la restauration via un unique binaire de décompression
  • Il suffit de ne réaliser qu’une seule fois les vérifications de sécurité et de fiabilité pour les appliquer à l’ensemble du système
  • Lors des mises à jour du décompresseur, les données historiques bénéficient elles aussi des gains de performance
  • Cela garantit la simplicité opérationnelle et la cohérence à l’échelle de toute la flotte
  • Il est possible de gérer simultanément plusieurs formats tout en préservant la compatibilité descendante

Résultats de comparaison des performances

• Sur divers jeux de données, OpenZL atteint un meilleur taux de compression et une meilleure vitesse que des compresseurs généralistes comme zstd ou xz
  • SAO : taux de compression multiplié par 2,06, vitesse de restauration de 1200 MB/s
  • ERA5 (données numériques) : meilleur taux de compression à temps égal, ou vitesse supérieure à taux de compression égal
  • Sur des jeux de données Parquet et CSV aussi, l’approche sensible au format permet une optimisation sur mesure
• En revanche, pour des données sans structure comme le texte, l’effet reste limité, avec repli sur zstd pour garantir un niveau minimal de performance
• Il permet de choisir différentes combinaisons selon trois axes — taux de compression, vitesse de compression et vitesse de restauration — offrant une flexibilité différente du simple réglage de “niveau” des compresseurs traditionnels

Évolution des données et réentraînement automatique

• Grâce à son intégration avec Managed Compression de Meta, OpenZL réapprend automatiquement les plans de compression lorsque le format des données change
  • Des échantillons sont prélevés et évalués périodiquement, puis une meilleure configuration est appliquée automatiquement si elle est trouvée
  • Le décompresseur reste inchangé, ce qui réduit au minimum les risques opérationnels

Participation à l’écosystème open source et orientations futures

• OpenZL est adapté aux données structurées en vecteurs, tableaux et arbres, et montre une excellente efficacité sur les séries temporelles, les tenseurs de ML et les tables de base de données
• Pour les textes sans structure (ex. : enwik, dickens, etc.), il utilise zstd
• Feuille de route :
  • extension de la bibliothèque de transformations pour les séries temporelles et les données maillées
  • renforcement de l’expressivité de SDDL pour les données imbriquées
  • amélioration des performances et de la stabilité de l’explorateur automatique de compresseurs
• Comment participer à la communauté :
  • exemples et documentation disponibles sur le site officiel d’OpenZL et le dépôt GitHub
  • test de nouveaux formats de données et proposition de Plan
  • contributions possibles à l’optimisation du moteur C/C++, à l’ajout de nouvelles transformations et aux benchmarks

Conclusion

• OpenZL propose une nouvelle approche qui standardise la compression fondée sur la reconnaissance du format tout en permettant d’unifier l’écosystème existant autour d’un décodeur unique
• Meta entend ainsi améliorer simultanément l’efficacité de compression, la vitesse et la maintenabilité à l’échelle de ses datacenters

[GN⁺]

Avis Hacker News

• En voyant récemment le billet HN sur la compression des données génomiques (lien), j’ai vraiment dû me retenir de parler d’OpenZL ; c’est un excellent exemple qui montre qu’avec de simples transformations des données, on peut fortement améliorer l’efficacité de compression, et OpenZL permet aussi facilement ce type de transformations en interne (via SDDL)
  • C’est exactement à ce billet que j’ai pensé ; je me demande si quelqu’un a déjà comparé le compresseur spécialisé mentionné là-bas avec OpenZL. Par exemple, le jeu de données Grace Blackwell de 661k pour 2.6Tbp est un classique des benchmarks de génomes microbiens, et l’approche MiniPhy de Karel Břinda le réduit de 2.46TiB à 27GiB (taux de compression 91). Je me demande si des résultats comparables sont possibles
  • J’aimerais voir des benchmarks sur les formats génomiques courants (fa, fq, sam, vcf), en particulier sur les données nanopore. Le stockage FAST5/POD5 est difficile, et on perd beaucoup de données utiles à cause de ça
  • [0] Je suis l’auteur du billet ; bravo d’avoir tenu bon et bien joué. J’ai très envie de l’essayer. Au sujet de l’entraînement d’un compresseur fasta, y a-t-il des conseils supplémentaires au-delà du guide OpenZL (lien) ?
• Dans un registre un peu lié, il y a récemment eu une discussion sur le format de fichier F3 (lien) ; là aussi, on peut faire de la compression consciente du format en embarquant le code du décompresseur en WASM. La motivation principale de F3 est la compatibilité future, mais il permet aussi d’utiliser des algorithmes de compression sur mesure. L’approche est complètement différente de celle d’OpenZL, et les dépendances d’OpenZL sont bien plus légères (seuls le compilateur/runtime SDDL sont nécessaires)
  • Dommage que zpaq ne soit pas mentionné, alors qu’il dispose déjà depuis 15 ans d’une fonction de décompresseur embarqué
  • Je m’inquiète du fait qu’inclure du code exécutable dans un fichier compressé augmente la surface de vulnérabilité aux virus
• Je suis surpris de voir arriver un outil vraiment très bon ; selon moi il aurait dû exister bien plus tôt. Lorsqu’on comprend correctement la structure du conteneur de données, l’efficacité de la déduplication augmente énormément. Licence BSD-3-Clause, implémentation C++ propre, documentation excellente ; j’espère voir davantage de formats de fichiers ajoutés à l’avenir
  • La spécialisation par format de fichier existait déjà auparavant (par ex. le préfiltre d’opcodes x86 de 7-Zip, ou l’embarquement de bytecode de décodeur spécialisé dans ZPAQ), mais l’implémentation concrète d’OpenZL, sa manière de décrire les données et son système d’entraînement sont impressionnants
• Si j’ai bien compris, en décrivant la structure des données avec SDDL, le compresseur peut définir la meilleure stratégie de compression pour chaque partie. Ça a l’air vraiment génial ; j’aimerais que cela puisse évoluer en framework général pour la compression de formats personnalisés
  • Exact ! SDDL (lien) fournit une boîte à outils no-code pour faire ce genre de choses. Les fonctionnalités sont encore limitées pour l’instant, mais il est prévu de les étendre. En attendant, on peut aussi écrire directement des parseurs de format en C++ ou en Python. À noter que ce code n’est nécessaire que du côté du compresseur ; le décompresseur, lui, fonctionne indépendamment du format
• Je me demande si cet outil prend en charge la compression seekable
• En lisant la documentation, je me demande dans quelle mesure l’IA pourrait convertir en SDDL les descriptions de technologies existantes comme imhex ou Kaitai ; avec cette approche, on pourrait sans doute rassembler rapidement de bons schémas
  • Je découvre tout juste l’existence de ces outils, mais oui, cela semble vraiment convertible en SDDL. Je compte absolument vérifier
• Le Nimble de Meta intègre nativement OpenZL (version pré-open source) et en tire de très gros avantages
  • La compression backend des formats de données en colonnes va parfaitement avec OpenZL. Quand on sait que les données à compresser sont des nombres comme des i64 ou des float, on obtient immédiatement un gros avantage par rapport à Zstandard
• Je me demande si OpenZL est adapté aux données de logs (logs JSON sans schéma stabilisé) ; je développe un outil de compression de logs (lien)
• La Non-Linear Compression (compression non linéaire), j’avais eu quelques idées et tenté des choses il y a longtemps sans aller très loin (lien) ; je suis donc très heureux de voir ce type d’essai, merci du partage
• Ça a l’air incroyablement intéressant, au point d’en être fou ; je vais absolument l’essayer ce soir sur de gros CSV
  • Ce serait super d’avoir un retour d’expérience. OpenZL a été développé à l’origine pour un usage interne chez Meta, et récemment beaucoup d’efforts ont été faits pour le rendre facile à utiliser aussi pour des utilisateurs externes. Les retours sont les bienvenus