OpenZL - Meta lance un framework open source de compression de données structurées
Vous compressez vos fichiers Parquet avec gzip ? Ça marche, c’est trop cooool ! Vos CSV sont en Snappy ? Nickel c’est le bonheur !! Vos time-series sont dans un format custom que personne ne comprend sauf le dev qui est parti y’a deux ans sans laisser d’adresse ? Ah, merde…
Du coup, combien ça vous coûte vraiment ces histoires de compression ? Non, je ne parle pas en octets économisés, mais plutôt en temps humain perdu. Parce que Meta vient de publier un truc super cool qui s’appelle
OpenZL
et qui est un framework open source qui révèle une vérité qu’on préfère ignorer : Zuck est un reptilien euh, non… utiliser des compresseurs génériques pour tout, c’est pratique mais c’est une facture cachée qui explose !
Hé oui car les compresseurs universels comme gzip ou zstd sont géniaux, ils fonctionnent partout mais le problème c’est qu’ils ne comprennent rien à vos données. Pour eux, un CSV c’est pareil qu’un JPEG ou qu’un binaire random, du coup, vous obtenez une compression “correcte” mais rarement optimale.
Et vous vous retrouvez alors dans le cycle classique suivant : Un nouveau dataset structuré, vous tentez gzip, c’est bof. Vous essayez alors un compresseur spécialisé, mais faut l’intégrer au pipeline et franchement, la flemme. Et ça, ça vous prend combien de temps en vrai ?
Oui, je sais, vous n’en avez aucune idée mais chez Meta, ils ont évalué ça en mois de développement pour chaque nouveau type de données. Oui, des mois, pas des jours. Et après faut maintenir tout ça, gérer les versions, les dépendances, les cas particuliers…. bref.
Meta a donc fait le calcul et le partage ouvertement . Ils avaient des centaines de cas d’usage différents pour la compression de données structurées avec des fichiers Parquet, des CSV, des time-series, des tensors de machine learning, des tables de bases de données…etc et à chaque fois, soit vous prenez gzip et vous laissez de l’espace disque et de la bande passante sur la table, soit vous développez un compresseur custom et vous perdez des semaines de dev.
La solution classique consistait donc à multiplier bêtement les compresseurs spécialisés. Un pour Parquet avec Snappy, un autre pour les CSV, encore un autre pour les données numériques colonnes…etc et là ça devient vite le bordel car chaque compresseur a son décodeur, sa config, ses quirks. Vous vous retrouvez alors avec une infrastructure de compression qui ressemble à un mille-feuille de dépendances mais sans le bonheur d’une crème pâtissière de qualité.
C’est là qu’OpenZL débarque avec une approche totalement différente puisqu’au lieu de créer encore un énième compresseur spécialisé, ils ont fait un framework qui comprend la structure de vos données et génère automatiquement la meilleure stratégie de compression.
Donc en gros, vous donnez à OpenZL une description de la structure de vos données via leur Simple Data Description Language (SDDL). Ensuite leur “trainer” analyse des échantillons et trouve la séquence optimale de transformations. Ces transformations révèlent alors des patterns cachés dans vos données structurées, ce qui permet ensuite une compression beaucoup plus efficace qu’un compresseur générique aveugle.
Faut voir OpenZL comme un genre de compilateur en fait. Vous lui donnez une description haut niveau de vos données, et il génère un “plan de compression” optimisé pour ce type précis de données. Un peu comme un compilateur transforme du code haut niveau en binaire optimisé.
Et le plus beau c’est que tous les fichiers compressés par OpenZL, même avec des configs complètement différentes, se décompressent avec le même binaire. Comme ça c’est fini le casse-tête des multiples décodeurs à maintenir. Là vous avez un seul exécutable à déployer partout. Bref, c’est surtout ça la promesse de Meta avec OpenZL.
Cet outil est en prod chez eux et visiblement, comme ils le racontent sur X , il a réduit les temps de développement de mois à jours, pour des gains de compression et de vitesse systématiquement supérieurs aux compresseurs génériques. Sur des datasets Parquet par exemple, ils obtiennent des ratios de compression meilleurs que gzip tout en étant plus rapides à compresser et décompresser.
Pour vous donner un ordre de grandeur, Parquet avec gzip c’est déjà 2.37 fois plus compact qu’un CSV classique. OpenZL lui, va encore plus loin en exploitant les régularités intrinsèques des données colonnes tels que des types énumérés, des contraintes de range, des patterns temporels dans les time-series et c’est ça qui fait la différence entre un compresseur qui voit des bytes et un qui comprend la structure.
Meta considère le core d’OpenZL comme production-ready et l’utilisent en interne à large échelle depuis un petit moment. Maintenant si ça vous intéresse pour vos propres projets, sachez que le framework est sous licence BSD et dispo sur GitHub et vous avez un Quick Start guide , de la doc complète , et même un papier académique sur arXiv si vous voulez plonger dans les détails techniques du modèle graph-based qu’ils utilisent.
Voilà, si vous bossez avec des volumes importants de données structurées, si vous en avez marre de bidouiller des configs de compression, ou si vous voulez juste arrêter de payer la facture cachée des compresseurs universels, allez voir OpenZL sur GitHub .