dbt Fundamentalsを受講してみた
はじめに
データアナリティクス事業本部のおざわ＠仙台です。バスケ日本代表で大活躍だった河村選手が11月に仙台にくるそうなので、さっそく試合のチケットを買いました。楽しみです。
今回は、ずっと気になっていたdbtに入門するべく、dbt公式が無料で提供している初心者向けコースの「dbt Fundamentals」を受講してみました。受講に必要なものは、dbt Cloudのアカウント（無料で作れます）とDWH用の環境になります。
コース概要
タイトルのとおり、入門者にとって重要な基礎を学ぶコースになっています。講師の方の話では、dbt入門にはModels, Sources, Tests, Documentation, Deploymentの5つが重要ということで、本コースでもこれらを重点的に学びます。
受講に必要な時間は、動画による学習コンテンツが2時間、演習時間におおよそ3時間となっています。すべてのコンテンツが英語（字幕あり）になりますので、最後まで走りきるには強い気持ちが必要です。私は内容が聞き取れずに何度も見返しましたので、動画視聴には2時間以上かかりました。
コースの流れ
コースは9つの章で構成されています。各章の最初に「Learning Objectives」で重要ポイントを確認してから動画のデモや説明があります。そのあと、dbt Cloudを使って手を動かしながら実際の動きを確認し、演習問題に進むという流れになっています。各章の終わりには、まとめと選択式のクイズが用意されており、理解度を確認することができます。すべてのクイズに正解すると修了証がもらえます。
各章の受講メモ
1. Welcome to dbt Fundamentals
元高校教師という経歴をもつKyleさんがコースについて説明してくれます。卒業要件レポートをまとめるためにCSV、Excelのデータをマニュアルで収集、加工していたものをすべてdbtで自動化し、BIに入れるところまでやったのがdbtとの出会いということです（つよい…）。
2. Who is an analytics engineer?
データ分析チームにおける各メンバーの役割・スキルセット、ETLとELT、Analytics Engineerとは、現状のモダンスタックの中でdbtがどこにフィットするのか、コースで使用するdbtプロジェクトの構成といった内容になっています。
私のように「Analytics Engineerってなに？」という人はこちらのブログもご覧ください。
3. Set up dbt Cloud
dbt Cloudとdbt Core(CLI)の違いや、サポートされるプラットフォームなど記載されています。また本章以降の学習で使用するdbt CloudのアカウントやDWH環境のセットアップを行います。Redshiftの環境は、こちらのCloudFormationテンプレートを使用しました。
デプロイされたらRedshiftのセキュリティグループの設定を変更し、dbt Cloud（IPはドキュメントに記載されています）からの接続を許可することで、dbt CloudとRedshiftを接続できます。
あとは設定画面のとおりに必要な情報を入れていきます。
dbtでは開発者別にスキーマを作り、その中で開発を行います（このコースではそうなっていました）。開発中のモデルの実行結果はすべて開発者自身の専用スキーマにあり、他の環境を汚さないようになっているので、安心して作業ができそうです。
4. Models
dbtでいう「モデル」は、プロジェクトのmodelsフォルダの下にあるSQLのSelectステートメントのことを指します。dbt入門時点では、「モデル」はDWH内のビュー、またはテーブルと1対1の関係にあると思っておくと良いそうです（必ずしもそうならない）。
dbtではビューやテーブルを作成（materialize）するためのDDL/DMLを書く必要はなく、設定ファイルやSQLの中で指示するとdbtがよしなにやってくれます。
本章では、最初にサンプルとしてdim_customers.sqlという全部の処理が詰まった大きめのモデルが示され、それを再利用できるよう小さなモデルに分けてモジュール化します。分けたモデルはref関数で呼び出します。ref関数を使うとモデルの参照が簡単になるだけでなく、dbtがモデル同士の依存関係をいい感じにDAGに反映してくれます。
コースでは、モデルに以下のような命名規則がありました。また、各SQLやYAMLのファイル名の接頭詞にカッコ内の３文字を付けています。
- Sources(src) 生データが保管されているソーステーブル（Fivetran、Stitchなどでロードされる）
- Staging(stg) ソーステーブルと1対1になっていてカラム名の変更等、比較的軽めな変更が加えられている場合がある。ソーステーブルが使いたい形になっている。
- Intermediate(int) Stagingと最終結果の間にある中間のモデル。ソーステーブルは直接参照せず、目的のために必要な変換が行われたStagingモデルを参照する。
- Facts(fct) 実際に起こった（起こっている）イベント等が記録される細く縦長のモデル。注文、イベント、クリックなど時間の経過とともに発生するようデータが入る
- Dimensions(dim) ユーザー、会社、場所などの存在を表すモデル。頻繁には変更されないが変更は発生する。
5. Sources
ここまでの章では、SQLにベタ書きしていたソースへの参照を変更し、source関数を使うようにします。source関数を使うと設定用のYAMLを参照して、テーブル名を抜き出してくれます。また、ref関数を使ったときのように、ソースがDAGに表示されるようになります。
6. Tests
以下の2種類のテストが用意されています。
- Singular - SQLで定義するテストです。１つか２つのモデルに対して特定のロジックをテストするために使用します。以下は、公式ドキュメントにあるSinglarテストのサンプルで、total_amountが常にゼロ以上であるということをテストしています。１件でもtotal_amountがマイナスのレコードがあればテストが失敗します。
select
order_id,
sum(amount) as total_amount
from {{ ref('fct_payments' )}}
group by 1
having not(total_amount >= 0)
- Generic - YAMLで定義するテストです。4つのビルトインテストが用意されており、カラムレベルで一意性（unique）、Not Null（not_null）、指定した値になっているか（accepted_values）、参照整合性（relationship）のテストを実施できます。モデルと同じフォルダにあるYAMLファイルに以下のようなかたちでテスト内容を記述します。
version: 2
models:
- name: stg_customers
description: one unique customer per row
columns:
- name: customer_id
description: The primary key for stg_customers
tests:
- unique
- not_null
7. Documentation
dbtのプロジェクトでは意図的にドキュメントとコードの距離が近くなっています。モデルと同じフォルダにあるYAMLファイル（前章のGenericテストでも使用）にドキュメントを書くかたちになります。YAMLの中からdoc blockを使うことで、別ファイルに書き出したマークダウンも読み込むことができます。以下、コースで使われているサンプルです。
version: 2
models:
- name: stg_customers
description: Staged customer data from our jaffle shop app.
columns:
- name: customer_id
description: The primary key for customers.
tests:
- unique
- not_null
- name: stg_orders
description: Staged order data from our jaffle shop app.
columns:
- name: order_id
description: Primary key for orders.
tests:
- unique
- not_null
- name: status
description: '{{ doc("order_status") }}'
# 略
{% docs order_status %}
One of the following values:
| status | definition |
|----------------|--------------------------------------------------|
| placed | Order placed, not yet shipped |
| shipped | Order has been shipped, not yet been delivered |
| completed | Order has been received by customers |
| return pending | Customer indicated they want to return this item |
| returned | Item has been returned |
{% enddocs %}
Overviewのページもdoc blockで簡単にカスタマイズできます。
私自身、進行中のプロジェクトに途中から参加することになり、どこにドキュメントがあるかわからない状況を経験したことがあったので、dbtのドキュメントの扱い方がすごく良いなと感じました。
8. Deployment
ここまでの章では、開発者用のスキーマですべての作業を行っていましたが、deployすると本番環境のスキーマにモデルを作ります。本番環境へのデプロイはスケジュール実行する以外にもWebhookを使用したり、APIを通して実施することができます。
9. Survey and Next Steps
コースに関して感想を送ってみます。英語作文タイム。
おわりに
以上、dbtの公式サイトにある入門コース「dbt Fundamentals」のご紹介でした。一度もdbtに触ったことがない状態でしたが、基本的な使い方を知ることができたと思います。dbtを標準ツールとして導入できたら、開発効率が爆上がりするのでは？と期待に胸が膨らむ良ツールでした。まだまだ知らないことだらけなので、これからも色々と触ってみたいと思います。
![[新機能]dbtのsnapshotsがyamlファイル上で定義できるようになり、snapshots出力先のスキーマ・データベースを環境別に分けることもできるようになりました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-f846b6052d1f7b983172226c6b1ed44b/6b4729aabfb5b7a3359acc27dc6b5453/dbt-1200x630-1.jpg)
