NDJSON を CSV に変換

NDJSON は 1 行に 1 レコードを保証するので、得られる行数はファイルの行数そのものです。行の中の改行は JSON の中でエスケープされているので、データの側から行が増えることはありません。

ファイルが 41 万 2 千行なら 41 万 2 千行と見出しの行が返ります。出力がそれより少なければ、入力側に問題があったということです。空行は末尾のものを含めて読み飛ばされます。

NDJSON の各行は独立していて、2 行目が 1 行目と同じキーを持つ義務はありません。リクエストとエラー、ジョブ完了のように複数の種類のイベントを 1 つのファイルに吐き出すログはよくあります。

この変換はファイル全体で見つかったすべてのキーに列を用意し、なかった行のセルは空にします。結果は疎な表になりがちで、40 列のうち各行が使うのは 8 列、ということも起こります。イベントの種類でフィルターしてから変換するほうが読みやすい表になります。

1 行でも正しい JSON でなければ、変換はそこで止まり「この行は正しい JSON として読めません — 3 行目」のように行番号を示します。黙って読み飛ばすより有用な設計です。

ログの壊れた行は多くの場合、書き込み処理が途中で終わったことを意味します。行番号が分かれば末尾を削るか直すかは一つのコマンドで済み、何を失ったかもはっきりします。

構造化ログは request オブジェクトの method や user オブジェクトの id のように入れ子になっていることが多く、それらは request.method、user.id のようにパスを名前にした列に展開されます。

1 段から 2 段の入れ子はたいてい扱いやすい表になります。もっと深い構造や、丸ごとのペイロードを含む行は列数が急激に増えるので、興味のある部分木だけを先に取り出すほうが良い表になります。

数値は数字として、真偽値は true/false として、null は空のセルとして正確に書かれますが、CSV には型という概念がなく、開いたソフトが何であるかを推測します。

Excel はしばしば見当違いの推測をします。先頭のゼロが消え、日付らしきものは日付になり、長い数字の ID は末尾の桁を失います。識別子の列をテキストとして取り込むか、XLSX に変換して型を明示するのが確実です。

タグやエラーのフレームのような配列を持つ行は tags.0、tags.1 のように番号付きの列に展開され、ファイル中で最も長い配列に合わせた列数になり、その多くは空です。

配列が付随的な情報なら、変換の前に 1 つの文字列に結合したほうが読みやすい列になります。配列そのものが分析の対象なら、1 要素につき 1 行になるよう先に展開してください。

この変換はページに読み込まれた JavaScript だけで行われ、ファイルを運ぶ通信は一切発生しません。アカウントも 1 日の上限もなく、ネットワークタブで確認できます。

本番のログには IP アドレス、セッション識別子、リクエストのパス、しばしばトークン付きのクエリ文字列まで含まれます。それをどこかの変換サービスに送ることこそ、多くの組織で許されない行為です。

無料枠は 100 MB までです。数十メガバイトなら問題なく処理でき、数百メガバイトになるとブラウザーのタブが重くなり始めます。

NDJSON は改行の位置ならどこで分割しても安全な形式なので、大きなログは split で分けてから変換しても構いません。数ギガバイトの規模なら、ストリーミング処理の道具のほうが適しています。