dbtの公式チュートリアル「Quickstart for dbt and Snowflake」をdbt Projects on Snowflakeでやってみた
さがらです。
dbt Cloud用の公式チュートリアルとして、「Quickstart for dbt and Snowflake」が提供されています。このチュートリアルはdbt自体のことを学ぶ始めの一歩として、おすすめの内容となっています。
また、2025年6月末にSnowflake内でdbtの開発・実行が行えるdbt Projects on Snowflakeがパブリックプレビューとなっています。
この「Quickstart for dbt and Snowflake」のチュートリアルをdbt Projects on Snowflakeでやってみたので、その内容を本記事でまとめてみます。
注意事項
以下のdbt Cloudを前提とした事項は本記事では対象外とします。ご注意ください。
- Managed Repositoryの利用
- 今回のチュートリアルではGit連携をせずに、開発を行います。
- dbt Projects on SnowflakeにおけるGit連携については、こちらのブログをご覧ください
- ドキュメントの閲覧
- Environment・Jobの設定（dbt Cloudのみの機能）
- dbt Projects on Snowflakeでは
profiles.ymlの定義と、dbt Projectsのデプロイ～タスク実行が該当しますので、これらの内容で代替します。
- dbt Projects on Snowflakeでは
0.事前準備
Snowflakeトライアルアカウントの作成
今回はSnowflakeのトライアルアカウントを利用しますので、トライアルアカウントを作成します。
セカンダリロールの有効化 ※もし有効化されていない場合
続いて、セカンダリロールが有効化されているかを、ワークシート上で確認します。
以下のクエリを実行し、default_secondary_rolesが["ALL"]になっていることを確認してください。
show users;
もし、別の値だった場合は、以下のクエリを実行してセカンダリロールを有効化してください。
alter user <ユーザー名> set default_secondary_roles = ('all');
1.Introduction
この章では、このチュートリアルで何を行うかの説明があります。
以下はリンク先の英文を日本語に翻訳しただけですが、以下の内容を順番に行っていきます。
- 新しいSnowflakeワークシートを作成します。
- サンプルデータをSnowflakeアカウントにロードします。
- サンプルクエリをdbtプロジェクトのモデルに変換します。dbtのモデルはSELECT文です。
- dbtプロジェクトにソースを追加します。ソースを使用すると、Snowflakeに既にロードされている生データに名前を付け、説明を付けることができます。
- モデルにテストを追加します。
- モデルを文書化します。
- ジョブの実行をスケジュールします。
- ※ジョブについては、dbt Projectsのデプロイ～タスク実行で代替します。
2.Create a new Snowflake worksheet
この章では、Snowflakeでクエリを実行するためにワークシートを作成します。
Snowflakeの画面左のメニューのProjectsから、Worksheetsを押します。
右上の+を押して、新しいワークシートを作成します。
3.Load data
この章では、チュートリアルで使用するデータをロードします。
まず、以下のクエリを実行して、チュートリアルに必要なデータベース・スキーマ・テーブル・ウェアハウスを作成します。テーブルについてはパブリックのS3からデータロードも行います。
注意点として、８行目のcreate schema analytics.dbt_ssagara;については、ご自身の名前などを用いて、自分のスキーマであることがわかるようにしてください。（私はsagara satoshiという名前のため、dbt_ssagaraとしています。）
use role accountadmin;
create warehouse transforming;
create database raw;
create database analytics;
create schema raw.jaffle_shop;
create schema raw.stripe;
create schema analytics.dbt_ssagara;
create schema analytics.prod;
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
);
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
);
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
);
この後、以下のクエリを順番に実行して、問題なくデータが各テーブルにロードされていることを確認します。
select * from raw.jaffle_shop.customers;
select * from raw.jaffle_shop.orders;
select * from raw.stripe.payment;
4.Connect dbt to Snowflake
この章では、dbt CloudからSnowflakeへの接続の設定を行うのですが、dbt Projeccts on Snowflakeでは不要のため、スキップします。
5.Set up a dbt managed repository
この章では、dbt Cloud特有の機能であるManaged Repositoryのセットアップを行うのですが、dbt Projeccts on Snowflakeでは関係のない設定のため、スキップします。
本記事冒頭の注意事項でも書いたように、今回のチュートリアルではGit連携をせずに開発を行います。
参考までに、dbt Projects on SnowflakeにおけるGit連携については、以下のブログをご覧ください。
6.Initialize your dbt project and start developing
この章では、dbt Projectのセットアップを行います。dbt Projects on Snowflake自体の操作に移ります！
Snowflakeの画面左のメニューのProjectsから、Workspacesを押します。
画面左上の+ Add newを押し、dbt Projectを押します。
表示されたポップアップで以下の内容を入力して、右下のCreateを押します。
Project Name：dbt_quickstart- 任意の名称でOKです
Role：accountadmin- Workspace内のdbt Projectsを介してクエリが実行されるときに利用されるロール。今回はチュートリアルのためACCOUNTADMINを利用しますが、使用するデータベース・スキーマ・テーブルの参照権限と、dbtを介してオブジェクトを作りたい作成先となるデータベース・スキーマの作成権限があるロールであればOKです。
Warehouse：transforming- Workspace内のdbt Projectsを介してクエリが実行されるときに利用されるウェアハウス
Database：analytics- dbtの出力先となるデータベース
Schema：dbt_ssagara- dbtの開発時の出力スキーマ
この操作により、新しいdbt Projectが作られます！
先ほど入力した内容は、profiles.ymlに記載されます。profiles.ymlについての公式ドキュメントはこちらになります。
profiles.ymlの内容を見ると、dev:と記載されていますが、これはdbtでいう開発環境・本番環境などdbtコマンドの実行先となる環境を切り替える際に利用できるtargetの名前となります。（dev以外の名前を設定しても問題ありませんが、現在設定されているprofileは開発環境向けなのでdevで問題ないと思います。）
また、target: devとなっていますが、これは「dbtコマンド実行時にtargetを指定しない場合はdevを使うよ」ということを意味しています。本番環境に対するprofileも後でprofiles.ymlに追記しますが、不用意なコマンドで本番環境を変更してしまわないように、target: devのまま変えないことを推奨します。
また、このタイミングで一度dbt runを実行してみます。dbt runは、modelsフォルダ内にある.sqlファイルで書かれたSELECT文を全て、指定したデータベース・スキーマに対してCTAS・CVAS文として実行するコマンドです。
右上のコマンドを指定するボタンからRunを選択し、再生ボタンを押します。
すると、Workspaceの下部にログが流れます。
処理が完了したら、Workspace左下のObject Explorerからdbt_ssagaraスキーマを確認してみます。デフォルトでmodelsフォルダに入っていたMY_FIRST_DBT_MODELとMY_SECOND_DBT_MODELが作られているのがわかりますね！
7.Build your first model
この章では、Snowflakeにロードしたデータを用いた新しい.sqlファイルを作成して、dbt runを実行してみます。
「model」というワードがありますが、dbtではmodelsフォルダに格納された.sqlファイルを「model」と呼びます。
modelsフォルダの横の+を押してSQL Fileを選択し、customers.sqlというファイルを作成します。
右側のエディター欄でcustomers.sqlを編集できるようになりましたので、以下のSQLをコピーして貼り付けます。
with customers as (
select
id as customer_id,
first_name,
last_name
from raw.jaffle_shop.customers
),
orders as (
select
id as order_id,
user_id as customer_id,
order_date,
status
from raw.jaffle_shop.orders
),
customer_orders as (
select
customer_id,
min(order_date) as first_order_date,
max(order_date) as most_recent_order_date,
count(order_id) as number_of_orders
from orders
group by 1
),
final as (
select
customers.customer_id,
customers.first_name,
customers.last_name,
customer_orders.first_order_date,
customer_orders.most_recent_order_date,
coalesce(customer_orders.number_of_orders, 0) as number_of_orders
from customers
left join customer_orders using (customer_id)
)
select * from final
貼り付けた後は下図のようになると思います。
dbt runを実行するため、右上のコマンドを指定するボタンからRunを選択し、再生ボタンを押します。
処理が完了したら、Workspace左下のObject Explorerからdbt_ssagaraスキーマを確認してみます。CUSTOMERSというビューが作られていることがわかります。
8.Change the way your model is materialized
この章では、Snowflakeに対してテーブル・ビューなど、どの方法で作成するのかを設定するMaterializationについて、試していきます。
まず、dbt_project.ymlを開きます。このファイルは、dbt Project全体の設定やフォルダパスの指定などを行える、dbtにとって必須のファイルとなります。
最下部のmodels:のコードを、下記のように書き換えます。
- Before
models:
dbt_quickstart:
+materialized: view
- After
models:
dbt_quickstart:
+materialized: table
この状態でdbt runを実行してどう変わるか挙動を確認します。右上のコマンドを指定するボタンからRunを選択し、再生ボタンを押します。
処理が完了したら、Workspace左下のObject Explorerからdbt_ssagaraスキーマを確認してみます。全てテーブルで作られていることがわかると思います。
参考情報として、Materializationの設定はdbt_project.ymlでプロジェクト全体やフォルダレベルで設定することに加えて、各.sqlファイル内でも指定可能です。例としてmy_first_dbt_model.sqlを見ると、下図のようにconfigの指定があると思います。dbt_project.ymlでも.sqlファイルでも同じconfigの設定がある場合は、.sqlファイルの方が優先される仕様となっています。
もう一つ参考情報として、Materializationはテーブルとビューだけでなく、増分更新に対応したincremental、オブジェクトは生成せずWITH句として使われるだけのephemeral、もあります。これらの詳細については以下の公式ドキュメントをご覧ください。
9.Delete the example models
この章では、デフォルトで追加されていたサンプルの.sqlファイルを削除します。
modelsフォルダから、my_first_dbt_model.sqlとmy_second_dbt_model.sql、それぞれ横の「・・・」を押し、Deleteを押します。
これでこの章で行うこととしては終わりなのですが、注意点としては、dbtは.sqlファイルが削除されたからといって、その.sqlファイルに対応するテーブル・ビューが削除される仕様ではないということです。.sqlファイル削除後は、ユーザー側で手動のSQLコマンド実行はもちろん、何かしらの方法でテーブル・ビューを削除する必要がありますのでご注意ください。
10.Build models on top of other models
この章では、dbtのベストプラクティスに沿って、データをクリーンアップするロジックを分解して別の.sqlファイルを作っていきます。（Staging層に該当します。）
まず、Staging層となる以下2つの新しい.sqlファイルをmodelsフォルダの直下に作成します。
stg_customers.sql
select
id as customer_id,
first_name,
last_name
from raw.jaffle_shop.customers
stg_orders.sql
select
id as order_id,
user_id as customer_id,
order_date,
status
from raw.jaffle_shop.orders
この後、先程作成していたcustomers.sqlも以下の内容に書き換えます。ポイントは、{{ ref() }}という書き方で既存の.sqlファイルの名前部分を指定することで、指定した.sqlファイルの実行が終わった後にこの.sqlファイルを実行するように処理の依存関係を構築することができます。
with customers as (
select * from {{ ref('stg_customers') }}
),
orders as (
select * from {{ ref('stg_orders') }}
),
customer_orders as (
select
customer_id,
min(order_date) as first_order_date,
max(order_date) as most_recent_order_date,
count(order_id) as number_of_orders
from orders
group by 1
),
final as (
select
customers.customer_id,
customers.first_name,
customers.last_name,
customer_orders.first_order_date,
customer_orders.most_recent_order_date,
coalesce(customer_orders.number_of_orders, 0) as number_of_orders
from customers
left join customer_orders using (customer_id)
)
select * from final
このModel間の依存関係をWorkspace上で確認できるため、各SQLファイルをコンパイルするdbt compileコマンドを実行します。
この後、Workspaceの画面右下のDAGを押すと、下図のように依存関係を表したリネージが表示されます。
この章の最後に、dbt runを実行して開発環境のスキーマに出力してみます。右上のコマンドを指定するボタンからRunを選択し、再生ボタンを押します。
処理が完了したら、Workspace左下のObject Explorerからdbt_ssagaraスキーマを確認してみます。新しく作成した2つの.sqlファイルが、テーブルとして出力されていることがわかります。
11.Build models on top of sources
この章では、dbtでの加工元となるソースデータを定義する「source」の設定を行っていきます。sourceを設定することで、リネージ上にソースデータを表示したり、12章で行うテストをソースデータに対して行った後にdbtでの変換を行う、ということが可能となります。
まず、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.
次に、Staging層として先ほど作成した2つ.sqlファイルを以下の内容に修正し、sourceを参照するようにします。sourceを参照する際は、{{ source('jaffle_shop', 'customers') }}のように記述します。
stg_customers.sql
select
id as customer_id,
first_name,
last_name
from {{ source('jaffle_shop', 'customers') }}
stg_orders.sql
select
id as order_id,
user_id as customer_id,
order_date,
status
from {{ source('jaffle_shop', 'orders') }}
sourceも含めた依存関係をWorkspace上で確認できるため、各SQLファイルをコンパイルするdbt compileコマンドを実行します。
この後、Workspaceの画面右下のDAGを押すと、sourceも含めたリネージが表示されます。
また、dbt compileを実行したことで、targetフォルダ内のcompiledフォルダにて、コンパイルされた各.sqlファイルを確認可能です。下図のように、sourceの箇所が適切なテーブル名に置き換わっていることがわかります。
12.Add tests to your models
この章では、dbt特有の機能と言えるデータテストの機能を試していきます。
データテストはyamlファイルで定義を行うため、modelsフォルダ内でschema.ymlを作成し、以下の内容を記述します。
version: 2
models:
- name: customers
description: One record per customer
columns:
- name: customer_id
description: Primary key
data_tests:
- unique
- not_null
- name: first_order_date
description: NULL when a customer has not yet placed an order.
- name: stg_customers
description: This model cleans up customer data
columns:
- name: customer_id
description: Primary key
data_tests:
- unique
- not_null
- name: stg_orders
description: This model cleans up order data
columns:
- name: order_id
description: Primary key
data_tests:
- unique
- not_null
- name: status
data_tests:
- accepted_values:
values: ['placed', 'shipped', 'completed', 'return_pending', 'returned']
- name: customer_id
data_tests:
- not_null
- relationships:
to: ref('stg_customers')
field: customer_id
上述のschema.ymlについて、データテストの定義のポイントはdate_testsのところで、以下4つのテストから必要なテストを各カラムに対して定義しています。
- unique
- 対象のカラムの値が、全レコードで比較して一意であるかを見るテスト
- not_null
- 対象のカラムの値が、全レコードで比較してでnullでないかを見るテスト
- accepted_values
- 対象のカラムの値が、リストで指定した値のいずれかであることを見るテスト
- relationships
- 技術的に言うと参照整合性の確認を行うテスト
- 上述のコードで言うと、「
stg_ordersのcustomer_id列は、stg_customersのcustomer_id列の値から構成されている」ことを確認しています
schema.ymlの作成後、データテストを実際に行いたいので、dbt testを実行します。
実行完了後にWorkspaceの右下からログを確認してみます。各テストが実行されてPASSとなっている場合はそのテストをクリアしたことを意味します。
13.Document your models
この章は、dbtのドキュメント生成機能を試す内容となっています。しかし2025年8月13日時点、dbt Projects on Snowflakeでは標準機能でdbt docs generateを実行できないため、スキップします。
14.Commit your changes
この章では、dbt CloudのManaged Repositoryの利用を前提として、Gitのコミット～プッシュを行っています。しかし、今回はGit連携を対象外としているため、本章の内容はスキップします。
参考までに改めての記載となりますが、dbt Projects on SnowflakeにおけるGit連携については、以下のブログをご覧ください。
15.Deploy dbt
この章では、開発した内容を本番環境に反映することを行っていきます。dbt Projects on Snowflakeでは、dbt Cloudと全く異なる操作が必要となりますので、ご注意ください。
profiles.ymlに対して本番環境の情報を追記
まず、本番環境として出力したいスキーマの情報をprofiles.ymlに追記します。
profiles.ymlを開き、以下のように変更します。prodという新しいtargetを追加し、schema: PRODとしていることがポイントとなります。
dbt_quickstart:
target: dev
outputs:
dev:
type: snowflake
role: ACCOUNTADMIN
warehouse: TRANSFORMING
database: ANALYTICS
schema: DBT_SSAGARA
account: ''
user: ''
prod:
type: snowflake
role: ACCOUNTADMIN
warehouse: TRANSFORMING
database: ANALYTICS
schema: PROD
account: ''
user: ''
指定したスキーマにdbt Projectをデプロイ
dbt Projects on Snowflakeはタスクとして定期実行できるのですが、このためには指定したスキーマにdbt Projectをデプロイする必要があります。
Workspaceの画面右上のConnectを押して、Deploy dbt projectを押します。
以下の内容を入力して、Deployを押します。
Select location- データベース：ANALYTICS
- スキーマ：PROD ※今回はデータの出力先と同じスキーマにしていますが、違うスキーマでも問題ありません。
- Select or create dbt project
+ Create dbt projectを押します。Enter Name：dbt_quickstart
デプロイに成功したら、下図のように表示されます。prodスキーマを見ると、dbt Projectがデプロイされていることがわかります。
この後、ワークシートに移動し、以下のクエリを実行してdbt Projectを用いたタスクを定義します。ポイントはargs='build --target prodで、buildによりdbt runとdbt testをModelごとに交互に実行できるdbt buildコマンドが実行され、--target prodにより先程作成した本番環境のtargetであるprodに対してdbtコマンドを実行することになります。
use role accountadmin;
create or alter task analytics.prod.dbt_execute
warehouse = transforming
schedule = 'using cron 0 9 1 1 * Asia/Tokyo' -- 毎年1月1日の午前9時に実行
as
execute dbt project analytics.prod.dbt_quickstart args='build --target prod';
この後、以下のコマンドを実行して手動でタスクを実行してみます。
execute task analytics.prod.dbt_execute;
参考までに、dbt project自体の実行状況は、画面左のMonitoringから、dbt projectsを押すことで確認可能です。
タスクの成功を確認した後にprodスキーマの中を見ると、無事にテーブルが作成されていました！
最後に
「Quickstart for dbt and Snowflake」のチュートリアルをdbt Projects on Snowflakeでやってみました。
dbt自体を学びながらdbt Projects on Snowflakeを試していくにはちょうどよい内容だと思います！ぜひお試しください。
