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

モダンデータスタック(MDS)

さがら

2022.02.22

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

さがらです。

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

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

事前準備

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_ROLE、PC_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などのGitリモートリポジトリを使用することを推奨しています。

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

１．Projectの新規作成

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

画面左上の三本線のメニューバー➟Account Settings➟New 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 ＆ PasswordかKey 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をご確認ください。