OpenZL: Open-Source-Kompressions-Framework mit Dateiformaterkennung

• OpenZL, von Meta veröffentlicht, ist ein neues Open-Source-Kompressions-Framework, das verlustfreie Kompression für strukturierte Daten bietet und Datenformate erkennt, um effiziente Transformationsprozesse auszuführen
• Für jedes Dateiformat werden unterschiedliche Transformationsschritte angewendet, ist aber so konzipiert, dass alle Dateien mit einem einzigen universellen Dekompressor entschlüsselt werden können
• Durch die explizite Übergabe der Datenstruktur an den Kompressor wird der Transformationsprozess optimiert, und über gelernte Kompressionskonfigurationen (Configs) lassen sich verschiedene Gleichgewichtspunkte zwischen Geschwindigkeit und Kompressionsrate wählen
• Ein besonderes Merkmal ist die Integration mit Metas internem System Managed Compression, wodurch automatisches Retraining und Aktualisieren entsprechend Datenänderungen möglich sind
• Bei Datensätzen mit klarer Struktur zeigt es hohe Leistung, verbessert dadurch die Verarbeitungseffizienz in Rechenzentren und deutet auf die Möglichkeit hin, das Kompressions-Ökosystem mit einem einzigen Decoder zu vereinfachen

---

Überblick über OpenZL

• OpenZL ist ein von Meta veröffentlichtes formatbewusstes Datenkompressions-Framework, das für strukturierte Daten spezialisierte Kompressionseffizienz bietet
  • Wenn das Datenformat explizit angegeben wird, findet es über einen internen Transformationsgraphen Regelmäßigkeiten und Wiederholungen in den Daten und komprimiert sie dadurch effizienter
• Als Nachfolgekonzept zu Zstandard verbindet es die Leistung formatoptimierter Kompression mit der Wartbarkeit einer einzigen ausführbaren Datei
  • Zstandard brachte in Rechenzentren einen großen Sprung, indem es Geschwindigkeit und Kompressionsrate zugleich erfüllte, hatte jedoch Grenzen für schrittweise Verbesserungen aufgrund der Verallgemeinerung des Algorithmus
• Bei strukturierten Daten ist maßgeschneiderte Kompression passend zur Form gegenüber allgemeinen Kompressionsverfahren sowohl bei Rate als auch Geschwindigkeit im Vorteil
• Allerdings ist der Aufwand groß, für jedes Dateiformat eigene Kompressoren und Dekompressoren zu entwickeln und zu betreiben
• OpenZL verfolgt zugleich die Leistung individueller Spezialkompressoren und die einfache Betriebsführung eines einzelnen Binaries

Strukturbasierter Kompressionsansatz

• Während herkömmliche Kompressoren Daten auf Basis von Vermutungen verarbeiten, erhält OpenZL die Datenstruktur als explizite Eingabe
  • Nutzer können über die Simple Data Description Language (SDDL) die Form der Daten beschreiben, etwa Zeilen, Spalten, Enumerationen oder verschachtelte Strukturen
  • Auf Basis dieser Informationen erzeugt OpenZL per Offline-Training (Trainer) die optimale Transformationssequenz (Plan)
  • Bei der späteren Kompression wird auf Grundlage dieses Plans der eigentliche Decoding Graph (Resolved Graph) erstellt und in den Frame eingebettet

Beispiel: SAO-Datenkompression

• Am Beispiel der SAO-Datei aus dem Silesia Compression Corpus trennt OpenZL die einzelnen Felder, wandelt sie in homogene Datenströme um und optimiert sie jeweils separat
  • Für die X-Achsen-Koordinate (SRA0) wird wegen der Sortierungstendenz eine Delta-Transformation angewendet
  • Für die Y-Achsen-Koordinate (SDEC0) wird unter Nutzung des begrenzten Wertebereichs eine Transpose-Transformation eingesetzt
  • Für die übrigen Felder erfolgt wegen der geringen Zahl unterschiedlicher Werte eine wörterbuchbasierte Kompression mittels Tokenize-Transformation
• Im Ergebnis erreicht es gegenüber zstd eine mehr als doppelt so hohe Kompressionsrate und höhere Geschwindigkeit (340 MB/s)

Automatische Kompressor-Erzeugung und Trainingsprozess

• Der Trainer von OpenZL durchsucht und lernt auf Basis von Datensamples automatisch Kompressionsstrategien
  • Trainingsablauf: describe(SDDL) → train(Plan-Erzeugung) → compress(Graph-Einbettung) → decode(Wiederherstellung mit einem einzelnen Binary)
  • Mit Control Points wird zur Laufzeit auf Basis statistischer Informationen der optimale Pfad gewählt
  • Auch wenn ein neuer Plan angewendet wird, können bestehende Daten weiterhin dekodiert werden, wodurch Rückwärtskompatibilität erhalten bleibt

Vorteile eines einzelnen Dekompressors

• OpenZL kann unabhängig vom verwendeten Kompressionsformat mit einem einzigen Dekompressor-Binary wiederhergestellt werden
  • Sicherheits- und Stabilitätsprüfungen müssen nur einmal durchgeführt werden und lassen sich dann auf das gesamte System anwenden
  • Bei Updates des Dekompressors profitieren auch alle älteren Daten von Leistungsverbesserungen
  • Betriebliche Einfachheit und Konsistenz über die gesamte Flotte werden sichergestellt
  • Auch bei gleichzeitiger Verwaltung mehrerer Formate bleibt Abwärtskompatibilität erhalten

Ergebnisse des Leistungsvergleichs

• Auf verschiedenen Datensätzen werden gegenüber allgemeinen Kompressoren wie zstd oder xz höhere Kompressionsraten und mehr Geschwindigkeit erzielt
  • SAO: 2,06-fache Kompressionsrate, 1200 MB/s Dekompressionsgeschwindigkeit
  • ERA5 (numerische Daten): bei gleicher Zeit eine höhere Kompressionsrate oder bei gleicher Kompressionsrate höhere Geschwindigkeit
  • Auch bei Parquet- und CSV-Datensätzen ist durch Formaterkennung maßgeschneiderte Optimierung möglich
• Bei unstrukturierten Daten wie textbasierten Inhalten ist der Effekt jedoch begrenzt; dann erfolgt ein Fallback auf zstd, um eine Mindestleistung sicherzustellen
• Über die drei Achsen Kompressionsrate/Kompressionsgeschwindigkeit/Dekompressionsgeschwindigkeit lassen sich vielfältige Kombinationen wählen und es bietet eine andere Flexibilität als die klassische „Level“-Steuerung traditioneller Kompressoren

Datenentwicklung und automatisches Retraining

• In Verbindung mit Metas Managed Compression werden bei Änderungen des Datenformats Kompressionspläne automatisch neu trainiert
  • Es wird periodisch gesampelt und evaluiert; wird ein besserer Plan gefunden, erfolgt ein automatisches Update
  • Der Dekompressor bleibt unverändert, wodurch Betriebsrisiken minimiert werden

Beteiligung am Open-Source-Ökosystem und weitere Ausrichtung

• OpenZL eignet sich für Vektor-, Tabellen- und Baumstruktur-Daten und zeigt hohe Effizienz etwa bei Zeitreihen, ML-Tensoren und Datenbanktabellen
• Für unstrukturierte Texte (z. B. enwik, dickens usw.) wird zstd verwendet
• Zukünftige Pläne:
  • Ausbau der Transformationsbibliothek für Zeitreihen- und Gitterdaten
  • Stärkere Ausdrucksfähigkeit von SDDL für verschachtelte Daten
  • Verbesserung von Leistung und Stabilität des automatischen Kompressor-Suchers
• Möglichkeiten zur Beteiligung der Community:
  • Auf der offiziellen OpenZL-Website und im GitHub-Repository finden sich Beispiele und Dokumentation
  • Testen neuer Datenformate und Vorschlagen von Plänen
  • Beiträge zur Optimierung der C/C++-Engine, zu neuen Transformationen und zu Benchmarks sind möglich

Fazit

• OpenZL ist ein neuer Ansatz, der formatbewusste Kompression standardisiert und zugleich das bestehende Ökosystem rund um einen einzelnen Decoder integrieren kann
• Meta will damit Kompressionseffizienz, Geschwindigkeit und Wartbarkeit im gesamten Rechenzentrum gleichzeitig verbessern

[GN⁺]

Hacker-News-Kommentare

• Nachdem ich neulich den HN-Beitrag über die Komprimierung von Genomdaten (Link) gesehen hatte, musste ich mich sehr beherrschen, nicht über OpenZL anzufangen; er zeigt sehr gut, dass schon sehr einfache Transformationen der Daten die Kompressionseffizienz stark verbessern können, und OpenZL kann solche Transformationen intern ebenfalls leicht durchführen (über SDDL)
  • Daran musste ich sofort denken. Mich würde interessieren, ob jemand Erfahrung damit hat, den dort erwähnten Spezialkompressor mit OpenZL zu vergleichen. Zum Beispiel ist der 2.6Tbp/661k-Datensatz von Grace Blackwell ein Klassiker unter den mikrobiellen Genom-Benchmarks, und Karel Břindas MiniPhy-Methode reduziert ihn von 2.46TiB auf 27GiB (Kompressionsrate 91). Ich frage mich, ob ähnliche Ergebnisse möglich sind
  • Ich würde gern Benchmark-Ergebnisse für allgemeine Genomformate (fa, fq, sam, vcf) sehen, insbesondere interessiert mich die Eignung für Nanopore-Daten. Das Speichern von FAST5/POD5 ist schwierig, wodurch viele nützliche Daten verloren gehen
  • [0] Ich bin der Autor des Beitrags; Glückwunsch dazu, dass du dich zurückgehalten hast, und gut gemacht. Ich möchte es unbedingt ausprobieren. Hast du zusätzlich zum OpenZL-Leitfaden zur Kompressor-Trainierung für fasta (Link) noch weitere Tipps?
• Als etwas verwandtes Thema gab es kürzlich eine Diskussion zum F3-Dateiformat (Link); auch dort ist formatbewusste Kompression möglich, indem der Decompressor-Code als WASM eingebettet wird. Die Hauptmotivation von F3 ist Zukunftskompatibilität, aber man kann auch maßgeschneiderte Kompressionsalgorithmen verwenden. Der Ansatz ist völlig anders als bei OpenZL, und OpenZL hat auch deutlich leichtere Abhängigkeiten (es braucht nur den SDDL-Compiler/-Runtime)
  • Schade, dass zpaq nicht erwähnt wurde, obwohl es schon seit 15 Jahren eine eingebettete Decompressor-Funktion hat
  • Ich frage mich, ob das Einbetten von ausführbarem Code in komprimierte Dateien die Anfälligkeit für Viren nicht erhöht
• Ich bin überrascht, dass ein wirklich ziemlich gutes Tool erschienen ist; meiner Meinung nach hätte es viel früher kommen sollen. Wenn man die Struktur eines Datencontainers richtig versteht, steigt die Deduplizierungseffizienz enorm. BSD-3-Clause-Lizenz, eine saubere C++-Implementierung, und die Dokumentation ist ebenfalls hervorragend. Ich hoffe, dass künftig noch mehr Dateiformate hinzukommen
  • Die Spezialisierung auf Dateiformate gab es auch bisher schon (z. B. 7-Zips x86-Opcode-Prefilter, ZPAQs Einbettung spezialisierter Decoder-Bytecodes), aber die konkrete Umsetzung von OpenZL, die Art der Datenbeschreibung und das Trainingssystem sind beeindruckend
• Wenn ich es richtig verstanden habe, kann der Kompressor, wenn man die Datenstruktur in SDDL beschreibt, für jeden Teil eine optimale Kompressionsstrategie festlegen. Das sieht wirklich großartig aus. Ich hoffe, dass sich daraus ein allgemeines Framework für die Kompression benutzerdefinierter Formate entwickeln kann
  • Genau! SDDL (Link) stellt ein No-Code-Toolkit für solche Aufgaben bereit. Der Funktionsumfang ist noch begrenzt, soll aber künftig erweitert werden. Bis dahin kann man Format-Parser auch direkt in C++ oder Python erstellen. Zur Info: Dieser Code wird nur auf der Kompressor-Seite benötigt; der Dekompressor arbeitet formatunabhängig
• Mich würde interessieren, ob dieses Tool seekable compression unterstützt
• Beim Lesen der Dokumentation frage ich mich, wie gut KI bestehende Technikbeschreibungen wie imhex oder Kaitai in SDDL umwandeln könnte. Mit diesem Ansatz ließen sich gute Schemata wohl schnell sammeln
  • Ich wusste gar nicht, dass es solche Tools gibt, aber das scheint sich tatsächlich in SDDL umwandeln zu lassen. Ich werde es auf jeden Fall prüfen
• Metas Nimble hat OpenZL (die Pre-OSS-Version) nativ integriert und erzielt damit sehr große Vorteile
  • Die Backend-Kompression für spaltenbasierte Datenformate passt perfekt zu OpenZL. Wenn man weiß, dass die zu komprimierenden Daten Zahlen wie i64 oder float sind, ergibt sich sofort ein großer Vorteil gegenüber Zstandard
• Ich frage mich, ob OpenZL für Log-Daten geeignet ist (JSON-Logs ohne festgelegtes Schema). Ich entwickle gerade ein Tool zur Log-Komprimierung (Link)
• Non-Linear Compression (nichtlineare Kompression) hatte ich früher mit einigen Ideen kurz ausprobiert, bin aber nicht weit gekommen (Link); deshalb freue ich mich sehr, so einen Versuch zu sehen. Danke fürs Teilen
• Das sieht wirklich wahnsinnig interessant aus, ich werde es heute Abend unbedingt mit großen CSV-Dateien ausprobieren
  • Es wäre toll, von deinen Erfahrungen zu hören. OpenZL wurde ursprünglich für den internen Einsatz bei Meta entwickelt. In letzter Zeit wurde viel Aufwand betrieben, damit es auch für externe Nutzer leicht einsetzbar ist. Feedback ist willkommen