世界を動かす技術を、日本語で。

OpenZL: フォーマット対応のオープンソース圧縮フレームワーク

概要

  • OpenZL は構造化データ向けの 新しいオープンソースロスレス圧縮フレームワーク
  • フォーマット固有の圧縮性能と 単一バイナリによる運用の容易さ を両立。
  • データ構造を明示的に指定し、変換グラフで圧縮最適化 を実現。
  • ユニバーサルデコーダ により、すべてのOpenZLファイルを単一バイナリで復号可能。
  • 柔軟なトレーニングと運用管理で 継続的な最適化と後方互換性 を確保。

OpenZL:構造化データのための次世代圧縮フレームワーク

  • OpenZL は構造化データ向けに設計された ロスレス圧縮フレームワーク
  • フォーマット固有の圧縮性能単一バイナリ運用 の両立。
  • Quick StartガイドGitHubリポジトリ で導入が容易。
  • 圧縮理論の詳細は ホワイトペーパー で解説。
  • 公開リリース により、誰でも利用・検証が可能。

Zstandardからの進化と課題意識

  • Zstandard は高圧縮率とデータセンター向けの高速性で普及。
  • しかし、 汎用手法 では構造化データの圧縮効率に限界。
  • データ特有の構造(カラム、enum、範囲制約、繰り返し)を活かした 専用圧縮 が有利。
  • 専用圧縮は 運用負荷 (複数バイナリ管理、監査、パッチ適用)を増大。
  • OpenZL はこのトレードオフへの解答。

構造の明示と圧縮プロセス

  • 一般的な圧縮器 は一律の処理または推測にリソースを消費。
  • OpenZLデータ構造を明示的に指定 し、可逆変換のシーケンスでパターンを顕在化。
  • ユーザーはプリセットまたは 薄いフォーマット記述 で形状を指定。
  • トレーナー(オフライン最適化コンポーネント) が最適な圧縮設定を自動生成。
  • エンコード時に設定が 具体的なデコードレシピ に解決され、フレームに埋め込まれる。
  • ユニバーサルデコーダ はレシピを直接実行、追加情報不要。

圧縮例:Silesia Corpusのsaoファイル

  • saoファイル は星のレコード配列という明確な構造。
  • OpenZLは ヘッダとテーブル分離、各フィールドを独立ストリーム化
  • 各ストリームに最適な圧縮戦略を適用。
    • SRA0(X軸位置) :インデックスがほぼソート→delta変換で範囲縮小。
    • SDEC0(Y軸位置) :範囲制約を利用し、transposeで高効率化。
    • IS, MAG, XRPM, XDPM :低カーディナリティ→tokenizeで辞書化。
  • 各ストリームは 異なる圧縮グラフ に送信。
  • 主な役割は同質データのストリーム分割、以降はOpenZLが自動処理。

ベンチマーク比較(M1 CPU, clang-17)

| Compressor | zstd -3 | xz -9 | OpenZL | |------------|---------|-------|--------| | Compressed Size | 5,531,935 B | 4,414,351 B | 3,516,649 B | | Compression Ratio | x1.31 | x1.64 | x2.06 | | Compression Speed | 220 MB/s | 3.5 MB/s | 340 MB/s | | Decompression Speed | 850 MB/s | 45 MB/s | 1200 MB/s |

  • OpenZLは高圧縮率・高速処理を両立、データセンター用途に最適。

圧縮戦略の自動生成とSDDL

  • Simple Data Description Language(SDDL) でデータ形状を簡潔に記述可能。
  • 独自パーサ関数 もサポート、OpenZLに登録してロジック委譲可能。
  • トレーナー がプリセット・パーサ・SDDLから最適なPlanを自動探索。
    • クラスターファインダー で類似フィールドをグループ化。
    • グラフエクスプローラー で候補グラフを検証・スコアリング。
  • エンコード時にPlanが Resolved Graph に変換され、分岐選択も記録。
  • 各フレームに 圧縮レシピ埋め込み、デコーダは分岐を順次実行。
  • Plan更新時もデコーダはそのまま、旧データも新データも無停止対応。

ワークフロー

  • describe(SDDL)→ train(Plan生成)→ compress(フレーム出力)→ decode(同一バイナリ)

継続的な最適化と運用管理

  • データ構造や内容の変化 に柔軟対応可能。
  • Managed Compression との連携で、サンプル収集・再トレーニング・新設定配布を自動化。
  • デコーダ側は 一切変更不要、新旧データを同時サポート。
  • 圧縮設定には 制御ポイント を設け、圧縮時の統計値で分岐選択。
    • 例:文字列繰返し統計、ランレングス、ヒストグラム、デルタ分散など。
  • 分岐結果はフレームに記録、デコーダは記録通りに処理。
  • 圧縮時の動的最適化と デコーダのシンプル運用 を両立。

ユニバーサルデコーダの利点

  • あらゆるデータ形式を単一デコーダで復号
  • 圧縮設定が変わってもデコーダは不変、運用・監査負担を大幅削減。
  • セキュリティ・正当性監査 は単一バイナリで完結。
  • デコーダ更新 (セキュリティ・性能向上)は全ファイルに即時適用。
  • CLI・メトリクス・ダッシュボード統一、運用の一貫性。
  • オフライントレーニングと段階的ロールアウト で継続的な改善と後方互換性。

OpenZLの実運用と結果

  • ファイルフォーマットを理解・解析できれば、圧縮率・速度とも大幅向上
  • 未対応フォーマットは zstdにフォールバック
  • オフライントレーニング で多様な速度・圧縮率トレードオフを実現。
  • 従来の圧縮器はレベル指定のみだが、OpenZLはグラフ記述で柔軟設定
  • 白書掲載のデータセット で検証、再現性あるスクリプト・データ公開。
  • パレート最適な構成 を選択可能、用途に応じた最適化。

参考リンク

Hackerたちの意見

わお、これすごいね。今日の後で大きなCSVファイルで試してみたいな。

結果教えてね!OpenZLは最初、Metaで自分たち用に開発したんだ。最近は、OpenZLを開発してない人たちにも使いやすいツールにするために、かなり力を入れてるよ。フィードバック待ってるね!

MetaのNimbleはOpenZL(プレOSSバージョン)とネイティブに統合されてて、めちゃくちゃ恩恵を受けてるよ。

うん、カラムデータ形式のバックエンド圧縮はOpenZLにぴったりだね。圧縮するデータが数値(例えば、i64やfloatのカラム)だってわかると、Zstandardよりもすぐに効果が出るよ。

最近のHNの投稿でOpenZLについてバラすのを我慢するのが本当に大変だったよ。遺伝子配列データの圧縮に関する投稿ね。データに対してできるシンプルな変換の素晴らしい例で、かなりの圧縮改善が期待できるんだ。OpenZLはその変換を内部で簡単に(SDDLで!)行えるよ。[0] https://news.ycombinator.com/item?id=45223827

[0]の著者だよ。おめでとう、我慢できたね。早く試してみたい!追記:例えば「OpenZLの使い方」(https://openzl.org/getting-started/using-openzl/)で言われていること以外に、fasta圧縮器のトレーニングに関する具体的なアドバイスはある?

その投稿、私もすぐに思い出したよ!OPで言及されている専門的なコンプレッサーについて、何か比較できるものがあれば教えてもらえる? > グレース・ブラックウェルの2.6Tbp 661kデータセットは、微生物ゲノミクスの手法をベンチマークするためのクラシックな選択肢だよね。(...) カレル・ブリンダの専門的なMiniPhyアプローチは、このデータセットを2.46TiBからわずか27GiB(CR: 91)にまで圧縮するんだ。似たようなゲノムをクラスタリングして圧縮することで。

これをいくつかの一般的なゲノムフォーマット(fa、fq、sam、vcf)でベンチマークしてみてほしいな。ナノポアデータへの適用性を見るのも二重に面白いと思う。FAST5/POD5を保存するのが面倒だから、たくさんの有用なデータが失われてるからね。

ディレクトリ(または.tarファイル)を圧縮するにはどうすればいいの?リポジトリに例が見当たらないんだけど、zli compress -o dir.tar.zl dir.tar -> 無効な引数:圧縮プロファイルまたはシリアライズされた圧縮器が指定されていません。同じことがtrainコマンドでも起きる。追記:@terrelln、わかった、ありがとう!

こちらにクイックスタートガイドがあるよ: https://openzl.org/getting-started/quick-start/ でも、OpenZLはデータをどう圧縮するかを圧縮器に教えなきゃいけないから、ちょっと違うんだ。CLIツールにはいくつかのビルトイン「プロファイル」があって、--profile引数で指定できるよ。例えば、csv、parquet、le-u64とかね。./zli list-profilesでリストアップできるよ。いつでもserialプロファイルを使えるけど、OpenZLにデータについて何も教えてないから、内部ではただZstandardを使うだけなんだ。トレーニングで圧縮器を学ぶことはできるけど、.tarのようなフォーマットは今日のところ学べないよ。生の数値データやParquet、大きなCSVファイルを投げるなら、OpenZLが本当に良いパフォーマンスを発揮すると思うよ。

へぇ、これはちょっと驚いたな。もっと早く出てきてもよかった良いツールだと思う。アプローチがかなりしっかりしてるからね。データコンテナが理解できれば、重複排除がもっと効率的になるんだ。ターゲットを絞れるからね。BSD-3-Clauseライセンスで、しっかりしたC++実装、ドキュメントも充実してる。新しいファイルフォーマットが追加されるのを楽しみにしてるよ。

ファイルフォーマットの専門化は新しいことじゃないよね(例えば、7-ZipはBCJ2プリフィルタリングを使ってx86オペコードを絶対から相対JMP命令に変換するし)、アーカイブに専門的なデコーダーバイトコードを埋め込むことも(例えば、ZPAQはこれをやってマット・マホニーのベンチマークでたくさんの評価を得た)新しいことじゃないけど、OpenZLの実行、データ記述、トレーニングシステムは本当に素晴らしいと思う。

なるほど、あなたのデータの構造をSDLで記述して、それに基づいてコンプレッサーがデータの各部分をどう圧縮するか戦略を立てるってこと?正直、すごく見えるね。カスタムフォーマットを圧縮するための一般的なフレームワークを提供できたら素晴らしいと思う。

その通り!SDDL [0] は、ノーコードでこれを実現するためのツールキットを提供してるけど、今のところかなり制限があるんだ。機能セットを拡張する予定だけど、その間にC++やPythonでフォーマットをパースするコードを書くこともできるよ。このコードは圧縮側だけだから、デコンプレッサーはあなたのフォーマットには依存しないんだ。[0] https://openzl.org/api/c/graphs/sddl/

入力を数行のデータとLLMを使って自動的に記述したり推測したりできないかな?

LLMにSDDLの説明[0]を生成させたり、C++やPythonのトークナイザーを書かせたりすることもできるよ。圧縮が成功すれば、必ず往復できるからね。LLMが生成したロジックは圧縮側にしか存在しないし、デコーダーはそれに依存しないから。これは機械学習に適した問題かもしれない。明確な目的関数があるからね:圧縮は成功したのか、もしそうなら圧縮サイズはどれくらいか。[0] https://openzl.org/api/c/graphs/sddl/

論文の中でDAG自体がどうエンコードされているかの説明が見つからなかったんだけど、何かアイデアある?

論文からは省いたんだけど、これは実装の詳細で、フォーマットが進化するにつれて絶対に変わる部分なんだ。実際にそれをやってる関数はこれなんだけど[0]、特別なことはないよ。ビットを節約するためのビットパッキングのトリックはあるけど、特にクレイジーなことはない。将来的には、この表現をさらに縮小する改善を期待してる。小さいデータには重要だし、辞書にこの表現やその一部を移動できるようにするためでもあるんだ。[0] https://github.com/facebook/openzl/blob/d1f05d0aa7b8d80627e5...

ドキュメントを見て、AIがimhexやKaitaiの説明をSDDLにどれくらいうまく翻訳できるか気になるな。そうすれば、すぐにいくつかの良いスキーマが得られるかもしれない。

おお、これを教えてくれてありがとう!こういうツールがあるとは知らなかったけど、他の仕様フォーマットをSDDLの説明に変換するのはかなり可能性がありそうだね。ちょっと調べてみるよ。

それ、めっちゃ良さそう!圧縮速度のチャートは、ハードウェアアクセラレーションありとなしで同じ条件で比較されてるの?

うん。テストしたアルゴリズムの中では、実行したベンチマークでハードウェアアクセラレーションは使ってなかったよ。