XML を NDJSON に変換

改行区切りの JSON は分割の手がかりとして、解析されたデータのいちばん外側にあるリストを使います。XML を解析した結果は常にルート要素名をキーとする 1 個のオブジェクトになり、そこにリストは現れません。入力が 1 個の値なら、出力は 1 行です。

これはファイルがどれだけ大きくても、繰り返し要素をいくつ含んでいても変わりません。1 万件のレコードを持つ 40 MB の書き出しは、40 MB の 1 行に変換されます。何も失われず、何も分割されません。もし欲しかったのが 1 万行だったなら、この変換だけではそれを得られていません。

うまくいく道筋は 2 段階です。まずファイルを JSON に変換し、次に jq に通します。繰り返し要素のあるパスを選び、それを反復し、コンパクト出力フラグを使って各オブジェクトを 1 行にします。1 個のコマンドで済み、スクリプトの中で繰り返し使え、何をレコードと見なすかという判断をあなた自身の手に残せます。

この判断は文書だけから機械的には決められません。RSS フィードならレコードは item 要素、SOAP のレスポンスなら本体の 3 階層下にあるかもしれず、銀行の書き出しならベンダーが取引と呼ぶことにした何かです。推測するツールは、たいていは正しくても、たまに間違えて読み込みを壊すという結果になります。

これはまったく使い道のない組み合わせではありません。入力が 1 個の大きな文書ではなく、たくさんの小さな XML 文書——請求書のフォルダー、マニフェストの束、イベントごとのペイロードの一群——であれば、1 ファイル 1 行がまさにローダーが求める形で、出力をつなげれば元の文書ごとに 1 レコードを持つ正しい NDJSON になります。

棚卸し用途にも向いています。リポジトリ内の設定ファイルをそれぞれ変換して連結すれば、何が書かれているかを問い合わせできるデータセットになり、これは他の方法ではなかなか得にくいものです。どちらの場合も、1 行という結果はこの変換が正しく仕事をしている証拠です。

レコードを分割したあとも、XML 由来の性質が 1 つ残ります。繰り返し要素は複数回現れたときだけ配列になります。タグ要素を 1 個だけ含むレコードは文字列に、2 個含むレコードはリストになります。同じ書き出しの中でも、行によって配列だったりそうでなかったりします。

スキーマオンリードの仕組みは最初に見たレコードから型を推定し、それ以降を拒否するか強制的に変換します。直す場所はローダーではなく jq の段階で、繰り返しうるすべてのフィールドを、書き出す各行で配列に正規化しておけば、下流の何かが見る前にストリームを均一にできます。

インデントなしのコンパクトな JSON で、キーは文書の順序どおり、末尾に改行が付きます。属性は @ を接頭辞に持つキーとして現れ、属性を持つタグの要素テキストは #text というキーの下に入ります。名前空間の接頭辞はキー名の中にそのまま残るため、soap:Body はコロンを含むキーになり、XML 宣言のある文書は ?xml という名前のトップレベルのキーを 1 個余分に持ちます。

この 2 つは読み込みの前に取り除く価値があります。コロンや疑問符を含むフィールド名は多くのクエリエンジンやテーブルスキーマで扱いづらいか無効であり、宣言はファイルについてのメタデータであってファイルの中のデータではありません。

数値に見える値は属性でも要素テキストでも解析されます。件数には便利ですが識別子には破壊的です。007 と書かれた注文番号は数値の 7 になり、1.0 と書かれたバージョン属性は 1 になります。データストアに入れると、これらは数値列になりパディングは全行から消えます。

一方で、恐れているほど悪くない挙動が 1 つあります。JavaScript の数値として表現できないほど長い整数は、丸められるのではなく文字列のまま残るので、19 桁の参照番号はそのまま保たれます。指数表記はこの保護を受けません。1e3 と書かれた値は 1000 になります。どちらの場合もエラーは出ません。あとで結合に使う参照番号があるなら、最初の読み込みより前、jq の段階で文字列に戻しておいてください。

NDJSON は jq でそのまま読め、pandas は lines オプションで読め、主要な倉庫ローダーの読み込み形式としても使われます。Elasticsearch の一括投入は各文書の前にアクション行が必要で、これはレコードを分割するのと同じ jq の工程で加えられます。

この組み合わせに特有の注意点は行の長さです。1 行ずつ処理するリーダーは、その行全体をメモリーに保持しなければなりません。文書丸ごとの 1 行は文書丸ごとのバッファーを意味し、読み込み先の 1 レコードあたりのサイズ制限は、レコードではなくファイル全体に対して効いてしまいます。これが、読み込む前にレコードを分割しておくべき実務上の理由です。

書き出しが大きく、定期的に行われ、毎回ストリームにする必要があるなら、正直な答えはブラウザー上の変換ツールではありません。ストリーミング型のパーサーは XML ファイルを木構造としてメモリーに構築せずに要素単位で読み進められ、そのループから 1 レコードにつき 1 個の JSON 行を出す処理は、どの言語でも短いプログラムで書けます。

この方式ならメモリーに収まらない大きさのファイルにも対応できますが、ここでの解析は書き出す前に文書全体を JavaScript のオブジェクトとして構築するため、そこまでは対応しません。単発のファイルや上記の「1 ファイル 1 行」の用途なら、この変換ツールのほうがプログラムを書くより速く済みます。繰り返し動かすパイプラインなら、そうではありません。

XML のコメントは解析の段階で捨てられ、NDJSON にはそれを受け取るコメント構文がないため、書き出しの中にあった説明文はすべて消えます。ヘッダーもスキーマも前置きもなく、NDJSON ファイルの各行はレコードであり、ローダーはファイルの先頭にある何であってもレコードとして読もうとします。

データの由来を記録する必要があるなら、それはレコードの中のフィールドかファイル名に属するべき情報です。先頭行として書き加えると、そのファイルは目的にとって無効になり、ローダーはそれを、この文章よりずっとわかりにくい形で知らせてきます。