対象読者
- データエンジニア、データアナリスト、開発担当者
- Snowflakeの運用効率化やデータ保護を重視する技術者
- 開発・検証環境の効率化を目指す管理者
説明すること / 説明しないこと
説明すること
- Time Travel、Fail Safe、Zero-Copy Cloningの概要と活用方法
- Table Typesとストレージコスト最適化のポイント
- ベストプラクティスとよくある失敗の回避策
説明しないこと
- Snowflakeの内部実装や暗号化アルゴリズムの詳細
- 他社DWHとの詳細な比較やベンチマーク
- 高度なSQLチューニングやパフォーマンス最適化手法
1. なぜこれらの機能が重要なのか
Snowflakeは、データ保護を強化し、開発効率を向上させるために、他のDWHにはない高度な機能を提供します。これにより、運用リスクを低減し、迅速な開発を実現します。
本記事では、以下の3つを中心に解説します。
- Time Travel：過去のデータにアクセス
- Fail Safe：災害復旧のための最終手段
- Zero-Copy Cloning：データコピーなしで複製
2. Time Travel：過去のデータを簡単に復元
Time Travelを利用することで、過去のデータベース、スキーマ、テーブルの状態に容易にアクセスでき、誤削除や検証作業に迅速に対応できます。
特徴
- 保持期間：Standardは1日、Enterprise以上は最大90日
-
用途：
- 誤削除データの復元
- 過去スナップショットでの検証
サンプルSQL
-- 過去の状態を参照
SELECT * FROM orders AT (TIMESTAMP => '2025-08-01 00:00:00');
-- 過去の状態を基にテーブルを復元
CREATE TABLE orders_restore CLONE orders
BEFORE (TIMESTAMP => '2025-08-01 00:00:00');
3. Fail Safe：災害復旧のための最後の砦
Fail Safeは、Time Travel期間終了後の7日間、Snowflakeがデータを保持する仕組みです。
- ユーザー操作不可（復旧はSnowflakeサポートのみ）
- 対象：Permanentテーブルのみ
- 注意：ストレージコストに影響
4. Zero-Copy Cloning：データコピーなしで複製
Zero-Copy Cloningは、データを物理的にコピーせずにテーブル、スキーマ、データベースを複製でき、ストレージコストを削減し、環境構築を高速化します。
-
用途：
- 開発・テスト環境の作成
- 本番データを使った検証
-
メリット：
- ストレージコスト削減
- 作成が高速
サンプルSQL
-- テーブルをクローン
CREATE TABLE dev_orders CLONE prod_orders;
-- スキーマをクローン
CREATE SCHEMA dev_schema CLONE prod_schema;
5. Table Typesとストレージコスト最適化
Snowflakeには3種類のテーブルタイプがあります。
- Permanent：Time Travel（最大90日）＋Fail Safe
- Transient：Time Travel（最大1日）、Fail Safeなし
- Temporary：セッション終了時に削除
ベストプラクティス
- 開発・検証用：TransientまたはTemporary
- 本番データ：Permanent
6. ベストプラクティス
- Time Travel期間を最小限に設定（不要なストレージコストを防ぐ）
- 開発環境はZero-Copy Cloningで作成
- Fail Safeは最後の手段と認識し、Time Travelで復旧できるように運用
7. よくある失敗と回避策
失敗1：Time Travelを90日に設定してコスト増
-
回避策：開発環境は
TRANSIENTテーブルを使用
失敗2：クローン後に元データを削除して影響発生
- 回避策：クローンはメタデータ参照なので、元データ削除に注意
8. 次回予告
次回は 「Snowflakeのデータ共有とセキュリティ」 を解説します。
RBAC、データマスキング、Reader Accountの仕組みを詳しく紹介します。