dbt Cloud×Snowflakeでdbt cloneコマンドの挙動を確認してみた
2025.02.27さがらです。
dbt cloneコマンドをdbt Cloud×Snowflakeで使ってみたとき、どのような挙動となるのかを確かめてみたので、本記事でその内容をまとめてみます。
dbt cloneについて
dbt cloneの大まかな仕様としては、下記の仕様となっています。
- Snowflake、Databricks、BigQueryといったゼロコピークローンに対応している製品：各ゼロコピークローン機能を用いたクローンを行う
- 他のゼロコピークローンに対応していない製品：
select * from tableのviewを作成する
主な使い所としては、以下のケースが考えられると思います。
- CI jobsでIncremental Modelを先にクローンすることで、CI Jobsのビルドコストを削減する
- 公式ドキュメントでも言及されている方法です
- Production Environmentのみにあるテーブルやビューも含めて、開発用スキーマにすべてまとめることで、開発中のデータアプリケーションやBIツールからの参照を容易にする
前提条件
基本的にはdbt CloudのIDE上でdbt cloneコマンドを試すのですが、コマンド実行前に対象のスキーマであるdbt_ssagaraの中身は空にしておきます。
一方で、対象のdbt projectのProduction Environmentに設定しているDeploy Jobにより、下図のようにproductionスキーマにテーブルとビューが作られている状態とします。
パターン１：IDEで「Defer to staging/production」をオフにした場合
IDEで「Defer to staging/production」をオフにした状態でdbt cloneコマンドを実行してみます。
すると、下図のようにエラーとなりました。これは、dbt cloneではstateを指定することが必須であるためです。dbt Cloudの場合は「Defer to staging/production」を有効化することでこのstateの指定をコマンドから行うことなく、staging/productionのEnvironment
パターン２：IDEで「Defer to staging/production」をオンにして、何も既存Modelを編集していない場合
IDEで「Defer to staging/production」をオンにした状態でdbt cloneコマンドを実行してみます。また、既存のModelは何も編集していない状態で実行してみます。
すると、下図のように実行がされ、Snowflakeのdbt_ssagaraスキーマを見てみると、テーブルとビューそれぞれが作られていました。
パターン３：IDEで「Defer to staging/production」をオンにして、既存Modelを編集している場合
もう一度、IDEで「Defer to staging/production」をオンにした状態でdbt cloneコマンドを実行してみます。先ほどのパターン２と変えて、Production EnvironmentでDeploy Jobsを実行済の既存Modelを編集している場合にどうなるかを確認してみます。
今回は、model_aとmodel_cを変更してみました。
すると、先ほどのパターン２と変わらず、編集していたmodel_aとmodel_cも含めたModelもCloneされました。
パターン４：IDEで「Defer to staging/production」をオンにして、既存Modelを編集しており、excludeオプションを追加した場合
もう一度、IDEで「Defer to staging/production」をオンにした状態でdbt cloneコマンドを実行してみます。先程のパターン３と変えて、Production EnvironmentでDeploy Jobsを実行済の既存Modelを編集した上で、--exclude state:modified+を追加したdbt cloneコマンドを実行してみます。
編集したModelはパターン３と変えずに、model_aとmodel_cを変更しています。
すると、編集していたmodel_aとmodel_cはcloneされませんでした！IDEで編集したModelとその下流のModelをCloneしたくない場合は、--exclude state:modified+を追加して実行すれば良さそうですね。
注意点：本番用と開発用でdbtのロールを分けている場合
これまでの検証では基本的にDevelopment EnvironmentとProduction Environmentで同じロールを用いて検証していたのですが、仮にDevelopment EnvironmentとProduction Environmentで異なるロールを使っている場合、Development Environmentで使用するロールが、Production Environmentのテーブル・ビューに対してSELECT権限がないとdbt cloneコマンドはエラーとなります。
以下は、「Development Environment：SAGARA_DEV_ROLE」、「Production Environment：SAGARA_ADMIN_ROLE」を用いた場合の例です。
- 上手くいく例：Production Environmentのテーブル・ビューに対してSELECT権限あり
- 上手くいかない例：Production Environmentのテーブル・ビューに対してSELECT権限なし
最後に
dbt Cloud×Snowflakeでdbt cloneコマンドの挙動を確認してみました。
有効に使えるとコンピュートリソースやストレージコストを削減でき、非常に便利な機能だと思います！ぜひご活用ください。
