XLSX を Parquet に変換

ワークブックの他の出力先はすべて 1 レコードずつ順に保存します。Parquet はフィールドごとにまとめて保存します。5 万件の注文日をすべて並べ、次に都市をすべて並べ、次に金額をすべて並べるという具合です。これは書式の好みではなく、この形式が存在する理由そのものです。

200 列のうち 2 列だけを読むクエリは全行ではなく 2 列分のバイトだけに触れます。列内で値が繰り返されるほど圧縮も効きます。ファイル末尾には自分自身のスキーマが記録されているので、1 行も読まずに列名と型を知ることができます。

型は宣言ではなく値から推定されます。ある列の空でない値がすべて真偽値なら BOOLEAN、すべて 32 ビットの範囲内の整数なら INT32、整数でない数値や範囲外の数値を含むなら DOUBLE、それ以外はすべて文字列になります。

判定はファイル全体を読んでから行われ、先頭だけを見て決めることはしません。読み込みは遅くなりますが、最初の千行がきれいで 4 万行目が違う、という本番でだけ壊れる失敗のクラスをまるごと消せます。

5 千件の数値のあとに SW1A 1AA のような郵便番号が 1 つ混じっていれば、その列は文字列列になり、数値だった部分も文字列として書かれます。

先頭行の型を採用し、合わない値を null にするという代替案は、正しく読み込めて静かに値を消してしまうファイルを作ります。文字列列であれば失われる値はなく、あとから 1 つの式でキャストできます。

Parquet は 64 ビット整数の型を持ちますが、ここでは使われません。値は JavaScript の数値として届き、それは 53 ビットの整数精度しか持たないので、INT64 として書けばすでに失われている正確さを約束することになります。

9 千兆を超える識別子を扱うなら、変換前にスプレッドシート側でテキストとして保存しておけば文字列列としてそのまま届きます。

5 万行 6 列のシートで、Parquet ファイルは 301 KB でした。同じデータは .xlsx で約 4.3 MB、タブ区切りテキストで約 1.8 MB でした。

差は圧縮だけによるものではありません。列の中で繰り返される値は 1 度だけ保持され参照されるので、都市名や商品コードの列はほとんど費用がかかりません。差が大きく出るのは業務データで、ほぼすべて異なる自由記述の列では差は縮まります。

スプレッドシートの日付セルが保持しているのは数値と表示書式です。変換はその数値をそのまま書くので、2024 年 1 月 1 日は 45292 になり、整数として型付けされます。

出力にはタイムスタンプの意味は付きません。クエリを実行する側で日数にエポック日を足す 1 行の式を使うほうが、ワークブックをテキストに変換し直すより確実です。

DuckDB は FROM 句に直接指定でき、pandas は 1 回の呼び出しで読み込め、Spark とその上のクエリエンジンはネイティブなテーブル形式として扱います。ファイルは PAR1 の 4 バイトで始まり終わるので、それだけで見分けられます。

読み込んだあとまず確認すべきは推定された型です。数値だと思っていた列が文字列として届いたら、それはスプレッドシートについての本当の事実を教えてくれています。

変換はワークブックの最初のシートだけを読みます。Parquet は 1 つのスキーマを持つ 1 つのテーブルなので、複数シートを 1 つのファイルに無理に統合することはできません。

複数のシートが重要なら、それぞれを別々に変換してクエリエンジン側で結合してください。それが複数のエンジンが設計されている使い方です。

スプレッドシートの読み込みも Parquet の書き出しも、あなたのブラウザーの中で行われます。顧客データや財務データの書き出しでは、これが決め手になることが多く、変換サービスへのアップロードそのものが方針で禁じられている場合もあるからです。

制約は料金プランではなくメモリーです。シート全体を行として読み込み、列に転置してから書き出すので、数百メガバイトを超えるとブラウザーのタブが厳しくなります。