列指向フォーマット（Parquet・ORC）

分析基盤で「ファイル形式」が主役になる理由

トランザクション DB では、データの物理表現は DB エンジンの内部実装であり外から意識しません。ビッグデータの分析基盤では逆転します。データは S3・GCS のようなオブジェクトストレージにファイルとして置かれ、それを Spark・Trino・Presto・Hive・DuckDB・Flink といった複数のエンジンが読む。ここでは「どのファイル形式で書くか」が性能・コスト・相互運用性を決める第一級の設計判断になります。

Parquet と ORC は、この用途のためのオープンな列指向ファイル形式です。特定 DB 製品に閉じていないため、Spark で書いた Parquet を別ジョブが Trino で、BI ツールが DuckDB で、いずれも変換なしに読めます。これがストレージと計算の分離を成立させます。データは安価なオブジェクトストレージに一元的に置き、計算エンジンは必要時に起動して同じファイルを読む。「データを入れたエンジンでしか読めない」という DB 的なロックインが消えるのが、分析基盤における列指向フォーマットの核心的な価値です。

オブジェクトストレージ経済：読まないバイトは課金されない

分析基盤の列指向が効く本質は、圧縮率よりむしろ読まずに済ませる（pruning）ことにあります。そしてオブジェクトストレージ上では、これが単なる高速化ではなく直接のコスト削減になります。Athena や BigQuery のオンデマンド課金は「クエリがスキャンしたバイト量」に比例するため、読むバイトを減らせば料金がそのまま下がるからです。

列指向ファイルは三段の粒度でスキャンを削ります。

たとえば WHERE dt='2024-01-10' AND amount > 1000 なら、まず dt=2024-01-10 以外のディレクトリを開かず、残ったファイル内でも amount の最大値が 1000 以下の行グループを飛ばし、さらに amount 列のバイトだけを範囲 GET で取りに行きます。オブジェクトストレージはバイト範囲指定の GETに対応するので、「フッタを1回読んで必要位置を知り、その範囲だけ取得する」動きが可能です。読むバイトが減れば、転送時間・GET 課金・スキャン量課金がまとめて減ります。

自己記述フッタ：中央カタログなしで読める仕組み

Parquet も ORC も、スキーマと全メタデータ（各行グループ・各カラムの統計とバイトオフセット）をファイル末尾のフッタにまとめて置きます。本体を書き終えるまで統計は確定しないため、ストリーミング書き込みと相性が良く、末尾に置くのが理にかないます。

この自己記述性が分析基盤で効くのは、**スキーマオンリード（schema-on-read）**を成立させるからです。読み手はファイル自身のフッタからスキーマと型を得られるので、DB のような中央のスキーマ定義がなくてもよい。列を追加するような後方互換な進化なら、古い読み手は新しい列を無視し、新しい読み手は欠けた列を null として扱えます。中央カタログでの DDL 強制なしに、ファイル単位でスキーマが進化していける点が、レイクのゆるやかな運用に合います。

Parquet / ORC ファイルの外形（読み手の動き）
[ 行グループ0 | 行グループ1 | ... | フッタ | フッタ長(固定) ]
                                     ▲
1) 末尾の固定長からフッタ位置を逆算し、フッタだけを1回読む
2) 必要な行グループ/カラムのオフセットと統計を得る
3) 述語で不要な行グループを外し、必要カラムの範囲だけ GET する

ファイルサイズ設計と小ファイル問題

分析基盤特有の落とし穴が**小ファイル問題（small files problem）**です。行グループは既定で 128MB 前後を目安に作られますが、ストリーミング取り込みや過剰なパーティション分割で、数 KB〜数 MB の Parquet が大量に生成されることがあります。

なぜ問題か。第一に、ファイルごとにフッタ読み取りと最低1回の GET が要るため、ファイル数に比例してメタデータ処理とリクエスト回数が膨らみ、小ファイルが多いとクエリ時間の大半がファイルを開く往復で消えます（GET はリクエスト単位でも課金・レイテンシがある）。第二に、行グループが小さいと統計・辞書・フッタの相対オーバーヘッドが増え、符号化の効きも落ちます。逆に大きすぎると枝刈りの粒度が粗くなり、条件に1行合うだけで巨大な行グループ全体を読む無駄が出ます。

エンコーディングと圧縮：転送量を減らして計算へ渡す

列指向ファイルの最内層は、軽量符号化＋汎用圧縮の二段構えです。下段は辞書符号化（低カーディナリティ値を整数 ID へ）・RLE（連続同値をカウントへ）・デルタやビットパッキング（整数の値域を詰める）といった、型のそろった整数列を生む符号化。上段はその整数列に Snappy・Zstandard・gzip のような汎用圧縮を掛けて最終的に容量を詰めます（各符号化アルゴリズムの詳細はデータベース側で扱います）。

分析基盤の観点で重要なのは、この二段構えがネットワークと計算の両方を軽くすることです。オブジェクトストレージからワーカーへ流すバイトが減るので転送が速く、かつ辞書 ID の等値比較のように復号せず圧縮表現のまま述語評価できる符号化は、読み込み後のスキャンを SIMD ベースのベクトル化実行にそのまま乗せられます。圧縮方式の選択は、CPU に余裕があり容量を詰めたいなら Zstandard、計算律速で展開を速くしたいなら Snappy、というトレードオフで選びます。

Parquet と ORC の使い分け

両者は思想がほぼ同じ（ファイル → 行グループ／ストライプ → カラムチャンク → ページ／ストリームの入れ子、フッタ統計、二段圧縮）ですが、出自とエコシステムの重心が違います。

現状のクラウド分析やレイクハウスでは Parquet が事実上の標準で、Arrow との連携や幅広いエンジン対応から新規はまず Parquet を選ぶのが無難です。ORC は既存の Hive/Hadoop 資産や、ORC を前提に最適化された基盤で引き続き使われます。どちらを選んでも、上に Iceberg・Delta・Hudi といったテーブルフォーマットを重ねれば、不変ファイル＋差し替え可能なメタデータで ACID やタイムトラベルを足せます。ファイル形式（読む単位）とテーブル形式（トランザクションの単位）は層が違う、と切り分けると全体像がつながります。

まとめ

• Parquet・ORC は特定 DB に閉じないオープンな列指向ファイルで、オブジェクトストレージに置くことでストレージと計算を分離し、Spark・Trino・DuckDB など複数エンジンが同じファイルを変換なしに読める。これが分析基盤における最大の価値。
• スキャン削減はパーティション枝刈り→行グループの min/max スキップ→列プロジェクションの三段で効き、読んだバイトで課金される環境ではそのままコストと所要時間の削減になる。
• 自己記述的なフッタが全メタデータを持つため、中央カタログなしでスキーマオンリードと列プロジェクションが成り立ち、後方互換なスキーマ進化を許す。
• 行グループ（ストライプ）が分散スキャンの割り当て単位。ゆえにファイルサイズ設計と小ファイル問題が性能を左右し、コンパクションで 128MB 前後に保つのが定石。
• 最内層は軽量符号化＋汎用圧縮の二段構えで転送量を削り、圧縮のまま述語評価してベクトル化実行へ渡す。新規は Parquet が事実上の標準、ORC は Hive 資産で残る。ファイル形式の上にテーブルフォーマットを重ねれば ACID・タイムトラベルを足せる。