DML・タイムトラベル・スナップショット

DML とバルク変更のコスト

BigQuery の DML（データ操作言語）は INSERT / UPDATE / DELETE / MERGE / TRUNCATE TABLE の 5 種類です。いずれも GA（一般提供）で、GoogleSQL 方言で書きます。TRUNCATE TABLE は全行を削除しつつスキーマ・説明・ラベルなどのメタデータは保持するので、全件削除だけが目的なら DELETE より効率的です。

DML はいずれもスキャンしたバイト数に応じて課金される点で SELECT クエリと同じです。パーティション化されたテーブルに対する UPDATE / DELETE は、パーティションキーを WHERE 句に含めれば対象パーティションだけを書き換えるので、スキャン量を大きく抑えられます（パーティショニングの詳細は 第 6 章）。

同時実行数にも文の種類で違いがあります。INSERT は 24 時間で先着 1,500 ステートメントまで即座に実行され、それ以降は同時 10・キュー最大 100 まで受け付けます。一方 UPDATE / DELETE / MERGE は「ミューテーティング DML」として扱われ、同一テーブルに対して同時実行できるのは最大 2 件、キューは最大 20 件までです（2026-08 時点）。

MERGE による Upsert

MERGE はソーステーブルとターゲットテーブルを突き合わせ、行ごとに次の 3 パターンへ振り分けて 1 つのアトミックな操作として実行します。CDC（変更データキャプチャ）を反映する際の基本形です。

MERGE [INTO] target_name [[AS] alias]
USING source_name [[AS] alias]
ON merge_condition
WHEN MATCHED [AND search_condition] THEN
  UPDATE SET ... | DELETE
WHEN NOT MATCHED [BY TARGET] [AND search_condition] THEN
  INSERT (...) VALUES (...)
WHEN NOT MATCHED BY SOURCE [AND search_condition] THEN
  UPDATE SET ... | DELETE

WHEN NOT MATCHED BY TARGET（ソースにしかない行）では列名を省略すると、ターゲットテーブルの全列が序数の昇順で対象になります。ただし取り込み時刻パーティションテーブルが対象の場合は列名の明示が必須です。重要な制約として、WHEN MATCHED 句で UPDATE を行う場合、複数のソース行が同一のターゲット行にマッチしているとランタイムエラーになります。ステージングテーブル側のキー重複が典型的な原因です。

マルチステートメントトランザクションとの関係

BEGIN TRANSACTION / COMMIT TRANSACTION / ROLLBACK TRANSACTION を使うと、複数の DML をまとめてアトミックに実行できます（スナップショット分離）。トランザクション内では CURRENT_TIMESTAMP() はトランザクション開始時刻を返し、変更できるテーブルは最大 100、パーティション変更は最大 100,000 までという上限があります。永続オブジェクトを作成・削除する DDL はトランザクション内では使えません。単一クエリで完結させる場合はこの構文で十分ですが、複数クエリにまたがる一連の処理は次章以降で扱うスクリプトやセッションで組み立てます。

タイムトラベルと fail-safe

タイムトラベルは、テーブルの過去の状態を FOR SYSTEM_TIME AS OF 句で読み出せる仕組みです。既定の保持期間は 7 日間で、データセット単位（または ALTER SCHEMA によるプロジェクト既定値）で 2 日から 7 日の範囲に設定できます（2026-08 時点）。

-- タイムトラベル保持期間を変更する（48〜168 の 24 の倍数で指定）
ALTER SCHEMA `PROJECT_ID.handson_ch09`
SET OPTIONS (max_time_travel_hours = 48);

-- 過去の状態を読み出す
SELECT *
FROM `PROJECT_ID.handson_ch09.orders`
FOR SYSTEM_TIME AS OF TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 10 MINUTE);

タイムトラベル期間が終了すると、続けて fail-safe 期間が始まります。fail-safe は削除・変更されたデータをさらに 7 日間、BigQuery 内部に保持する仕組みですが、この 7 日間は固定でユーザーが設定を変更することはできず、FOR SYSTEM_TIME AS OF でユーザーが直接読み出すこともできません（データ復旧には Google Cloud のサポートが必要です）。物理ストレージ課金モデルではタイムトラベルと fail-safe 用のストレージにも課金されますが、論理ストレージモデルでは基本料金に含まれます。

スナップショット・クローン・変更履歴

テーブルスナップショットとテーブルクローンは、どちらも「ある時点のテーブルのコピー」を作る機能ですが、書き込み可否と課金モデルが異なります。

-- スナップショットを作る（過去の時点を指定することも可能）
CREATE SNAPSHOT TABLE `PROJECT_ID.handson_ch09.prices_snapshot`
CLONE `PROJECT_ID.handson_ch09.prices`
OPTIONS (expiration_timestamp = TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL 1 DAY));

-- クローンを作る
CREATE TABLE `PROJECT_ID.handson_ch09.prices_clone`
CLONE `PROJECT_ID.handson_ch09.prices`;

-- スナップショットから標準テーブルへ復元する（上書きする場合は CREATE OR REPLACE）
CREATE OR REPLACE TABLE `PROJECT_ID.handson_ch09.prices`
CLONE `PROJECT_ID.handson_ch09.prices_snapshot`;

変更履歴を追う（APPENDS / CHANGES）

APPENDS(TABLE table, start_timestamp, end_timestamp) は追加された行だけを、CHANGES(TABLE table, start_timestamp, end_timestamp) は追加・更新・削除のすべてを返すテーブル値関数です。APPENDS は常に使えますが、CHANGES を使うにはテーブル作成時（または後から）に enable_change_history = TRUE を設定する必要があり、この設定はメタデータ保存コストの増加を伴います。どちらも戻り値に _CHANGE_TYPE（INSERT / UPDATE / DELETE）と _CHANGE_TIMESTAMP 列が付与され、CHANGES はさらに更新由来の削除かどうかを示す _CHANGE_IS_FOR_UPDATE 列を持ちます。なお CHANGES は 1 回の呼び出しで指定できる期間（start_timestamp〜end_timestamp）が最大 1 日という上限があるため、長い期間を追うには呼び出しを日単位に分割します。

CREATE TABLE `PROJECT_ID.handson_ch09.events` (event_id INT64, status STRING)
OPTIONS (enable_change_history = true);

SELECT event_id, status, _CHANGE_TYPE, _CHANGE_TIMESTAMP
FROM CHANGES(TABLE `PROJECT_ID.handson_ch09.events`, NULL, CURRENT_TIMESTAMP())
ORDER BY _CHANGE_TIMESTAMP;

# bq CLI でデータセットを作成
bq mk --location=US --dataset PROJECT_ID:handson_ch09

CREATE TABLE `PROJECT_ID.handson_ch09.orders` AS
SELECT * FROM UNNEST([
  STRUCT(1 AS order_id, 'JP' AS region, 120 AS amount),
  STRUCT(2, 'JP', 340),
  STRUCT(3, 'US', 500),
  STRUCT(4, 'JP', 90),
  STRUCT(5, 'US', 220)
]);

-- 本来 WHERE order_id = 4 のつもりが、region で条件を書いてしまった
DELETE FROM `PROJECT_ID.handson_ch09.orders`
WHERE region = 'JP';

SELECT *
FROM `PROJECT_ID.handson_ch09.orders`
FOR SYSTEM_TIME AS OF TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 5 MINUTE)
ORDER BY order_id;

INSERT INTO `PROJECT_ID.handson_ch09.orders`
SELECT *
FROM `PROJECT_ID.handson_ch09.orders`
FOR SYSTEM_TIME AS OF TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 5 MINUTE)
WHERE region = 'JP';

bq rm -f -t PROJECT_ID:handson_ch09.orders

CREATE TABLE `PROJECT_ID.handson_ch09.inventory` AS
SELECT * FROM UNNEST([
  STRUCT('sku-001' AS sku, 100 AS stock, 'active' AS status),
  STRUCT('sku-002', 50, 'active'),
  STRUCT('sku-003', 0, 'discontinued')
]);

CREATE TABLE `PROJECT_ID.handson_ch09.inventory_staging` AS
SELECT * FROM UNNEST([
  STRUCT('sku-002' AS sku, 30 AS stock, 'active' AS status),
  STRUCT('sku-004', 75, 'active')
]);

MERGE `PROJECT_ID.handson_ch09.inventory` T
USING `PROJECT_ID.handson_ch09.inventory_staging` S
ON T.sku = S.sku
WHEN MATCHED THEN
  UPDATE SET stock = S.stock, status = S.status
WHEN NOT MATCHED BY TARGET THEN
  INSERT (sku, stock, status) VALUES (S.sku, S.stock, S.status);

bq rm -f -t PROJECT_ID:handson_ch09.inventory
bq rm -f -t PROJECT_ID:handson_ch09.inventory_staging

CREATE TABLE `PROJECT_ID.handson_ch09.prices` AS
SELECT * FROM UNNEST([
  STRUCT('A' AS item, 1000 AS price),
  STRUCT('B', 2000)
]);

CREATE SNAPSHOT TABLE `PROJECT_ID.handson_ch09.prices_snapshot`
CLONE `PROJECT_ID.handson_ch09.prices`
OPTIONS (expiration_timestamp = TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL 1 DAY));

CREATE TABLE `PROJECT_ID.handson_ch09.prices_clone`
CLONE `PROJECT_ID.handson_ch09.prices`;

UPDATE `PROJECT_ID.handson_ch09.prices`
SET price = price * 2
WHERE TRUE;

UPDATE `PROJECT_ID.handson_ch09.prices_clone`
SET price = price + 100
WHERE item = 'A';

CREATE OR REPLACE TABLE `PROJECT_ID.handson_ch09.prices`
CLONE `PROJECT_ID.handson_ch09.prices_snapshot`;

bq rm -r -f -d PROJECT_ID:handson_ch09

つまずきポイント

理解度チェック

まとめと次章へ

• DML はバルク変更向けで、INSERT は緩やかだが UPDATE・DELETE・MERGE は同時 2 件までしか走らない
• MERGE は WHEN MATCHED / NOT MATCHED BY TARGET / NOT MATCHED BY SOURCE で 1 行ずつ INSERT・UPDATE・DELETE に振り分ける upsert の基本形
• タイムトラベル（既定 7 日、2〜7 日で設定可）は自分で読み出せる窓、fail-safe（固定 7 日）はサポート経由の最終手段
• スナップショットは読み取り専用の凍結コピー、クローンは書き込み可能で独立したコピー。差分課金の考え方は同じ
• APPENDS（常時利用可）と CHANGES（enable_change_history が必要）でテーブルの変更履歴を追える

次章では、BigLake・Iceberg やフェデレーションを使って BigQuery の外側にあるデータを扱う方法を学びます（第 10 章）。

• Data manipulation language (DML)
• DML syntax reference
• Multi-statement transactions
• Time travel
• Introduction to table snapshots
• Introduction to table clones
• Track changes in a table
• BigQuery sandbox