CSV を Parquet に変換 — 型付き・圧縮済みで

CSV が自分自身について知っていることはヘッダー行だけで、ヘッダー行は名前の一覧にすぎません。amount が小数であること、is_active が真偽値であること、customer_id を計算に使ってはいけないことは示せません。読み込むツールごとに毎回推測し直され、推測の仕方はツールごとに微妙に違うので、同じデータが場所によって 3 通りに読み込まれることが起きます。

Parquet ファイルはスキーマ、行数、列ごとのメタデータを持つフッターで終わります。クエリエンジンはまずこのフッター——ファイル末尾の数キロバイト——を読み、1 行もデータに触れずに列名と型が分かります。これは便利さの話ではなく構造の話で、書いた本人がいなくても安全に渡せるファイルにしているのはこの仕組みです。

各列には 3 つのことが起き、それが重なります。値は 10 進のテキストではなく 2 進の形で書かれるので、CSV で 11 文字だった数字が 4 バイトになります。各列は Snappy——ここでの既定の符号化方式——で個別に圧縮されます。そして値が繰り返す列は辞書符号化され、異なる値だけを辞書ページに 1 度ずつ書き、列自体はその辞書への小さな整数の参照になります。

辞書は列ごとに、割に合う場合だけ適用されます。書き込み側は最初の 1000 個の値を調べ、その半分以下しか異なる値がなければ辞書を使います。国名やステータス、商品コード、通貨のような列が当てはまり、独自の自由記述テキストの列では辞書のほうが元データより大きくなるので使われません。業務データでの節約が大きく、独自の文章ばかりの表での節約が控えめなのはこのためです。

行は 1 つの塊ではなく、1000 行から 10 万行までの単位のグループとして書かれ、その中のページは 1 メガバイトを上限とします。グループ内の各列のかたまりは統計情報を持ち、この統計こそが走査を読み飛ばしに変える仕組みです。

これが「Parquet は速い」と言われる理由の実体です。日付範囲で絞り込むクエリはフッターを読み、ある行グループが指定範囲の外にしか値を持たないと分かれば、そのグループをまったく読みません。40 列のうち 2 列だけを名指しするクエリは、その 2 列分のバイト数だけを読みます。CSV ではどちらもできません。何がどこにあるかを知るには先頭から読むしかないからです。

型は宣言されるのではなく、値から推測されます。各列を全部読み、すべて真偽値なら BOOLEAN、すべて 32 ビットの範囲内の整数なら INT32、整数でないか大きすぎる数字なら DOUBLE、それ以外はすべて文字列になります。null は判定に加わらないので、欠損のある数値列は数値のままです。

1 つでも例外的な値があれば列全体がテキストになり、これは制限ではなく意図的な設計です。先頭の行から型を決めると、数字で始まる列は整数列として書かれ、後から出てくる数値でない値はすべて null になり、警告もなく行が消えたファイルができます。文字列列は目に見え、1 つの式でキャストでき、何も失いません。数値を期待した列がテキストで届いたら、キャストに失敗する値を調べれば、注釈や合計、「なし」という文字が入った少数の行が見つかります。それぞれがそのデータの本当の姿です。

この変換は型推測をしながら CSV を読むので、書き込み側が列の型を決める時点で 007 はすでに数字の 7 です。結果の INT32 列は、すでに間違っていた値を忠実に記録しているだけです。Parquet はこれで非難されがちですが、それは筋違いです。損失はテキスト解析の段階で起き、それは他のあらゆる CSV リーダーが行う同じ段階です。

危険なのは計算に意味がない列——郵便番号、部品番号、電話番号、口座参照番号、ゼロ埋めされた番号です。抽出元を自分で管理できるなら、それらの列を引用符付きか接頭辞付きで書き出せば文字列として無傷で届きます。管理できないなら、恒久的な場所にファイルを置く前に出力の列を確認してください。Parquet に移す意味は、そのファイルが二度と作り直されないことにあるからです。

識別子、商品コード、都市名、数量、価格、フラグの 6 列 5 万行の表で、実測した Parquet の出力は 301 KB でした。同じデータをタブ区切りテキストで書くとおよそ 1.8 MB で、CSV はフィールドを区切るバイトとカンマを含む値への引用符が違うだけでほぼ同じです。

これはおよそ 6 分の 1 への削減で、コードやカテゴリーが繰り返す業務データなら妥当な見込みです。独自の自由記述テキストばかりのファイルはこれよりかなり劣ります。辞書にも 2 進符号化にも生かせる材料が少ないからです。どちらの数字も CSV に圧縮をかけない前提で、gzip をかければ差の一部は縮まりますが、その代わり全体を展開するまで検索できなくなります。

設定は不要です。DuckDB は FROM 句でファイルを直接読み、pandas は 1 回の呼び出しで読み込み、Spark はネイティブなテーブル形式として扱います。ファイルの先頭と末尾には PAR1 という 4 バイトがあり、それぞれのツールがフッターを読む前にこれで Parquet だと認識します。

読み込んだ後にまず見るべきは、先頭 10 行ではなく推測されたスキーマです。数値だと思っていた列が文字列として届いていたら、それは CSV についての本当の事実を教えています。3 つの表と結合してウェアハウスにコピーした後より、今知るほうがずっと安上がりです。テーブルに入れる際にキャストするなら列ごとに 1 つの式で済み、何も考えずキャストすると、守られたはずの行が結局失われます。

表全体はメモリー上に保持されます。CSV は行に解析され、行は列に転置され、列が書き出されます。数十メガバイトなら何の問題もなく変換でき、数百メガバイトあたりからタブが苦しくなります。これはプランの上限ではなく本当の天井です。アップロードもなく課金もないからです。

本当に大きな抽出には DuckDB が正しい道具で、CSV をディスクから読みながら 1 つの文で Parquet を書け、ファイル全体をメモリーに保持しません。2 ギガバイトの変換が 3 分の 2 で失敗するより、はっきりそう伝えるほうが役に立ちます。このページはたいていの場合にあたる「収まるファイル」のためのもので、何かをインストールするのが選択肢にない場合のためのものです。

この両方——CSV の解析と Parquet の書き込み——はこのページで動きます。必要に応じて読み込まれるライブラリで、ファイルをどこかへ運ぶ通信は一切ありません。データ基盤へ向かう CSV は、結合やマスキング前の生のダンプで、パイプライン中でいちばん加工されていないファイルであることが多く、それを変換サイトにアップロードすることは、まさにデータ保護方針が防ごうとしている手順そのものです。

また 1 段階分の心配が消えます。待ち行列も、行数の上限も、登録も要らないので、残る問いはファイルがメモリーに収まるかどうかだけで、それは見れば分かります。

人が読むものにとって Parquet は不向きな行き先です。バイナリで編集できず、適切なツールを持たない同僚はまったく開けません。レジストリがこの形式の対応状況を「ばらつきがある」と記録しているのはまさにこのためです。相手が機械ではなく人間なら、CSV かスプレッドシートを送ってください。

1 回だけ読み込んで捨てるようなロードにも不向きです。二度とクエリされないなら書き込みのコストは何も生みません。区切りテキストを直接読む一括ローダーのほうが最初から最後まで速いはずです。Parquet を選ぶべきなのは、同じデータが繰り返し走査され、絞り込まれ、結合され、保管され続けるときで、そのときこそ型付き列と読み飛ばせる行グループが元を取り始めます。