SQLスケジュールクエリを効率よく実行する~DML~

私は会社でBigqueryを利用しているのですが、
その費用が増大してしまい、、(スケジュールクエリが原因ではないのですが)
そんなこんなでクエリを回す環境を整えようということで、
スケジュールクエリの構成をより費用の抑えた形で更新できるよう変更しました。
今回はそのDMLを使ったスケジュールクエリの構成変更と、さらにその構成変更に伴う失敗談を残しておこうかなと思います。

DMLでのスケジュールクエリ設定

これまでBigQueryのスケジュール機能を利用して
ダッシュボードのグラフを自動更新していました。
ただスケジュールを回す際に、
期間の指定を「データがある期間すべて」で回していました。データをとってる期間が長ければ長いほど、費用はかかってしまいます。
そこで取り入れたのがDML。
簡単にではありますが、備忘録的に文を載せます。

MERGE ｀データを更新していく中間テーブル｀ AS existing_data
USING (

~SQLクエリ~

/*
TABLE＿SUFFIX文にて５日前から１日前までを更新する形にする
例：TABLE_SUFFIX BETWEEN FORMAT_DATE("%Y%m%d",DATE_SUB(DATE(FORMAT_DATETIME("%Y-%madder1709@gmail.com-%d",@run_time,"Asia/Tokyo")), INTERVAL 5 DAY)) AND FORMAT_DATE("%Y%m%d",DATE_SUB(DATE(FORMAT_DATETIME("%Y-%madder1709@gmail.com-%d",@run_time,"Asia/Tokyo")), INTERVAL 1 DAY))
*/

) AS new_data
ON (existing_data.event_date = new_data.event_date) ---ここで指定したものが既に中間テーブル内にあるかないかで下記の対応が選択される
WHEN MATCHED THEN
UPDATE SET　---上書き

WHEN　NOT MUTCHED　THEN
INSERT　---追加
（）

失敗談

スケジュールクエリの設定が要因で、データが一部重複してしまっていた、という失敗談になります。幸いすぐ気付いて対応できました。
▼詳細
該当テーブルの内容：セッションごとの流入経路を特定しまとめた中間テーブル
事象：1日単体でクエリを回すとその日のセッション数が合致するが、複数日で実行すると、セッション数がやや多い
原因：５日前から回して中間テーブルに数値が入っていれば上書きという形でスケジュールクエリを書いてしまっていたこと。
※日跨ぎでのセッションをとっているユーザーがいる場合この事象は起こります。そのユーザーの流入元情報が載っているログが1日目に発火された場合、その1日目（12/1）がクエリを回す期間(12/2~12/5)から外れ、かつ日跨ぎ2日目(12/2)がクエリを回す期間に入っている場合、2日目のログには流入元情報の載っているログが発火していないので同じセッションでも2日目の流入元は1日目とは異なるものとしてUPDATEされ、結果1セッションで2つの流入元(1日目と2日目で異なる)が記録されてしまいました＝重複してしまっている状況になった
解決方法：UPDATE文を除外すること

よく考えればその通りなのですが、クエリを書いた達成感で機械的にスケジュールしてしまったのが原因ですね。。
もっと確認して行こう。。！