Parquetとは？CSVとの違いから変換方法・閲覧ツールまでまるごと解説

大量のCSVファイルを集計するたびに「遅い」「重い」と感じているなら、Parquet（パーケット）形式を検討する価値があります。

Parquetはデータを列単位で保存するファイル形式で、CSVと比べてファイルサイズが数十分の1、クエリ速度は数倍に改善されるケースがあります。

例えば以下のような、100万行×9列の売上のサンプルデータでは、CSVでは163MBありますが、Parquetに圧縮することによって3.9MB（約40分の1）ほどのファイルサイズとなります。

この記事では、ParquetとCSVの違いを図解で示しながら、速さの理由、変換手順、中身の確認方法まで一通り押さえます。

Parquet（パーケット）とは？概要と読み方

Parquet（読み方：パーケット）は、Apache Software Foundationが管理するオープンソースの列指向（カラムナ）ファイル形式です。

もともとはTwitter社とCloudera社が、Googleの論文「Dremel」のデータレイアウトをオープンソース実装したものとして2013年に公開されました。

Parquetが「データ分析のデファクトスタンダード」と呼ばれるのには3つの理由があります。

1. クラウド分析基盤が標準対応している — Amazon Athena、Google BigQuery、Azure Synapse、Databricks、Snowflakeなど主要なサービスがParquetをネイティブにサポートしています
2. 言語を問わず使える — Python（pandas/pyarrow）、R（arrow）、Java、Rust、Go向けのライブラリが揃っています
3. CSVの弱点を構造的に解消する — 型情報の欠如、圧縮効率の悪さ、列選択読み込みの不可能さといったCSVの課題を、フォーマットレベルで解決しています

拡張子は .parquet です。バイナリ形式のため、テキストエディタで直接開くことはできません（閲覧方法は後述します）。

CSVとParquetの決定的な違い — 行指向 vs 列指向 図解

CSVとParquetの最大の違いは、データの「並べ方」にあります。

CSVの保存イメージ（行指向）

CSVは行指向です。1行のデータが、そのまま横一列に書かれています。

名前,年齢,部署,給与
田中,30,営業,450000
佐藤,25,開発,500000
鈴木,35,営業,480000

「年齢」列だけを読みたい場合でも、CSVではファイルの先頭から末尾まで全行を走査して、カンマで区切って2番目の値を取り出す必要があります。

100列あるCSVから1列だけ取り出す場合でも、残り99列分のデータを読み飛ばす処理が発生するため、データ量に比例して処理のための時間も大きくなります。

Parquetの保存イメージ（列指向）

Parquetは列指向です。同じ列のデータが物理的にまとまって保存されます。

[名前]: 田中, 佐藤, 鈴木, ...
[年齢]: 30, 25, 35, ...
[部署]: 営業, 開発, 営業, ...
[給与]: 450000, 500000, 480000, ...

「年齢」列だけ必要なら、年齢のブロックだけをピンポイントで読むことができます。他の列はディスク上にあっても一切触りません。

フィルタリングや集計作業などですべての列のデータを必要とすることは稀なので、「必要な列だけ読む」仕組みが、Parquetの速さとサイズ効率の根幹です。

ParquetとCSVの処理速度・サイズの違い（実測データ）

列指向と行指向の差は、実測するとはっきり数字に出ます。

「平均年齢を出す」クエリで比較する処理効率

従業員100万人のデータから平均年齢を計算する場面を考えます。

CSVの場合: ファイル全体を先頭から末尾まで読み込み、各行をカンマで分割し、「年齢」列を取り出して数値に変換し、合計と件数を計算します。100列のCSVでも、必要なのは1列だけなのに100列分のデータを読むことになります。

Parquetの場合: 「年齢」列のブロックに直接アクセスし、バイナリの数値データをそのまま合計します。他の99列のデータはディスクから読まれすらしません。

この差は列数が増えるほど大きくなります。5列のCSVなら差は小さくても、50列、100列と増えるにつれてParquetの優位性が際立ちます。

実測ベンチマーク（pandas + pyarrowでの速度・サイズ比較）

実際にどれくらい差が出るのか、NYC Yellow Taxi Trip Recordsを2025年1月〜2月の2ヶ月分をマージしたデータ（7,052,769行×20列）を使ってpandas + pyarrowで計測しました。

なお、2ヶ月分のParquetファイルの結合には筆者が開発したLeapRowsのファイル結合機能を使用しています。

import os
import time
from pathlib import Path

import pandas as pd
from tabulate import tabulate

# pip install pandas pyarrow tabulate

INPUT_CSV     = "./yellow_taxi_202501-2025-02.csv"
INPUT_PARQUET = "./yellow_taxi_202501-2025-02.parquet"

TARGET_COLUMNS = ["trip_distance", "fare_amount", "tip_amount", "total_amount"]
AGG_COLUMN   = "fare_amount"
GROUP_COLUMN = "passenger_count"
N_TRIALS = 3


def measure(func, n=N_TRIALS):
    """n 回実行して最小値・平均値を返す（秒）"""
    times = []
    for _ in range(n):
        start = time.perf_counter()
        result = func()
        times.append(time.perf_counter() - start)
    return result, min(times), sum(times) / len(times)


def file_size_mb(path):
    return os.path.getsize(path) / (1024 ** 2)


def main():
    csv_mb = file_size_mb(INPUT_CSV)
    pq_mb  = file_size_mb(INPUT_PARQUET)
    print(f"CSV: {csv_mb:.1f} MB / Parquet: {pq_mb:.1f} MB")

    # 特定列のみ読み込み
    _, csv_col_min, csv_col_avg = measure(
        lambda: pd.read_csv(INPUT_CSV, usecols=TARGET_COLUMNS))
    _, pq_col_min, pq_col_avg = measure(
        lambda: pd.read_parquet(INPUT_PARQUET, columns=TARGET_COLUMNS, engine="pyarrow"))
    print(f"列読み込み - CSV: {csv_col_min:.3f}s / Parquet: {pq_col_min:.3f}s")

    # 集計クエリ
    _, csv_agg_min, csv_agg_avg = measure(lambda: (
        pd.read_csv(INPUT_CSV, usecols=[GROUP_COLUMN, AGG_COLUMN])
          .groupby(GROUP_COLUMN)[AGG_COLUMN].agg(["mean", "sum"])))
    _, pq_agg_min, pq_agg_avg = measure(lambda: (
        pd.read_parquet(INPUT_PARQUET, columns=[GROUP_COLUMN, AGG_COLUMN], engine="pyarrow")
          .groupby(GROUP_COLUMN)[AGG_COLUMN].agg(["mean", "sum"])))
    print(f"集計クエリ - CSV: {csv_agg_min:.3f}s / Parquet: {pq_agg_min:.3f}s")


if __name__ == "__main__":
    main()

ファイルサイズ

同じデータでも、Parquetに変換するだけでファイルサイズが約7分の1に縮小しました。

特定列のみ読み込み速度（3回計測の最小値）

対象列: trip_distance, fare_amount, tip_amount, total_amount

19列あるデータから4列だけを取り出す処理で、Parquetは約32倍高速でした。CSVは19列すべてを読み込んでから4列を抽出しますが、Parquetは必要な4列のブロックだけを読みます。

集計クエリ速度（3回計測の最小値）

クエリ: passenger_countごとのfare_amountの平均・合計

まとめ

特にファイルサイズの削減効果は大きく、AWS Athenaのようなスキャンデータ量で課金されるサービスでは、Parquetに変換するだけでクエリコストも大幅に削減できます。

Parquetが圧倒的に速くて小さい4つの理由

実測で見た速度差・サイズ差は、Parquetの4つの設計特性から生まれています。

列プルーニング — 必要な列だけ読む

Parquetは列ごとにデータが物理的にまとまっているため、クエリに必要な列だけをディスクから読み込めます。この仕組みを**列プルーニング（Column Pruning）**と呼びます。

100列のテーブルから3列だけSELECTする場合、CSVは100列分のデータを全て読みますが、Parquetは3列分だけ読みます。ディスクI/Oが97%削減される計算です。

圧縮効率 — 同じ型が並ぶから劇的に縮む

CSVの1行には「名前（文字列）・年齢（数値）・部署（文字列）・給与（数値）」と異なる型のデータが混在します。混在するデータは圧縮しにくい。

Parquetは列ごとにデータをまとめるため、同じ型の値が連続して並びます。「営業, 営業, 開発, 営業, ...」のように同じ値が繰り返される列では**辞書圧縮（Dictionary Encoding）が効き、「1, 1, 2, 1, ...」のように短い符号で表現できます。数値列にはランレングス符号化（Run-Length Encoding）**も適用されます。

メタデータ — ファイル末尾の「目次」で読み飛ばし

Parquetファイルの末尾（フッター）には、各列の統計情報が記録されています。具体的には列ごとのmin値・max値、NULL件数などです。

たとえば WHERE age > 50 というクエリを実行する場合、フッターを先に読んで「この行グループのage列はmax=45」とわかれば、その行グループ全体を読み飛ばせます。これが**述語プッシュダウン（Predicate Pushdown）**です。

条件に合わない行グループをファイルを開く前にスキップできるため、大規模データでの集計が高速になります。

スキーマ内蔵 — 型の自動判定・変換コストゼロ

CSVのデータは全て「文字列」です。"30" が数値なのか文字列なのか、ファイル自体は区別しません。読み込み側が毎回、型推論や型変換（デシリアライズ）を行う必要があります。

Parquetはファイル内にスキーマ（各列の名前と型）を保持しています。INT32、DOUBLE、UTF8 といった型情報がバイナリレベルで定義されているため、読み込み時の型推論が不要です。

この差は、数百万行のファイルを読み込む場面で処理時間に直結します。

「中身が見れない！」Parquetファイルを開く・確認する方法

Parquetはバイナリ形式のため、CSVのようにテキストエディタやExcelでは開けません。「変換したら中身が確認できなくなった」という声は多いですが、専用ツールを使えばCSVと同じ感覚でデータを閲覧できます。

GUIビューア（Tad / ParquetViewer）

Parquetファイルを確認するGUIツール比較：

どちらも無料で、ドラッグ&ドロップで使えます。

VS Code拡張機能

開発環境から離れずにParquetの中身を確認したい場合は、VS Code拡張機能が便利です。

• Data Wrangler（Microsoft公式）：Parquetファイルをテーブル形式で表示。フィルタリングやソートもGUI上で操作できます
• parquet-viewer：ParquetをJSON形式に変換して表示するシンプルな拡張機能

エクスプローラーからファイルをクリックするだけで中身が表示されるため、作業フローを中断しません。

コマンドライン（DuckDB CLI）

スキーマや統計情報を素早く確認するなら、DuckDB CLIが最も確実で使いやすい選択肢です。SQLでParquetファイルを直接クエリできます。

-- スキーマ確認
DESCRIBE SELECT * FROM 'data.parquet';

-- 先頭5行を表示
SELECT * FROM 'data.parquet' LIMIT 5;

-- メタデータ確認
SELECT * FROM parquet_metadata('data.parquet');

DuckDBはインストールが簡単で（Homebrewなら brew install duckdb）、Parquetのネイティブ読み込みに対応しているため、追加ライブラリなしで使えます。

その他のCLIツール（parquet-tools等）も存在しますが、パッケージ名やコマンド体系がバージョンによって異なります。迷う場合はDuckDB CLIを使うのが無難です。

CSVからParquetへの変換方法3選（比較表つき）

Python（pandas + pyarrow）で変換する（手軽度★★）

Pythonが使える環境なら、pandasで3行で変換できます。

pip install pandas pyarrow

import pandas as pd

# CSV → Parquet
df = pd.read_csv('data.csv')
df.to_parquet('data.parquet', engine='pyarrow', compression='snappy')

# Parquet → 読み込み（特定列のみ）
df = pd.read_parquet('data.parquet', columns=['name', 'age'])

compression パラメータで圧縮方式を指定します。snappy は速度重視（読み書きが速く、多くのケースで推奨）、gzip はサイズ重視（圧縮率が高い分、書き込みが遅くなる）、zstd はバランス型です。省略時の挙動はpandasおよびpyarrowのバージョンによって異なるため、用途に合わせて明示的に指定するのがおすすめです。

スキーマを明示的に指定したい場合や、大規模ファイルを分割して変換したい場合は、pyarrowのAPIを直接使うとより細かい制御が可能です。

import pyarrow as pa
import pyarrow.parquet as pq
import pyarrow.csv as pa_csv  # Pythonの標準ライブラリ csv との名前衝突を避けるため pa_csv でインポート

# CSVを読み込み（型を明示指定）
table = pa_csv.read_csv('data.csv')

# Parquetに書き出し（行グループサイズを指定）
pq.write_table(table, 'data.parquet', row_group_size=100000)

ブラウザ完結ツールで変換する（手軽度★★★）

プログラミング環境がない場合や、単発のファイル変換にはブラウザ完結型のツールが手軽です。

LeapRows（※筆者開発ツール）は、CSVファイルをドラッグ&ドロップするだけでParquet形式に変換できるブラウザツールです。データはブラウザ内で処理され、サーバーに送信されません。Pythonや追加ソフトのインストールは不要で、変換後のParquetファイルはそのままダウンロードできます。

ブラウザ完結型ツールを選ぶ際は、データがサーバーに送信されるかどうかを確認してください。業務データや個人情報を含むCSVを扱う場合、ローカル処理型のツールを選ぶのが安全です。

クラウドETLサービスで変換する（手軽度★）

大量のCSVファイルを定期的にParquetへ変換するなら、クラウドETLサービスの利用が現実的です。

• AWS Glue: S3上のCSVをジョブで自動変換。スキーマ検出（Crawler）も自動化可能
• Azure Data Factory: CSVソースからParquetシンクへのコピーアクティビティで変換
• Google Cloud Dataflow: Apache Beamベースのパイプラインで変換

これらはCSVが数十GB〜TBスケールで、日次・週次の定期変換が必要な場面に向いています。単発の変換にはオーバースペックなので、PythonかブラウザツールでCSVからParquetに変換し、変換後のParquetをクラウドストレージにアップロードする方が効率的です。

Parquetの弱点・向かない場面と移行チェックリスト

Parquetは万能ではありません。弱点を理解したうえで、CSVとの使い分けを判断するのが実務的なアプローチです。

人間が直接読めない・特殊文字のエラー等（弱点）

バイナリ形式のため中身が見えない。 テキストエディタでは文字化けした内容が表示されるだけで、CSVのように「ちょっと目で確認」ができません。前述のビューアツールで対処できますが、非エンジニアのチームメンバーとデータを共有する場面では、CSVやExcelのほうが受け渡しがスムーズです。

列名に特殊文字があるとエラーになりやすい。 セミコロン（;）、括弧（()）、改行、タブなどが列名に含まれていると、変換時や読み込み時にトラブルが発生することがあります。CSVからParquetに変換する前に、列名を英数字とアンダースコアに正規化しておくのが確実です。

追記・更新・削除には向かない。 Parquetは「一括書き込み・繰り返し読み取り」に最適化された形式です。行単位のINSERTやUPDATEが頻繁に発生するユースケースには、RDBMSや行指向のストレージが適しています。

CSVのままでよいケース

以下に該当するなら、無理にParquetへ移行する必要はありません。

• データが数千行以下: ファイルサイズも処理速度もCSVで十分。変換の手間がメリットを上回ります
• 非エンジニアとの手動共有が主目的: ExcelやGoogleスプレッドシートで直接開けるCSVのほうが、やり取りの摩擦が少ない
• 行単位のCRUDが頻繁: 在庫管理や受注管理のように、1行ずつ追加・更新・削除する運用にはParquetは不向き

CSVからParquetへ移行すべき3つのサイン

逆に、以下のサインが1つでも当てはまるなら、Parquetへの移行を検討する価値があります。

1. CSVファイルが数百MB以上になっている — ファイルの読み込みだけで数十秒かかるなら、Parquetに変換するだけで体感速度が変わります
2. 「特定の列だけ集計したい」場面が多い — 100列中3列だけ使う集計が頻繁なら、列プルーニングの恩恵が大きい
3. Athena・BigQuery・Databricksなどのクラウド分析基盤を使っている — これらのサービスはParquetに最適化されており、スキャンコストとクエリ速度の両方が改善されます

まとめ

• Parquetは列指向のバイナリファイル形式。「必要な列だけ読む」「圧縮が効く」「型が保持される」が三大メリット
• CSVの代替ではなく、用途に応じた使い分けが正解。数千行のデータや非エンジニアとの共有にはCSVが便利
• 変換はPythonなら3行、ブラウザツールならドラッグ&ドロップで完了する。移行のハードルは想像より低い
• 「中身が見えない」問題はTadやDuckDB CLIで解決できる。Parquetだからといってデータの確認に困ることはない