このツールの動作
JSON の標本が BigQuery のスキーマファイルになります。bq load --schema が受け取る、項目記述の配列です。
{ "id": 1, "firstName": "Ada", "address": { "city": "Paris" } }[
{ "name": "id", "type": "INTEGER", "mode": "REQUIRED" },
{ "name": "firstName", "type": "STRING", "mode": "REQUIRED" },
{
"name": "address",
"type": "RECORD",
"mode": "REQUIRED",
"fields": [{ "name": "city", "type": "STRING", "mode": "REQUIRED" }]
}
]項目名は JSON の鍵をそのまま保ちます。BigQuery が許すのは英字、数字、下線で、たいていの鍵はすでにその範囲です。
すべての行を、最初の一つだけでなく
[{ "a": 1 }, { "a": 2, "b": "x" }][
{ "name": "a", "type": "INTEGER", "mode": "REQUIRED" },
{ "name": "b", "type": "STRING", "mode": "NULLABLE" }
]スキーマは最初のオブジェクトだけから読まれていたので、あなた自身の標本の残りを読み込むと no such field: b で失敗しました。今は項目がすべてのオブジェクトにわたって束ねられ、どこかに無いものは NULLABLE になります。実際にそうだからです。
本物の欠陥で、この文章を書く過程で見つけ、下の二つとともに直しました。
フィールドと一緒に型も統合されます。ある行で INTEGER、次の行で STRING になるキーは JSON の列になります。STRING では読み込みのときに数値が弾かれるからです。一方、オブジェクトどうしは一つの RECORD に統合され、片方に無いサブフィールドはそこで NULLABLE になります。
型の混ざった配列は JSON の列
{ "arr": [1, "x"] }[{ "name": "arr", "type": "JSON", "mode": "NULLABLE" }]繰り返し列の型は一つ、[1, "x"] の型は二つです。最初の要素から INTEGER REPEATED と決めれば、標本そのものが読み込めないスキーマができます。BigQuery の JSON 型は値をそのまま持ちます。混ざった配列と、配列の配列がそれになります。整数と小数だけが混ざっている場合は、両方を覆う FLOAT の繰り返し列のままです。
二つの推測、名指しで
nullはSTRING NULLABLEになります。 標本が見せたのは鍵だけで、型ではありません。STRING は選択であって読み取りではありません。その項目が数値なら、最初の読み込みの前に変えてください。- 空の配列は
STRING REPEATEDになります。 理屈は同じで、中に何も無かったからです。どちらもあなたの標本は問題なく読み込めます。そして項目の中身が分かったら、どちらも見直す値打ちがあります。
JSONをBigQueryに読み込む
噛み合わせるものが三つあります。噛み合っていないとき、BigQuery はそのどれもはっきりとは教えてくれません。
一行に一件。 BigQuery が読み込むのは改行区切りの JSON であって、JSON の配列ではありません。ファイルが [ で始まっていれば読み込みは通りません。ここの NDJSON 変換が、まさにその変換です。
スキーマは別のファイルに。 上の配列を schema.json として保存します。データファイルの一部ではなく、そこから読み取られることもありません。
bq load \
--source_format=NEWLINE_DELIMITED_JSON \
--schema=schema.json \
mydataset.mytable \
data.ndjsonあるいは API で。 同じ配列を、読み込みジョブ設定の schema.fields に置きます。ファイルでも API でも中身は同じです。
プライバシー
すべての処理はブラウザ内のJavaScriptだけで完結します。データがアップロードされることはないため、機密情報でも安心して利用でき、オフラインでも動作します。