Snowflake & dbt Cloudハンズオン実践 #8: 『実践編5(デプロイ)』 #snowflakeDB #dbt

アライアンス事業部 エンジニアグループ　モダンデータスタック(MDS)チームの しんや です。

Snowflakeが展開しているサイト『Snowflake Quickstarts』では、Snowflake単体、またSnowflakeと他サービスとの連携について実戦形式で手を動かしながら学んでいけるコンテンツが多数公開されています。

その中の1つ『Accelerating Data Teams with Snowflake and dbt Cloud Hands On Lab(Snowflake と dbt Cloud ハンズオン ラボを使用してデータ チームを加速する)』は、dbt CloudとSnowflakeを連携させる形で、Snowflakeのデータを使ってdbt Cloudでデータ変換の処理を作り上げていく流れを学ぶことが出来る非常に参考になるコンテンツです。

当エントリ及び一連のエントリ群では、この一連の手順を実際に手を動かしながら進めた記録をまとめて行こうと思います。

第8弾の当エントリでは『実践編5(デプロイ)』パートについて実践内容を紹介します。

目次

• Step11. dbt環境の本番環境デプロイ
  • gitリポジトリの状況確認
  • 本番環境の確認(と設定変更)
  • ジョブの作成と実行、内容確認
• まとめ

Step11. dbt環境の本番環境デプロイ

前エントリまでの実施手順でdbtにおけるテストと文書化の準備が終わったので、設定やコードを開発環境から本番環境にデプロイする準備が整いました。コードを本番環境にデプロイする前に、環境について簡単に言及しておきます。

前エントリ完了の時点までで、dbt Cloud IDEで行ってきた作業は全て「開発環境」で行われ、編集してきたコードや設定はフィーチャーブランチにコミットされ、構築したモデルは開発環境接続で定義された内容でSnowflakeの開発スキーマに作成されました。フィーチャーブランチでこの作業を行うことで、私達のコードを他の同僚がビルドしているコードや、既に本番環境への準備が出来ていると判断されたコードから切り離すことが出来ます。

Snowflakeの開発スキーマでモデルをビルドすることで、私達がまだ修正やテストを行っているかもしれないデータベースオブジェクトと、本番用ダッシュボードやその他の下流の依存関係を実行しているデータベースオブジェクトを分離することが可能となります。gitブランチとSnowflakeデータベースオブジェクトの組み合わせが、私達の環境を形成します。

gitリポジトリの状況確認

作業を始める前に、全ての作業をfeatureブランチにコミットしたことを確認します。まだコミットする作業が残っている場合は、Commit and pushボタンをクリックしてメッセージを入力し、もう一度Commitをクリック。

全ての作業がコミットされると、gitワークフローのボタンが[Merge to main]と表示されるようになります。をクリックすると、マージ処理がバックグラウンドで自動的に実行されます。完了すると、ブランチを作成というボタンが表示され、現在見ているブランチがメインとなります。

全ての開発作業がメインブランチにマージされたことで、デプロイジョブをビルドできます。本番環境と本番ジョブはPartner Connectによって自動的に作成されています。なのでその設定を状況に合わせて更新していきます。

本番環境の確認(と設定変更)

画面上部メニューの[Deploy]タブをクリックし、[Environments]をクリック。

2つの環境が表示されるので、Deployment環境をクリックして開き、右上の[Settings]をクリックして変更。

設定に変更を加える前に、この環境内で何が定義されているかについて言及していきます。

• Snowflake接続には、dbt Cloudがこの環境に使用している資格情報が表示されている。これらの情報はSnowflake Partner Connectを通じて作成されたものと同じ
• デプロイジョブはPC_DBT_DBデータベースに構築されており、そのためにデフォルトの Partner Connectロールとウェアハウスが使われている
  • 
• デプロイ認証情報セクションでは、Partner Connect ジョブで作成された情報も使用して認証情報接続を作成している(ただし、開発環境のスキーマとして使用してきたものと同じデフォルト スキーマが使用されている)
  • 

デプロイ認証情報関する情報を更新し、本番環境専用の新しいスキーマを作成します。画面右上の右上隅の[Edit] をクリック。

[Deployment Credentials]セクションの情報を本番環境の内容に更新します(ここではアカウント情報を環境に繋がるユーザー、スキーマを手順に従ってproductionとしました)。 本番環境のスキーマをproductionに更新することで、この環境のデプロイジョブが、Snowflake Connectionセクションで定義したように、PC_DBT_DBデータベース内のproductionスキーマでdbtモデルを構築される形となります。

変更を加えた後は、画面右上にある[Save]をクリック。

ジョブの作成と実行、内容確認

元ネタ手順では「ジョブが既に用意されています。実行しましょう！」だったのですが手元の環境では既存作成済みのジョブはありませんでした。なので流れで作っていきます。

ジョブ作成画面にて[Create Job/Deploy Job]を選択。

[Job Settings]欄に必要事項を適宜記入。[Exection Settigns]のコマンド部分もデフォルト値指定のdbt buildで問題ありません。

スケジュール設定については今回は行わない形としました。

[Advanced Setting]も特に触らず。画面右上の[Save]を押下して設定を保存します。

ジョブ実行の準備が出来ました！[Run Now]を押下。

ジョブが実行キューに入り、程無くして実行に入ります。

実行完了、成功です！

途中警告が出ているようですが、実行自体に問題は無いようです。

Snowflake環境に移動して、本番スキーマで全てが期待通りに構築されたことを確認してみます。以下のような形で、Snowflakeアカウントのデータベースオブジェクトを更新すると、デフォルトのPartner Connectデータベース内に本番スキーマが表示されていることを確認出来ました。

まとめ

という訳で、Snowflake QuickStarts『Accelerating Data Teams with Snowflake and dbt Cloud Hands On Lab』実践第8弾、dbt Cloud実践編5(デプロイ)に関する内容の紹介でした。

次エントリ(第9弾)ではSnowsightダッシュボード可視化編に関するパートを進めていきます。

• dbt の記事一覧 | DevelopersIO
  • dbt Cloud の記事一覧 | DevelopersIO
• Snowflake の記事一覧 | DevelopersIO