TSV を NDJSON に変換

検索エンジンやドキュメントストアは、タブ区切りのファイルをそのままでは受け付けません。Elasticsearch や OpenSearch の一括登録エンドポイントは改行区切りの JSON を読み取り、MongoDB の取り込みツールは既定で1行1つの JSON 文書を読み取ります。BigQuery にも同じ形式専用の読み込みモードがあります。

これは表を文書に変える作業でもあります。1行は表の中の位置であることをやめ、フィールド名を自分で持つ独立したオブジェクトになります。他の文書と異なるフィールド構成であっても、そのまま格納できます。

出力は完全な JSON オブジェクトが1行ごとに並んだもので、先頭の角括弧も、区切りのカンマも、末尾の角括弧もありません。この「何もない」ことこそがこの形式の本質です。読み込み側は1行読み、処理し、忘れて次に進めます。

そのため、このファイル全体は正しい JSON にはなりません。配列を期待するパーサーは2行目で失敗します。これは欠陥ではなく、メモリーの限られた処理が数億行のファイルを読み込めるようにするための性質です。

ヘッダー行の値がそのままフィールド名として使われます。スペースや記号もそのまま残るため、送り先のシステムによっては受け付けない場合があります。

Elasticsearch や MongoDB のドット記法では、フィールド名に含まれるピリオドがパスの区切りとして解釈されます。BigQuery はフィールド名が文字またはアンダースコアで始まり、英数字とアンダースコアだけで構成されていることを要求します。変換前に元のヘッダー行を直しておくほうが、後で大量の文書を直すより簡単です。

TSV には型がないため、変換のたびに推測が行われます。数値として読める値は数値に、trueとfalseは真偽値に、空欄はnullになり、それ以外はすべて文字列として扱われます。

この推測が問題になるのは識別子です。00123のような値は数値の123になり、先頭のゼロが失われます。数値化してほしくない列は、変換前に文字として明示しておくか、変換後に元に戻す作業が必要です。

出力に含まれるのは文書だけです。Elasticsearch や OpenSearch の一括登録エンドポイントは、各文書の前にどの操作を行うかを示す小さなメタデータの行を必要としますが、この変換はそれを書き出しません。

この行を挿入する処理を1回はさむ必要があります。それ以外の読み込み先——MongoDB の取り込みツールや BigQuery の読み込みジョブ——は、この出力をそのまま受け取れます。

検索対象になるのはたいてい扱いにくい列——商品の説明文や記事本文、レビューのテキストです。タブ区切りの表では、こうした値がまさに問題を起こす原因になります。貼り付けられたタブが列を増やし、改行が行を途中で終わらせます。

JSONではこれらは単なる文字列の中身として扱われます。タブは\t、改行は\nとしてエスケープされ、構造を壊すことはありません。検索用のテキストが、そのまま安全に運ばれるのはこのためです。

空の欄はnullとして書き出されます。ヘッダーより多い列を持つ行があっても、余分な列に名前が作られることはなく、その行だけに特別な扱いが記録されます。

これはマッピングに影響します。最初の数千件がnullで、その後に数値が現れる列は、たまたま最初に見た値によって型が決まってしまうことがあります。取り込み前にマッピングを明示しておくと安全です。

タブ区切りの読み取りと JSON の書き出しは、どちらもこのページに読み込まれた JavaScript が行います。ファイルがどこかへ送信されることはありません。

無料枠の上限は1ファイルあたり100MB、一度に100ファイルまでです。ファイル全体がメモリー上に構築されてから書き出されるため、数十メガバイト程度であれば余裕がありますが、上限に近いサイズではブラウザーのタブに負荷がかかります。それを超える規模であれば、ストリーミングで処理するスクリプトのほうが適しています。