🔖 キーワード索引

別名・略称：（なし）

📍 あなたが今見ているもの

🎨 直感で掴む

📐 定義 / 数式

🔬 記号・式を言葉で読み解く

可逆圧縮

完全に元に戻せる。 テキスト・プログラム・数値データ用。

非可逆圧縮

完全には戻せないが、 知覚的に問題ない範囲で大幅圧縮。 画像/音声/動画用。

Huffman 符号

出現頻度の高い記号に短い符号を割り当てる古典手法。

辞書式（LZ77/LZ78）

繰り返しパターンを「ここまで戻って何文字コピー」と表現。 gzip 内部で使用。

カラムナ形式

Parquet/ORC。 列毎にデータ型と分布が一様 → 圧縮率が良い。

🧮 実データで計算してみる

🐍 Python 実装

SSDSE-B-2026（47 都道府県・2023 年データ）を題材にした最小コード：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

import pandas as pd

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='utf-8', skiprows=1)

# gzip 圧縮で保存
df.to_csv('data/processed/ssdse.csv.gz', index=False, compression='gzip')

# Parquet（Snappy 圧縮、 デフォルト）
df.to_parquet('data/processed/ssdse.parquet', index=False)

# Parquet + Zstd（より高圧縮）
df.to_parquet('data/processed/ssdse_zstd.parquet', compression='zstd')

⚠️ よくある落とし穴

🌐 関連手法・この用語を使う論文

🔖 詳細キーワード索引

🎨 直感で掴む（深掘り）

圧縮を一言で言えば「パターンを見つけて短く書く」。 「AAAAA」と書く代わりに「A×5」と書けば短くなる、 という発想です。

日本語にも例えれば「あいうえおあいうえおあいうえお」を「[あいうえお]×3」と表現できる。 アルゴリズムごとに「どんなパターンを探すか」が異なります：

• LZ77 系（gzip, zstd）：前出の同じ文字列を「○○行前の□□文字」とポインタで表現
• Huffman 符号：頻繁な文字には短い符号、 稀な文字には長い符号を割り当て
• BWT（bzip2）：文字列を並べ替えて圧縮しやすい形に変換
• 算術符号：1 ストリームを 1 つの小数として表現
• 変換符号（JPEG）：人間の目に分からない高周波成分を捨てる

📍 文脈 ── データ基盤の中で

データ圧縮は データレイク 設計、 分散処理、 ネットワーク転送、 メモリ効率の全てで効いてくる横断的技術。 「CPU を使ってでも、 ディスク IO / ネットワークを減らす」のが現代的トレードオフ。

分析パイプライン上では、 収集 直後の Bronze 層から最初に適用し、 Silver/Gold まで一貫させます。 列指向＋圧縮で 10〜30 倍縮むのが普通で、 ストレージ費・クエリ費の双方を削減します。

🌐 関連手法・派生

• 辞書符号化 — categorical 列を ID に置換、 Parquet/ORC の核
• エンコーディング — UTF-8, base64, Avro
• バイナリ形式 — Protocol Buffers, FlatBuffers, MessagePack
• 列指向 DB — ClickHouse, Vertica の内部圧縮
• ベクトル化（Arrow） — メモリ内でも列指向＋圧縮
• 差分プライバシー — ノイズを足して情報を制御

🔗 関連用語（前提・並列・発展）

役割で色分け：前提／並列／発展

⚡ パフォーマンスのトレードオフ

圧縮レベルを上げると 圧縮率は向上するが、 CPU 時間が増加します。 全体スループットは IO ボトルネックの解消量とのバランス：

$$ T_{\text{総}} = T_{\text{圧縮}} + T_{\text{IO}} + T_{\text{解凍}} $$

$T_{\text{IO}}$ が支配的（ネットワーク・HDD 書き込み）なら圧縮で総時間短縮。 メモリ内処理が中心なら圧縮はオーバーヘッドになる場合も。

SSD：3GB/s → snappy/lz4 で十分（CPU が追いつく）
HDD/Network：100MB/s 程度 → zstd レベル 3〜6 で IO 短縮効果が CPU コストを上回る

💡 結論（補足）

データ圧縮はデータ基盤の費用・性能を左右する鍵。 「列指向＋現代的可逆圧縮」が分析用途の標準。 一次的なシナリオごとに、 圧縮速度・解凍速度・圧縮率のトレードオフを意識すれば、 大半の問題は解決します。

• 分析データの定番：Parquet + snappy or zstd
• 1 列の中身が似ているほど 圧縮が効くので、 列指向必須
• dtype 最適化：int64 → int32、 object → category で読み速度も向上
• 過剰圧縮：xz レベル 9 はアーカイブ専用、 日常使いは zstd 程度に
• 暗号化：圧縮 → 暗号化の順。 圧縮による情報漏洩（CRIME 等）注意
• 圧縮率の理論限界：Shannon エントロピー以下にはできない
• 1 ファイル 100MB〜1GB：レイク上のサイズ目安

📡 通信プロトコルにおける圧縮

ネットワーク経由のデータ転送でも圧縮は必須。 主要なケース：

🔬 専門用語の解説

🎯 圧縮の設計指針（決定木）

1. 用途は？ ── 分析（読み多）／アーカイブ（保存多）／転送（速度重視）
2. 分析なら ── 列指向必須（Parquet/ORC）、 圧縮は snappy or zstd（速）
3. アーカイブなら ── 圧縮率重視、 xz / brotli / zstd level 19 等
4. 転送なら ── lz4 / snappy（CPU負荷小）、 ネットワーク 1 GbE 未満なら zstd
5. 更新が多いなら ── 列指向は不向き、 行指向（Avro）も検討
6. SQL/BI で頻繁にクエリ ── Parquet＋パーティション＋snappy が王道
7. ストリーミング ── 行指向 Avro＋snappy がKafka 連携で便利

📊 圧縮ベンチマーク参考値

SSDSE-B 程度の表形式データを各方式で圧縮した場合の代表的な数値（実測値は環境依存）：

🛠 主要な圧縮アルゴリズム

圧縮は 可逆（lossless） と 不可逆（lossy） に大別されます。 データサイエンスでは可逆が基本：

2025 年現在、 大量データのデフォルトは Parquet + zstd または Parquet + snappy。 zstd は近年急速にシェア拡大。

📊 列指向ストレージと圧縮の相乗効果

分析データは 列指向（columnar） 形式で保存すると圧縮率が劇的に向上します。 同じ列に並ぶ値は型と分布が似ているため、 アルゴリズムが効きやすくなるからです。

$$ \text{圧縮率} = \frac{\text{元サイズ}}{\text{圧縮後サイズ}} $$

🐍 Python 実装（パフォーマンス比較）

(1) 各圧縮方式の比較：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

import pandas as pd
import os, time

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='utf-8', skiprows=1)

for comp in ['snappy', 'gzip', 'brotli', 'zstd', 'lz4']:
    t = time.time()
    df.to_parquet(f'/tmp/test_{comp}.parquet', compression=comp)
    sz = os.path.getsize(f'/tmp/test_{comp}.parquet')
    print(f'{comp}: {sz/1024:.1f} KB, {time.time()-t:.2f}s')

(2) DataFrame の dtype 最適化で圧縮率を上げる：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

import numpy as np

# int64 を int32 へ
df['人口総数'] = df['人口総数'].astype('int32')

# object → category
df['都道府県'] = df['都道府県'].astype('category')

# float64 を float32 へ（精度が許せば）
df['高齢化率'] = df['高齢化率'].astype('float32')

print('メモリ使用量:', df.memory_usage(deep=True).sum() / 1024, 'KB')

(3) ストリーミング圧縮（巨大ファイルでメモリ節約）：

1
2
3
4
5
6
7
8
9

import gzip, shutil

# 大きな CSV を gzip 圧縮
with open('large.csv', 'rb') as f_in:
    with gzip.open('large.csv.gz', 'wb', compresslevel=6) as f_out:
        shutil.copyfileobj(f_in, f_out)

# pandas で直接読める
df = pd.read_csv('large.csv.gz', encoding='utf-8')

⚠️ 落とし穴（さらに）

📐 情報理論的限界（Shannon エントロピー）

どんなに優れた可逆圧縮でも、 Shannon エントロピー以下にはできません。 確率分布 $p(x)$ を持つ情報源の理論的下限：

$$ H(X) = -\sum_i p_i \log_2 p_i \quad [\text{bits/symbol}] $$

例：8 ビット文字でも、 ASCII 英文の実効エントロピーは約 4.7 bit/char。 つまり理論上 1.7 倍圧縮できる。 実際の gzip でも 2〜3 倍程度に収まります。

乱数や既に圧縮されたデータはエントロピーが高く、 さらなる圧縮はほぼ不可能。 「圧縮できる」＝「データに冗長性がある」ということです。

📖 事例：センサーデータの圧縮戦略

工場で 1 kHz の振動センサーが 100 台稼働する場合、 1 日 8.64 億行。 CSV のままなら 30 GB／日、 月 1 TB。

• 差分符号化：隣接時刻の差を保存 → 値の幅が縮小
• 列指向化（Parquet）：時刻列とセンサー値列で別圧縮
• zstd レベル 3：適度な圧縮率と高速デコード
• 結果：30 GB → 約 1.5 GB／日（20 倍圧縮）
• 月コスト：S3 で約 $30、 1 年で $360 → 元の数百分の一

📜 歴史

• 1948 年：Shannon の情報理論、 エントロピーの概念
• 1952 年：Huffman 符号化、 可変長符号
• 1977 年：LZ77（Lempel-Ziv）アルゴリズム、 後の gzip の基礎
• 1992 年：JPEG 標準化、 不可逆画像圧縮
• 1996 年：bzip2、 ブロックソート＋Huffman
• 1998 年：LZMA、 7-Zip / xz の基礎
• 2011 年：Google snappy、 速さ重視
• 2016 年：Facebook zstd、 速さと圧縮率を両立
• 2020 年代：列指向（Parquet, Arrow）＋zstd が主流

❓ よくある質問

🔗 関連用語（前提・並列・発展）

📚 関連グループ教材

この用語の全体像を学ぶには、 まず横断的な教材で文脈を掴むのが効率的です：

• 📚 用語集トップ — カテゴリ別の一覧から関連用語を辿る
• 🗺️ 概念マップ — 全体の繋がりを俯瞰