Parquetファイルとは

Parquet はバイナリ形式です。これを知っているプログラムにしか意味を持ちません。 長期保存とプログラム間のデータ受け渡しのために使われます。

拡張子は .parquet、正式名称は Apache Parquet です。ただしどちらも、そのファイルが中に何を持てるかほどには多くを語りません。このページの残りは、その中身についての話です。

Apache Software Foundation が 2013 年に公開しました。

古さが役に立つのは、ごく実務的な理由からです。形式が古いほど、それを覚える時間が多くのプログラムに与えられてきたということだからです。

仕様書がそのまま公開されているので、中身を推し量るのではなく文書を読んで実装できます。この形式が数多くのプログラムに載っているのはそのためであり、20 年前に書かれたファイルが今も開けるのもそのためです。ただし「仕様が公開されている」ことと「使用料が要らない」ことは別の話です。中でコーデックを包んでいる形式では、特許のライセンスは仕様書が答えていない別の問題として残ります。

Parquet ファイルは中身をそのまま保存します。保存し直しても何も変わらないので、開いて、直して、また保存する——それを何度繰り返しても劣化は積み上がりません。これが、渡すための形式ではなく作業のための形式である理由です。

Parquet ファイルは壊れたファイルが黙って誤読されるのではなく、壊れていると分かるようにするチェックサムと必要なら暗号化を備えています。

暗号化されたファイルは、変換の前に解除する必要があります。ここでも、ほかのどこでも同じです。パスワードはコンバーターが通り抜けられる類のものではありませんし、通り抜けられると称するものには、そもそもファイルを渡すべきではありません。

pandas、Apache Spark、DuckDBが読めますし、同じ種類のプログラムならたいてい読めます。

ファイルが開かないとき、形式が悪いことはめったにありません。たいていはプログラムのほうが形式より古いのです。もっと古い形式に変換してしまうのが確実な逃げ道で、このサイトの残りの部分はそのためにあります。

これを読めるブラウザーはありません。

これを変換するいちばんよくある理由がこれです。形式が悪いのではありません。ファイルを見せたい場所が、それを読めないというだけのことです。

Parquet は渡すために作られたもので、中で作業するためのものではありません。編集は可能ですが、快適だったためしはありません。賢い道は、元のファイルへ戻ってもう一度書き出すほうを通ります。

繰り返し挙がる不満はこれです。本来の分野の外では対応がまばら。

どれも、この形式を避ける理由にはなりません。どれかに不意を突かれる前に知っておくべきことがら、というだけです。これは別の主張であり、そして役に立つほうの主張です。

CSV は一件ずつレコードを書きます。名前、日付、国、金額、そして次のレコードです。Parquet は一列ずつ書きます。すべての名前をまとめて、次にすべての日付、次にすべての国です。

この並べ替え一つが、この形式のすべてです。単なる整理の好みのように聞こえますが、その後のあらゆる処理の経済性を変えます。五十列のうち二列だけを求めるクエリーは、その二列だけを読んで残りを読み飛ばせますし、似た値の並ぶ列は、無関係な値が並ぶ行よりずっとよく圧縮できます。

同じ列の中の値は似ています。日付は日付らしく、国コードは繰り返し、金額は桁数が近い。この類似性こそが圧縮の材料です。Parquet は圧縮の前にも工夫を凝らします。異なる値の少ない列は辞書と小さな整数の列になり、同じ値の連続は個数として記録されます。

結果として、同じデータの CSV に比べて五分の一から十分の一の大きさになることが普通で、繰り返しの多い列を持つ横幅の広いテーブルでは、それをはるかに超えることもあります。これは保存容量の単純な節約であり、さらに重要なのは、それを読むあらゆる処理の転送時間の節約です。

CSV には型がまったくなく、読み込む側がすべて推測します。先頭のゼロが消え、識別子が日付に化けるのはこのためです。Parquet は独自のスキーマにすべての列の型を記録しています。これは 64 ビット整数、これは文字列、これはタイムゾーン付きのタイムスタンプ、これはこの精度の小数、という具合です。

そのため、データは意味していたとおりの意味を持ったまま届きます。何も推測されず、地域設定にも左右されず、郵便番号の列は郵便番号の列のままです。システム間を移動するデータにとって、これは圧縮以上に実務的な利点です。

Parquet は行グループという単位で構成されていて、それぞれが列ごとの統計 — 最小値、最大値、null の数 — を記録しています。日付の範囲で絞り込むクエリーは、その統計を見て、ある行グループが範囲の外にあると分かれば、何も展開せずに読み飛ばせます。

大きな Parquet のデータセットへのクエリーが、同じクエリーを CSV に対して行うより劇的に速くなるのはこのためで、読む列が少ないという理由だけではありません。データセットを日付ごとにフォルダー分けするパーティション分割がうまく機能するのも同じ理由です。エンジンは処理を始める前に、ファイル丸ごとを読み飛ばせます。

一件のレコードを読むことです。一行を再構成するには、すべての列からそれぞれ値を集める必要があり、これはまさにこのレイアウトが想定していないアクセスパターンです。Parquet は分析用の形式であって、データベースではありません。

追記です。ファイルは統計とフッターを末尾で計算しながら丸ごと書かれるため、行を追加するには書き直すか新しいファイルを書く必要があります。ストリーミングのデータは多数の小さなファイルとして届き、後でまとめて圧縮されます。データレイクを運用するうえでは普通のことですが、あらかじめ計画していないと厄介です。

そして見ることです。バイナリなので、テキストエディターでは何も分からず、確認にはツールが必要です。

以前よりハードルは下がっています。DuckDB は一行の SQL クエリーで Parquet ファイルを直接読め、数秒でインストールできます。Python の pandas や Polars も一行で読み込めます。いくつかの無料のデスクトップビューアーは、スプレッドシートのように表示してくれます。

CSV への変換はもう一つの経路で、同僚がスプレッドシートでデータを見る必要があるときには正しい選択です。ただし型は再び推測に頼ることになり、ファイルは数倍の大きさになります。Parquet を元データとして残し、頼まれた相手のために CSV を生成してください。

データが大規模に分析される場所ならどこでもです。クラウドストレージ上のデータレイク、Spark や Databricks、Snowflake や BigQuery のエクスポート、AWS Athena、dbt のパイプライン、そして今では普通の Python の分析でも、データフレームを保存する既定の方法として、いつの間にか CSV に取って代わっています。

公的機関や研究プロジェクトが大きなデータセットを公開する形式としても広まりつつあります。もう一つの選択肢である二ギガバイトの CSV は、どのみちスプレッドシートで開けず誰の役にも立たないからです。もしこれを渡されたなら、ほぼ間違いなくその理由からです。