OpenZL: ファイル形式を認識できるオープンソース圧縮フレームワーク

• Metaが公開した OpenZL は、構造化データに対して 可逆圧縮 を提供する 新しいオープンソース圧縮フレームワーク で、データ形式を認識して効率的な変換処理を実行
• 各ファイル形式ごとに異なる変換段階を適用するが、すべてのファイルを 単一の汎用デコンプレッサー で展開できるよう設計されている
• 圧縮器にデータ構造を 明示的に渡す ことで変換処理を最適化し、学習済みの 圧縮構成(config) により速度と圧縮率のさまざまなバランスポイントを選択できる
• Meta内部の Managed Compression システムと連携し、データ変化に合わせて 自動再学習と更新 が可能な点が特徴
• 構造が明確なデータセットで高い性能を示し、データセンターの処理効率を改善 しつつ、圧縮エコシステムを単一デコーダーで単純化できる可能性を示している

---

OpenZL 概要

• OpenZL はMetaが公開した フォーマット認識型データ圧縮フレームワーク で、構造化データ向けに 特化した圧縮効率 を提供する
  • データの形式を明示的に伝えると、内部の変換グラフを通じてデータの規則性と反復性を見つけ、より効率的に圧縮する
• Zstandardの後継的な概念として、フォーマット別最適化圧縮の性能と単一実行ファイルの保守性を組み合わせた構造
  • Zstandardはデータセンターで 速度と圧縮率 を同時に満たして大きな飛躍を遂げたが、アルゴリズムの汎用化による 漸進的改善の限界 が存在する
• 構造化データでは一般的な圧縮法より 形状に合わせたカスタム圧縮 のほうが比率と速度の両面で有利
• しかし、各ファイルフォーマットごとに専用の圧縮器/復元器を構築・運用する 負担が大きい
• OpenZLは個別のカスタム圧縮器の性能と 単一バイナリ運用の容易さ を同時に追求している

構造ベースの圧縮方式

• 一般的な圧縮器がデータを推測ベースで処理するのに対し、OpenZLは データ構造を明示的入力として受け取る
  • ユーザーは Simple Data Description Language (SDDL) を通じてデータの形態（行、列、列挙型、ネスト構造など）を記述できる
  • この情報をもとにOpenZLはオフライン学習（トレーナー）によって 最適な変換シーケンス(Plan) を生成する
  • その後、圧縮時にはこのPlanをもとに実際の デコーディンググラフ(Resolved Graph) を作成し、フレームに埋め込む

例: SAO データ圧縮

• Silesia Compression CorpusのSAOファイルを例にすると、OpenZLは各フィールドを分離して 同質的なデータストリーム に変換した後、個別最適化を行う
  • X軸座標(SRA0)は整列傾向があるため デルタ(delta)変換 を適用
  • Y軸座標(SDEC0)は範囲制限を活用して transpose変換
  • 残りのフィールドは固有値数が少ないため tokenize変換 で辞書ベース圧縮を実行
• 結果としてzstd比で 2倍以上の圧縮率 と より高速な速度(340 MB/s) を記録

自動圧縮器生成と学習プロセス

• OpenZLのトレーナーはデータサンプルをもとに 自動で圧縮戦略を探索・学習 する
  • 学習プロセス: describe(SDDL) → train(Plan生成) → compress(グラフ埋め込み) → decode(単一バイナリで復元)
  • コントロールポイント(control points) を使い、ランタイム時点で統計情報に基づいて最適な経路を選択する
  • 新しいPlanを適用しても 既存データはそのまま復号可能 で、後方互換性を維持する

単一デコンプレッサーの利点

• OpenZLはどのフォーマットで圧縮しても 単一のデコンプレッサーバイナリ で復元できる
  • セキュリティと安定性の検証 を一度行えばシステム全体に適用可能
  • デコンプレッサー更新時には、すべての過去データにも 性能向上効果 が適用される
  • 運用の単純化 と フリート全体の一貫性 を確保
  • 複数フォーマットを同時管理しながらも 下位互換性を維持

性能比較結果

• さまざまなデータセットでzstd、xzなどの汎用圧縮器より 高い圧縮率と速度 を達成
  • SAO: 2.06倍の圧縮率、1200 MB/sの復元速度
  • ERA5(数値データ): 同じ時間でより高い圧縮率、または同じ圧縮率でより高速
  • Parquet、CSVデータセットでもフォーマット認識ベースで カスタム最適化が可能
• ただし、テキストベースのような 構造のないデータでは効果が限定的 で、zstdにフォールバックして最低限の性能を保証
• 圧縮率/圧縮速度/復元速度の3軸で多様な組み合わせを選べ、従来圧縮器の「レベル」調整とは異なる柔軟性 を提供

データ進化と自動再学習

• Metaの Managed Compression と連携し、データフォーマット変更時に 自動で圧縮Planを再学習
  • 定期的にサンプリング・評価し、より良いPlanが見つかれば自動更新
  • デコンプレッサーは同一のまま維持され、運用リスクを最小化

オープンソースエコシステムへの参加と今後の方向性

• OpenZLは ベクター、テーブル、ツリー構造データ に適しており、時系列・MLテンソル・データベーステーブルなどで優れた効率を示す
• 構造のないテキスト（例: enwik、dickens など）にはzstdを適用
• 今後の計画:
  • 時系列および格子データ向け変換ライブラリの拡張
  • SDDLのネストデータ表現力強化
  • 自動圧縮器探索器の性能と安定性向上
• コミュニティ参加方法:
  • 公式の OpenZL サイト および GitHub リポジトリ で例や文書を参照可能
  • 新しいデータフォーマットのテストおよびPlan提案
  • C/C++エンジン最適化、新しい変換の追加、ベンチマークへの貢献が可能

結論

• OpenZLは フォーマット認識型圧縮を標準化 しつつ、既存エコシステムを 単一デコーダー中心に統合 できる新しいアプローチ
• Metaはこれによりデータセンター全体の 圧縮効率、速度、保守性 を同時に改善しようとしている

[GN⁺]

Hacker Newsのコメント

• 最近HNのゲノムデータ圧縮の記事（リンク）を見て、OpenZLの話を持ち出すのをずいぶん我慢していた。データに本当に簡単な変換を加えるだけでも圧縮効率を大きく上げられることをよく示した事例で、OpenZLでも内部的にこうした変換を簡単に行える（SDDLを活用）
  • その記事をすぐ思い出した。そこで言及されていた特殊な圧縮器とOpenZLを比較した経験があるか気になる。たとえばGrace Blackwellの2.6Tbp 661kデータセットは微生物ゲノムのベンチマークでは古典的で、Karel BřindaのMiniPhy方式はこれを2.46TiBから27GiB（圧縮率91）まで縮めている。似たような結果が可能なのか知りたい
  • 一般的なゲノム形式（fa, fq, sam, vcf）でのベンチマーク結果を見てみたい。特にnanoporeデータへの適用可能性が気になる。FAST5/POD5の保存が難しく、有用なデータをかなり失っている
  • [0] 記事の作者です。我慢してくれておめでとう、そしてよくやった。ぜひ使ってみたい。fasta圧縮器のトレーニングについて、OpenZLガイド（リンク）以外に追加で助言できることがあるか気になる
• 少し関連する話として、最近F3ファイル形式に関する議論（リンク）があったが、こちらもdecompressorコードをWASMとして埋め込んでフォーマット認識圧縮を可能にしている。F3の主な動機は将来互換性だが、カスタム圧縮アルゴリズムも使える。アプローチはOpenZLと完全に異なり、OpenZLの依存関係もずっと軽い（必要なのはSDDL compiler/runtimeだけ）
  • zpaqもすでに15年間、埋め込みdecompressor機能を備えていたのに言及がなくて残念
  • 圧縮ファイルに実行可能コードを含めると、ウイルスへの脆弱性が高まるのではないかと心配になる
• 本当にかなり良いツールが出てきたことに驚いた。もっとずっと早く登場すべきだったと思う。データコンテナ構造を正しく把握すると重複排除の効率がものすごく上がる。BSD-3-Clauseライセンスで、きれいなC++実装、ドキュメントも素晴らしい。より多くのファイル形式が追加されて発展していくことを期待している
  • ファイル形式特化は以前からあった手法（例: 7-Zipのx86 opcode prefilter、ZPAQのspecialized decoder bytecode埋め込み）だが、OpenZLの実際の実装、データ記述方式、トレーニングシステムは印象的だ
• 自分の理解が正しければ、SDDLでデータ構造を記述すると、圧縮器が各部分に合った最適な圧縮戦略を立てられるようだ。本当にすごそうだし、カスタム形式圧縮のための汎用フレームワークへ発展してほしい
  • その通り！ SDDL（リンク）は、こうしたことをノーコードで行えるツールキットを提供している。機能はまだ限定的だが、今後拡張予定。それまではC++やPythonで直接フォーマットパーサーを作ることもできる。参考までに、このコードが必要なのは圧縮器側だけで、デコンプレッサーはフォーマット非依存で動作する
• このツールはseekable compressionをサポートしているのだろうか
• ドキュメントを見ながら、AIがimhexやKaitaiのような既存技術の説明をどれだけうまくSDDLに変換できるのか気になる。この方法なら良いスキーマをすぐ集められそうだ
  • こういうツールがあること自体初めて知ったが、本当にSDDLへ変換できそうだ。ぜひ確認してみるつもり
• MetaのNimbleにはOpenZL（OSS化前バージョン）がネイティブ統合されていて、非常に大きな恩恵を得ている
  • カラム指向データ形式のバックエンド圧縮はOpenZLと相性抜群だ。圧縮対象データがi64やfloatのような数値だと分かっていれば、Zstandardよりすぐに大きな優位性が出る
• ログデータ（スキーマ未確定のJSONログ）にOpenZLが適しているのか気になる。ログ圧縮ツールを開発中（リンク）
• Non-Linear Compression（非線形圧縮）は以前少しアイデアを持って試してみたことがあるが、あまり先までは進められなかった（リンク）。こうした試みを見るのはとても嬉しい。共有に感謝
• 本当に狂気じみるほど面白そうだ。今晩、大容量CSVでぜひ試してみるつもり
  • 使った感想を共有してくれると嬉しい。OpenZLはもともとMetaの内部利用向けに開発されたが、最近は外部ユーザーでも簡単に使えるよう多くの努力をしている。フィードバック歓迎だ