dbt cloneを利用した開発者毎の開発DB構築 on Snowflake

背景

dbtにより開発を行う際、開発者毎に開発用DBを用意する必要があります。開発DBをプロダクションDBを元に作成する場合、その手段としてdbtではdbt cloneというコマンドが用意されています。本記事では、dbt cloneの仕様や、開発プロセスに組み込んだ場合に想定される利用方法を検討してみます。尚、検証はdbt cloudとSnowflakeの組み合わせで行っています。

dbt cloneについて

dbt cloneを実行することで、production環境のモデルが開発環境へ複製されます。
挙動について公式では以下のように説明されています。

By default, dbt clone will not recreate pre-existing relations in the current target. To override this, use the --full-refresh flag.

全てのオブジェクトを開発環境にコピーするには--full-refreshフラグが必要で、フラグを付けない場合は既にテーブルなどがあった場合、例え列の定義が違ってもCloneされないようです。実際に挙動を検証してもそのようでした。

dbt versionの考慮

利用するdbtのバージョンを、DeploymentのジョブとCredentialに指定できます。Clone実行時にはこれらのバージョンが一致している必要があり、不一致の場合は以下のようなエラーが出ます。

Runtime Error
Expected a schema version of "https://schemas.getdbt.com/dbt/manifest/v10.json" in /usr/src/dbt-server-shared/defer_state/run-303778402/manifest.json, but found "https://schemas.getdbt.com/dbt/manifest/v12.json". Are you running with a different version of dbt?

尚、dbt_project.ymlにもversionを指定することが可能ですが、こちらはDeploymentやCredentialなどのバージョンと一致していなくともエラーにはなりませんでした。versionパラメータはOptionalみたいですが、用途は不明です。

clone対象

cloneによりschemaは新規作成されるものの、dbは作成対象とならず、アクセス対象のDBが存在しない旨のエラーが発生します。これはcloneに限らず、dbt buildの挙動とも共通します。

動的なDB・スキーマ参照に対するcloneの挙動

実務では生データやデータマートなど用途に応じてDBを分けることが多いと思います。またその際、成果物の作成先は動的に変える方法としてdbt_project.ymlやcustom_database_nameマクロなどを利用しているとかと思います（参考記事）。

dbt clone実行時に、上記の設定が反映されているか確認したところ、無事反映されていました。例えば、ユーザー1の開発環境としてraw_user1とmart_user1データベースが、プロダクション環境としてrawとmartデータベースが存在する場合、それぞれが対となってcloneされます。素晴らしい。

開発プロセスへの導入とまとめ

dbt cloneではDBが作成されないことを踏まえると、開発者毎のDBはあらかじめ準備しておく必要があります。dbt cloudにおいては、管理者が開発者アカウントを作成したタイミングでDBも作成するのが良さそうです。

その後は、ブランチを切って開発を始めるタイミングで開発者がdbt clone --full-refreshを実行することで、毎回最新のプロダクション環境をベースにした開発を行えそうです。