Parquetとは｜CSVとの違い・読み書き・中身を100万行で実測

Parquet のファイルは、先頭と末尾に「PAR1」という目印があり、その間に「行グループ」ごとの列のデータが並び、最後に「フッター（スキーマと統計値）」が付いています。読むプログラムは、まず末尾のフッターを読み、必要な列・必要な行グループの場所だけを取りに行きます。

flowchart TD
    A[PAR1 先頭4バイト] --> B[行グループ 0<br>列チャンク × 列の数]
    B --> C[行グループ 1 以降]
    C --> D[フッター<br>スキーマ・位置・統計値]
    D --> E[フッターの長さ 4バイト]
    E --> F[PAR1 末尾4バイト]

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS（Intel Xeon 2.10GHz の2コア・メモリ 8GB）の上で、Python 3.13.18 の venv に pyarrow 26.0.0・pandas 3.1.0（NumPy 2.5.4）・DuckDB 2.0.0（Python パッケージ）を入れて実行しました。データは乱数（シード 86）で作った注文データ 1,000,000行×7列（注文ID・注文日時（タイムゾーンつき）・店舗コード（先頭0つきの5桁）・カテゴリー（日本語5種）・金額・数量・クーポン（null と空文字を含む））です。CSV と Parquet（無圧縮・snappy・zstd・gzip ほか）に保存し、サイズ・書き込み時間・読み込み時間（5回の中央値、書き込みは3回）・特定の列だけ読む時間・DuckDB の集計時間を測りました。ファイルの中身は pyarrow の read_metadata と DuckDB の parquet_metadata()、述語プッシュダウンは DuckDB の EXPLAIN ANALYZE で確かめ、エラーは実際に起こした原文を載せています。Spark・BigQuery・Athena・Power Query は動かしておらず、各公式ドキュメントで確かめた範囲だけを書いています。時間は手元の環境での値で、同じ処理でも回によって1.5倍ほどぶれました（確認日 2026年10月29日）。

Parquetとは（意味・読み方・列指向ファイル形式）

この節では、Parquet が何のための形式で、どこが「列指向」なのかが分かります。

Apache Parquet は、データを効率よく保存し、取り出すために作られた、オープンソースの列指向（カラムナー）のデータファイル形式です。 公式サイトは「Apache Parquet is an open source, column-oriented data file format designed for efficient data storage and retrieval.」と説明しています。拡張子は .parquet です。

• 読み方：英語の発音に近い「パーケイ」と書かれることが多く、「パーケット」とも読まれます。もとはフランス語で、木片を組み合わせた寄木張りの床のことです。
• 成り立ち：Twitter と Cloudera の共同の取り組みとして始まり、2013年に最初の版が出ました。Google の論文「Dremel」の、入れ子のデータを列に分けて保存する方法を取り入れています。2015年4月27日から Apache ソフトウェア財団のトップレベルプロジェクトです（Wikipedia の Apache Parquet の項）。
• 仕様と実装：仕様（parquet-format）は公開されていて、読み書きのプログラムは Java（parquet-java）・C++（Arrow の一部）・Rust・Go・DuckDB など、別々に実装されています。

行指向と列指向の違い

同じ3行の表を、行指向（CSV）と列指向（Parquet）で並べると、ディスク上の順番が次のように変わります。

列指向にすると、同じ種類の値が隣り合うので圧縮が効き、集計に使う列だけを読めば済みます。その代わり、1件を書き足したり書き換えたりするのは苦手です。

ParquetとCSVの違い（一覧表）

この節では、Parquet と CSV の違いを、データの持ち方・型・使い道の面から一覧で比べられます。

CSV は「人が読める文字の表」、Parquet は「プログラムが速く読むための、型つきで圧縮された表」です。 どちらが上というより、向いている場面が違います。

Avro は行指向のバイナリ形式で、1件ずつの書き込みやメッセージのやり取りに向きます。ORC は Parquet と同じ列指向の形式で、Hive の世界で広く使われてきました。Athena の公式ドキュメントは、容量が気になる場合は ORC のほうが小さくなることが多い、と書いています。

100万行で実測：CSVとParquetのサイズと速度

この節では、同じ100万行を CSV と Parquet に保存したときの大きさと、書き込み・読み込みの時間が、実測の表で分かります。

データは乱数で作った注文データ 1,000,000行×7列で、メモリ上では 65.2MB でした。CSV は pandas の to_csv、Parquet は pyarrow の write_table（圧縮の指定だけを変える）で書いています。

import pandas as pd, pyarrow as pa, pyarrow.parquet as pq

df = make()                               # 100万行の DataFrame（乱数で作成）
t = pa.Table.from_pandas(df, preserve_index=False)

df.to_csv("orders.csv", index=False)
for comp in ["none", "snappy", "zstd", "gzip"]:
    pq.write_table(t, f"orders_{comp}.parquet", compression=comp)

大きさと書き込み時間

• 無圧縮の Parquet でも CSV の約3分の1でした。 数値を文字ではなく8バイトの値で持ち、同じ値の多い列を辞書（よく出る値の一覧と番号）に置き換えているためです。
• pandas の to_csv は、タイムゾーンつきの日時を1行ずつ文字にするため遅く、23秒かかりました。同じデータを pyarrow の write_csv で書くと1.3秒でした。

読み込み時間（全部の列・1列だけ・DuckDB で集計）

「1列」は金額の列だけ（CSV は usecols=['price']、Parquet は columns=['price']）、「DuckDB 集計」はカテゴリーごとの金額の合計です。

読んだバイト数（DuckDB の EXPLAIN ANALYZE）

速さの理由は、読む量の違いです。DuckDB の EXPLAIN ANALYZE が表示する「Data Read」を比べました（snappy のファイル）。

金額の合計では、Parquet は金額の列の 1.8MB だけを読み、CSV はファイル全体の 57.5MB を読みました。 1.8MB は、次の節で見る金額の列チャンクの大きさ（1,784,292バイト）とほぼ同じです。DuckDB の公式ドキュメントも、Parquet ファイルに対して必要な列だけを読む「projection pushdown」を自動で行うと説明しています。

Parquetの圧縮：snappy・zstd・gzipの選び方

この節では、圧縮方式（コーデック）ごとの大きさと書き込み時間の違いと、どれを選ぶかが分かります。

pyarrow・pandas・Spark・DuckDB の既定はどれも snappy です。 保存する量を減らしたいときは zstd に変えると、手元では snappy より約27%小さくなり、書き込み時間はほとんど変わりませんでした。同じデータで、ほかの指定も試しました。

• 辞書（dictionary）エンコーディングを切ると、snappy でも 15.4MB から 21.7MB に増えました。 カテゴリー（5種）やクーポン（3種と null）のように種類の少ない列は、辞書に置き換えるだけで大きく縮みます。pyarrow は既定で辞書を使い、辞書が大きくなりすぎた列は PLAIN（そのままの並び）に切り替えます（pyarrow の write_table の説明）。
• zstd のレベルを19に上げると、さらに12%小さくなりましたが、書き込みは約30倍の時間でした。何度も書き直すデータには向きません。
• 圧縮は列ごとに選べます。pyarrow では compression={'price': 'zstd', 'category': 'snappy'} のように辞書で渡します。

1. 1迷ったら snappy（既定）のままどのツールでも読める。書き込みも読み込みも速い
2. 2保存の量や転送料を減らすなら zstd手元では snappy より約27%小さく、時間はほぼ同じ
3. 3一度書いて長く置くだけなら zstd の高いレベル・brotli書き込みは何倍も遅くなる
4. 4gzip は相手が gzip しか読めないときだけ大きさは zstd と同じくらいで、書き込みがいちばん遅かった

読み込む側が対応しているかも確かめます。BigQuery の公式ドキュメントが挙げる、Parquet の読み込みで使える圧縮は GZip・LZO_1C・LZO_1X・LZ4_RAW・Snappy・ZSTD です。

Parquetファイルの中身（行グループ・列チャンク・統計値）

この節では、Parquet ファイルの中に何が入っているかを、実際のファイルを開いた出力で確かめられます。

Parquet は「行グループ（行のかたまり）→ 列チャンク（その中の1列分）→ ページ（読み書きの最小単位）」の3段でできていて、末尾のフッターに、スキーマ・各列チャンクの位置・最小値と最大値などの統計値が入っています。 公式の仕様によると、ファイルの先頭と末尾は4バイトの「PAR1」で、末尾の PAR1 の直前に、フッターの長さが4バイト（リトルエンディアン）で入っています。

先頭と末尾のバイトを見る

b = open("orders_snappy.parquet", "rb").read()
print(b[:4], b[-8:], int.from_bytes(b[-8:-4], "little"))

b'PAR1' b'\x90\x0f\x00\x00PAR1' 3984

末尾の4バイト手前の 90 0f 00 00 は、リトルエンディアンで 0x0f90＝3,984 です。フッターが 3,984 バイトあることを示しています。読むプログラムは、まず末尾の8バイトを読み、フッターの場所を知ります。 途中で切れたファイルが「magic bytes not found in footer」というエラーになるのはこのためです（エラーの節）。

pyarrow.parquet.read_metadata で全体を見る

parquet-tools のような専用のコマンドが無くても、pyarrow の read_metadata でフッターの中身を表示できます。

import pyarrow.parquet as pq
md = pq.read_metadata("orders_snappy.parquet")
print(md)
print(md.schema)
print(md.row_group(0).column(3))   # 4番目の列（category）の列チャンク

<pyarrow._parquet.FileMetaData object at 0x7f25add08e00>
  created_by: parquet-cpp-arrow version 26.0.0
  num_columns: 7
  num_rows: 1000000
  num_row_groups: 1
  format_version: 2.6
  serialized_size: 3984

required group field_id=-1 schema {
  optional int64 field_id=-1 order_id;
  optional int64 field_id=-1 ordered_at (Timestamp(isAdjustedToUTC=true, timeUnit=milliseconds, ...));
  optional binary field_id=-1 store_code (String);
  optional binary field_id=-1 category (String);
  optional double field_id=-1 price;
  optional int32 field_id=-1 qty;
  optional binary field_id=-1 coupon (String);
}

  path_in_schema: category
  statistics:
      has_min_max: True
      min: 家電
      max: 食品
      null_count: 0
      num_values: 1000000
      logical_type: String
  compression: SNAPPY
  encodings: ('PLAIN', 'RLE', 'RLE_DICTIONARY')
  has_dictionary_page: True
  total_compressed_size: 379917
  total_uncompressed_size: 379667

• num_row_groups: 1：pyarrow は既定で、1つの行グループを最大 1,048,576（1024×1024）行にします。100万行は1つに収まりました。
• 文字列は物理型 binary（BYTE_ARRAY）に、論理型 String を付けて保存されています。日時は int64 に Timestamp の論理型です。物理型（保存の形）と論理型（意味）の2段になっているのが Parquet の型の特徴です。
• pandas の秒単位の日時は、ミリ秒（timeUnit=milliseconds）で保存されていました。pyarrow の説明に「Parquet には秒の精度の時刻型が無いため、秒は常にミリ秒に変換する」とあります。
• min: 家電・max: 食品 は、UTF-8 のバイト列としての大小で決まっています。五十音順ではありません。

列ごとの大きさ（DuckDB の parquet_metadata）

DuckDB の parquet_metadata() は、列チャンクごとの統計と大きさを表で返します。抜き出して並べました（snappy のファイル）。

SELECT path_in_schema, stats_min, stats_max, stats_null_count,
       total_compressed_size, total_uncompressed_size
FROM parquet_metadata('orders_snappy.parquet');

• 100万行の category は、辞書に置き換えた時点で 38万バイトまで縮み、snappy はほとんど効いていません（圧縮前と後がほぼ同じ）。大きいのは、ほぼすべて違う値の order_id と ordered_at です。
• 日時の統計は UTC で入っています。2025-12-31 15:00:25（UTC）は、日本時間の 2026-01-01 00:00:25 です。
• coupon の null は 599,706件と数えられていて、空文字（最小値が空）とは別に扱われています。

スキーマに入っている pandas の情報

pandas から書いた Parquet には、フッターのキーと値の欄に、pandas の型やインデックスの情報が JSON で入ります。pq.read_schema で見えます。

order_id: int64
ordered_at: timestamp[ms, tz=Asia/Tokyo]
store_code: large_string
category: large_string
price: double
qty: int32
coupon: large_string
-- schema metadata --
pandas: '{"index_columns": [], "column_indexes": [], "columns": [{"name":' + 908

述語プッシュダウン：統計値で行グループを読み飛ばす

この節では、Parquet の「条件に合わない部分を読まない」仕組みと、効かせるためにデータをどう並べればよいかが、実測で分かります。

述語プッシュダウン（predicate pushdown・filter pushdown）は、WHERE の条件を読み込みの段階に持ち込み、フッターの最小値・最大値から「この行グループには条件に合う行が無い」と分かった部分を読まない仕組みです。 Athena の公式ドキュメントも、Parquet と ORC では最大値・最小値などの統計を使ってブロックを読むか飛ばすかを決める、と説明しています。

同じ100万行を、10万行ずつの行グループ（row_group_size=100_000）で、注文日時の順に並べ替えずに保存したものと、並べ替えて保存したものを作り、「2026年3月1日の注文」を読みました。

pq.write_table(t, "unsorted.parquet", compression="zstd", row_group_size=100_000)
pq.write_table(t.sort_by("ordered_at"), "sorted.parquet", compression="zstd", row_group_size=100_000)

lo = pd.Timestamp("2026-03-01", tz="Asia/Tokyo"); hi = pd.Timestamp("2026-03-02", tz="Asia/Tokyo")
pq.read_table("sorted.parquet", filters=[("ordered_at", ">=", lo), ("ordered_at", "<", hi)])

行グループごとの統計値（ordered_at の最小〜最大、UTC）は次のとおりでした。

ソートなし
  RG 0 2025-12-31 15:03:15+00:00 〜 2026-09-30 14:58:19+00:00
  RG 1 2025-12-31 15:03:36+00:00 〜 2026-09-30 14:59:57+00:00
  RG 2 2025-12-31 15:00:25+00:00 〜 2026-09-30 14:58:52+00:00
ordered_atでソート
  RG 0 2025-12-31 15:00:25+00:00 〜 2026-01-27 21:26:32+00:00
  RG 1 2026-01-27 21:26:53+00:00 〜 2026-02-24 02:31:19+00:00
  RG 2 2026-02-24 02:33:09+00:00 〜 2026-03-23 11:34:31+00:00

どちらも返った行は 3,627行で、結果は同じです。ソートなしでは、どの行グループも1月〜9月の値を含むため、最小値・最大値では1つも飛ばせませんでした。 並べ替えたファイルでは、3月1日を含む行グループは1つだけで、10倍ほど速くなりました。並べ替えたほうが、ファイルも 14,671,830 バイトから 14,058,080 バイトへ少し小さくなりました。

DuckDB の EXPLAIN ANALYZE では、読んだ行グループの数が表示されます（表示を一部省いています）。

Total Time: 0.0033s
Data Read: 538.9 kB
Table Scan
 Function: PARQUET_SCAN
 Filters:
 (ordered_at >= '2026-02-28 15:00:00+00'::TIMESTAMP WITH TIME ZONE) AND (ordered_at < '2026-03-01 15:00:00+00'::TIMESTAMP WITH TIME ZONE)
 Total Files Read: 1
 Row Groups Scanned: 1 / 10
 3,627 rows

• 1よく絞り込む列で並べてから書く日時・ID・店舗など。並べないと最小値・最大値の幅が全体と同じになり、読み飛ばせない
• 2行グループを1つにしないpyarrow の既定は最大約105万行。行が少ないと1つになり、読み飛ばす単位が無い
• 3効いたかは数字で確かめるDuckDB の Row Groups Scanned、読み込み量（Data Read）で確かめる

行グループの大きさは、書くツールで違いました。pyarrow は最大 1,048,576行、DuckDB の COPY ... TO ... (FORMAT parquet) では、同じ100万行が9つの行グループ（先頭は124,576行）に分かれました。公式の仕様のページは、行グループを大きく（512MB〜1GB）することを勧めています（HDFS などで大きなファイルを読む前提の値です）。

CSVで型が崩れる例とParquetの型

この節では、CSV に保存して読み戻すと何が変わってしまうのかと、Parquet ではどう残るのかが、実行結果で分かります。

CSV には型の情報が無いため、読む側が中身から型を推測します。その推測で、先頭の0・日時・null・整数の欠け・配列が変わりました。 2行だけの表を、CSV と Parquet に書いて pandas で読み戻しました。

df = pd.DataFrame({
    "store_code": ["00123", "04560"],
    "ordered_at": pd.to_datetime(["2026-10-29 09:00:00.123456", "2026-10-29 23:59:59.000000"]).tz_localize("Asia/Tokyo"),
    "coupon": [None, ""],
    "qty": pd.array([3, None], dtype="Int64"),
    "paid": [True, False],
    "big_id": [9007199254740993, 1],
    "memo": ["カンマ,あり", '改行\nあり "引用"'],
    "tags": [["a", "b"], []],
})
df.to_csv("t.csv", index=False);  c = pd.read_csv("t.csv")
df.to_parquet("t.parquet");       p = pd.read_parquet("t.parquet")

書き出された CSV です。

store_code,ordered_at,coupon,qty,paid,big_id,memo,tags
00123,2026-10-29 09:00:00.123456+09:00,,3,True,9007199254740993,"カンマ,あり","['a', 'b']"
04560,2026-10-29 23:59:59.000000+09:00,,,False,1,"改行
あり ""引用""",[]

• Parquet では、8列すべての型と値が元のとおりに戻りました。 配列の列だけ、Python のリストではなく NumPy の配列で戻るため、df.equals(p) は False になりました。
• CSV でも、dtype={'store_code': 'str'}・parse_dates=['ordered_at'] を指定すれば戻せます。ただし100万行で試すと、日時は datetime64[us, UTC+09:00]（地域名ではなく時差だけ）になり、数量は int32 から int64 に変わり、クーポンの null（599,706件）と空文字（100,543件）は、keep_default_na=False を付けると両方が空文字の 700,249件にまとまりました。CSV には「null と空文字の違い」を書く場所そのものが無いためです。
• DuckDB の read_csv は、"00123" を VARCHAR（文字）と推測して先頭の0を残しました。推測の結果は読む道具によって変わります。

CSV を Python で読み書きするときの指定と文字化けの対策は、関連記事「PythonでCSVを読み書き｜コピペ用テンプレートと文字化け対策」で扱っています。

PythonでParquetを読み書きする（pandas・pyarrow）

この節では、pandas と pyarrow で Parquet を読み書きする基本の書き方と、よく使う引数が分かります。

pandas の to_parquet・read_parquet は、中で pyarrow（または fastparquet）を使います。 pandas だけを入れた環境では動かず、pyarrow を入れます。pandas 3.1.0 の公式ドキュメントでは、engine の 'fastparquet' と 'auto' は非推奨になり、engine を省くか 'pyarrow' を指定する形が案内されています。

python3 -m venv .venv
. .venv/bin/activate
pip install pyarrow pandas duckdb

pandas で書く・読む

import pandas as pd

df.to_parquet("orders.parquet")                         # 既定は snappy
df.to_parquet("orders_zstd.parquet", compression="zstd") # 圧縮を変える
df.to_parquet("orders.parquet", index=False)            # インデックスを保存しない

d = pd.read_parquet("orders.parquet")                                    # 全部
d = pd.read_parquet("orders.parquet", columns=["category", "price"])    # 列を選ぶ
d = pd.read_parquet("orders.parquet", filters=[("category", "=", "家電")])  # 行を絞る

pyarrow で書く・読む

import pyarrow as pa, pyarrow.parquet as pq

t = pa.Table.from_pandas(df, preserve_index=False)
pq.write_table(t, "orders.parquet", compression="zstd", row_group_size=100_000)

t2 = pq.read_table("orders.parquet", columns=["price"])
print(pq.read_metadata("orders.parquet").num_row_groups)
print(pq.read_schema("orders.parquet"))

1つのファイルに追記はできない

Parquet のファイルには、あとから行を書き足せません。 フッターが末尾にあり、全体を書き終えてから作られるためです。手元で確かめた動きは次のとおりです。

w = pq.ParquetWriter("app.parquet", t.schema)   # 開いている間は何回でも書ける
w.write_table(t); w.write_table(t); w.close()
# → 行 6・行グループ 2（3行のテーブルを2回）

pq.write_table(t, "app.parquet")                 # 同じ名前に書くと上書き
# → 行 3

毎日のデータを足していくときは、ファイルを1つずつ増やし、フォルダーごと読みます（次の DuckDB とパーティションの節）。pandas の使い方全般は、関連記事「pandasの使い方 逆引き81選｜pandas 3.0の実行結果つき」で扱っています。

DuckDBでParquetを開く・SQLで集計・CSVと変換

この節では、Parquet ファイルの中身を開いて見る方法と、SQL での集計、CSV との相互変換が分かります。

DuckDB は、Parquet ファイルをテーブルのように SQL で直接読めます。 取り込みの作業は要らず、FROM にファイル名を書くだけです。

import duckdb
con = duckdb.connect()
print(con.sql("DESCRIBE SELECT * FROM 'conv.parquet'"))
print(con.sql("SELECT * FROM 'conv.parquet' LIMIT 3"))

┌──────────┬──────────────────────────┬────────────┬──────────┬────────┬───────┬─────────┐
│ order_id │        ordered_at        │ store_code │ category │ price  │  qty  │ coupon  │
│  int64   │ timestamp with time zone │  varchar   │ varchar  │ double │ int64 │ varchar │
├──────────┼──────────────────────────┼────────────┼──────────┼────────┼───────┼─────────┤
│        1 │ 2026-09-19 11:24:14+09   │ 00268      │ 家電     │ 1227.0 │     8 │ SALE10  │
│        2 │ 2026-06-18 00:30:32+09   │ 00357      │ 食品     │  231.0 │     3 │ NEW     │
│        3 │ 2026-02-20 07:49:18+09   │ 00473      │ 家電     │  501.0 │     6 │ NULL    │
└──────────┴──────────────────────────┴────────────┴──────────┴────────┴───────┴─────────┘

CSV から Parquet へ、Parquet から CSV へ

COPY (SELECT * FROM read_csv('orders.csv'))
  TO 'conv.parquet' (FORMAT parquet, COMPRESSION zstd);

COPY (SELECT * FROM 'conv.parquet') TO 'back.csv' (HEADER);

• CSV を経由した Parquet では、数量の列が int32 ではなく int64（BIGINT）になりました。CSV の時点で型の情報が消えているため、DuckDB が推測した型で書かれます。Parquet に直すときは、必要なら CAST や read_csv の types で型を決めてから書きます。
• DuckDB の公式ドキュメントによると、COPY ... TO の Parquet の既定の圧縮は snappy です。

フォルダーの Parquet をまとめて読む

SELECT category, sum(price) FROM read_parquet('daily/*.parquet') GROUP BY 1;
SELECT * FROM read_parquet(['a.parquet', 'b.parquet'], union_by_name = true);
SELECT * FROM read_parquet('daily/*.parquet', filename = true) LIMIT 5;  -- どのファイルの行か

union_by_name は、列の並びや有無が違うファイルを、列名で合わせて読む指定です。指定しないと、最初のファイルのスキーマで読みます（エラーの節に原文があります）。

パーティション分割（hive形式のフォルダー）

この節では、Parquet をフォルダーに分けて保存する「パーティション分割」の形と、読み飛ばしの効果が分かります。

パーティション分割は、「month=2026-03」のような名前のフォルダーに分けて保存し、フォルダー名を列として扱う方法です。 この形は Hive が使い始めたため「hive 形式」と呼ばれ、pyarrow・DuckDB・Spark・Athena・BigQuery が読めます。

import pyarrow.compute as pc
t2 = t.append_column("month", pc.strftime(t["ordered_at"], format="%Y-%m"))
pq.write_to_dataset(t2, "part", partition_cols=["month"], compression="zstd")

part/month=2026-01/01c4ab9e2065485093c66d5e11579514-0.parquet 1669916
part/month=2026-02/01c4ab9e2065485093c66d5e11579514-0.parquet 1460678
part/month=2026-03/01c4ab9e2065485093c66d5e11579514-0.parquet 1695738
...
part/month=2026-09/01c4ab9e2065485093c66d5e11579514-0.parquet 1555580

SELECT month, count(*)
FROM read_parquet('part/*/*.parquet', hive_partitioning = true)
WHERE month = '2026-03' GROUP BY 1;
-- EXPLAIN の表示: File Filters: month = '2026-03' / Scanning Files: 1/9

• フォルダー名で絞れるため、統計値を見る前にファイルごと読み飛ばせます。 DuckDB は9つのファイルのうち1つだけを開きました。
• pyarrow で読むと、month の列は dictionary<values=string> 型になりました。pyarrow の公式ドキュメントも、パーティションの列は dictionary 型（pandas では categorical）で読まれると説明しています。
• 細かく分けすぎると、小さいファイルが大量にでき、開くだけで時間がかかります（小さいファイルの問題）。絞り込みによく使い、値の種類が多すぎない列（年月・地域など）を選びます。

S3 に置いた Parquet の一覧やコピーは、関連記事「aws s3コマンド一覧｜cp・sync・ls実行例とオプション早見表」で扱っています。

Spark・BigQuery・AthenaでのParquet（公式の範囲）

この節では、分析基盤で Parquet を使うときの基本を、各公式ドキュメントで確かめた範囲で分かります。手元では動かしていません。

BigQuery の読み込みの例です（公式ドキュメントの形）。

bq load \
--source_format=PARQUET \
mydataset.mytable \
gs://mybucket/mydata.parquet

Spark で読み書きする最小の形です（公式ドキュメントの例をもとにしています）。

df = spark.read.json("people.json")
df.write.parquet("people.parquet")
p = spark.read.parquet("people.parquet")          # スキーマはファイルから戻る
m = spark.read.option("mergeSchema", "true").parquet("data/test_table")

Athena・Spark・BigQuery のどれでも、「必要な列だけを SELECT する」「パーティションの列で絞る」の2つで、読む量（多くの場合は料金や時間）が変わります。SELECT * は Parquet の利点を消します。

Parquetのよくあるエラーと直し方（原文）

この節では、Parquet を扱うときに出るエラーの原文と、原因・直し方が分かります。すべて手元で実際に起こしたものです。

pyarrow・pandas のエラー原文

ImportError: Unable to find a usable engine; tried using: 'pyarrow', 'fastparquet'.
A suitable version of pyarrow or fastparquet is required for parquet support.
Trying to import the above resulted in these errors:
 - `Import pyarrow` failed. pyarrow is required for parquet support. Use pip, conda, or your preferred package management tool to install the pyarrow package.

pyarrow.lib.ArrowInvalid: Could not open Parquet input source '.../cut.parquet': Parquet magic bytes not found in footer. Either the file is corrupted or this is not a parquet file.

pyarrow.lib.ArrowInvalid: Could not open Parquet input source '.../x.csv': Parquet file size is 6 bytes, smaller than the minimum file footer (8 bytes)

pyarrow.lib.ArrowInvalid: No match for FieldRef.Name(nope) in id: int64
qty: int32

pyarrow.lib.ArrowInvalid: Failed to parse string: '5個' as a scalar of type int32

pyarrow.lib.ArrowInvalid: Casting from timestamp[ns] to timestamp[ms] would lose data: 1793264400123456789

pyarrow.lib.ArrowInvalid: ("Could not convert 'a' with type str: tried to convert to int64", 'Conversion failed for column v with type object')

FileNotFoundError: .../none.parquet

ナノ秒の時刻は、allow_truncated_timestamps=True を付けると 2026-10-29 09:00:00.123000 に切り捨てて書けました。pyarrow の既定（format の版 2.6）では、ナノ秒はそのまま書けます。ミリ秒で書く指定は、ナノ秒を読めない相手に渡すときに使います。

DuckDB のエラー原文

InvalidInputException: Invalid Input Error: No magic bytes found at end of file '.../cut.parquet'

BinderException: Binder Error: Referenced column "nope" not found in FROM clause!
Candidate bindings: "id"

ConversionException: Conversion Error: Error while reading file ".../mix/b.parquet": failed to cast column "qty" from type VARCHAR to INTEGER: : Could not convert string '5個' to INT32

In file ".../mix/b.parquet" the column "qty" has type VARCHAR, but we are trying to read it as type INTEGER.
This can happen when reading multiple Parquet files. The schema information is taken from the first Parquet file by default.

InvalidInputException: Invalid Input Error: Failed to read file ".../mix2.parquet": schema mismatch in glob: column "qty" was read from the original file ".../ok.parquet", but could not be found in file ".../mix2.parquet".
Candidate names: id, price
If you are trying to read files with different schemas, try setting union_by_name=True

最後のエラーは、メッセージのとおり union_by_name=true を付けると読め、無い列は NULL で埋まりました（[(1, 1, None), (2, 2, None), (3, 3, None), (5, None, 1.5)]）。型の違い（VARCHAR と INTEGER）は union_by_name では直らず、書く側で型を揃えるのが確実です。

Parquetを使う・使わないの判断表

この節では、手元のデータを Parquet にするか、CSV などのままにするかを、場面ごとに決められます。

行指向のデータベースで速く探す仕組み（インデックス）との違いを知りたいときは、関連記事「DBインデックス8選｜複合の列順・カバリング・ビットマップ・リビルド判断」で扱っています。

よくある質問

Q. Parquetとは何ですか？ A. 表のデータを列ごとにまとめ、列ごとに圧縮して保存するファイル形式です。Apache のオープンソースで、pandas・Spark・DuckDB・BigQuery・Athena など多くの道具が読み書きできます。CSV より小さく、一部の列だけを速く読めます。

Q. Parquetの読み方は？ A. 「パーケイ」と書かれることが多く、「パーケット」とも読まれます。もとはフランス語で、寄木張りの床を意味します。

Q. ParquetとCSVの違いは何ですか？ A. CSV は行ごとの文字のファイルで、型の情報がありません。Parquet は列ごとのバイナリのファイルで、列名と型、圧縮、統計値を持っています。手元の100万行では、CSV 57.5MB に対し Parquet（zstd）は 11.2MB でした。

Q. Parquetファイルの開き方は？中身を見たいです。 A. DuckDB で SELECT * FROM 'ファイル名.parquet' LIMIT 10 とするのが手軽です。Python なら pd.read_parquet で読み、pq.read_metadata で行グループや統計値を見られます。メモ帳では開けません。

Q. ParquetはExcelで開けますか？ A. Excel で直接は開けません。Power Query の Parquet コネクタの対応製品の一覧には、2026年10月29日時点で Power BI などが載っていて、Excel の記載はありません。Excel で見たいときは、DuckDB や pandas で CSV か xlsx に変換して渡します。

Q. ParquetをCSVに変換するには？ A. DuckDB なら COPY (SELECT * FROM 'a.parquet') TO 'a.csv' (HEADER);、pandas なら pd.read_parquet('a.parquet').to_csv('a.csv', index=False) です。手元では DuckDB で100万行を0.57秒で変換できました。

Q. snappy・zstd・gzip のどれを選べばよいですか？ A. 迷ったら既定の snappy、保存量を減らしたいなら zstd です。手元では zstd は snappy より約27%小さく、書き込み時間はほぼ同じでした。gzip は zstd と同じくらいの大きさで、書き込みが約60倍遅くなりました。

Q. pandasでread_parquetするとImportErrorになります。 A. pandas は Parquet の読み書きに pyarrow か fastparquet を使います。pip install pyarrow で入れます。エラーの原文は「Unable to find a usable engine; tried using: 'pyarrow', 'fastparquet'.」です。

Q. Parquetにすると必ず速くなりますか？ A. いいえ。手元では、全部の列を pandas で読む時間は CSV 0.19秒、Parquet 0.08〜0.16秒で、差は小さめでした。差が大きく開くのは、一部の列だけを読むときと、並べて保存した列で絞り込むときです。SELECT * ばかりなら効果は小さくなります。

まとめ

• Parquet は、列ごとにまとめて圧縮する列指向のファイル形式。ファイルは PAR1・行グループ・列チャンク・フッター（スキーマと統計値）でできている。
• 100万行で、CSV 57.5MB に対し Parquet は無圧縮 20.6MB・snappy 15.4MB・zstd 11.2MB。1列だけ読む時間は CSV の約10分の1、DuckDB の金額の合計は CSV の 57.5MB に対し 1.8MB だけを読んだ。
• CSV では先頭の0・日時・null と空文字・欠けのある整数・配列が崩れ、Parquet ではすべて元の型で戻った。
• 統計値による読み飛ばしは、絞り込む列で並べて書いたときに効いた（10個中1個の行グループだけを読み、約10倍速い）。パーティション分割ではファイルごと飛ばせた。
• 迷ったら snappy、保存量を減らすなら zstd。Excel で見る・1件ずつ更新するデータは Parquet に向かない。

次に読むとよい記事です。CSV を Excel で開いたときの文字化けは関連記事「CSV文字化けの直し方｜エクセルで今すぐ直す手順とUTF-8で直らない原因」で、pandas の操作は関連記事「pandasの使い方 逆引き81選｜pandas 3.0の実行結果つき」で扱っています。

参考・出典

確認日はいずれも 2026年10月29日です。

• Apache Parquet「Overview」：https://parquet.apache.org/docs/overview/
• Apache Parquet「File Format」：https://parquet.apache.org/docs/file-format/
• Apache Parquet「Configurations」（Row Group Size・Data Page Size）：https://parquet.apache.org/docs/file-format/configurations/
• Apache Arrow「pyarrow.parquet.write_table」：https://arrow.apache.org/docs/python/generated/pyarrow.parquet.write_table.html
• Apache Arrow「Reading and Writing the Apache Parquet Format」：https://arrow.apache.org/docs/python/parquet.html
• pandas「pandas.read_parquet」：https://pandas.pydata.org/docs/reference/api/pandas.read_parquet.html
• DuckDB「Reading and Writing Parquet Files」：https://duckdb.org/docs/stable/data/parquet/overview
• Apache Spark「Parquet Files」：https://spark.apache.org/docs/latest/sql-data-sources-parquet.html
• Google Cloud「Loading Parquet data from Cloud Storage」：https://cloud.google.com/bigquery/docs/loading-data-cloud-storage-parquet
• AWS「Use columnar storage formats」（Amazon Athena）：https://docs.aws.amazon.com/athena/latest/ug/columnar-storage.html
• Microsoft Learn「Parquet」（Power Query コネクタ）：https://learn.microsoft.com/en-us/power-query/connectors/parquet
• Wikipedia「Apache Parquet」：https://en.wikipedia.org/wiki/Apache_Parquet

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。