Parquetファイルを極める：構造、ユースケース、そして主なメリット

Parquetファイルは、行ではなく列単位でデータを保存します。Apache Parquetプロジェクトでは、これを「効率的なデータの保存と取得のために設計された、オープンソースの列指向データファイルフォーマット」と説明しています。この設計上の選択肢こそが、ファイルサイズが小さく、クエリが高速で、ダブルクリックでは開きにくい理由です。

Parquetファイルとは？

Parquetは、Apacheプロジェクトとして管理されている表形式データ用のファイルフォーマットです。公式ドキュメントには、「複雑なデータを一括して処理するための高性能な圧縮およびエンコード方式を提供する」と記載されています。さらに、このフォーマットは「多くのプログラミング言語や分析ツールでサポートされている」とも付け加えられています。

最大の特徴は、そのデータの並び方向（指向性）にあります。CSVは1行ずつ書き込みます。つまり、レコード1のすべてのフィールドを書き込み、次にレコード2のすべてのフィールドを書き込みます。一方、Parquetは1列ずつ書き込みます。最初の列のすべての値を書き込み、次に2番目の列のすべての値を書き込みます。

これは単なる技術的な詳細のように聞こえるかもしれませんが、2つの大きなメリットをもたらします。1つは、単一の列内の値は互いに似ている傾向があるため、様々なデータが混ざった行よりもはるかに効率的に圧縮できる点です。もう1つは、90列のうち3列だけを必要とするクエリを実行する場合、すべての行をスキャンして不要な大部分を捨てるのではなく、その3列だけを読み取ることができる点です。

このフォーマットは正式に仕様化されています。Apacheのドキュメントには、「parquet-formatリポジトリにはParquetファイルフォーマットの公式仕様が格納されており、データの構造化と保存の方法が定義されている」と記されています。

Parquetファイルの構造

エンベロープ（外枠）

すべてのParquetファイルは、同じ4バイトで始まり、同じ4バイトで終わります。仕様書によると、ファイルの先頭には「4バイトのマジックナンバー 'PAR1'」があり、末尾にも全く同じマジックナンバーが存在します。

その間にデータが格納され、末尾の近くにメタデータが配置されます。末尾を閉じるマジックナンバーの直前には、「ファイルメタデータのバイト長を示す4バイト（リトルエンディアン）」が存在します。この値によって、リーダーはメタデータブロックを見つけるためにどれだけ前に戻ればよいかを知ることができます。

行グループと列チャンク

エンベロープの内部では、データは2段階で分割されています。仕様書では、ファイルは「このテーブル内のN個の列が、M個の行グループに分割されている」と説明されています。

行グループとは、水平方向の切り出し、つまり行のバッチ（まとまり）のことです。各行グループ内では、各列の値が「列チャンク」としてまとめて保存されます。したがって、90の列と10の行グループを持つファイルには900の列チャンクが含まれ、それぞれが単一の列からの連続した値の並びとなります。

この2段階の分割こそが、選択的な読み取りを可能にしている理由です。クエリは、一致する行が含まれるはずのない行グループ全体をスキップし、残りの行グループから必要な列チャンクだけを読み取ることができます。

なぜメタデータが末尾にあるのか

ヘッダーがあると思い込んでいる人は、これに驚くかもしれません。Apacheのドキュメントはその理由を直接説明しています。「シングルパス書き込みを可能にするため、ファイルメタデータはデータの後に書き込まれる」のです。

大規模なデータセットをストリーミング出力するライターは、実際に書き込みを終えるまで、各チャンクの最終的なバイト位置を知ることができません。メタデータを最後に配置することで、後から戻ってヘッダーを修正する必要がなくなります。

読み取りのパターンもこれに従います。ドキュメントによると、ファイルメタデータには「すべての列チャンクの開始位置」が含まれています。さらに、「リーダーは、まずファイルメタデータを読み取って、関心のあるすべての列チャンクを見つけることが期待されている」と付け加えられています。

Parquetの用途

通常、.parquetファイルを目にするのは、次の4つの状況のいずれかです。

データウェアハウスからのエクスポート： 近年のデータウェアハウスから巨大なテーブルをエクスポートする場合、ファイルサイズを扱いやすい大きさに抑えられるため、これがデフォルトの形式になることがよくあります。

データレイクストレージ： クラウドのオブジェクトストレージに置かれるファイルでよく使用されます。これはまさに、クエリエンジンがすべてをダウンロードすることなく、列の一部だけを読み取ることができるためです。

チーム間のデータ受け渡し： データエンジニアが1年分の取引データを送ってくれる場合、数倍の大きさになるCSVではなく、この形式を選択することがよくあります。

分析ツール間の相互運用： このフォーマットは多くの言語やツールでサポートされているため、途中で変換処理を挟むことなく、システム間を移動させることができます。

共通しているのは「サイズ」です。CSVでは手軽に持ち運べなくなる境界線において、このフォーマットが当然の選択肢となります。

Parquet vs CSV

	Parquet	CSV
データの並び方向	列指向	行指向
テキストエディタで読めるか	いいえ、バイナリ形式です	はい
一般的なファイルサイズ	列圧縮により小さい	同じデータでも大きい
一部の列のみを読み取る場合	該当する列チャンクのみを読み取る	ファイル全体を読み取る
データ型	ファイルメタデータ内に保持される	開くツールによって推測される
ダブルクリックで開くか	一般的には開かない	通常は表計算ソフトで開く
最適な用途	大規模なテーブル、繰り返しのクエリ実行	小規模なテーブル、素早い確認、汎用的な共有

データ型の扱いについては特筆に値します。CSVは 00123 が数値なのか文字列なのかを判別できないため、インポート時に先頭のゼロが消えたり、日付が文字化けしたりします。Parquetはメタデータ内に型を記録するため、書き込んだ値がそのまま正確に読み戻されます。

この比較における行指向の側面については、CSVの解説記事で逆の視点から同じテーマを扱っています。また、タブ区切りのバリアントについてはTSVの解説記事で詳しく説明しています。

主なメリット

相乗効果を生む圧縮： 類似した値を隣り合わせに保存することで、エンコーダーの処理効率が大幅に向上します。Apacheのドキュメントでは、「高性能な圧縮およびエンコード方式」の恩恵であると説明されています。

列の刈り込み（カラムプルーニング）： 90列のうち3列だけを読み取る場合、90列分ではなく、ほぼ3列分のI/Oコストしかかかりません。

行グループのスキップ： メタデータに各行グループの内容が記録されているため、リーダーはデータにアクセスする前に、不要なスライス全体を破棄（スキップ）できます。

データ型が保持される： スキーマがファイル内部に保持されるため、日付は日付のまま、識別子は先頭のゼロを維持したまま保持されます。

シングルパス書き込み： メタデータが末尾にあるため、非常に大きなファイルでもストリームとして書き込むことができます。

幅広いサポート： ドキュメントに「多くのプログラミング言語や分析ツール」でサポートされているとある通り、互換性の問題で行き詰まることはほとんどありません。

Parquetが万能ではないケース

Parquetは保存と取得の課題を解決します。しかし、ファイルの中に実際に何が入っているかという疑問を解決してくれるわけではありません。

バイナリ形式であるため、一目で中身を確認することはできません。CSVを開いて売上列が総売上（グロス）か純売上（ネット）かを確認するだけなら5秒で済みます。しかし、バイナリファイルは、中身を見るだけでも何らかのツールが必要になります。

また、小規模なデータには不向きです。200行程度のルックアップテーブルの場合、メタデータのオーバーヘッドやツールの必要性が、圧縮によるメリットを上回ってしまいます。そのような場合はCSVの方が適したフォーマットであり、その事実を率静に認めることも、Parquetを上手に使いこなすための一歩です。

さらに、データの品質については何も保証しません。完全に型定義され、効率的に圧縮された「無意味なデータ」が格納されている可能性もあります。重複したレコード、2つの通貨が混在する通貨列、3月にスキーマが変更された顧客IDなどです。このフォーマットが保証するのは再現性（忠実度）であり、正確性ではありません。

エンジニアではない人がParquetファイルを扱う方法

ここに実務上のギャップがあります。ほとんどのビジネスツールはスプレッドシートを前提としており、.parquetファイルはCSVのように簡単には開けません。

現実的な解決策は、変換ステップを挟むことです。ファイルを作成した担当者に、実際に必要な列だけを抽出したCSVまたはExcelファイルを依頼するか、Parquetに対応したツールを使って自分で変換します。圧縮のメリットは失われますが、データが手元のマシンにダウンロードされ、必要な範囲に絞り込まれてしまえば、それは問題になりません。

そこから先は、通常の分析作業と同じです。Powerdrill Bloomの料金ページには、Excel、CSV、PDF、およびドキュメントのアップロードが記載されているため、変換した抽出データをそのまま取り込むことができます。クエリを書く代わりに、自然言語で質問を投げかけることができます。CSV AI assistantがそのプロセスをサポートし、エクスポートするよりも直接データを取得した方がよい場合はdata connectorsが対応します。

覚えておくべき重要な違いは、Parquetはあなたよりも上流のプロセスで下された「保存方法に関する意思決定」に過ぎないということです。これは分析ツールではないため、ファイルが手元に届いた時点で別の形式に変換することは、その場しのぎの回避策ではなく、ごく一般的な手順です。

まとめ

Parquetは、スキーマとインデックスがファイルの末尾に配置された列指向のストレージ形式です。この設計により、高い圧縮率、選択的な読み取り、そして信頼性の高いデータ型が実現されており、大規模なデータを扱う際のデファクトスタンダードとなっています。

一方で、視認性（中身のわかりやすさ）は得られません。保存場所ではなく「答え」を必要としている人の手元にファイルが届いた瞬間、次に取るべき有効なステップは、必要な範囲を抽出して問いかけることです。

もしそのような状況であれば、変換したファイルを使ってPowerdrill Bloomをお試しください。まずはチャート（図表）に変換することから始めてみましょう。

よくある質問

Parquetファイルは何に使われますか？

Parquetは、大規模な表形式のデータセットを効率的に保存するために使用されます。データウェアハウスからのエクスポート、データレイクストレージ、チーム間のデータの受け渡し、分析ツール間の相互運用などで一般的です。その理由は、圧縮率が高く、選択した列のみの読み取りをサポートしているためです。

ParquetはCSVよりも優れていますか？

繰り返しクエリが実行される大規模なテーブルにおいては、はい、優れています。ファイルサイズが小さく、データ型を保持し、列の刈り込みをサポートしているためです。一方で、中身を確認したり広く共有したりする必要がある小規模なテーブルにおいては、テキスト形式でどこでも開くことができるCSVの方が簡単で適しています。

ExcelでParquetファイルを開くことはできますか？

Parquetはテキストではなくバイナリ形式であるため、ダブルクリックして開くことはできません。一般的な方法は、まずCSVやExcel形式に変換するか、Parquetを直接読み取ることができるツールを使用することです。

なぜParquetのメタデータはファイルの末尾に保存されるのですか？

Apacheのドキュメントでは、「シングルパス書き込みを可能にするため」にメタデータがデータの後に書き込まれると説明されています。大規模なデータセットをストリーミングするライターは、事前に最終的なチャンク位置を知ることができないため、メタデータを最後に書き込むことで、ヘッダーを書き直すために戻る必要をなくしています。

Parquetにおける行グループとは何ですか？

行グループとは、テーブルの水平方向のスライス（切り出し）のことです。仕様書では、ファイルの列が「M個の行グループに分割されている」と説明されており、各列は各グループ内で個別のチャンクとして保存されます。このレイアウトにより、リーダーは不要なグループと列の両方をスキップすることができます。