はじめに
データ変換は、データパイプラインにおける重要なプロセスであり、dbt(データビルドツール)はこれらの変換を管理するためにますます人気が高まっています。この記事では、dbtプロジェクトを効果的に構成する方法について包括的な理解を提供します。ソース、ステージングモデル、マートモデルについて説明し、それぞれの例を交えて始め方を説明します。
ソースの定義
ソースは、dbtプロジェクトで使用する元データです。データベース内のテーブルとビューを表します。
データソースの識別
dbtでソースを構成する前に、プロジェクトで使用するデータベース内のテーブルとビューを識別する必要があります。
ソースYAMLの設定
dbtプロジェクトで、models
フォルダ内にsources.yml
ファイルを作成します。このファイルには、ソースとその構成が定義されます。
例:ソースの設定
ソースを設定するには、次の構成をsources.yml
ファイルに追加します。
version: 2
sources:
- name: my_source
database: my_database
schema: my_schema
tables: - name: my_table
ステージングモデルの構築
ステージングモデルは、dbtにおける最初の変換レベルです。これらは、生のデータに対して一貫したインターフェースを提供し、クリーンアップや標準化が可能になります。
ステージングモデルの目的
ステージングモデルは、生データとビジネス固有の変換の橋渡しとなります。より複雑な変換に移る前に、基本的なデータクリーニングと標準化を適用することができます。
ステージングモデルの命名と整理
ステージングモデルは、慣習的に、ソース名に続いてstg_
で始まる名前を付けます。models
フォルダ内のstaging
フォルダに整理します。
例:ステージングモデルの作成
my_table
ソースのステージングモデルを作成するには、staging
フォルダにstg_my_table.sql
という名前のファイルを作成し、次の内容を記述します。
SELECT
column1,
column2,
...
FROM {{ source('my_source', 'my_table') }}
マートモデルの設計
マートモデルは、データ変換パイプラインの最終段階です。ビジネスユースケースに合わせた集約された要約データセットを作成します。
マートモデルの理解
マートモデルは、dbtプロジェクトの最終出力を表します。データをアナリスト、データサイエンティスト、その他のステークホルダーが簡単に消費できる形式に変換します。
マートモデルの種類
マートモデルには、次の2つの主要なタイプがあります。ディメンションモデル(命名規則ではdim_
)は、記述的属性を整理してデータウェアハウスのスキーマを作成します。ファクトモデル(命名規則ではfct_
)は、量的データを格納し、興味のある主要なパフォーマンス指標や測定を表します。
例:マートモデルの実装
ディメンションモデルとファクトモデルを作成するには、まずmodels
フォルダにmarts
フォルダがあることを確認してください。
ディメンションモデルの場合は、marts
フォルダ内にdim_customer.sql
という名前のファイルを作成し、次の内容を記述します。
SELECT
customer_id,
first_name,
last_name,
email,
...
FROM {{ ref('stg_customers') }}
この例は、stg_customers
ステージングモデルを使用して、顧客データの次元モデルを作成する方法を示しています。
ファクトモデルの場合は、marts
フォルダ内にfct_sales.sql
という名前のファイルを作成し、次の内容を記述します。
WITH sales_data AS (
SELECT
order_id,
customer_id,
product_id,
SUM(quantity) AS total_quantity,
SUM(price) AS total_price,
...
FROM {{ ref('stg_orders') }}
GROUP BY order_id, customer_id, product_id
)
SELECT
order_id,
customer_id,
product_id,
total_quantity,
total_price,
...
FROM sales_data
この例は、stg_orders
ステージングモデルからセールスデータを集計するファクトモデルを作成する方法を示しています。
Example Models Directory
この記事では、Stripe APIを使用してデータウェアハウスに支払い記録をロードする例に基づくディレクトリ構造が紹介されています。
├── dbt_project.yml
└── models
├── marts
│ ├── core
│ │ ├── core.yml
│ │ ├── dim_customers.sql
│ │ ├── fct_orders.sql
│ ├── finance
│ ├── marketing
│ └── product
└── staging
└── stripe
├── src_stripe.yml
├── stg_stripe.yml
├── stg_stripe__customers.sql
└── stg_stripe__invoices.sql
参考