OpenZL: framework de compresión de código abierto con reconocimiento de formatos de archivo

• OpenZL, publicado por Meta, es un nuevo framework de compresión de código abierto que ofrece compresión sin pérdida para datos estructurados, reconociendo el formato de los datos para realizar transformaciones eficientes
• Aplica etapas de transformación distintas para cada formato de archivo, pero está diseñado para que todos los archivos puedan descomprimirse con un único descompresor de propósito general
• Al pasar explícitamente la estructura de los datos al compresor, optimiza el proceso de transformación, y mediante una configuración (config) de compresión entrenada permite elegir distintos puntos de equilibrio entre velocidad y tasa de compresión
• Se integra con el sistema interno de Managed Compression de Meta, y se caracteriza por permitir reentrenamiento y actualización automáticos según cambian los datos
• Muestra alto rendimiento en conjuntos de datos con estructura clara, lo que mejora la eficiencia de procesamiento en centros de datos y sugiere la posibilidad de simplificar el ecosistema de compresión con un único decodificador

---

Resumen de OpenZL

• OpenZL es un framework de compresión de datos con reconocimiento de formato publicado por Meta, que ofrece eficiencia de compresión especializada para datos estructurados
  • Si se indica explícitamente el formato de los datos, encuentra regularidades y repeticiones mediante un grafo interno de transformaciones para comprimir con mayor eficiencia
• Como concepto sucesor de Zstandard, combina el rendimiento de la compresión optimizada por formato con la facilidad de mantenimiento de un solo ejecutable
  • Zstandard logró un gran avance en centros de datos al satisfacer simultáneamente velocidad y tasa de compresión, pero tiene límites de mejora gradual debido a la generalización del algoritmo
• En datos estructurados, la compresión personalizada según la forma de los datos supera a los métodos generales tanto en tasa como en velocidad
• Sin embargo, construir y operar compresores/descompresores dedicados para cada formato de archivo implica una gran carga
• OpenZL busca al mismo tiempo el rendimiento de compresores personalizados individuales y la simplicidad operativa de un solo binario

Método de compresión basado en estructura

• Mientras los compresores convencionales procesan los datos de forma inferida, OpenZL recibe la estructura de los datos como entrada explícita
  • El usuario puede describir la forma de los datos (filas, columnas, enumeraciones, estructuras anidadas, etc.) mediante Simple Data Description Language (SDDL)
  • Con esta información, OpenZL genera una secuencia óptima de transformaciones (Plan) mediante entrenamiento offline (trainer)
  • Luego, al comprimir, crea el grafo de decodificación real (Resolved Graph) sobre la base de ese Plan y lo incrusta en el frame

Ejemplo: compresión de datos SAO

• Tomando como ejemplo el archivo SAO del Silesia Compression Corpus, OpenZL separa cada campo y lo transforma en flujos de datos homogéneos para luego optimizar cada uno por separado
  • La coordenada del eje X (SRA0) tiene una tendencia de ordenamiento, por lo que se aplica una transformación delta
  • La coordenada del eje Y (SDEC0) aprovecha la limitación de rango con una transformación transpose
  • Los demás campos, debido a su bajo número de valores únicos, usan una transformación tokenize para compresión basada en diccionario
• Como resultado, registra una tasa de compresión más de 2 veces superior a zstd y mayor velocidad (340 MB/s)

Generación automática de compresores y proceso de entrenamiento

• El trainer de OpenZL explora y aprende automáticamente estrategias de compresión a partir de muestras de datos
  • Proceso de entrenamiento: describe(SDDL) → train(generación del Plan) → compress(incrustación del grafo) → decode(recuperación con un solo binario)
  • Utiliza control points para elegir en tiempo de ejecución la ruta óptima según información estadística
  • Incluso al aplicar un nuevo Plan, los datos existentes siguen pudiendo descomprimirse, manteniendo compatibilidad hacia atrás

Ventajas de un único descompresor

• OpenZL permite restaurar cualquier formato comprimido con un único binario descompresor
  • Basta con realizar una sola vez la verificación de seguridad y estabilidad para aplicarla a todo el sistema
  • Al actualizar el descompresor, la mejora de rendimiento se aplica también a todos los datos antiguos
  • Asegura simplicidad operativa y consistencia en toda la flota
  • Permite gestionar varios formatos al mismo tiempo manteniendo compatibilidad hacia atrás

Resultados de comparación de rendimiento

• En diversos conjuntos de datos, logra mayor tasa de compresión y velocidad que compresores de propósito general como zstd y xz
  • SAO: tasa de compresión de 2.06x, velocidad de descompresión de 1200 MB/s
  • ERA5 (datos numéricos): mayor tasa de compresión en el mismo tiempo, o mayor velocidad con la misma tasa de compresión
  • En conjuntos de datos Parquet y CSV también permite optimización personalizada basada en reconocimiento de formato
• Sin embargo, en datos sin estructura, como texto, su efecto es limitado y recurre a zstd como fallback para garantizar un rendimiento mínimo
• Se pueden elegir varias combinaciones en los tres ejes de tasa de compresión / velocidad de compresión / velocidad de descompresión, ofreciendo una flexibilidad distinta al ajuste de “niveles” de los compresores tradicionales

Evolución de datos y reentrenamiento automático

• Integrado con Managed Compression de Meta, reentrena automáticamente el plan de compresión cuando cambia el formato de los datos
  • Realiza muestreo y evaluación periódicos, y si encuentra un mejor Plan, lo actualiza automáticamente
  • El descompresor se mantiene igual, lo que minimiza el riesgo operativo

Participación del ecosistema open source y dirección futura

• OpenZL es adecuado para datos estructurados en forma de vectores, tablas y árboles, y muestra una eficiencia destacada en series temporales, tensores de ML y tablas de bases de datos
• Para texto no estructurado (por ejemplo, enwik, dickens, etc.) aplica zstd
• Planes a futuro:
  • Ampliar la biblioteca de transformaciones para series temporales y datos en rejilla
  • Reforzar la capacidad de SDDL para representar datos anidados
  • Mejorar el rendimiento y la estabilidad del explorador automático de compresores
• Cómo participar en la comunidad:
  • En el sitio oficial de OpenZL y el repositorio de GitHub se pueden consultar ejemplos y documentación
  • Probar nuevos formatos de datos y proponer Planes
  • Es posible contribuir con optimizaciones del motor en C/C++, nuevas transformaciones y benchmarks

Conclusión

• OpenZL es un nuevo enfoque que estandariza la compresión basada en reconocimiento de formato y, al mismo tiempo, puede integrar el ecosistema existente alrededor de un único decodificador
• Meta busca con ello mejorar al mismo tiempo la eficiencia de compresión, la velocidad y la mantenibilidad en todo el centro de datos

[GN⁺]

Comentarios de Hacker News

• Viendo la publicación reciente de HN sobre compresión de datos genómicos (enlace), me costó mucho aguantarme las ganas de hablar de OpenZL; es un gran ejemplo de cómo incluso transformaciones realmente simples sobre los datos pueden mejorar muchísimo la eficiencia de compresión, y OpenZL también permite hacer este tipo de transformaciones fácilmente por dentro (usando SDDL)
  • Justo me vino a la mente esa publicación; me pregunto si alguien ha comparado el compresor especializado que se mencionó ahí con OpenZL. Por ejemplo, el dataset 661k de 2.6Tbp de Grace Blackwell es un clásico en benchmarks de genomas microbianos, y el método MiniPhy de Karel Břinda lo reduce de 2.46TiB a 27GiB (ratio de compresión 91). Me da curiosidad si se podrían lograr resultados parecidos
  • Me gustaría ver resultados de benchmarks en formatos genómicos comunes (fa, fq, sam, vcf), y especialmente me interesa si se puede aplicar a datos de nanopore. Almacenar FAST5/POD5 es complicado, así que se está perdiendo mucha data útil
  • [0] Soy el autor de la publicación; felicidades por haberte aguantado y bien hecho. Definitivamente quiero probarlo. Además de la guía de OpenZL sobre entrenamiento de compresores fasta (enlace), me pregunto si hay algún consejo adicional que dar
• En una línea parecida, hace poco hubo una discusión sobre el formato de archivo F3 (enlace); ahí también se puede hacer compresión consciente del formato incrustando código del decompressor en WASM. La motivación principal de F3 es la compatibilidad futura, pero también permite usar algoritmos de compresión personalizados. El enfoque es completamente distinto al de OpenZL, y además las dependencias de OpenZL son mucho más ligeras (solo necesita el compilador/runtime de SDDL)
  • También me da pena que no se mencione zpaq, que ya tenía una función de decompressor embebido desde hace 15 años
  • Me preocupa si incluir código ejecutable dentro de un archivo comprimido no aumenta la superficie de ataque para virus
• Me sorprende que haya salido una herramienta tan buena; siento que debió existir mucho antes. Si entiendes bien la estructura del contenedor de datos, la eficiencia de deduplicación aumenta muchísimo. Implementación limpia en C++ bajo licencia BSD-3-Clause, documentación excelente, y espero que siga avanzando con más formatos de archivo añadidos
  • La especialización por formato de archivo ya existía antes (por ejemplo, el prefilter de opcodes x86 de 7-Zip, o la incrustación de bytecode de decoder especializado en ZPAQ), pero la implementación concreta de OpenZL, su forma de describir los datos y su sistema de entrenamiento son impresionantes
• Si entendí bien, al describir la estructura de los datos con SDDL, parece que el compresor puede definir una estrategia de compresión óptima para cada parte. Se ve realmente genial; ojalá pueda evolucionar hasta ser un framework general para compresión de formatos personalizados
  • ¡Correcto! SDDL (enlace) ofrece un toolkit no-code para hacer este tipo de cosas. Por ahora sus capacidades son limitadas, pero está planeado expandirlas en el futuro. Antes de eso, también se puede crear directamente un parser del formato en C++ o Python. Como referencia, ese código solo se necesita del lado del compresor; el decompresor funciona sin depender del formato
• Me pregunto si esta herramienta soporta seekable compression
• Viendo la documentación, me da curiosidad qué tan bien una IA podría convertir descripciones de tecnologías existentes como imhex o Kaitai a SDDL; con este método parece que se podrían reunir buenos esquemas muy rápido
  • No sabía que existían herramientas así, pero de verdad parece posible convertirlas a SDDL. Definitivamente pienso revisarlo
• Nimble de Meta tiene OpenZL integrado de forma nativa (la versión previa a OSS) y está obteniendo beneficios muy grandes
  • La compresión backend de formatos de datos columnares encaja perfecto con OpenZL. Si sabes que los datos a comprimir son números como i64 o float, ya obtienes una ventaja grande frente a Zstandard
• Me pregunto si OpenZL es adecuado para datos de logs (logs JSON sin esquema definido); estoy desarrollando una herramienta de compresión de logs (enlace)
• Hace tiempo intenté un poco la idea de Non-Linear Compression (compresión no lineal), aunque no llegué muy lejos (enlace); me da mucho gusto ver un intento como este, gracias por compartirlo
• Se ve absurdamente interesante; hoy en la noche definitivamente lo voy a probar con CSVs grandes
  • Estaría bueno que compartieras tu experiencia de uso. OpenZL originalmente se desarrolló para uso interno en Meta, y últimamente han hecho mucho esfuerzo para que también sea fácil de usar para gente externa. Toda retroalimentación es bienvenida