ディメンショナルモデリングとは？：dbt×BigQueryを使ったデータモデリング入門
この記事では、BigQueryとdbt(Data Build Tool)Cloudを使用してデータモデリングにおけるディメンショナルモデリングの基本について解説しています。
目次
はじめに
データモデリングはデータウェアハウス設計の根幹をなすプロセスであり、データサイエンティストが分析をスムーズに進めていくための重要なテクニックです。今回の記事では、BigQueryとdbt(Data Build Tool)Cloudを使用してデータモデリングにおけるディメンショナルモデリングの基本について解説します。
ディメンショナルモデリングとは？
ディメンショナルモデリングは、データを「事実（Fact）」と「次元（Dimension）」に分けて組織化する手法です。このモデルは、特にデータウェアハウスの設計に適しています。
- 事実テーブル: 事実テーブルは、ビジネスプロセスの量的側面を捉え、売上、数量、利益などの計測可能なデータを含みます。
- 次元テーブル: 次元テーブルは、事実テーブルの計測値を「誰が」「何を」「いつ」「どこで」などの文脈で説明します。これには顧客名、日付、製品情報などの記述的なデータが含まれます。
ディメンショナルモデリングの利点について
ディメンショナルモデリングには以下のような利点があります。
- 分析の容易さ: 分析者が理解しやすい形式でデータが整理されるため、データの探索やレポート作成が容易になります。
- クエリパフォーマンス: 適切に設計されたディメンショナルモデルは、データベースのクエリパフォーマンスを向上させることができます。
- 柔軟性: 新しいデータ源の統合や変更がしやすく、ビジネスの変化に対応する柔軟性を持っています。
BigQuery上でテーブルを作成
まずはBigQuery上にデータを格納するための適当なテーブルを用意、または作成します。今回は以下のような架空のEコマーストランザクションデータのテーブルを作成してみました。
事実テーブルモデルの作成
ここからはdbt Cloud上で作業を行います。
dbt Cloudの詳細はdbt Cloudxbigqueryの実践をご参照ください。
まずmodels配下にfact_transactions.sqlファイルを作成します。
事実テーブルはビジネスイベントを数値で捉えるための中心的なテーブルです。これには通常、数量や価格などのメトリックスと、それらが発生した時間や関連する次元のキーが含まれます。以下のfact_transactionsモデルでは、トランザクションごとの詳細な情報を記載しています。
ファクトテーブルモデル（fact_transactions.sql）
{{ config(materialized='table') }}
WITH source_data AS (
SELECT
TransactionID,
TransactionDate,
CustomerName,
ProductName,
Quantity,
UnitPrice,
TotalPrice,
PaymentMethod
FROM {{ source('data_test', 'ecommerce_transactions') }}
)
SELECT
TransactionID,
TransactionDate,
CustomerName,
ProductName,
Quantity,
UnitPrice,
TotalPrice,
PaymentMethod
FROM source_data次元テーブルモデルの作成
次元テーブルは、ビジネスプロセスの文脈を提供するための補助的なテーブルです。ここでは、顧客、製品、支払い方法などの属性に焦点を当てます。次元テーブルは通常、非常に記述的であり、分析者が簡単に理解できるような情報を含んでいます。
顧客ディメンションモデル (dim_customers.sql)
{{ config(materialized='table') }}
WITH source_data AS (
SELECT DISTINCT
CustomerName
FROM {{ source('data_test', 'ecommerce_transactions') }}
)
SELECT
ROW_NUMBER() OVER (ORDER BY CustomerName) AS CustomerID,
CustomerName
FROM source_data商品ディメンションモデル (dim_products.sql)
{{ config(materialized='table') }}
WITH source_data AS (
SELECT DISTINCT
ProductName,
UnitPrice
FROM {{ source('data_test', 'ecommerce_transactions') }}
)
SELECT
ROW_NUMBER() OVER (ORDER BY ProductName) AS ProductID,
ProductName,
UnitPrice
FROM source_data支払方法ディメンションモデル(dim_payment_methods.sql)
{{ config(materialized='table') }}
WITH source_data AS (
SELECT DISTINCT
PaymentMethod
FROM {{ source('data_test', 'ecommerce_transactions') }}
)
SELECT
ROW_NUMBER() OVER (ORDER BY PaymentMethod) AS PaymentMethodID,
PaymentMethod
FROM source_dataモデルの依存関係について
モデル間の依存関係を定義することで、dbtはモデルをどの順番でビルドすべきかを自動的に理解します。fact_transactions モデルは dim_customers、dim_products、dim_payment_methods モデルに依存しています。
以下のようなLineageになっていれば問題ありません。
モデルのテストと実行
ディメンショナルモデリングプロセスにおいて、モデルの実行前にデータの品質を保証するためにdbt testコマンドでテストを実行します。テストが無事に完了したら、次はdbt runコマンドを使用して、モデルを実行し、実際にデータベースにテーブルを作成または更新します。
このように表示されていれば成功です。
BigQueryで反映結果確認
dbtの実行が成功した後、BigQueryコンソールを使用して、生成されたテーブルが期待通りに作成されているかを確認します。
正しくテーブルが作られていることが確認できます。
GitHubでのモデル管理
モデルのコードやドキュメントはバージョン管理のためGitHubにプッシュしておくと良いでしょう。
最後に
ディメンショナルモデルはデータウェアハウス設計において非常に重要な要素であり、適切なデータモデリングアプローチを選択することはデータ分析の成功に直結します。ディメンショナルモデリングを理解し、実践することで、データウェアハウスプロジェクトをより効果的に管理し、価値を最大化できるでしょう。
