Parquet を TSV に変換

Parquet は圧縮され、辞書化されたバイナリの入れ物です。`head` をかけても先頭の PAR1 の 4 文字のあとは意味のないバイトが並ぶだけで、`grep` は圧縮された値の中から何も見つけられず、`wc -l` が返す行数は実際の件数と何の関係もありません。この形式はエンジンに読ませるために作られていて、機械にエンジンが入っていなければ、ファイルは中身の分からない箱のままです。

このページが向いているのは、まさにその状況です。サーバー上に置かれた Parquet の抽出、管理者権限のないノートパソコン、何も入っていないコンテナ、質問への答えを二分以内に出さなければならないときに誰かから送られてきたファイル。行に変えてしまうのが、そのファイルについて何かを答えられる状態にいちばん早く到達する道です。

データの抽出にはカンマがあふれています。住所、商品名、自由記述のテキスト、ヨーロッパ式のロケールで書かれた数値。カンマ区切りのファイルはそのすべてを引用符でくるまなければならず、読み手のほうも引用と、エスケープされた引用符と、値の中の改行を正しく処理して初めて列の境目を見つけられます。

タブはその種のデータにはほとんど出てきません。だから区切り文字と中身が競合しなくなります。この変換のあと `cut -f3` は第 3 列を見つけ、`awk -F"\t"` も見つけ、`sort -t$'\t' -k2` は第 2 列で並べ替えられます。何も解析する必要がなく、分割するだけで済む。この違いが信頼性のすべてで、タブ区切りの出力を一行のシェルコマンドで正しく扱える理由です。

値の中のタブは例外です。スプレッドシートから来たデータより Parquet から来たデータのほうがまれですが、起こります。自由記述の欄には、もとに貼り付けられたものがそのまま残っているからです。そのときこの変換は、その項目を二重引用符でくるんで書き出します。ほかにやりようがなく、そうしなければ列が黙って一つ増えた行になってしまうからです。

その出力は正しく、本物のパーサーなら正しく扱います。`cut -f` はそうはいきません。タブの数を数えるだけで、引用符のことなど知らないので、その行から先はすべて一列ずれます。百万行のうち何行かだけがずれているように見えたら、`grep -c '"' output.tsv` を打てば一秒で分かります。

日時の列は ISO 8601 の文字列、たとえば `2024-03-11T09:30:00.000Z` として書き出されます。日付型を持たない形式では、これがいちばん筋の通った答えです。シェルの中で効いてくる性質があり、単純な文字列としての並べ替えが、そのままカレンダー順の並べ替えになります。上の桁から下の桁へ並んでいるからです。

だから `sort -k4` は日付の列に対して意図どおりに動き、先頭の 10 文字で `uniq -c` を取れば日ごとの件数が数えられ、範囲での絞り込みも文字列の比較で済みます。ロケール表記の日付や、エポック秒の数値では、どれもうまくいきません。テキストに変換することが操作を難しくするのではなく、むしろ楽にする、数少ない場面です。

Parquet はリストや構造体、マップをそのまま持てます。一行のテキストにはその居場所がないので、入れ子の列はその項目の中に JSON として書かれます。リストは `["a","b"]` のように、構造体はメンバー名を持つオブジェクトとして出てきます。

それはわざと、別の道具が読める形にしてあります。`cut -f5 output.tsv | jq ".[0]"` はすべての行のリストの先頭要素を取り出し、列に分解して名前を考え直すような手間もなく、入れ子構造がそのまま渡っていきます。その項目にはタブが含まれないので、周りに引用符が付くこともなく、パイプラインは単純なままです。テキストの注記がないバイナリ列は小文字の16進数として書かれます。これは可逆で、区切り文字を含まず、誰も文章と見間違えないからです。

null は空の項目として書かれます。どの行もタブの数は変わらないので、ファイルは長方形のまま整い、位置に頼る道具の列もずれません。それがこの変換に求められる振る舞いです。

ただし、それは元のファイルが丁寧に区別していた違いを消してしまいます。Parquet は列ごとに null 許容かどうかを記録し、null と空文字列を別のものとして扱いますが、出力の中ではどちらも同じ、タブとタブの間の 0 文字です。欠損値を数えたいなら `awk -F"\t" '$3==""'` は両方をまとめて数えてしまい、シェルのコマンドだけではもう一度分けることはできません。そこが重要なら、テキストからではなく、クエリエンジンで元のファイルから数を取ってください。

Parquet ファイルが列について知っていたこと ── それぞれの型、行数、列ごとの統計 ── はフッターの中にあり、タブ区切りのファイルには何も引き継がれません。出力にあるのは名前だけの見出し行と、そのあとに続く文字です。

スキーマを読める手段があるなら、変換の前に読んで書き留めておいてください。DuckDB なら `DESCRIBE SELECT * FROM "file.parquet"` の一文で済みます。何の手がかりもないときは、テキストそのものが唯一の証拠になります。`cut -f2 | sort -u | head` で列ごとに値の見本を見て、数字の並びだからといって量を表しているとは決めつけないことです。

Parquet は圧縮され、辞書化されているので、展開されるテキストはたいていファイルの何倍にもなり、それをはるかに超えることも珍しくありません。繰り返しの多いステータスコードの列は、元のファイルではほとんど場所を取らなくても、出力では行ごとにまるごとコピーされるコストがかかります。

見たことのないファイルを変換する前に、これを見積もっておく価値があります。展開された表は変換の間ずっとメモリに載っているからです。100 メガバイトの抽出が、ディスク上のサイズから思うよりずっと早く上限に届くことがあります。

Parquet の読み取りは、このページが必要になったときだけ読み込むライブラリで、書き出しはただの JavaScript です。ファイルを運ぶ通信は発生しないので、データ基盤の途中から取り出した抽出 ── たいてい集計もマスキングもされていない生の姿 ── が、読むためだけに誰かのサーバー上のコピーになることはありません。

待ち行列もアカウントもなく、上限は 1 ファイルあたり 100 MB です。それより大きなファイルには、より大きな変換ツールではなくクエリエンジンのほうが答えとしてふさわしく、しかも関心のある列だけを取り出せる分だけ、こちらのほうが優れています。

何かを入れられる状況なら、DuckDB を入れてください。取り込みの手順なしで Parquet ファイルをその場で読み、一文でスキーマを表示し、WHERE 句で実際に知りたかったことに答え、表全体をメモリに展開することもありません。その選択肢があるなら、テキストへの変換は常にそれより劣ります。

このページが役に立つのは、それができないときです。使用の制限された機械、同僚のノートパソコン、メールで届いたファイル、環境を用意するほどでもない五分の質問。行き先が本当にテキストのパイプラインである場合 ── 既存の awk スクリプト、昨日のダンプとの diff、タブ区切りを受け付ける何かへの貼り付け ── にも、これは正しい選択です。