Parquet (.parquet) | Apache Parquet 列指向ファイルフォーマット解説

要点

• Apache Parquet は Hadoop エコシステムから生まれた列指向（Columnar）のバイナリファイル形式で、拡張子は .parquet。
• CSV と比較して読み込みが 10〜100 倍速く、ファイルサイズは Snappy/zstd 圧縮で 1/5〜1/10 になることが多い。
• BigQuery / Amazon Athena / Apache Spark / DuckDB / Polars など、ほぼすべての分析エンジンが標準でサポートする事実上の業界標準。
• 内部は Row Group → Column Chunk → Page の階層構造で、列単位の圧縮と Predicate Pushdown（WHERE 句を IO 層に押し下げる最適化）が効く。

概要

Parquet は 2013 年に Twitter と Cloudera が共同開発を始め、現在は Apache Software Foundation 配下の OSS として運営されている列指向ファイルフォーマットである。当時 Hadoop / Hive 上で行指向の TSV や SequenceFile が主流だったが、SELECT で「数百カラムのうち 2〜3 列だけ集計したい」というワークロードに対してまったく効率的でなかった。Parquet は列単位でデータを並べることで、必要な列だけを IO することを可能にし、Hive/Impala/Spark などの SQL on Hadoop 世代を支える基盤になった。

2020 年代に入ると、クラウド DWH である BigQuery や Snowflake のエクスポート形式、Amazon S3 上のデータレイク（Athena / Redshift Spectrum）、ストリーミング ETL の Delta Lake / Apache Iceberg / Apache Hudi といったテーブルフォーマットの実体ファイルとして、Parquet は クラウドデータ基盤の共通通貨 の地位を確立した。Python から扱うには pyarrow / fastparquet、Pandas なら pd.read_parquet() / pd.to_parquet() ですぐ読み書きできる。

CSV (CSV（.csv）) との対比でいうと、CSV が「テキストで人間が読める行指向」なのに対し、Parquet は「バイナリで圧縮済み・型付き・列指向」であり、ほとんど真逆の設計思想を持つ。両者は競合ではなく、受け渡し用は CSV、分析・保管用は Parquet という棲み分けが定着している。

内部構造

Parquet ファイルは大きく次の 3 層からなる。

1. Row Group: 行を 128 MB〜1 GB 程度の塊にまとめた単位。並列処理の最小単位で、Spark の 1 タスク = 1 Row Group が基本になる。
2. Column Chunk: Row Group 内の 1 列ぶん。ここで列単位の圧縮（Snappy / gzip / zstd / LZ4）が掛かる。同じ型・似た値が並ぶので圧縮率が極めて高い。
3. Page: Column Chunk をさらに 1 MB 程度に分割した単位。Data Page（実データ）と Dictionary Page（辞書）に分かれる。

エンコーディングは Dictionary Encoding（カーディナリティが低い列は辞書 ID で表現）、RLE（Run Length Encoding）、Bit Packing、Delta Encoding を列の特性に応じて自動選択する。たとえば「性別」のように 2 値しかない列は辞書化して数バイトで済み、CSV で 100 万行 "Female"/"Male" と書いた場合に比べて 1000 倍以上小さくなることもある。

各 Row Group の末尾には Footer（メタデータ）があり、列ごとの min/max/null count、ファイル全体のスキーマ（型、ネスト構造）が記録されている。クエリエンジンはこれを読むだけで「この Row Group には条件に合うデータが無い」と判定でき、本体を読まずにスキップできる。これが Predicate Pushdown の正体である。

主な用途

• データレイク: S3 / GCS / ADLS にパーティション付きで配置（year=2026/month=06/dt.parquet）し、Athena / BigQuery / Trino / Spark から SQL でクエリ。
• ETL の中間ファイル: CSV や JSON から取り込んだ生データを、列指向に変換して保管する 2nd-tier ストレージ。
• 機械学習の特徴量ストア: 数百カラム × 数億行になりがちな特徴量テーブルを、必要な列だけ高速に取り出す。
• Pandas / Polars の永続化: pickle と違ってバージョン非依存・他言語からも読める。データサイエンス案件の事実上のデフォルト保存形式。

関連形式との比較

同じ列指向の ORC とは性能差はワークロード次第でほぼ互角だが、Hadoop/Hive 圏外（クラウド DWH や Python 系）では Parquet が圧倒的なシェアを持つ。長期保管の選定では、「読み手のエコシステムが何を使っているか」で決めるのが妥当である。

コマンド・ツール

CLI で覗くには Apache Arrow 同梱の parquet-tools、もしくはより軽量な pqrs が便利である。

$ parquet-tools schema sample.parquet
message schema {
  optional binary user_id (STRING);
  optional int64  ts (TIMESTAMP_MILLIS);
  optional double amount;
}

$ parquet-tools head -n 5 sample.parquet
$ parquet-tools meta sample.parquet

Python なら次の通り。

import pandas as pd
df = pd.read_parquet("sample.parquet")
df.to_parquet("out.parquet", compression="zstd")

# pyarrow で部分読み（列指向の真価）
import pyarrow.parquet as pq
table = pq.read_table("sample.parquet", columns=["user_id", "amount"])

DuckDB はインストール不要で、Parquet を SQL で直接舐められる。手元の分析にきわめて強力。

duckdb -c "SELECT user_id, SUM(amount) FROM 'sample.parquet' GROUP BY 1"

注意点

• 追記が苦手: 既存ファイルへの行追加は基本不可。append したい場合は新しいファイルを書いて Hive パーティションで分けるか、Delta Lake / Iceberg などのテーブルフォーマットを被せる。
• 1 行だけの取り出しは遅い: 列指向のため Row Group 全体を読まされる。OLTP 用途には絶対に向かない。
• 小さすぎるファイルは性能が出ない: 数 KB の Parquet が大量にあると、メタデータ読みが支配的になり CSV より遅くなる。Row Group 128MB を 1 目安にコンパクションするのが定石。
• スキーマ進化に弱点: 列追加は可能だが、型変更（int→string など）はファイル間で混在するとエンジンによってエラーになる。本格的な進化が必要なら Avro と組み合わせる。

関連リンク

• 親: データベース・データ交換
• 概論: ファイル拡張子とは
• カテゴリ: データベース（カテゴリ）
• テキスト系比較: CSV（.csv）
• 関連する形式: Avro（.avro） / ORC（.orc） / Feather / Arrow IPC