ZStandard（可逆データ圧縮アルゴリズム）

「ZStandard（可逆データ圧縮アルゴリズム）」

データ活用やDX成功に必要な考え方を、各種キーワードの解説で理解できる用語解説集です。
今回は、データ圧縮の新しいアルゴリズムについて、およびデータ活用におけるデータ圧縮の意義について、少し考えてみます。

ZStandard（可逆データ圧縮アルゴリズム）とは

ZStandard （zstd）とは、データ圧縮処理とデータ展開処理の高速性で知られる、可逆データ圧縮アルゴリズムのこと。FacebookのMeta社に所属するYann Colletにより開発され、2016年にリファレンス実装が公開された新しいアルゴリズムです。
ZIPファイルに圧縮するような場面での「データを圧縮する手段」として利用される技術であり、ZIPが用いているアルゴリズムdeflateと比較して大幅に高速に処理できることを特徴としています。オープンに利用可能な技術であることとも合わせて、ZStandardが利用されることが増えつつあります。

ZStandardは「ZIPファイルみたいなもの」の最新技術

非常に簡単に説明をするなら（やや不正確ですが）、ZStandardとは「ZIPファイルのようにデータを小さくする技術」の最近出てきたものです。正しくはZIPファイルの圧縮アルゴリズムであるdeflateに相当する新しい技術です。

皆さんご存じ「ZIPファイル」
- ファイル拡張子：.zip
- データ圧縮アルゴリズム：deflate
- 広く利用されているデファクトスタンダード
今回話題にする新技術
- ファイル拡張子：.zstなど
- データ圧縮アルゴリズム：ZStandard
- RFCとして規格化されたオープンな技術

ZStandardは、2015年から開発され、2016年に最初のリファレンス実装が公開された新しい技術です。先ほども書いた通りFacebookのMeta社に所属のエンジニア、Yann Colletさんが開発しています。リファレンス実装は自由に利用できるオープンソースソフトウェアとして公開されており、RFCとして規格化もなされています。Linux環境において採用と利用が進んでおり、Linuxカーネル自体にもZStandardが含まれるようになっています。

ZIP（deflate）と大きく違うところは、圧縮処理や伸長処理（解凍処理）が圧倒的に速いことで、処理時間が一桁違うくらいの高速性があることです。

どうして「可逆データ圧縮」ができるのか

データ圧縮には大まかに2種類あります。可逆圧縮と非可逆圧縮です。

非可逆圧縮は画像や動画を圧縮するアルゴリズムの大半が該当します。「人の見た目には大きくは変わらないが、データサイズは大幅に削減される」技術で、大幅なサイズ削減ができることが多い代わりに、圧縮後は元のデータを復元することはできません。

これに対して可逆圧縮アルゴリズムは、元のデータをすべて保ったままデータサイズを小さくする技術です。「失うデータは何もない」のにサイズは小さくなるという、よくよく考えてみると不思議なことを実現する技術です。実際私も、圧縮技術というものがあると初めて知った時には、まるで魔法のようだと思いました。

連長圧縮/ランレングス圧縮（RLE：Run Length Encoding)

データ圧縮のニーズは大昔からあります。ITの黎明期においても、コンピュータのメインメモリや外部媒体に記録できるデータ量が非常に少なかったので、データをコンパクトに格納して容量を節約することは切実なことでした。

例えば8bitのファミコンの時代、初代ドラゴンクエストはわずか64KB（メガバイトではありませんキロバイトです）にゲーム全部を納めなければいけませんでした。

そのような時代にデータを小さく格納する方法としてよく使われていたのが、「データの連続を畳んで小さくする」方法です。例えば「AAAABBCCDDDDD」というデータなら、「A4B2C2D5」と同じ文字の連続を畳むとサイズを縮小できます。

ゲームのマップデータなら、ずっと草原になっている領域のデータを眺めると同じデータで延々埋められていて無駄に思えるとか、グラフィックスなら背景の黒一色の部分で延々ゼロが並んでいるのは見るからに無駄なので「連続データを畳んで無駄をなくそう」というような発想です。シンプルな発想なのCPUでの処理も難しくありません。

素朴にデータ圧縮の方法を考えると、このような連続するデータを畳むような仕組みが考案されることが多いようで、古くから利用されている圧縮方式です。データ損失のない画像ファイル形式「BMP」でも、色数が少ない場合（同じデータが連続しやすい「16色」「256色」の場合）にRLE圧縮が利用できるモードがあります。

辞書式圧縮アルゴリズム

ZStandard（やZIPのdeflate）は主として2つの考え方で高度で汎用性の高いデータ圧縮を実現しています。そのうちの一つが、データには「同じようなデータパターン」が繰り返し出現することを前提にした、辞書式の圧縮方式です。

例えば、東京都港区の企業の一覧データを作っていると考えてみましょう。そのデータには「同じパターン」が大量に出現します。

「株式会社」という文字列が頻繁に出現する
「東京都港区」という文字列が頻繁に出現する

他にも郵便番号とか電話番号にも「繰り返されるパターン」が様々にあるはずです。

「東京都港区」と何百回も記録するのが容量の無駄に思えるなら、「辞書」に「東京都港区」と一度だけ記録して、各出現箇所からは辞書を参照するようにするとどうでしょうか。容量は節約できるはずです。あるいは、最初の出現箇所のみ「東京都港区」と記録して、それ以降の出現箇所ではその文字列データをポインタで間接参照するイメージです。

ZIPファイルへの圧縮ではテキストデータが効率的に小さくなり、バイナリデータでは今ひとつだったりする印象があると思いますが、このような辞書式の圧縮がどういう場合に機能しやすいかを考えると、どうしてなのか理解できると思います。

エントロピー符号化

もう一つの仕組みは、「データの符号長を可変にして、最適な符号化をする」ことによる圧縮です。

例えば「A～Dの4文字からなる100文字のデータ」があるとします。普通にデータを格納するなら、このように2進数のビット列にエンコードして「2ビット×100文字で、200ビットのデータ」になります。

A：00
B：01
C：10
D：11

しかし、データの出現頻度がこのようになっていたとします。

A：97文字
B：1文字
C：1文字
D：1文字

通常利用するデータにおいてもこのような「偏り」はよくあります。例えば英語のテキストなら「e」なら頻繁に出現しますが「q」などは少ししか出現しません。上記の例を、このように可変長の表現でビット列にするとどうなるでしょうか。

A：0
B：100
C：101
D：110

出現頻度と合わせて計算すると、元は200ビット（2×100）だったデータが、内容を保ったまま106ビット（1×97＋3×1＋3×1＋3×1）まで減らすことができます。

説明が難しくなってしまうのできちんとした説明は割愛しますが、「シャノンの情報源符号化定理」を用いた圧縮です。符号化を工夫して各ビットに含まれる情報量（そのビットが0か1かを知ることによる「気づき」の量）を最大にすることで、各ビットの持つ情報エントロピーを最大化し、シャノンの理論での最短のデータ長になるようにする圧縮方式です。

例のデータでは、「どうせほとんどAですよね」なのでAは最短の符号長にします。それ以外は出現したら意外性がありますが。そのような「びっくり度が大きい情報」ほど符号長を長くするような方法です。

「ZIP以外」を使っても圧縮サイズが劇的には変わらない理由

より効率的なデータ圧縮を実現する研究は今でも日々続けられています。ZIPは大昔からありますが、それ以降、新たな提案もずっと行われてきました。例えば一昔前、RARの方がZIPより高圧縮だとして、一部の人には広く使われていた時期がありました。他にも、MicrosoftのインストーラではZIPではなくCABが用いられており、最近だと7-Zip（.7z）を見かけることもあるかもしれません。

多くの新しい提案がなされましたが、今でもZIPが広く使われています。なぜならば、新方式を採用しても劇的に圧縮サイズが改善されるわけではないことが多かったためです。例えば、RARにしても確かに圧縮率は高いものの「ややサイズが小さくなる」程度で、例えばZIPの10分の1になるような劇的な改善は起こりませんでした。

どうして劇的な改善が見られないのでしょうか。まず、可逆圧縮は無制限に小さくできるわけではなく理論的な限界が存在します。また、ZIP（deflate）もZStandardも、それ以降の可逆圧縮アルゴリズムにおいても、基本的には「辞書式圧縮アルゴリズム」と「エントロピー符号化」の組み合わせで実現されていることが多く、ZIPが登場した時点で技術的にかなり完成されていたためです。

改善の方向性が違うZStandardと、新たなユースケース

一方でZStandardは、サイズを小さくすることを徹底追及した新方式ではありません。その代わりに「同様の圧縮能力を保ったまま、処理速度を圧倒的に改善する」ことを追求しており、それにより注目されるようになりました。

ZIP（Deflate）では、特に圧縮時の処理に時間がかかる傾向があります。しかしZStandardでは、圧縮後のサイズは同水準でありながら、一桁以上処理時間が違うくらいに高速に圧縮することができます。

もしかしたら「高速になった程度で画期的かなあ？」と思うかもしれません。しかし、それは「圧縮処理とは時間がかかるものだ」というこれまでの前提でユースケースを考えてしまっているからかもしれません。例えば我々は、圧縮すれば記憶容量を節約できることを知っていますが、パソコンの中のあらゆるデータを圧縮したりしません、なぜでしょうか。「圧縮処理で毎回時間がかかってしまう」などにより、不便になってしまうと思っているからではないでしょうか。

ZStandardは「データ圧縮技術の潜在的な可能性」を、そのような制約から解き放つ可能性があります。ZIP（deflate）など従来方式では処理に時間がかかりすぎて不便になってしまう用途などで、活用できることが多くなるはずです。

より広い用途での利用が可能になる

もし次のバージョンのwindowsが「PC上のデータをすべてZIP圧縮する」と聞いたら、どう思うでしょうか。容量は節約できそうだけれど、重たくて快適に利用できないことがあるのではないか、など心配になったりしないでしょうか。圧縮処理の負荷が大きいと思えるので、広すぎる用途での利用に不安に思えるわけです。処理負荷が圧倒的に小さいのなら、従来よりも広い用途で一般的に利用しやすくなります。

巨大データでの遠慮のない利用

例えば、ギガバイト単位のログファイルが多数あって記憶容量を圧迫していたとします。ログファイルを圧縮すると50分の1まで小さくできて一気に容量を節約できるものの、圧縮に3分かかってしまうとします。効果はあるけれども3分ものあいだ高負荷状態になるのは不安で、圧縮中に別の圧縮処理が始まったりするとメインの処理に悪影響すらあるかもしれません。しかしZStandardで圧縮してみたところ、圧縮後の容量はほぼ同じなのに7秒で圧縮できたとします。違うのは処理速度だけですが、利用するハードルは一気に下がります。

リアルタイム性が求められる処理での利用

データ転送処理でデータ圧縮を利用することができます。データ圧縮すれば転送すべきデータ量が減り、転送完了までの「通信にかかる時間」を短縮できる可能性があります。しかし、通信時間が10秒から5秒に減っても、データ圧縮処理で20秒かかるのなら、全体での処理時間は増えてしまって逆効果になります。それがもし1秒で圧縮できるようになったなら、どうでしょうか。データ通信のようなリアルタイム性が求められる用途での活用を広げられる可能性があります。

ZStandard の活用例：ファイル転送での活用

ビジネスでのIT活用はますます盛んになっていますが、そうなってくると必ず重要になってくるのが「データ連携」です。社内の複数のITシステムやクラウドサービスにまたがった処理を実現するために必要になるのはもちろん、企業間をまたがったIT活用に取り組みたいのなら、自社システムとはまったく事情が違うこともある他社システム多数とのデータ連携を実現する必要が出てきます。

業務遂行を担うITシステムともなれば、データ連携が止まると業務が止まり、データ連携が遅延すると業務も遅延します。さらには各社のシステムは、それぞれ技術も違うことがあり、業界の違いなどからデータの持ち方なども違うことはよくあります。多種多様な事情を持つ環境との連携を長期的に維持できる手段が必要になります。そのような状況に適した、ファイルを介したシステム間連携（ファイル連携）は、今なお広く利用されています。

企業間でのデータ転送では通信速度の出ない通信回線を経由することがありますし、通信相手が地球の裏側ということもあります。社内システム同士での連携の場合でも大量の連携処理を常時行うような状況になることは珍しくありません。そのような状況において、データ圧縮により転送するファイルのサイズを大幅に小さくできるのなら、大きな改善効果が見込めます。

ZStandardは、圧縮処理による遅延の悪影響を減らせる

ファイルを圧縮すれば転送サイズを抑えられるのだとしても、ZIP圧縮では圧縮処理自体が重いことから、圧縮完了までの遅延やサーバへの処理負荷集中によって、転送能力が逆に落ちてしまうこともありました（規定時間内に3600ファイル送信できていたものが、ZIP圧縮すると逆に600ファイルに減るなど）。

ZStandardなら、ZIP（deflate）に比べて10倍以上の速さでの圧縮処理を見込むことができます。ZStandardであれば、圧縮処理により悪影響が出てしまう可能性が低くなり、性能を引き上げられることが多くなるはずです。

ZStandardは、今後も利用される技術である

ZStandardはRFC 8878としてオープンに規格化されている技術であり、Linuxカーネル自体も採用しているような技術です。今後も継続的に同技術が世界中で活用され、関連するソフトウェアも継続して提供されることが期待できることから、長期的に安心して利用しやすい技術であると言えます。

ZStandardに対応している、ファイル連携ミドルウェア「HULFT」

HULFT（ハルフト）は、日本国内で圧倒的な実績を持つ、ファイル連携によるデータ連携基盤を実現するミドルウェアのデファクトスタンダードです。ZStandardにも製品自体で対応しています。

日本の金融機関の全てが利用しているHULFT

金融機関のITシステムは当然に非常に高度な「安全安心確実さ」が求められます。HULFTは日本の金融機関の全て（銀行協会の会員企業の全て）で利用されている実績があります。

日本の基幹システムのファイル連携基盤では、長年にわたりHULFTがデファクトスタンダードとなっており、安全安心確実さが求められる分野での圧倒的な実績があります。

古いシステムとのデータ連携で圧倒的

HULFTは長い実績があることから、メインフレームや古いハードウェア環境への対応、昔には広く使われていた各社の商用UNIXへの対応など古い技術への対応では圧倒的な実績があります。さらには、固定長データや可変長データ、外字を含むEBCDICの日本語データなど、古い環境特有のデータと現在よくつかわれるデータ形式との相互変換も得意です。

WindowsやLinux、さらにはクラウドなどの新しいIT環境と昔からあるITシステムをうまく共存されることは通常は困難です。しかし業務上有用なデータが旧環境にあることは珍しくありません。HULFTを使えば、世代の違う新旧技術でも疎結合でうまく組み合わせて活用することができます。例えば、Linuxしかわからないエンジニアにもメインフレームとのデータ連携を、メインフレームしかわからない技術者にもクラウドとのデータ連携が実現できます。

関係するキーワード（さらに理解するために）

ファイル連携
- 様々な企業活動を支えるITシステムの基盤として活躍している連携手段です。業務に関連して取り扱われているデータ、特に事務処理や経理に関連するITの利活用では、ファイル形式でのデータのやり取りはとても一般的です。
MFT（Managed File Transfer）
- ファイルによる連携処理を、企業活動を支えられるだけの高度な水準の「安全安心確実さ」で実現する連携基盤です。間違いがあってはならない業務や監査対応など、高度な信頼が求められるITシステムの実現手段として利用できます。

HULFTとファイル連携（MFT）に興味を持たれましたら

興味を持たれましたら、ぜひファイル連携の世界を実現する製品を実際に試してみてください。

MFTの決定版「HULFT」

国内で圧倒的な実績がある、国産MFT製品の最高峰にして「ファイル連携基盤のデファクトスタンダード」である「HULFT（ハルフト）」を是非お試しください。

ITシステムに対して最高度の対応が求められる金融機関でその基盤として長年使われているなど圧倒的な実績があります。あらゆる環境が、あっという間にファイルでつながった世界が出来上がります。

今ではHULFTはクラウドサービスとの連携など最新のIT環境にも対応しており、大容量ファイルの高速転送や、大量のファイルの転送処理など、性能が求められる状況でも活躍しています。

ファイル転送の仕組みを学ぶ HULFT 製品紹介・オンラインセミナーはこちら

インターネット経由で安全安心のファイル転送が利用できる「HULFT WebConnect」

HULFTの安全安心確実なファイル転送を、インターネット回線経由で利用できるクラウドサービスが「HULFT WebConnect（ハルフト・ウェブコネクト）」です。

自社の拠点間はもちろん、海外支社との間や取引先との間など、エンタープライズクラスのしっかりしたファイル連携手段を、一般のインターネット回線だけで実現できます。

インターネットの向こう側ともHULFTによる転送を利用できます
コストのかかる専用線やVPNなどが不要で低コストです
クラウドサービスのため、自社での運用作業が不要ですぐに利用開始できます
転送路に情報を残さない仕様となっているなど、監査対応に配慮した仕様です
通信相手が多数の企業の場合を想定した機能があります
- 多数の取引先と請求書や注文書などをセキュアにやり取りする基盤として活用できる機能が整えられています（簡単に利用できる専用クライアントなど）

WebConnectの製品紹介・オンラインセミナーはこちら