dbt Fundamentalsの「Deployment」のセクションについて理解した内容を言葉にしてみた。
自動化を解決するのにdbt Cloudを使用した記事となっている。この記事は前回の続き。
いったんdbtそのものの理解に留めたいので、かなり端折気味。
デプロイメントとは
以下、動画の意訳。
開発環境であればIDE上でコマンド(dbt run,dbt test)をAd-Hocに必要に応じて実行してきた。
本番環境へのデプロイメントは異なる。本番環境用に分離されたブランチ(main,master?)が存在し、
そして分離されたスキーマが存在する。(開発環境と異なり)意思決定に必要なデータが存在する。
また、本番環境では(Ad-Hocではなく)dbtコマンドをスケジュール実行する。
ビジネス要件に応じてdbt run, dbt testを実行することになる。
本番環境は、分離されたブランチ・スキーマ上においてSSOT(Single Source Of Truth)を実現する。
そして、これまで作業してきた開発環境を分離し、様々な変更を本番環境への影響なしに実行する。
Snowflakeの本番検証環境分離の戦略
これ、動画にないのだけれど、そもそもSnowflake側を検証環境と本番環境に分離しないといけない。
以前、以下の記事にマルチテナントに関係するホワイトペーパーを読んで内容を整理してみたが、
そこで、環境を分離するにあたって必要な考慮事項がまとめられている。
概ね、テナント=環境と捉えて問題ないという感想を持っている。
OPT(Object Per Tenant)、つまり、同一アカウント内に検証/本番環境を共存させるスタイルと、
APT(Account Per Tenant)、つまり、アカウント毎に検証/本番環境を分離するスタイル、
両方あると考えている。
Snowflakeにおいて、アカウントを跨いでオブジェクトを共有できないことがポイントで、
それを不自由な制限事項と取るか、確実な安全の確保と取るか、どちらかの選択となる。
OPTであれAPTであれ、オブジェクト数の増加に伴いTerraform等のツールが事実上必須となる
ことから、実はAPTでも事実上の共有をしているのと同じとなり、APTの方が良いのかなと思っている。
URLが分離するので運用の調整がしやすいし、第一に安全性にグレーな部分が無くなる。
dbt Cloud上でのデプロイメントの準備
dbt Coreの各コマンドをスケジュール実行することで機能を実現する、という特徴から、
そもそも検証/本番環境を実現するためにはdbt Coreだけでは機能が足りない。
dbt Cloudには、検証/本番環境の実現に必要な機能が乗っている。
なので、このDeploymentセクションはdbt Cloudの機能説明に近い。
ちょっと記事の趣旨から外れてしまうのでサラッと眺めるに留める。
dbt Cloud上のDeploymentメニュー配下には以下のメニューがある。
– Run History
– Jobs
– Environments
– Data Sources
Environmentsから、Deployment単位に対する操作が行える。
Create Environmentの操作により、新たなEnvironmentを作成できる。
– General Settings
– Name
– Type
– dbt Version
– [Check] Only run on cuustom branch
データプラットフォーム(DW)との接続に必要な設定を行う。
DW側がアカウント分離方式で環境分離しているのであれば、ここで本番検証の差異が発生する。
– Deployment Connection
– (Overwrite connection settings for this environment, only certain fields are able to be overwrite )
– Account
– Role (Optional)
– Database
– Warehouse
接続に必要なCredentialsの設定を行う。環境分離されている粒度で接続を行う。
– Deployment Credentials
– (Enter your deployment credentials here, dbt will use these credentials to connect to your database and run scheduled jobs in this environment )
– Auth method
– Username
– Password
– Schema
ジョブ実行時の設定を行う。タイムアウト設定や、都度ドキュメントを作るか、都度source freshnesを判定するか、
また、そもそも何のコマンドを実行するか。
– Execution Settings
– Run Timeout
– (Number of seconds a run will execute before it is canceled by dbt Cloud. Set to 0 riever time out for this job)
– Defer to a previous run state ?
– Generate docs on run
– (Automatically generate updated project docs each time this job runs)
– Run source freshness
– (Enables dbt source freshness as the first step on this job, without breaking subsequent jobs)
– Commands
– (This is where you can pass whatever dbt commands you would like. So this could be dbt run, dbt tests, dbt seed, whatever it might be)
省略…
– Helpful Resouruces
– Enabling CI
– Souurce Freshness
dbtがどういったトリガでジョブを起動するかを設定する。
結構いろいろなことができる。スケジュール実行だけでなくWebhook、APIなんかも設定できる。
細かいところは省略。
– Triggers
– Configure when and how dbt should trigger this job.
– Schedulue
– [Check] Run on Schedule
– [Radio] Schedule Days
– Subday,Monday,Tuesday,Wednesday,Thursday,Friday,Saturday
– [Radio] Enter custom schedule
– Timing
– Every [??] hours (Starting at midnight UTC)
– At exact intervals [??] UTC (e.g.”0,12,23″ for midnight,noon,and 11PM UTC)
– Webhooks
– [Check] Run on Pull Requests ?
– (省略)
– API
(省略)
デプロイメント まとめ
Historiesから、Jobの実行の実行履歴を観察できる。
以下、上からGit RepositoryからCloneした後、Snowflakeとの接続諸々を実行、
dbt deps (dbt Fundamentalsで出てきてないが、モジュール化されたパッケージのインストール)を実行。
まとめ
dbt Fundamentalsの動画を聴いて、dbtのデプロイメント機能を追ってみた。
dbtそのものを追いたいので大分端折ってしまった。あまり記事に意味がないかもしれない。
自分の経験が追いついてきたらもう一度トライしてみたい。