datasetIdは、数字から始めてはならない
2015/03時点
ドキュメントには書いておらずAPIも通ってしまうが、例えばTABLE_QUERY関数で認識しなくなる。
こんなエラー。
Error: Encountered "" at line 51, column 22. Was expecting one of:
TABLE_QUERY関数では、STRING関数もCAST関数も認識しない。
datasetごと作り直すハメになる。
BigQuery APIはテストしづらい
GAE SDKに用意されているようなstubがない。
クライアントの言語にPythonを選択するのは、間違い。
実行時に、やっとエラーを検出するような言語は向いていない。
JavaかGoで。
Output field used as input
HttpError: <HttpError 400 when requesting ...tables?alt=json returned "Output field used as input">
原因: response専用のfieldに値を入れている。
Pythonクライアントのドキュメントには、requestの説明にもresponse専用の[Output-only]なfieldが記載してあり、紛らわしいのでよく見ないとならない。
例えば、bigquery.tables().insert()でVIEWをinsertしたい場合、typeにVIEWを指定してはならない。queryを指定するだけでVIEWになる。
TABLE_QUERY+REGEXP_MATCHで死ぬ
個別のtableIdを列挙しなくてもTABLE_QUERYでREGEXP_MATCHを使うと、正規表現でtableIdを指定しFROMへ渡すことができる。
SELECT *
FROM (TABLE_QUERY(datasetId, 'REGEXP_MATCH(table_id, r"^.*_csv$")'))
WHERE field != ''
;
このようなクエリの結果を、新しくnew_csvというtableIdへinsertするjobを発行したとしよう。
何らかの理由で同じjobが発行された場合に、新しく作成されたnew_csvがFROM句にマッチしてしまう。
後述の「危険なオプション」との複合要因により、永遠にnew_csvに書き込み続けるループが起こりうる。
（BigQueryの使用量が請求明細に反映されるまでには、3日程度を要する）
危険なオプション
これらのオプションは課金額に大きく影響する可能性がある。設定する時は慎重にならなければならない。
Jobs
configuration.copy.writeDisposition
永遠に追記する可能性がある。
configuration.query.allowLargeResults
これを指定するとMaximum response size: 128 MB compressedのQuotaも外れてしまう。
App Engine
GAEからBigQuery APIへjobを発行する場合、TaskQueueのtask_retry_limitを設定しておかないと、予期せずにクエリの実行を繰り返してしまう恐れがある。
2015/08/16追記: GAE 1.9.25でretry_limitの挙動が変更された。
Failed tasks in queues configured with a ‘retry_limit’ of zero will no longer be retried.