Snowflakeのdbtプロジェクトが環境変数と非公開Gitに対応

Snowflakeのdbtプロジェクトで、env.ymlを使った環境変数管理が一般提供となり、非公開Gitリポジトリからのパッケージ取得にも対応しました。

要点

• 一つのenv.ymlに複数環境を定義し、平文値、SQLで計算する値、Snowflake管理の秘密情報を実行前に解決できます。
• プロジェクト既定の環境、実行時の環境、個別変数の上書きをSQLから指定できます。
• DBT_ENV_SECRET_変数、ネットワークルール、外部アクセス統合を使い、dbt depsから非公開Gitパッケージへ認証できます。

今回の更新で変わること

Snowflakeのdbtプロジェクトは、プロジェクトに含めたenv.ymlから実行環境を構成できるようになりました。ファイルには複数の名前付き環境を定義し、固定値だけでなく、SnowflakeのSQLで求める値や管理された秘密情報を設定できます。Snowflakeはdbtの実行前にenv.ymlを解決し、得られた値を環境変数として渡します。開発、検証、本番の差を一つのGit管理ファイルへまとめながら、秘密そのものをリポジトリへ書かない構成が可能です。

SQLで値を求められるため、CURRENT_USER()、CURRENT_ROLE()、CURRENT_WAREHOUSE()などのコンテキスト関数を使い、開発者ごとに分離したスキーマや実行設定を選べます。管理テーブル、タスク履歴、ストアドプロシージャから増分処理の期間などを決め、モデル実行前に渡すこともできます。便利な一方、同じGitコミットでも利用者、ロール、ウェアハウス、実行時刻によって値が変わります。再現性を保つには、選択した環境と解決後の値のうち秘密でない項目を実行履歴へ残す必要があります。

既定環境はプロジェクトオブジェクトにあるDEFAULT_ENVIRONMENTで設定し、EXECUTE DBT PROJECTのENVIRONMENTで実行ごとに選択できます。個別の値はENV_VARSで上書きできます。SHOW DBT PROJECTSでは既定環境を確認でき、SNOWFLAKE.ACCOUNT_USAGE.DBT_PROJECT_EXECUTION_HISTORYには実行時に選ばれた環境が記録されます。CI/CDでは暗黙の既定値だけに頼らず、重要な実行で環境名を明示し、履歴から想定した環境だったことを確認したいです。

非公開Gitパッケージは、Snowflakeの秘密情報をenv.ymlからDBT_ENV_SECRET_変数として参照し、ネットワークルールと外部アクセス統合を組み合わせてdbt depsへ認証します。この構成はワークスペース、配備済みのプロジェクトオブジェクト、Snowflake管理モードのCoCo Desktopで利用できます。Snowflake CLIの関連オプションには3.21以降が必要です。秘密をログやエラーへ出さないこと、外部接続先を必要なGitホストへ限定すること、資格情報のローテーション後も依存取得が成功することを確認します。

関係しそうなチーム

Snowflakeのdbtプロジェクトを運用する分析エンジニア、複数環境と実行履歴を管理する基盤担当、非公開Gitの秘密情報と外部通信を管理するセキュリティ担当に関係します。

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

1. env.ymlの環境名、DEFAULT_ENVIRONMENT、実行時のENVIRONMENTの優先関係を試します。
2. SQL計算値が利用者やロールで変わる場合、再現に必要な実行情報を履歴へ残します。
3. 非公開Gitの秘密情報、ネットワークルール、外部アクセス統合、CLI版を確認します。

結局、この更新をどう読むべきか

dbtプロジェクトの環境差分と非公開依存をSnowflakeの管理面へ取り込む更新です。Git管理と秘密管理を両立できますが、実行時に解決される値と外部通信の統制を明示的に監査できる設計が必要です。