dbt CloudでSnowflakeとGithubリポジトリの設定を行いプロジェクトを作ってみる #dbt #SnowflakeDB

2022.02.22

さがらです。

最近さらにデータエンジニア界隈で賑わいを見せているdbtについて本記事では改めて、dbt Cloudを用いてSnowflakeをConnectionとして設定したdbt Projectの作り方をまとめてみます。 また、おまけで自前のGithubリポジトリを設定する方法も書いておきます。

※ちなみにSnowflakeの「パートナー接続」機能でも簡単に連携可能ですが、データベース、ウェアハウス、ユーザー、ロールの名称が固定されています。そのため、各オブジェクトの定義も自分で行い、1から設定する方法を本記事でまとめておきます。

事前準備

dbtで新しいProjectの作成に取り掛かる前に、事前に準備しておきたいことがあります。

Snowflakeでdbtのジョブ用のウェアハウスの準備

dbtはELTのT(Transform)を担い、DWH上でデータマートに当たるテーブルやビューを生成するためのツールです。そのため、その生成処理を担うウェアハウスの準備が必須となります。

すでにデータロードやBIツール用途などに使用しているウェアハウスではなく、dbt専用にウェアハウスを用意しておくとリソースの奪い合いもなくdbtで消費されたクレジットの確認も容易になるため、dbt専用にウェアハウスを作成することをオススメします。

以下は、ウェアハウスを作成するときのクエリサンプルです。各種オプションの設定値は公式Docも参考にしてみてください。

USE ROLE SYSADMIN;

CREATE OR REPLACE WAREHOUSE <任意のウェアハウス名> WITH
    WAREHOUSE_SIZE = 'XSMALL'
    WAREHOUSE_TYPE = 'STANDARD'
    AUTO_SUSPEND = 60
    AUTO_RESUME = TRUE
    MIN_CLUSTER_COUNT = 1
    MAX_CLUSTER_COUNT = 1
    SCALING_POLICY = 'STANDARD'
    INITIALLY_SUSPENDED = TRUE;

Snowflakeでdbt用のロールの準備

dbtで発行されたクエリを実行するロールを準備します。

必要なPrivilegeは以下です。(Snowflakeのパートナー接続でdbtと連携した際に自動で作成されるロールPC_DBT_ROLEPC_DBT_DB_PICKER_ROLEのPrivilegeより引用)

  • dbtからクエリ発行対象のデータベースに対するPrivilege
    • DATABSEへのUSAGE権限
    • SCHEMAへのUSAGE権限
    • TABLEへのSELECT権限 
  • dbtで生成されるスキーマ・テーブル・ビューが格納されるデータベースに対するPrivilege
    • DATABSEへのUSAGE権限、CREATE SCHEMA権限
  • 使用するウェアハウスに対するPrivilege
    • 対象のWAREHOUSEへのOPERATE権限、USAGE権限

また、Snowflakeのベストプラクティスとして作成したロールは必ずSYSADMINの下に連なるようにしましょう。SYSADMINロールの子はもちろん、SYSADMINの孫ロールでもOKです。

実際に運用する上では、dbtで生成されたテーブルやビューを参照するためのロールも必要になると思います。参照するためのロールも踏まえた、dbtにおけるSnowflakeのロール構成についてはこちらの記事で私の考えをまとめていますのでぜひご覧ください。

Gitリモートリポジトリの準備

続いて、Gitリモートリポジトリの準備です。

dbt側でホスティングしているGitリポジトリを設定して使うことも可能ですが、プルリクエストなどのGit機能が使用できません。そのため、dbtのベストプラクティスとしても、ユーザー自身が用意したGithubリポジトリを使用することを推奨しています。

本記事ではGithubのリモートリポジトリとの連携方法をまとめていきます。私は事前に空のGithubリポジトリをPrivateで作成しておきました。

1.Projectの新規作成

まず、開発のベースとなりGitリポジトリと一対となる「Project」を新規作成します。

画面左上の三本線のメニューバー➟Account SettingsNew Projectと順番に押します。

下図の画面が表示されたら、Beginを押します。

NAMEにプロジェクト名を入れたあと、右上のContinueを押します。

使用するデータウェアハウスを選択する画面が出たら、Snowflakeを選択します。

続いて、使用するSnowflakeに関する設定を行います。

まず画面一番上のNAMEですが、対象のConnectionの名前を入力します。使用するアカウント名やデータベース名とは関係ないため、自由に入力してOKです。

続いて、使用するSnowflakeアカウントやデータベースの情報を入力します。

  • ACCOUNT
    • 使用するSnowflakeのアカウント識別子を入れます。より詳しくは公式Docをご確認ください。
    • SnowflakeのURLで言うと、https://.snowflakecomputing.comの間の内容です。
    • dbt公式Docの例:db5261993,db5261993.east-us-2.azure
  • ROLE(OPTIONAL)
    • 対象のプロジェクトで発行されたクエリを実行するロール名を入力します。任意ですが、使用するロールを明確にするためにも指定することを推奨します
  • DATABASE
    • 対象のdbt projectによりスキーマやテーブルが生成されるデータベース名を指定します。
    • 対象のdbt projectで発行されるクエリが1つのデータベース内で完結する場合:元データを保持するデータベースを指定しても良いと思いますが、開発環境に当たるdbtユーザーごとのスキーマと、本番環境に当たるスキーマが作られることにご注意ください。
    • 対象のdbt projectが複数のデータベースのテーブルを用いる場合:「元データ」と「dbtにより生成された複数データベースのテーブルを結合したデータ」が混在しないように、dbt project専用のデータベースを新しく作成することを推奨します。
  • WAREHOUSE
    • 対象のdbt projectがクエリを発行するときに使用するウェアハウス名を指定します。

Snowflakeの設定の最後に、対象のdbt projectでの開発時に使用するSnowflakeの認証情報を設定します。

  • AUTH METHOD
    • Username & PasswordKey Pairから設定可能です。この記事ではひとまずUsername & Passwordで進めます。
    • Snowflakeのキーペア認証を行いたい場合は、こちらの記事も参考にしてみてください。
  • USERNAME
    • 対象のSnowflakeアカウントでのユーザー名を入れます。
  • PASSWORD
    • 対象のユーザーのパスワードを入れます。
  • SCHEMA
    • 開発時に実行したジョブが生成するテーブル・ビューの保存先のスキーマ名を入れます。
    • デフォルトで、ユーザー名を用いたdbt_ssagaraのようなスキーマ名が入っていると思います。必要に応じて変更してください。
  • TARGET NAME
    • ここに記入した情報を用いて、dbt modelで条件分岐を行いたいときに設定します。例えば、開発環境ではある1年だけのデータに絞り込むが、本番環境では絞り込まない、といった条件分けが可能になります。詳しくは公式Docをご確認ください。
    • この設定は後で各ユーザーのProfileから変更可能ですので、まずはdefaultで問題ないと思います。必要に応じて、変更しましょう。
  • THREADS
    • dbtはmodelという単位で処理を実行していきますが、このTHREADSはジョブ実行時の最大同時model処理数を意味します。
    • デフォルトでは「4」と設定されているので、定義されたDAGに沿って最大4つのmodelが同時に実行される、ということになります。
    • 値を高くしすぎると他のクエリの動作に影響を及ぼす可能性があるため、状況に応じて上げたり下げたり検討することが望ましいです。
    • より詳しくは、公式Docをご確認ください。

ここまで入力し終えると、右上のTestから正しく接続が行えるかテストが可能です。テストに成功したら、Continueを押して次の設定に移ります。

次はGitリポジトリの設定です。今回は冒頭で述べたとおり、Githubのリモートリポジトリを設定していきます。

Add repository from:からGithubを選択します。

すると、dbt CloudがログインしているGithubアカウントへの認可を求めてきます。問題なければAuthorize dbt Cloudを押しましょう。

画面がまたdbt Cloudに戻りGithubを選択すると、No repos foundと出てきます。まだ接続したGithubアカウントのどのリポジトリに対してもアクセス権を与えていないからですね。

ここまでで一旦projectとしての設定は終わりとし、ProfileでのGithubリポジトリの設定に移ります。

2.ProfileでのGithubアカウントの連携設定

右上のユーザーアイコンから、Profileを押します。

左のIntegrationsを押し、Githubの設定中のConfigure integration in Githubを押します。

対象のGithubアカウントに対して、dbt CLoudをインストールするよう促されますので、Installを押します。

これで、dbt CloudとGithubアカウントの連携設定は完了です!

3.dbt ProjectにGithubリモートリポジトリを紐付ける

最後に、作成したdbt projectへのGithubリモートリポジトリの紐付けを行います。

画面左上の三本線のメニューバー➟Account Settings➟作成したプロジェクト、と順番に押します。

Configure a repositoryを押します。

Githubを選択すると、連携したGithubアカウントで使用できるリポジトリの一覧が出てきます。検索Boxも使用して、用意したリポジトリを選択します。

一定時間経過後、下図のように連携したGithubリモートリポジトリへのDEPLOY KEYなどが表示されれば、設定完了です!

参考:プロジェクト設定後の開発の流れ

あとはdbtでひたすら開発していくだけなのですが、どんな流れで開発していけばよいのかイメージがつかない…という方もいるかと思います。

dbtを用いた開発の流れの参考として、弊社でもいくつかブログ記事を書いていますので、ぜひ参考にしてみてください!