こんばんは。oneTossiyです👓
Snowflakeにはさまざまなテーブル形式が用意されています。
便利な反面、選び方を間違えると「消したデータが戻せない」「一時的なつもりが残り続ける」といった事故に繋がることがあります。
特に復旧やバックアップに関連する『Time Travel』や『Fail-safe』は、何となく理解したつもりになりやすいポイントです。
今回は、「Snowflake そのテーブル復旧できません！」というテーマでテーブル種別の違いと、復旧できる・できないの境界をざっくり整理します。
想定ゴール
- 永続テーブル・仮テーブル・一時テーブルの違いを説明できる
- 『Time Travel』と『Fail-safe』の違いをざっくり理解できる
Snowflakeのデータ復旧手段について
Snowflakeでは、テーブルの種類によって復旧性が違います。
同じテーブルでも、
- しっかり保護されるもの
- 一部だけ戻せるもの
- そもそも使い捨て前提のもの
があります。
復旧の手段として大きく『Time Travel』を使う、もしくは『Fail-safe』機能を使うという２つの選択肢が存在します。
Time Travel
『Time Travel』は、過去の時点のデータにアクセスしたり、削除・更新前の状態に戻せたりする仕組みです。
例えば、
- 誤ってDROP TABLEしてしまった
- UPDATEでデータを壊した
- 以前のクエリを再度叩きたい
と言った場合でも、保持期間内であれば過去の状態を参照・復元することが可能となります。(タイムスタンプレベルで指定が可能）
復旧させる場合は、SQLから実行することができます。例えばsampleテーブルを誤って削除してしまった場合は、以下のようなSQLで復旧させることが可能です。
UNDROP TABLE SAMPLE;
また、特定の時点のデータを参照したい場合は以下のように記述できます。
-- タイムスタンプ指定 SELECT * FROM sample AT (TIMESTAMP => '2024-01-01 00:00:00'::TIMESTAMP); -- 何秒前かを指定 SELECT * FROM sample AT (OFFSET => -3600);
★エディションによるTime Travelの機能範囲について
契約しているエディションにより、最大保持期間が変わるので注意しましょう。
- 最大保持期間
- Standard Edition
- 1日
- Enterprise以上
- 最大90日
- Standard Edition
エディションの他にも、テーブルの種別によって期間は変わります。
Fail-Safe
『Fail-safe』は、『Time Travel』の保持期間が終了した後でも、一定期間だけ追加で保護される仕組みとなります。
ただし『Time Travel』とは異なり、ユーザ側で復旧作業ができない制約があります。
復旧をするためには、Snowflake側に問い合わせが必要です。
そのため、すぐに復旧することはできませんので最後の手段として利用するものと理解しておきましょう。
バックアップにおけるストレージコストについて
『Time Travel』、『Fail-safe』ともにバックアップのための費用が発生します。
特に注意が必要なのが、以下のような繰り返し処理です。
INSERT→TRUNCATE→INSERT→TRUNCATE
このような操作を大規模データに対して繰り返すと、
- 現在のテーブルのデータ量
- Time Travelで保持している過去データ分
- Fail-safeで保持している分
これら全てのストレージコストが積み上がっていきます。
バッチ処理やステージングテーブルとして使う場合は、バックアップが不要なテーブル種別を選ぶことでコストを抑えられます。（詳しくは後述のテーブル種別にて解説します。）
テーブル種別
Snowflakeには主に3種類、以下のテーブルが存在します。
- Permanent Table
- Temporary Table
- Transient Table
テーブル種別についてはSnowPro Core試験でもよく問われる部分なので、押さえておきたいポイントとなります。
Permanent Table
Snowflakeで最も基本的なテーブルです。特に何も指定せずにCREATE TABLEを実行すると、このタイプが作成されます。
本番環境のデータやマスタデータなど、長期保持が必要なデータに適しています。
作成方法
-- mytableをpermanent tableで作成 CREATE TABLE my_table ( id INT, name STRING ); -- または明示的に CREATE PERMANENT TABLE my_table ( id INT, name STRING );
Time Travel
- 保持期間：デフォルト1日/最大90日まで設定可能
- DATA_RETENTION_TIME_IN_DAYSで設定変更が可能
-- my_tableのタイムトラベルを7日間に設定 ALTER TABLE my_table SET DATA_RETENTION_TIME_IN_DAYS = 7;
★エディションによるTime Travelの違い
| エディション | Time Travel最大期間 |
|---|---|
| Standard | 1日 |
| Enterprise以上 | 最大90日まで設定可能 |
StandardエディションではTime Travelの保持期間が最大1日のため、「昨日消してしまったテーブルを今日復元したい」という場面でも、タイミング次第では復旧できないケースがあります。 長期の保持が必要な場合はEnterpriseエディション以上の利用を検討しましょう。
Fail-safe
- 7日間の保護期間あり
Temporary Table
セッションが終了すると自動的に削除されるテーブルです。
同名のテーブルがPermanentテーブルとして存在していても、SELECT文などで呼び出す際はこちらの一時テーブルが優先されます。
作成方法
-- tmp_workをTEMPORARYテーブルで作成 CREATE TEMPORARY TABLE tmp_work ( id INT, name STRING ); -- または省略形 CREATE TEMP TABLE tmp_work ( id INT, name STRING );
Time Travel
- 保持期間：1日(セッションが残り続けている時点まで）
- エディションによる機能差はなし
Fail-safe
- なし（全エディション共通)
Transient Table
Permanent TableとTemporary Tableの中間に位置するテーブルです。
明示的に削除しない限り残り続けますが、Fail-safeがない分、永続テーブルと比べてストレージコストを抑えることが可能です。
頻繁にデータの洗い替えが行われるものや、中間テーブルとして利用するものに関しては、「Transient Table」を利用することでコスト削減が可能です。
作成方法
-- work_tableをTRANSIENTテーブルで作成 CREATE TRANSIENT TABLE work_table ( id INT, name STRING );
テーブルの他にも、スキーマやデータベース単位でも設定可能です。
-- スキーマの場合 CREATE TRANSIENT SCHEMA work_schema; -- データベースの場合 CREATE TRANSIENT DATABASE work_db;
Time Travel
- 保持期間：最大1日(0日に設定することも可能、エディションによる機能差なし)
- バックアップが不要であれば0日にも設定することで、Time Travel自体を無効化し、コストをさらに抑えることができます。
Fail-safe
- なし（全エディション共通)
まとめ
テーブルの復旧方法およびテーブル種別について今回はまとめました。
用途によってテーブルを選択することで、復旧リスクを下げつつコストも最適化できます。
最適なテーブルの種類を考えずに「なんとなくCREATE TABLEしていた」という方は、ぜひこの機会にプロジェクトのテーブル設計を見直してみてください！
この記事を書いた人
