はじめに
今回は、データ分析の文脈で出てくる「Parquet」形式についてまとめてみました。
一般的にデータ格納形式として使われるCSVファイルと比較しながら、Parquetが持つ特徴を整理します。
目次
Parquet形式とは何か
Parquet（パーケ、パルケ）形式は、大量のデータを高速に分析するために作られた列指向（カラムナ）ファイル形式です。
特に、ログ分析や売上集計などの「大量のデータをあとからまとめて集計・分析する用途（OLAP）」において広く使われています。
背景
近年の分析基盤では、データをデータベース（RDB）の中ではなく、ストレージ上に「ファイル」として保存する運用される場合が多くあります。
データレイク / データレイクハウス と呼ばれる構成では、
- データはオブジェクトストレージなどに「ファイル」として保存され
- クエリエンジン（Apache Spark / Trino / DuckDBなど）が
- それらのファイルを 直接読み取って分析 します
このような構成では、
「どんなファイル形式でデータを保存するか」 が、システムの性能とコスト（転送量）に直結します。
Parquetは、この 「ファイルとして保存された大量データを、いかに高速に分析するか」 に特化して設計されています。
Parquet形式は Apache Parquet として標準的に定義・提供されています。
「Apache」とは何か
Apache Parquet の「Apache」は、Apache Software Foundation（ASF） という非営利団体が管理している公式オープンソースプロジェクトであることを表してます。
■ Apache Software Foundation
- 世界的に有名なオープンソース財団
- 特定の会社に依存せず、中立的にソフトウェアを管理している
Apache Parquet のほかにも、Apache Hadoop や Apache Spark など、多くのデータ基盤技術が Apache プロジェクトとして提供されています。
なお、「Apache」というとWebサーバソフトウェアである「Apache HTTP Server」を思い浮かべる方も多いですが、これも本来はオープンソースプロジェクトの一つという位置づけです。
行指向（CSV）と 列指向（Parquet）の違い
最大の差は、ディスク上での「データの並び順」にあります。
Parquet形式では、データを 列単位（列指向 / カラムナ） で保存します。
行指向（Row-based）
id,name,price
1,apple,100
2,banana,120
3,orange,150
- 1行分のデータがまとまって保存される
- 1件ずつ処理する OLTP（トランザクション処理） には向いている
- でも「price列だけ集計したい」場合でも全列を読む必要がある
列指向（Parquet）
id: 1, 2, 3
name: apple, banana, orange
price: 100, 120, 150
- 列ごとにデータがまとまって保存される
- 分析クエリ（集計・フィルタ）で 必要な列だけ読める
- I/O が劇的に減る
なぜ Parquet は分析が速いのか
Parquetが速い理由は、単に「列指向だから」だけではありません。「読み込む量を最小限にする仕組み」と「コンピュータが理解しやすいデータ形式」の組み合わせに秘密があります。
① 必要な列だけ読む（列プルーニング）
分析で、例えば「100列あるうちの、売上の1列だけ使いたい」というケースの場合：
- *CSVの場合： 特定の列だけ欲しくても、全列（
id, name, priceなど）を端から順に読み飛ばす必要があります。 - Parquetの場合：
price列が必要なら、そのデータが格納されている場所へダイレクトにアクセスします。
👉 ディスクI/O（データの読み取り量）が劇的に減り、処理が高速化します。これを列プルーニング（Column Pruning） と呼びます。
② 統計情報を持っている（ファイル単位のメタデータ）
Parquetファイルの末尾（フッター）には、統計情報（メタデータ） が記録されています。
- 各列の 最小値（min）/ 最大値（max）
- nullの有無
- データ数など
例えば WHERE price > 1000 という条件で検索した場合、
クエリエンジンはまずファイルのメタデータを確認します。「このファイルの最大値は500だ」と分かれば、ファイルの中身を1ミリも読まずにスキップします。
👉 条件に合わないファイルは 最初から読み飛ばすため、実際にスキャンする対象が大幅に削減されます。
これを述語プッシュダウン（Predicate Pushdown） と呼びます。
③ 圧縮効率が高い
同じ列には「同じデータ型」や「似た値」が並びます。
例：都道府県 列なら「東京都、東京都、東京都……」と並ぶ。
例：ステータス 列なら「0, 0, 1, 0, 0……」と並ぶ。
このように規則性があるデータは、「辞書圧縮」（同じ値を短いコードに置き換える）などの手法が非常に効果的です。
👉 CSVに比べてファイルサイズが劇的に小さくなります。ストレージ代が安くなるだけでなく、「データが小さい＝読み込みが速い」 という相乗効果を生みます。
④ CPU効率の最大化（バイナリ形式とスキーマ保持）
CSVとの決定的な違いは、Parquetが「型情報を持ったバイナリ形式」であることです。
-
パース（解析）が不要： コンピュータがCSVを読む際、すべてのデータを一度「文字列」として認識し、そこから「123」を数値の 123 に、「2024-01-01」を 日付型 に変換する処理が発生します。このデシリアライズ（復元処理） に大きなCPUサイクルが消費されます。Parquetは最初からコンピュータが理解できる「0と1」のバイナリなので、そのままメモリに載せて処理できます。
-
型定義（スキーマ）が最初から決まっている： ファイルヘッダーに「1列目はInt64型（長整数型）」といった厳格な**スキーマ（定義書）**を持っています。読み込み側は推論を行う必要がなく、常にデータの正確性が保証されます。
👉 CPUの計算リソースを無駄遣いせず、テラバイト級のデータでもスムーズに処理できます。
Parquet単体では「テーブル」ではない
Parquetはあくまで ファイル形式 であり、
- どのファイルがテーブルに含まれるか
- どれが最新版なのか
- 更新・削除・履歴管理
といった テーブル管理の責務は持っていません。
そのため実運用では、
- Parquet（ファイル形式）
- Iceberg / Delta Lake / Hudi（テーブルフォーマット）
を セットで使う のが前提になります。
まとめ
- Parquet は、分析に特化した「列指向」のファイル形式。
- 列プルーニング と 統計情報（メタデータ） により、スキャン量を最小化できる。
- 高い圧縮率とバイナリ形式により、コストとCPU負荷を同時に削減できる。。
- Iceberg などと組み合わせることで、クラウド上での強力な分析基盤になる。