Apache Parquet（パーケ）は2013年にTwitterとClouderaが共同で公開したオープンソースの列指向ファイル形式で、Hadoopエコシステムから生まれながら現在ではSpark・Presto・Trino・DuckDB・BigQuery外部テーブルなど多くの分析エンジンが第一級でサポートするデファクト標準となった。Dremelの論文に着想を得たネスト構造の表現と、列単位のエンコーディング・圧縮により、TB級データに対する集計クエリで圧倒的なI/O効率を実現する。
この記事の目次
- Parquetの内部構造を読み解く
- なぜ列指向が分析で速いのか
- 実務で踏みやすい落とし穴
- 周辺ツールとの組み合わせ
- まとめ
Parquetの内部構造を読み解く
Parquetファイルは大きく4階層で構成される。最上位はファイル全体で、その内部に複数のRow Group（既定128MB前後）が並ぶ。各Row Groupは列ごとにColumn Chunkを持ち、Column Chunkはさらに数MB単位のPageに分割される。ファイル末尾にはFooterというメタデータ領域があり、スキーマ・統計情報・各Page位置がここに集約されているため、ヘッダ全読込なしで列単位アクセスができる。
Pageには値そのもののData PageとDictionary Pageがあり、辞書圧縮・RLE・Delta・Bit Packingなど複数のエンコーディングをカラムの統計分布に応じて切り替える。外側ではSnappy・Zstd・Gzipなどブロック圧縮も併用可能で、文字列カラムでは元データの1/5〜1/10にまで縮むケースが珍しくない。min/max統計を使ったPredicatePushdownにより、フィルタ条件を満たさないRow Groupは読み飛ばされる。
なぜ列指向が分析で速いのか
行指向のCSVやAvroはレコード1件を連続バイトに並べるため、1行全体を取り出すOLTP的アクセスには向く。一方Parquetは同じカラムの値を連続領域に固めて格納するため、SELECT col1, col2 FROM huge_table のように一部の列だけ集計する典型的なOLAPクエリでは、不要な列のディスク読込をまるごと省略できる。同種データが連続するためCPUキャッシュ効率も高く、SIMD演算とも親和性が高い。
ただし1行をまるごとupdateするような操作は不得意で、追記的なWORM（Write Once Read Many）運用が前提となる。差分更新を扱いたい場合はDelta Lake・Apache Iceberg・Apache Hudiといったテーブルフォーマットを上に被せるのが現代的構成で、Parquetは「物理ファイル形式」、Iceberg等は「論理テーブル管理」と役割が分かれる。
実務で踏みやすい落とし穴
Parquetは万能に見えて、小さなファイルを大量に作ると性能が崩壊する。FooterとPageヘッダのオーバーヘッドが効いてくるため、1ファイルは数百MB〜1GBにまとめるのが鉄則で、Kafka Connectなどで秒単位に書き出している場合は定期的なcompaction処理が必須となる。S3上での小ファイル爆発は分析チームの典型的な悩みだ。
また、書き出し時のスキーマ進化にも注意が必要である。Parquet自体は列の追加・削除に対し名前ベースで柔軟だが、Sparkなど一部エンジンはインデックス位置で読むモードがあり、列順を変えると過去ファイルが壊れて見える事故が起きる。タイムスタンプのINT96 vs INT64問題、TIMEZONE設定もエンジン間の互換性で頻出のハマりどころだ。
周辺ツールとの組み合わせ
Parquetは単体で使うより、データレイクの基盤として他コンポーネントと束ねて使うことが多い。ETLでSparkやFlinkが書き出し、メタデータはHive MetastoreやAWS Glue Catalogが管理し、クエリはTrino・Athena・DuckDBが直接読み出す、という分業が定着している。DuckDBはローカルでも数GBのParquetを軽快に扱えるため、アナリストが手元PCで前処理に使うケースが2023年以降急増した。
機械学習側ではpandasがpyarrow経由でParquetを読み書きでき、PyTorch/TensorFlowの学習データセットとしても活用される。Hugging Face Hubが2024年時点でデータセットの標準配布形式をParquetに揃えたことで、研究領域でもデファクト化が進んだ。Parquetを選んだ瞬間、エコシステム全体の恩恵が一気に得られる点が最大の価値である。
まとめ
Apache Parquetは列指向・自己記述・圧縮効率という三拍子が揃ったファイル形式で、データレイク／レイクハウスの物理層を独占的に支えている。小ファイル問題やスキーマ進化など運用上の注意は残るが、Iceberg等と組み合わせればペタバイトクラスでも安定する。分析基盤を作るなら最初に選択肢に上がる形式だ。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント