Parquetとは｜20.44MBが1.11MBに、1列だけ読むと44.0msが1.4msに

20.44MBが1.11MBに、1列だけ読むと44.0msが1.4msに

同じ20万行をCSVとParquetで保存して測りました。大きさも読み込みも桁が変わります。

Parquetで何がどれだけ変わるのかを、実際に保存して測りました。用意したのは出張申請を模した20万行・8列の表です。

列は番号・課・目的・勤務地・日数・金額・海外かどうか・備考です。備考だけは行ごとに違う文字列にしました。

pacsv.write_csv(tbl, paths['csv'])
for name, comp in [('parquet-none', 'none'),
                   ('parquet-snappy', 'snappy'),
                   ('parquet-zstd', 'zstd')]:
    pq.write_table(tbl, os.path.join(TMP, f'{name}.parquet'), compression=comp)

形式                    大きさ    CSVとの比
CSV                      20.44 MB     100.0%
Parquet（圧縮なし）            13.22 MB      64.7%
Parquet（snappy）           2.22 MB      10.8%
Parquet（zstd）             1.11 MB       5.4%

上の表を見てください。20.44MBが1.11MBになりました。CSVの5.4%です。

列によって縮み方が違う

列          型        保存後の大きさ  1行あたり
id          INT32            896.7 KB      4.59 B
ka          BYTE_ARRAY         0.9 KB      0.00 B
mokuteki    BYTE_ARRAY         1.8 KB      0.01 B
site        BYTE_ARRAY         1.3 KB      0.01 B
nissu       INT32              1.4 KB      0.01 B
kingaku     INT32              6.0 KB      0.03 B
kaigai      INT32              0.9 KB      0.00 B
biko        BYTE_ARRAY       223.1 KB      1.14 B

課の列は20万行で0.9KBです。値が8種類しかないので、ほとんど場所を取りません。

一方で備考の列は223.1KBです。行ごとに違う文字列なので、まとめても縮みません。

読む列を絞ると速い

形式                    かかった時間  読んだ大きさ
CSV                         44.0 ms       20.44 MB
Parquet（zstd）                1.4 ms        1.11 MB

読む列                      かかった時間
1列（kingaku）                      2.0 ms
2列（kingaku, nissu）               2.2 ms
3列（＋ka）                          3.8 ms
備考も含む                           38.3 ms

金額の列だけを合計する処理は44.0ミリ秒が1.4ミリ秒になりました。31倍です。

ただし備考の列まで含めると38.3ミリ秒まで戻ります。CSVの44.0ミリ秒に近い値です。

Parquetとは、列ごとにまとめる保存形式

列ごとにまとめて保存するファイル形式です。行ごとに並べるCSVとは、並べ方が違います。

Parquetは、列ごとにまとめて保存するファイル形式です。公式の説明でも効率的なデータの保存と取り出しのために設計された、列を向いたオープンソースのデータファイル形式だとされています。

並べ方が違う

CSVは1行ぶんを続けて書きます。番号・課・目的・金額の順で1行、次の行も同じ順で並びます。

Parquetは1列ぶんを続けて書きます。番号だけを20万個、次に課だけを20万個、という並びです。

並べ方から出てくる利点

1. 同じような値が隣り合う。まとめて縮められる
2. 要る列だけ読める。他の列は触らずに済む
3. 列ごとに縮め方を変えられる。数値と文字列で別の方式が使える
4. 型が保存される。読むときに推測しなくてよい

前の節の結果は、1番目と2番目がそのまま出たものです。課の列が0.9KBまで縮み、1列だけ読むと1.4ミリ秒で済みました。

縮め方も選べる

同じ説明は、大量の複雑なデータを扱うための高性能な圧縮と符号化の方式を備えており、多くのプログラミング言語で対応されているとしています。

前の節でも、圧縮なしで13.22MB、方式を変えて2.22MBと1.11MBでした。同じ形式でも指定によって倍以上変わります。

Parquetが効く場面と効かない場面

読む列を絞る使い方で効きます。1件ずつ書き足す用途や、全列を読む用途では利点が出ません。

Parquetはどんな場面でも速くなるわけではありません。前の節の実測が、その境目を示しています。

効く場面

いちばん効くのは列の一部だけを使う集計です。20万行から金額を合計する処理が1.4ミリ秒でした。

保存の量も効きます。1.11MBと20.44MBなので、置き場の費用も、送る時間も18分の1になります。

効かない場面

1. 全列を読む。備考込みで38.3ミリ秒まで戻った
2. 1件ずつ書き足す。まとめて書く形式なので向かない
3. 1行を取り出す。列ごとに散っているので集め直しが要る
4. 人が直接開く。テキストではないので専用の道具が要る

2番目が実務では効きます。取引が発生するたびに1行追記するという使い方には向きません。

使い分ける

現実には、受け取りはCSVで、溜めるときにParquetへ変えるという組み方になります。取り込みの時点で1回だけ変換します。

形式そのものは公開されています。データがどう構造化され保存されるかを定めた公式の仕様が置かれているので、特定の製品に縛られません。