Snowflakeのテーブルガイド：Permanent, Transient, Temporary の違いと「使い分け」

🚀 はじめに

Snowflakeを使い始めたとき、CREATE TABLE は他のデータベースと同じように見えるかもしれません。しかし、Snowflakeのテーブルには、そのユニークなアーキテクチャに由来する強力な機能と、知っておくべき「種類」があります。

• 「PERMANENT って何？ デフォルトだから気にしなくていい？」
• 「TRANSIENT と TEMPORARY って、どっちがどう一時的なの？」
• 「テーブルの種類を選ぶと、コストやTime Travelにどう影響する？」

この記事では、Snowflakeの核となる3つのテーブルタイプ（Permanent, Transient, Temporary）に焦点を当て、それぞれのデータ保護機能（Time Travel, Fail-safe）との関係、そしてコストへの影響を体系的に整理してみました。

私自身が、TRANSIENT と TEMPORARYを間違えて覚えてしまっていたことに気づき戒めもこめて、、、

1. Snowflakeテーブルを支える2大機能

まず、テーブルタイプの違いを理解する前提として、Snowflakeの強力なデータ保護機能である「Time Travel」と「Fail-safe」を知る必要があります。

1.1. Time Travel (タイムトラベル)

Time Travelは、ユーザーが 過去の特定時点のデータを参照したり、UNDROP コマンドで復元したりできる機能です。

• 保持期間: DATA_RETENTION_TIME_IN_DAYS パラメータで設定します。アカウント→DB→スキーマ→テーブルで継承（ただし、下位で上位の内容を上書きできる）
  • Standard Edition: デフォルトは1日で、0（無効化）または 1 に設定可能です。
  • Enterprise Edition以上: PERMANENT オブジェクトの場合、0日〜最大90日まで任意に設定可能です。
• 用途: クエリミス（UPDATE や DELETE の誤実行）のリカバリ、過去時点のデータ分析など。
• コスト: Time Travelで保持されているデータ（変更前の古いマイクロパーティション）に対してもストレージコストが発生します。

1.2. Fail-safe (フェイルセーフ)

Fail-safeは、Time Travelの保持期間が終了した後に、さらに7日間データを保持する、Snowflake側の最終的なディザスタリカバリ機能です。

• 保持期間: Time Travel期間終了後、固定で7日間。
• 用途: ハードウェア障害や重大なバグなど、壊滅的なデータ損失からの復旧用です。
• アクセス: ユーザーはFail-safe領域のデータに一切アクセスできません。復旧はSnowflakeサポートへの依頼が必要です。
• コスト: Fail-safeで保持されているデータに対してもストレージコストが発生します。

2. 3つの主要テーブルタイプ比較

Snowflakeのテーブルタイプは、上記2つのデータ保護機能を「どの程度利用するか」によって定義されています。

特徴	Permanent (永続)	Transient (一時)	Temporary (テンポラリ)
デフォルト	はい	いいえ	いいえ
Time Travel	0日〜90日 (設定可能, Editionによる)	0日または1日 (設定可能)	0日または1日 (設定可能)
Fail-safe	あり (7日間)	なし	なし
可視性	全セッション	全セッション	作成したセッションのみ
ライフサイクル	DROPされるまで永続	DROPされるまで永続	セッション終了時に自動DROP
主な用途	本番データ、マスターデータ	中間テーブル、リカバリ不要なデータ	セッション内の一時的な作業領域

3. 各テーブルタイプの詳細

3.1. Permanent テーブル (デフォルト)

CREATE TABLE ... で TRANSIENT や TEMPORARY キーワードを指定しない場合に作成される、標準のテーブルです。

特徴:

• Time Travel（最大90日、Editionによる） とFail-safe（7日） の両方の恩恵を最大限に受けられます。
• 最もデータ保護機能が強固ですが、その分、Time TravelとFail-safeの両方のストレージコストがかかります。

構文:

-- PERMANENTがデフォルトのため、キーワードは不要
CREATE TABLE my_permanent_table (id INT, data VARCHAR);

主な用途:

• Fact テーブル、Dimension テーブル
• マスターデータ、顧客情報
• 絶対に失ってはならない、すべてのコアデータ

3.2. Transient テーブル

PERMANENT から Fail-safe 機能を取り除いたテーブルです。

特徴:

• Fail-safeが適用されません。これにより、Fail-safe分の追加ストレージコスト（7日分）が発生しません。
• Time Travelは0日または1日に設定可能です。
• セッションが終了しても消えません（明示的な DROP が必要）。

構文:

CREATE TRANSIENT TABLE my_transient_table (id INT, data VARCHAR);

主な用途:

• ELT/ETL処理の中間テーブル。
• リカバリ（復旧）の必要性が低いが、セッションを超えて保持する必要があるデータ。
• コストを節約したいが、DROP は手動で行いたい場合に最適です。

3.3. Temporary テーブル

セッション内でのみ有効な、一時的な作業領域としてのテーブルです。

特徴:

• セッション終了時に自動的に DROP されます。
• Fail-safe は適用されません。
• Time Travelは0日または1日に設定可能ですが、セッション終了と同時にデータはパージ（完全削除）されるため、セッション終了後の UNDROP 等は不可能です。
• 他のユーザーやセッションからは不可視です。
• （落とし穴） PERMANENT や TRANSIENT テーブルと同名で作成可能です。その場合、そのセッション内ではTemporaryテーブルが優先されます（この同名作成には、既存オブジェクトのOWNERSHIP権限が必要です）。

構文:

CREATE TEMPORARY TABLE my_temp_table (id INT, data VARCHAR);

主な用途:

• ストアドプロシージャ内での一時的な計算。
• 複雑なクエリのステップバイステップの中間結果保持。
• スクリプト実行中だけ必要な、完全な使い捨てデータに最適です。

4. 特殊なテーブルタイプ（補足）

上記3つが基本的なテーブルですが、SnowPro Core試験では以下のテーブルの概念も問われることがあります。

• External Table (外部テーブル):
  S3やAzure Blobなどのデータレイク上のファイルを、Snowflakeにロードせず直接クエリするためのテーブルです。データはSnowflakeのストレージには存在しません。
• Directory Table (ディレクトリテーブル):
  ステージ（内部または外部）上にあるファイルの一覧（メタデータ）を直接クエリできるようにする機能です。ステージ作成時に DIRECTORY = (ENABLE = TRUE) を指定して有効化し、SELECT * FROM DIRECTORY(@my_stage); のように参照します。
  • （補足）外部ステージの自動更新はイベント通知（SQS/Event Grid/Pub/Sub）で、内部ステージの自動更新は現在AWSホストのアカウントのみ対応しています。

5. どう使い分けるか？ (実践シナリオ)

適切なテーブルタイプを選ぶことは、コストと安全性の最適なバランスを見つけることです。

使い分けの基本方針:

• 本番データ（失うと困る）: 迷わず PERMANENT
• バッチ処理の中間データ（再実行で復元可能）: TRANSIENT
• スクリプト内の一時データ（セッション終了時に不要）: TEMPORARY

シナリオ1：顧客マスターテーブルを定義する
$\rightarrow$ PERMANENT。Time TravelとFail-safeによる最大限の保護が必要です。

シナリオ2：毎晩のELTバッチで、Raw層からDWH層へロードする際の中間集計テーブル
$\rightarrow$ TRANSIENT。バッチが失敗しても、最悪Rawから再実行すれば復元可能です。Fail-safeのコスト（7日分）を節約するのが合理的です。

シナリオ3：アドホック分析で、複数のテーブルをJOINした複雑な結果セットを一時的に保存し、次のクエリで使いたい
$\rightarrow$ TEMPORARY。分析セッションが終われば不要になるため、自動でクリーンアップされるのが最も効率的です。

コストに関する警告
PERMANENT テーブルを DROP しても、Time Travel（最大90日）と Fail-safe（7日）の期間が過ぎるまで、そのデータはストレージコストを消費し続けます。TRANSIENT や TEMPORARY はFail-safeコストが発生しないため、不要なデータを永続化させないための重要な選択肢となります。

😌 おわりに

Snowflakeのテーブルタイプは、単なる分類ではなく、コストとデータ保護レベルをユーザーが明示的に選択するための重要な機能です。

• PERMANENT: 最大限の保護（高コスト）
• TRANSIENT: Fail-safeを省略（中コスト）
• TEMPORARY: セッション限定・Fail-safe省略（低コスト）

デフォルトの PERMANENT を使い続けるのではなく、ELTの中間テーブルに TRANSIENT を活用するなど、データの特性に合わせて適切なテーブルタイプを選択することが、Snowflakeを賢く運用する第一歩になることでしょう。

📚 参考出典

• Snowflakeドキュメント | Time Travel と Fail-safe の理解 (エディション差、0日設定含む)
• Snowflakeドキュメント | CREATE TABLE (構文、PERMANENTキーワードの不在)
• Snowflakeドキュメント | Temporary And Transient Tables (Transient/Temporaryの詳細、Time Travel 0or1日、セッション終了時の挙動)
• Snowflakeドキュメント | ディレクトリテーブル (自動更新の条件、Pub/Sub等)