Parquet を CSV に変換

逆方向は明らかに変換だと分かります。テキストが型付きの列になり、誰もが結果を確認するはずだと思います。この方向は書き出しのように感じられます。データが出てくるだけで、何も圧縮されず、何も推測されません。ですがその印象は、特定の高くつく点で間違っています。

Parquet はスキーマを運んでいます。すべての列に宣言された型があり、フッターに記録され、クエリエンジンは行を読む前にそのフッターを読みます。CSV が持つのは名前の並んだヘッダー行だけです。ですからこの変換は値を無傷のまま移しつつ、その値についてファイルが知っていたすべてを捨ててしまいます。次にこのファイルを読むツールは、Parquet が実際に宣言していたのとはおそらく違う形で、もう一度型を推測し直すことになります。

真偽値は true と false になります。整数や浮動小数点数は 10 進表記で書かれます。文字列はそのまま書かれ、カンマやダブルクォート、改行を含む値だけが引用符で囲まれます。null は空欄になります。

これらはどれも元のスキーマに戻せません。Parquet が 32 ビット整数と宣言した列も、倍精度浮動小数点数と宣言した列も、どちらも小数点付きの数字に見えてしまい、真偽値の列と「true」という単語を含むテキスト列は区別できなくなります。もし CSV を独自のスキーマを持つ場所に読み込ませるなら、まず Parquet 側で列の型を確認してから——DuckDB の DESCRIBE が 1 行で表示してくれます——それを読み込み定義に書き込み、次のツールに推測させないでください。

タイムスタンプ列は ISO 8601 の文字列として書かれ、値はたとえば 2024-03-11T09:30:00.000Z のように出てきます。これは日付型を持たない形式にとって最も良い答えです。どの数字が月かについて曖昧さがなく、テキストとして正しく並べ替わり、どの言語・データベースも書式指定なしに読み取れます。

それでもテキストであることに変わりはありません。CSV の日付列は、読み込む側がその列を日付だと教わるまで日付計算に反応せず、表計算ソフトで開けば独自の解釈が適用されます。行き先がデータベースなら、読み込み時にタイムスタンプ型として宣言するだけで済み、意味は保たれます。行き先が人であれば、少なくとも ISO の形式はどの国でも同じ読み方になります。

Parquet は 64 ビット整数の型を持ち、変換を動かす JavaScript は 53 ビットまでしか整数を正確に表現できません。その範囲を超える値は、精度を失わずに数値として運ぶことができません。

丸める代わりに、変換はそれをテキストとして書き出します。注文番号やスノーフレーク ID は CSV の中で桁がすべて残り、安全な値と危険な値が混在する列は、数値だった項目と文字列だった項目が混ざりますが、CSV の中ではどのみち見分けが付きません。丸めるという代替案は、識別子が 1 だけずれたファイルを生みます。それは有効な識別子に見えたまま、いくつかのシステムを通り抜けたあとで初めて気づかれる種類の誤りです。

Parquet は入れ子のデータをネイティブに保持できます。文字列のリスト、名前付きメンバーを持つ構造体、マップなどが列になり得ます。CSV のセルは 1 つのスカラー値しか持たず、それ以外の構文がありません。

この変換はそれらの値をフィールド内に JSON として書き込みます。リスト列はセルの中で ["a","b"] のように現れ、JSON がカンマを含むため引用符が付きます。読み取る側がそれを解析するなら可逆ですが、行き先が表計算ソフトや取り込み画面なら、かなり扱いにくくなります。バイナリ列も似た扱いを受け、テキスト注記のないバイト配列は小文字の 16 進数として書かれます。少なくとも可逆で、明らかに文章ではありません。ファイルに入れ子の列があり、行き先が人間なら、変換の前にクエリで平坦化するか、それらを落としておくのがよいでしょう。

数倍を見込んでください。時にはそれ以上です。Parquet は値をバイナリ形式で書き、列ごとに個別に圧縮し、繰り返す値の列は辞書として 1 回だけ保存して小さな参照で済ませます。CSV にはそのどれもなく、すべての値がすべての行で、非圧縮の文字として書かれます。

取り込み時にいちばん強く縮んでいた列は、書き出し時にいちばん強く膨らみます。百万行にわたって繰り返される国コードは、Parquet の中ではほとんど場所を取りませんが、CSV の中では百万個の複製になります。結果をメールで送ろうとする前に知っておく価値があり、行き先が受け入れるなら CSV を gzip 圧縮すれば差の多くを取り戻せることも覚えておいてください。

CSV は BOM のない UTF-8 で、行の区切りは普通の改行です。スクリプトや取り込みツール、バージョン管理にとっては正しいのですが、それがまさに、Windows でダブルクリックして開いたときにアクセント付きの名前が文字化けする原因です。マークがないので Excel がシステムのコードページにフォールバックしてしまうからです。

データ、データの取得、テキストまたは CSV から、UTF-8 を選んで取り込めばそれを避けられ、識別子の列をテキストとして指定する機会も同時に得られます。Excel は先ほど捨てられた型を、独自の数値変換で勝手に当てはめてしまうからです。行き先が本当に表計算ソフトなら、Parquet を XLSX に変換したほうが文字コードの問題自体がなくなり、型も保持されます。

読み込み側は何かを書き出す前にすべての行を実体化するので、表全体が一度にメモリー上に存在します。数十メガバイトの Parquet なら快適ですが、これは圧縮形式であることに注意してください。控えめなファイルでも大量のテキストに膨らむことがあり、ファイルサイズが示すより早く上限に到達します。

大きな抽出には DuckDB が正しい道具です。Parquet を読み込み、どちらも保持することなく 1 つの文で CSV を書き出せます。必要な列だけを選ぶこともでき、それはたいてい良い答えでもあります。「データを CSV で」という要望の大半は、実際には数列だけの要望だからです。

Parquet の読み込みはこのページが必要なときに読み込むライブラリで、書き出しは普通の JavaScript です。ですから、ファイルを運ぶリクエストは一切ありません。これはほとんどの組み合わせより重要な点です。Parquet ファイルは普通、データ基盤の途中にある成果物で、マスキングや集計より前の段階のものだからです。

待ち行列もアカウントも、あなたの記憶容量以外の行数制限もありません。変換がうまくいくかどうかを決めるのは、展開後の表がメモリーに収まるかどうかだけで、それはフッターの行数からおおよそ見積もれます。

受け取る側が現代的なデータツールを何か持っているなら、元のファイルを送ってください。DuckDB、pandas、Polars、arrow を使う R、Spark、どのウェアハウスも Parquet を直接読み、型を保ち、ファイルを小さく保ち、何かが間違いうる工程をまるごと省きます。

CSV に変換するのは、受け取る側が本当に Parquet を扱えないときです。表計算ソフトしか持たない経理の同僚、形式を名指しする監査依頼、選択肢が固定のアップロード画面。これらは実在する、よくある状況で、この変換はそのためのものです。習慣にしてはいけません。Parquet から作られる CSV はすべて、自分が何を含んでいたかを忘れたコピーだからです。