🕰️

第6回Snowflake Rookies Camp ～FrostyFriday week103の振り返り〜

に公開
SQL
Snowflake
tech

Snowflake Rookies Camp 幹事メンバーのhueです。
この記事は2026年1月9日に開催した
「第2回Snowflake Rookies Camp～初心者向け勉強会～」の内容を振り返りとなります。

勉強会で実施した内容はFrosty Fridayのweek3となります。

新幹事!

改めて、当日参加いただいた皆さん、ありがとうございます！！
当日ハンズオンの内容を解説してくれた、Yuji Matsumotoさんは今回からの新幹事です！
みなさん、よろしくお願いします！

Time Travel

当日はこちらの記事にて紹介しているクエリを実行しました。

この記事では主に実行したTime Travelについて振り返しようと思います。

クエリIDを変数にセット

今回、データを作成した後にクエリIDを変数にセットしました。
変数とは、値を一時的に保存しておくたの「箱」です。その箱に名前をつけて、後から同じ値を何度も使えます。数値や文字、今回のようなQuery IDも変数に入れて扱えます。

-- クエリIDを変数にセット（Init）
SET last_query_id_ini = LAST_QUERY_ID();

実際に上記のコマンドで実行しましました。
その後、

SELECT $last_query_id_ini;

を実行するとどのような値がセットされているか確認することができます。

今回のデモでは、クエリIDを変数にセットして実行していますが、
当日の説明や、ブログでも紹介したようにクエリIDを直接指定して実行することも可能です。

ATとBEFORE

Snowflake の Time Travel では、
「いつの状態を見るか」 を次の2系統で指定できます。

  • AT ：その時点 ちょうど の状態を見る
  • BEFORE ：ある操作が行われる 直前 の状態を見る
    今回のコードでは BEFORE を使っています。

AT と BEFORE の違い

AT（その瞬間ピッタリ）

SELECT * FROM table AT (TIMESTAMP => '2024-07-20 10:00:00');

指定した 時刻ちょうど のデータを見る。
「この時点では、どんなデータだったか？」という考え方です。
時刻指定・オフセット指定で使います。

  • ATが受け取れるもの
AT (
  TIMESTAMP => ... | 
  OFFSET    => ... | 
  STATEMENT => ...
)

※ここでの STATEMENT は「そのクエリが完了した時点」 を意味します。

BEFORE（その処理の直前）

SELECT * FROM table BEFORE (STATEMENT => '<query_id>');

指定した クエリが実行される直前 の状態を見ます。
UPDATE / DELETE / INSERT が 起きる前の状態 に戻れる。
「この事故が起きる前はどうだった？」を正確に再現できます。

  • BEFOREが受け取れるもの
BEFORE (
  STATEMENT => ...
)

※ここでの STATEMENT は「そのクエリが実行される直前の状態」を意味します。

今回のデモでは、データの確認をするためSELECTを行っています。
おそらく、このように誤ったデータ操作してしまった場合、
①データ作成

INSERT INTO DB_WEEK103.sales.transactions 
(id, customer_name, amount, transaction_date) 
VALUES 
(1, 'Alice', 100.00, '2024-07-20 10:00:00'), 
(2, 'Bob', 200.00, '2024-07-20 11:00:00'), 
(3, 'Charlie', 300.00, '2024-07-20 12:00:00');

②データ削除(クエリID：'01c1a1fb-0003-2a0a-0003-37c600043sea')

DELETE FROM DB_WEEK103.sales.transactions WHERE id = 2;

③復旧

SELECT * FROM db_week103.sales.transactions before(statement => ('01c1a1fb-0003-2a0a-0003-37c600043sea'));

といった流れになります。
テーブルを消したクエリIDを指定すれば、
消す前の状態（①） を正確に再現できます！

UNDROP という、さらにやさしい選択肢

Time Travel では、クエリIDを使って
「ある操作が行われる直前の状態」を参照・復旧できることを紹介しました。

Snowflake には、もう一つ
さらにシンプルに“元に戻せる”方法として
UNDROP という機能も用意されています。

UNDROP とは？

UNDROP は、
誤って DROP してしまったオブジェクト（テーブルやスキーマなど）を、そのまま元に戻すための機能です。

例えば、誤ってテーブルを削除してしまった場合でも、

DROP TABLE sample_table;

その後に、

UNDROP TABLE sample_table;

と実行するだけで、
削除する前の状態のテーブルがそのまま復元されます。

クエリIDを指定する必要もなく、
「消してしまったものを、素直に元に戻す」
とても直感的な操作になっています。

Time Travel と UNDROP の使い分け

UNDROP はとても便利ですが、使える場面は限定されています。

操作内容 使う機能
UPDATE / DELETE Time Travel（BEFORE）
DROP UNDROP
  • データを更新・削除してしまった場合
    → Time Travel（BEFORE）
  • テーブルやスキーマ自体を消してしまった場合
    → UNDROP

このように、役割がはっきり分かれているのが特徴です。

まとめ

今回の勉強会では、
Frosty Friday の課題を通して
Snowflake Time Travel の基本と考え方を体験しました。

「間違って消したクエリIDさえ分かれば、その“直前の世界”に戻れる」

実務では、「壊れたときに、どれだけ早く正確に戻せるか」 が重要です。
Time Travel の BEFORE（STATEMENT）を使えば、
誤操作を起こしたクエリIDを起点に事故発生“直前”の世界をそのまま再現できます。

以前、誤ってデータを消してしまった経験があるからこそ、
Snowflake の「クエリで戻れる」という仕組みは本当にありがたい機能と感じます。
誤ってしまっても、やり直せる安心感がある。
そんな Snowflake の優しさを今回の勉強会を通して感じてもらえていたら嬉しいです。

Discussion