Scheduling queries または Scheduled queries と呼ばれているもの、日本語だといまいちしっくりこない名前。定期的にクエリを実行して結果を宛先テーブルへ書き込んでくれる。メールで通知したり Pub/Sub イベントを投げたりもできる。
クエリのスケジューリング | BigQuery | Google Cloud
クエリをスケジュールする前に @run_time パラメータと @run_date パラメータを使用してクエリ文字列を手動でテストするには、コマンドライン インターフェースを使用します。
実行時刻がパラメータとしてやってくるのだが、コンソールではパラメータを使えないので CLI を使う必要がある。とりあえず現在時刻で動作確認クエリを投げる場合以下のような感じでやっている。
bq query \ --project_id=YOUR_PROJECT_ID \ --use_legacy_sql=false \ --parameter="run_time:TIMESTAMP:$(date -u '+%Y-%m-%d %H:%M:%S')" \ --parameter="run_date:DATE:$(date '+%Y-%m-%d')" \ <<QUERY SELECT COUNT(*) as count, @run_time as bq_run_time, @run_date as bq_run_date, FROM ... QUERY
クエリ文字列は、標準 SQL で記述された有効なものでなければなりません。
なので bq コマンドはデフォルトが legacy sql なので --use_legacy_sql=false する。
クエリはヒアドキュメント内に書く。
date コマンドで UTC の @run_time と @run_date をつくる
@run_time と実際の実行時刻
@run_time は実際に実行された時間ではなく、設定スケジュール上の時刻がやってくる。例えば毎時 58 分に実行するクエリの @run_time と CURRENT_TIMESTAMP() を追記していくとこういう感じになる。スケジュール時刻にキューイングされて 1~2 分後に実際に実行される。
なので CURRENT_TIMESTAMP がスケジュール時刻であることを期待したクエリを書いていると意図しない結果になるかもしれない。スケジュール設定上の時刻がパラメータとしてやってくるのでそれを使って集計するべき。まあ実際には前日の範囲、 DATE_ADD(@run_date, INTERVAL -1 DAY) <= DATE(timestamp) AND DATE(timestamp) < @run_date を集計したりするだろうけども。
また、いつ集計されたものか一応データに残すようにしている、ただ単に SELECT ..., @run_time as bq_run_time のようにするだけ。
大量のログを BigQuery に入れたりしているけど、ダッシュボード等で毎回スキャンするには遅いしもったいないので、毎朝前日のログを集計してメトリックを書き出したりに使っている。またベータだしコンソールもいまいちいけてなくてテーブル名のバリデーションとかも動いてないし(例えばハイフンがテーブル名に入っていても設定はできて実行時にエラーになる)、Error loading location us-west4: Unknown Error みたいなエラーが常に出ててオイオイってなるのだが、そのうちよくなるんじゃないでしょうか。
