{"id":1321,"date":"2025-10-07T17:17:12","date_gmt":"2025-10-07T15:17:12","guid":{"rendered":"https:\/\/elearningsamba.com\/index.php\/openzl-meta-lance-un-framework-open-source-de-compression-de-donnees-structurees\/"},"modified":"2025-10-07T17:17:12","modified_gmt":"2025-10-07T15:17:12","slug":"openzl-meta-lance-un-framework-open-source-de-compression-de-donnees-structurees","status":"publish","type":"page","link":"https:\/\/elearningsamba.com\/index.php\/openzl-meta-lance-un-framework-open-source-de-compression-de-donnees-structurees\/","title":{"rendered":"OpenZL – Meta lance un framework open source de compression de donn\u00e9es structur\u00e9es"},"content":{"rendered":"

Vous compressez vos fichiers Parquet avec gzip ? \u00c7a marche, c\u2019est trop cooool ! Vos CSV sont en Snappy ? Nickel c\u2019est le bonheur !! Vos
\ntime-series<\/a>
\nsont dans un format custom que personne ne comprend sauf le dev qui est parti y\u2019a deux ans sans laisser d\u2019adresse ? Ah, merde\u2026<\/p>\n

Du coup, combien \u00e7a vous co\u00fbte vraiment ces histoires de compression ? Non, je ne parle pas en octets \u00e9conomis\u00e9s, mais plut\u00f4t en temps humain perdu. Parce que Meta vient de publier un truc super cool qui s\u2019appelle
\n OpenZL<\/a>
\net qui est un framework open source qui r\u00e9v\u00e8le une v\u00e9rit\u00e9 qu\u2019on pr\u00e9f\u00e8re ignorer : ~~Zuck est un reptilien<\/del> euh, non\u2026 utiliser des compresseurs g\u00e9n\u00e9riques pour tout, c\u2019est pratique mais c\u2019est une facture cach\u00e9e qui explose !<\/p>\n~~

H\u00e9 oui car les compresseurs universels comme gzip ou zstd sont g\u00e9niaux, ils fonctionnent partout mais le probl\u00e8me c\u2019est qu\u2019ils ne comprennent rien \u00e0 vos donn\u00e9es. Pour eux, un CSV c\u2019est pareil qu\u2019un JPEG ou qu\u2019un binaire random, du coup, vous obtenez une compression \u201ccorrecte\u201d mais rarement optimale.<\/p>\n

Et vous vous retrouvez alors dans le cycle classique suivant : Un nouveau dataset structur\u00e9, vous tentez gzip, c\u2019est bof. Vous essayez alors un compresseur sp\u00e9cialis\u00e9, mais faut l\u2019int\u00e9grer au pipeline et franchement, la flemme. Et \u00e7a, \u00e7a vous prend combien de temps en vrai ?<\/p>\n

Oui, je sais, vous n\u2019en avez aucune id\u00e9e mais chez Meta, ils ont \u00e9valu\u00e9 \u00e7a en mois de d\u00e9veloppement pour chaque nouveau type de donn\u00e9es. Oui, des mois, pas des jours. Et apr\u00e8s faut maintenir tout \u00e7a, g\u00e9rer les versions, les d\u00e9pendances, les cas particuliers\u2026. bref.<\/p>\n

Meta a donc fait le calcul et
\n le partage ouvertement<\/a>
\n. Ils avaient des centaines de cas d\u2019usage diff\u00e9rents pour la compression de donn\u00e9es structur\u00e9es avec des fichiers Parquet, des CSV, des time-series, des tensors de machine learning, des tables de bases de donn\u00e9es\u2026etc et \u00e0 chaque fois, soit vous prenez gzip et vous laissez de l\u2019espace disque et de la bande passante sur la table, soit vous d\u00e9veloppez un compresseur custom et vous perdez des semaines de dev.<\/p>\n

La solution classique consistait donc \u00e0 multiplier b\u00eatement les compresseurs sp\u00e9cialis\u00e9s. Un pour Parquet avec Snappy, un autre pour les CSV, encore un autre pour les donn\u00e9es num\u00e9riques colonnes\u2026etc et l\u00e0 \u00e7a devient vite le bordel car chaque compresseur a son d\u00e9codeur, sa config, ses quirks. Vous vous retrouvez alors avec une infrastructure de compression qui ressemble \u00e0 un mille-feuille de d\u00e9pendances mais sans le bonheur d\u2019une cr\u00e8me p\u00e2tissi\u00e8re de qualit\u00e9.<\/p>\n

C\u2019est l\u00e0 qu\u2019OpenZL d\u00e9barque avec une approche totalement diff\u00e9rente puisqu\u2019au lieu de cr\u00e9er encore un \u00e9ni\u00e8me compresseur sp\u00e9cialis\u00e9,
\n ils ont fait un framework<\/a>
\nqui comprend la structure de vos donn\u00e9es et g\u00e9n\u00e8re automatiquement la meilleure strat\u00e9gie de compression.<\/p>\n

Donc en gros, vous donnez \u00e0 OpenZL une description de la structure de vos donn\u00e9es via leur Simple Data Description Language (SDDL). Ensuite leur \u201ctrainer\u201d analyse des \u00e9chantillons et trouve la s\u00e9quence optimale de transformations. Ces transformations r\u00e9v\u00e8lent alors des patterns cach\u00e9s dans vos donn\u00e9es structur\u00e9es, ce qui permet ensuite une compression beaucoup plus efficace qu\u2019un compresseur g\u00e9n\u00e9rique aveugle.<\/p>\n

Faut voir OpenZL comme un genre de compilateur en fait. Vous lui donnez une description haut niveau de vos donn\u00e9es, et il g\u00e9n\u00e8re un \u201cplan de compression\u201d optimis\u00e9 pour ce type pr\u00e9cis de donn\u00e9es. Un peu comme un compilateur transforme du code haut niveau en binaire optimis\u00e9.<\/p>\n

Et le plus beau c\u2019est que tous les fichiers compress\u00e9s par OpenZL, m\u00eame avec des configs compl\u00e8tement diff\u00e9rentes, se d\u00e9compressent avec le m\u00eame binaire. Comme \u00e7a c\u2019est fini le casse-t\u00eate des multiples d\u00e9codeurs \u00e0 maintenir. L\u00e0 vous avez un seul ex\u00e9cutable \u00e0 d\u00e9ployer partout. Bref, c\u2019est surtout \u00e7a la promesse de Meta avec OpenZL.<\/p>\n

Cet outil est en prod chez eux et visiblement,
\n comme ils le racontent sur X<\/a>
\n, il a r\u00e9duit les temps de d\u00e9veloppement de mois \u00e0 jours, pour des gains de compression et de vitesse syst\u00e9matiquement sup\u00e9rieurs aux compresseurs g\u00e9n\u00e9riques. Sur des datasets Parquet par exemple, ils obtiennent des ratios de compression meilleurs que gzip tout en \u00e9tant plus rapides \u00e0 compresser et d\u00e9compresser.<\/p>\n

Pour vous donner un ordre de grandeur, Parquet avec gzip c\u2019est d\u00e9j\u00e0 2.37 fois plus compact qu\u2019un CSV classique. OpenZL lui, va encore plus loin en exploitant les r\u00e9gularit\u00e9s intrins\u00e8ques des donn\u00e9es colonnes tels que des types \u00e9num\u00e9r\u00e9s, des contraintes de range, des patterns temporels dans les time-series et c\u2019est \u00e7a qui fait la diff\u00e9rence entre un compresseur qui voit des bytes et un qui comprend la structure.<\/p>\n

Meta consid\u00e8re le core d\u2019OpenZL comme production-ready et l\u2019utilisent en interne \u00e0 large \u00e9chelle depuis un petit moment. Maintenant si \u00e7a vous int\u00e9resse pour vos propres projets, sachez que le framework est sous licence BSD et dispo sur
\n GitHub<\/a>
\net vous avez un
\n Quick Start guide<\/a>
\n, de
\n la doc compl\u00e8te<\/a>
\n, et m\u00eame un papier acad\u00e9mique sur
\n arXiv<\/a>
\nsi vous voulez plonger dans les d\u00e9tails techniques du mod\u00e8le graph-based qu\u2019ils utilisent.<\/p>\n

Voil\u00e0, si vous bossez avec des volumes importants de donn\u00e9es structur\u00e9es, si vous en avez marre de bidouiller des configs de compression, ou si vous voulez juste arr\u00eater de payer la facture cach\u00e9e des compresseurs universels, allez voir
\n OpenZL sur GitHub<\/a>
\n.<\/p>\n

\n Source<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"