dbtの公式入門ドキュメント『Quickstart for dbt Cloud and Snowflake』を実践してみた #dbt

特集

しんや

2023.09.01

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

先日公開した下記エントリはBigQuery環境に向けてdbt Cloud環境をセットアップし、一連の作業を行うチュートリアルの内容でした。

dbtが公開しているドキュメントの中には、その他のデータウェアハウス向けのチュートリアルも公開されています。当エントリではその中のSnowflake版、『Quickstart for dbt Cloud and Snowflake』をBigQuery版同様にやってみた内容を紹介したいと思います。

目次

　

01.はじめに

このドキュメントでは、dbt CloudでSnowflakeを扱ったプロジェクトを構築する手順について紹介されています。行うアクションは主に以下の通り。

  • 新しいSnowflakeワークシートを作成
  • Snowflakeアカウントにサンプルデータをロード
  • dbt CloudをSnowflakeに接続
  • サンプルクエリを取得し、dbtプロジェクトのモデル(select文を使用)に変換
  • dbtプロジェクトにソースを追加/これによりSnowflakeに格納した生データに名前をつけて情報を記述することが可能に
  • モデルにテストを追加
  • モデルのドキュメントを作成
  • ジョブの実行スケジュールを設定

予め必要なもの、やっておく事などは以下の通り。

  • dbt Cloudのアカウント
  • Snowflakeの(トライアル)アカウント
    • ユーザーにはACCOUNTADMIN権限が付与されている必要があります。
    • トライアルアカウント作成で臨んだ場合、アクセス権が付与されている状態を実現するためにEnterprise Snowflakeエディションを選択してください。
    • 通常アカウントの場合も、管理者との調整の上ユーザーに権限を付与してもらうようにしてください。

　

02.Snowflakeワークシートを作成

Snowflakeアカウントにログインし、画面右上の[+]から『SQLワークシート』を起動。

　

03.データのロード

今回実践で利用するSnowflake環境にデータをロードします。データはdbtが用意した「S3にアップロード済みのCSVデータ(パブリックアクセス可能なもの)」を活用します。

検証用のデータウェアハウス、データベース、スキーマを以下のSQL文を実行して作成。

create warehouse transforming;
create database raw;
create database analytics;
create schema raw.jaffle_shop;
create schema raw.stripe;

上記SQL文で作成したrawデータベース、jaffle_shop,stripeスキーマ配下に3つのテーブルを作成し、COPYコマンドを使ってそれらのテーブルにデータをロードします。

  • customersテーブル：
create table raw.jaffle_shop.customers 
( id integer,
  first_name varchar,
  last_name varchar
);

copy into raw.jaffle_shop.customers (id, first_name, last_name)
from 's3://dbt-tutorial-public/jaffle_shop_customers.csv'
file_format = (
    type = 'CSV'
    field_delimiter = ','
    skip_header = 1
    );
  • ordersテーブル
create table raw.jaffle_shop.orders
( id integer,
  user_id integer,
  order_date date,
  status varchar,
  _etl_loaded_at timestamp default current_timestamp
);

copy into raw.jaffle_shop.orders (id, user_id, order_date, status)
from 's3://dbt-tutorial-public/jaffle_shop_orders.csv'
file_format = (
    type = 'CSV'
    field_delimiter = ','
    skip_header = 1
    );
  • paymentテーブル
create table raw.stripe.payment 
( id integer,
  orderid integer,
  paymentmethod varchar,
  status varchar,
  amount integer,
  created date,
  _batched_at timestamp default current_timestamp
);

copy into raw.stripe.payment (id, orderid, paymentmethod, status, amount, created)
from 's3://dbt-tutorial-public/stripe_payments.csv'
file_format = (
    type = 'CSV'
    field_delimiter = ','
    skip_header = 1
    );

3テーブルへのデータロードの結果を改めて以下3つのSELECT文で確認します。

select * from raw.jaffle_shop.customers;
select * from raw.jaffle_shop.orders;
select * from raw.stripe.payment;

　

04.dbt CloudからSnowflakeへの接続

dbt Cloud環境からSnowflakeへの接続設定を行います。Snowflakeの場合、以下2つの接続方法を選ぶことが出来ます。今回は既にdbt Cloud環境もありますので後者の「手動設定による接続」で進めます。

  • Partner Connect経由での接続：
    • 新しいSnowflakeトライアルアカウント内からdbt Cloudアカウントを作成。
  • 手動設定による接続
    • dbt Cloudアカウントを別途作成し、Snowflakeへの接続も自分で行う(手動で接続)。

dbt Cloud環境にログインし、画面右上メニューから[Account Settings]を選択。

[Projects]→メニューに遷移後、一覧画面右上の[New Project]を押下。

プロジェクト名に任意の名前を設定し、[Continue]を押下。

ウェアハウスの選択画面。ここでは接続先に[Snowflake]を選択します。[Next]を押下。

接続先設定画面に遷移。Account(アカウント)に関しては、予め接続していたアカウントURLから必要な情報を抜き出して設定します。

  • 接続先アカウントのログイン画面に表示されているURLからsnowflakecomputing.comを抜き出す。
  • アカウント情報の順序は、Snowflakeのバージョンによって異なります。例えば、SnowflakeのClassicコンソールのURLは以下のようになります：oq65696.west-us-2.azure.snowflakecomputing.com

有効となる指定方法は[アカウント名]または[アカウント名].[リージョン].[クラウド種別]となる模様。このフォーマットに倣い、必要な情報を[Account]に指定します。

データベース名、ウェアハウス名はチュートリアルに倣う形で値を入力しておきます。

[Development Credentials]では接続先の認証情報等をそれぞれ入力。

  • ユーザー名＆パスワードは接続が可能な(前述操作で行った際に利用した)情報を設定。
  • スキーマ名に関しては、ログインアカウントに設定された名前を使ってdbt側で自動設定されます。ここではその自動設定された情報をアレンジして設定してみることにしました(dbt_ の後を修正しました)。

一通り設定が終わったら[Test Connection]を押下。

DB接続テストが完了したことを確認し、[Next]を押下。

　

05.マネージドリポジトリのセットアップ

今回のチュートリアル実践ではdbt Cloudで用意されているマネージドなリポジトリを活用することにします。任意のリポジトリ名を入力し、[Managed]が選択された状態で[Create]を押下。

リポジトリ連携が完了し、プロジェクトの準備が出来ました！

　

06.dbtプロジェクトの初期化と開発の開始

ここからは大筋、先日投稿した下記のBigQuery版と変わりません。差分で異なる部分、また変化のあった部分についてのみ抜粋して内容を紹介するに留めて置きたいと思います。

手順を最後まで進めてdbt runを実行したところ、analyticsデータベースに関するアクセスでエラーが発生。

前述手順でroleを指定する際、特に値を設定していなかった一方で、環境(ウェアハウス、データベース、スキーマ)を作成する際はACCOUNTADMIN権限で作っていたな...と思い、プロジェクトの設定画面で未入力だったroleの指定を修正してみることにしました。

設定保存後、dbt IDEに遷移すると環境のリフレッシュを求められるので従います。

改めてdbt runコマンド実行。今度は上手く行きました。

　

07.最初のモデル実行(ビルド)

当ステップに関してはBigQuery版と特に流れは変わらず。ブランチを作成し、customers.sqlファイルを作成、dbt runコマンドを実行し対応するモデルを作成しました。

　

08.モデルのマテリアライズ方法を変更

当ステップに関してはBigQuery版と特に流れは変わらず。customer.sqlで指定したモデルの対象となるモデルがテーブルとして作成されていたものが、設定ファイルの指定を変えることでビューとして再作成されていることがSnowflakeコンソールを通じて確認出来ました。

　

09.exampleモデルの削除

当ステップに関してはBigQuery版と特に流れは変わらず。例として生成されていたモデルに関する設定とファイル/フォルダを作成し、dbt runコマンドを実行して実行が成功していることを確認しました。

　

10.他のモデルの上にモデルを作成する

当ステップに関してはBigQuery版と特に流れは変わらず。モデル間の依存関係がある設定に変更し、順序を考慮したモデル作成の実行が行われることを確認しました。

　

11.ソースの上にモデルを作成する

このパートはBigQuery版には無い手順でした。なので順を追って見ていきます。

ソース(source)という仕組みを利用することで、抽出やロードツールによってウェアハウスにロードされるデータに名前を付けて参照することが出来るようになります。dbtでこれらのテーブルをソースとして宣言することで以下のアクションが可能となります。

  • {{ source() }}関数を利用し、モデル内のソース・テーブルから参照させる

  • ソースデータに関する仮定をテストする
  • ソースデータの"鮮度"を計算する

models/sources.ymlというファイルを作成し、以下の記述でファイルを保存。

version: 2

sources:
    - name: jaffle_shop
      description: This is a replica of the Postgres database used by our app
      database: raw
      schema: jaffle_shop
      tables:
          - name: customers
            description: One record per customer.
          - name: orders
            description: One record per order. Includes cancelled and deleted orders.

上記作成の内容を参照表示させる形で、models/stg_customers.sql、models/stg_orders.sqlのそれぞれのfrom句以降の内容を以下の形に変更。

models/stg_customers.sql

select
    id as customer_id,
    first_name,
    last_name

from {{ source('jaffle_shop', 'customers') }}

models/stg_orders.sql

select
    id as order_id,
    user_id as customer_id,
    order_date,
    status

from {{ source('jaffle_shop', 'orders') }}

dbt runコマンド実行、これまで同様に処理が成功することを確認。実行結果自体は同じですが、この設定を行うことでstg_cusutomersモデルとstg_ordersモデルは、Snowflakeの同じ生データソースからクエリを実行します。ソースを使用することで、生データをテストして文書化し、ソースの系統を理解することができます。

　

12.モデルに対してテストを追加

当ステップに関してはBigQuery版と特に流れは変わらず。モデルに対してテストを追加し、そのテストが全て成功することを確認しました。

　

13.モデルに対してドキュメントを生成

当ステップに関してはBigQuery版と特に流れは変わらず。dbt docsコマンドを用いて設定ファイルからドキュメントを生成し、静的ファイルとして参照閲覧出来ることを確認しました。

　

14.ここまでの変更をコミット＆マージ

当ステップに関してはBigQuery版と特に流れは変わらず。ここまでの変更をコミットし、ブランチにマージしました。

　

15.dbtのデプロイ

当ステップに関してはBigQuery版と特に流れは変わらず。一連のデプロイ作業を行い、最終的にデプロイ環境向けのドキュメントも閲覧出来ることを確認しました。

　

まとめ

という訳で、dbtのクイックスタートチュートリアル：Snowflake版の実践内容紹介でした。接続してしまえばあとはdbt側の世界の話なのでそこまでデータウェアハウス固有の条件や状況に悩まされる事無く、スムーズに作業を終えることが出来ました。

一方でこれはBigQuery版Snowflake版双方を実践して感じたことですが、データウェアハウスの世界の要素を踏まえて作成・生成されたdbtの世界の各種要素はそれぞれルールや関連性の"クセ"があるな、とも思いました。この辺りは情報を整理してスムーズな理解を出来るよう、引き続き色々触って試行錯誤してみようと思います。

*

関連記事

dbtで外部テーブルを参照するモデルを作成する

おざわ（じ）

2024.04.30

dbtの認定試験『dbt Analytics Engineering Certification Exam』が5月から新しくなるようです #dbt

しんや

2024.04.11

ストアドプロシージャからdbtへの移行手順 #dbt

しんや

2024.04.05

dbtでのSQLモデル記述時に利用推奨されている『共通テーブル式(CTE/Common Table Expression)』について

しんや

2024.03.31