Snowflake、動的Icebergテーブルのクローンを一般提供

Snowflakeは、動的Icebergテーブルのクローン機能を一般提供しました。テーブル単体の複製だけでなく、データベースやスキーマをクローンする際の扱いも変わります。

要点

• 動的Icebergテーブルから新しい動的Icebergテーブルを作成できる
• 動的IcebergテーブルをSnowflake管理のIcebergテーブルとしてクローンする選択肢もある
• データベースまたはスキーマのクローンに、配下の動的Icebergテーブルが含まれるようになった
• 従来はデータベースやスキーマをクローンしても、動的Icebergテーブルがエラーや警告を出さず除外されていた

今回の更新で何が変わるのか

今回の一般提供では、動的Icebergテーブルを起点に、別の動的IcebergテーブルまたはSnowflakeが管理するIcebergテーブルを作成できるようになりました。動的Icebergテーブルは、更新クエリと更新間隔に基づいてSnowflakeがデータ更新を管理しつつ、Apache Iceberg形式のテーブルとして扱うための仕組みです。開発環境の複製、検証用データセットの準備、構成変更前の退避といった場面で、元の動的な更新設定を引き継ぐ複製を作れます。一方、Snowflakeが管理するIcebergテーブルへクローンすると、データを特定時点で固定した静的スナップショットになります。こちらには更新スケジュール、目標遅延時間、ウェアハウスの割り当てがありません。

もう一つ重要なのは、テーブル単体ではなくデータベースやスキーマをクローンしたときの挙動です。公式リリースノートによると、クローン対象のデータベースまたはスキーマに動的Icebergテーブルが含まれている場合、そのテーブルも複製に含まれるようになりました。従来は動的Icebergテーブルがエラーや警告を出さず除外されていたため、クローン処理自体が成功しても、複製先のオブジェクト構成が元環境と一致しないことがありました。今回の変更により、環境単位の複製で動的Icebergテーブルだけが欠ける状態を避けやすくなります。

公式ガイドでは、動的Icebergテーブルのクローンが元テーブルと同じ外部ボリューム、カタログ、Iceberg形式のバージョンを使い、Snowflakeから新しいベースロケーションを割り当てられると説明されています。クローン作成時に EXTERNAL_VOLUME、CATALOG、BASE_LOCATION を指定するとエラーになります。静的スナップショットを作る場合は、元の動的Icebergテーブルが初期化済みであることも要件です。権限を維持したい場合は COPY GRANTS の利用を検討し、動的なクローンは作成直後に一時停止状態になるため、予定どおり更新させる前に再開する必要があります。

運用面では、これまで動的Icebergテーブルが除外される前提で組んだ補完処理にも注意が必要です。環境複製後に別途テーブルを作成していたスクリプトをそのまま残すと、同名オブジェクトの衝突や不要な二重処理につながり得ます。一般提供への移行に合わせて、クローン後のオブジェクト一覧を確認し、既存の自動化が新しい標準挙動と重複しないかを見直すことが大切です。

実務で確認したいポイント

まず、検証用のデータベースまたはスキーマをクローンし、動的Icebergテーブルが複製先に存在することを確認します。テーブル名だけでなく、更新定義、停止・再開状態、所有者、権限、カタログ、外部ボリューム、ベースロケーション、Iceberg形式のバージョンも比較しておきたいです。

次に、動的IcebergテーブルへのクローンとSnowflake管理のIcebergテーブルへのクローンを分けて試します。複製後も継続的な更新が必要な検証環境と、特定時点のデータを固定して分析したい環境では、適した宛先が異なります。既存の環境複製スクリプトに手動の再作成処理がある場合は、新しい挙動を確認してから削除または条件分岐してください。

結局、この更新をどう見るべきか

今回の更新は、動的IcebergテーブルをSnowflakeのクローン運用に正式に組み込むものです。特にデータベースやスキーマ単位で開発・検証環境を作るチームにとって、複製元にはあるIcebergオブジェクトが複製先で欠ける問題を減らせます。一般提供を機に、クローン後の完全性チェックと既存の補完処理を見直す価値があります。