データエンジニアリング初心者でも分かる！dbtの魅力と基本

2024/11/04

データ駆動型ビジネスが当たり前となった今日、多くの企業がデータ分析の課題に直面しています。複雑な SQL クエリの管理、データの整合性確保、分析プロセスの再現性など、様々な問題が山積みです。そんな中で注目を集めているのが「dbt（data build tool）」です。

本記事では、データエンジニアリングの深い知識がなくても理解できるよう、dbt の基本と魅力について解説します。

dbt とは？

dbt は、SQL を中心としたデータ変換ワークフローを管理するためのオープンソースツールです。従来の SQL スクリプト管理とは一線を画し、以下のような特徴を持っています：

モジュール化された SQL コード
バージョン管理との統合
自動テスト機能
ドキュメンテーション自動生成

これらの機能により、データ分析のプロセス全体を効率化し、品質を向上させることができます。

dbt が解決する主な問題

1. SQL コードの再利用性と保守性

dbt では、SQL クエリを再利用可能なモジュールとして管理できます。例えば：

models/staging/stg_orders.sql:

SELECT
    order_id,
    customer_id,
    order_date,
    status
FROM raw.orders

models/intermediate/int_customer_orders.sql:

SELECT
    customer_id,
    COUNT(order_id) as total_orders,
    MIN(order_date) as first_order_date
FROM {{ ref('stg_orders') }}
GROUP BY customer_id

{{ ref('stg_orders') }}で他のモデルを参照でき、依存関係が明確になります。

2. データの信頼性向上

dbt には組み込みのテスト機能があります。YAML ファイルでテストを定義できます：

models/staging/stg_orders.yml:

models:
  - name: stg_orders
    columns:
      - name: order_id
        tests:
          - unique
          - not_null
      - name: status
        tests:
          - accepted_values:
              values: ["pending", "shipped", "delivered", "returned"]

これにより、データの整合性を自動的に検証できます。

3. チーム協働の促進

dbt プロジェクトは Git などのバージョン管理システムと統合できるため、チームでの協働が容易になります。また、自動生成されるドキュメントにより、チーム全体でのナレッジ共有が促進されます。

dbt の主要機能

モデリング：SQL の力を最大限に活用

dbt のモデルは基本的に SQL ファイルですが、Jinja templating を使用することで、動的な SQL の生成が可能になります：

models/intermediate/int_order_payments.sql:

{% set payment_methods = ['credit_card', 'coupon', 'bank_transfer'] %}

SELECT
    order_id,
    {% for payment_method in payment_methods %}
    SUM(CASE WHEN payment_method = '{{ payment_method }}' THEN amount ELSE 0 END) as {{ payment_method }}_amount,
    {% endfor %}
    SUM(amount) as total_amount
FROM payments
GROUP BY order_id

このように、繰り返しの多い SQL を簡潔に書くことができます。

テスト：データ品質を自動チェック

YAML でのテスト定義に加え、カスタム SQL テストも作成可能です：

models/intermediate/int_order_payments.sql:

SELECT
    order_id,
    total_amount,
    credit_card_amount + coupon_amount + bank_transfer_amount as sum_of_methods,
    total_amount - (credit_card_amount + coupon_amount + bank_transfer_amount) as difference
FROM {{ ref('order_payments') }}
WHERE ABS(total_amount - (credit_card_amount + coupon_amount + bank_transfer_amount)) > 0.01

このテストは、合計金額が各支払い方法の合計と一致することを確認します。

ドキュメント：自動生成されるデータカタログ

dbt は、プロジェクトの構造やデータの定義を自動的にドキュメント化します。さらに、モデルやカラムにドキュメントを追加することもできます：

models/intermediate/int_customer_orders.yml:

models:
  - name: customer_orders
    description: "One row per customer with their order history"
    columns:
      - name: customer_id
        description: "The unique identifier for a customer"
      - name: total_orders
        description: "The total number of orders placed by this customer"

dbt を使う利点

分析者とエンジニアの協働促進: SQL を共通言語として使用することで、両者のスキルセットを最大限に活用できます。
データの一貫性と信頼性の向上: 自動テストとバージョン管理により、データの品質と一貫性が向上します。
分析プロセスの効率化: モジュール化と自動化により、新しい分析の作成や既存の分析の更新が迅速に行えるようになります。

簡単なユースケース例

ある小売企業が、顧客のライフタイムバリュー（LTV）を計算したいとします。dbt を使用すると：

注文データ、顧客データ、商品データを個別のステージングモデルとして定義
これらのモデルを組み合わせて、顧客ごとの総購入額を計算するマートモデルを作成
LTV 計算のロジックを別のモデルとして定義
各ステップでテストを実行し、データの整合性を確認
最終的な LTV モデルを定期的に更新し、ビジネスユーザーに提供

このプロセスが自動化されることで、データチームは計算ロジックの改善や新しい指標の開発に注力できるようになります。

各ステップでコード例も含めて解説します。

ステージングモデルの定義

まず、注文データ、顧客データ、商品データのステージングモデルを定義します。

models/staging/stg_orders.sql:

{{ config(materialized='view') }}

select
    order_id,
    customer_id,
    order_date,
    status
from {{ source('raw', 'orders') }}

models/staging/stg_customers.sql:

{{ config(materialized='view') }}

select
    customer_id,
    first_name,
    last_name,
    email
from {{ source('raw', 'customers') }}

models/staging/stg_products.sql:

{{ config(materialized='view') }}

select
    product_id,
    product_name,
    price
from {{ source('raw', 'products') }}

マートモデルの作成

次に、これらのステージングモデルを組み合わせて、顧客ごとの総購入額を計算するマートモデルを作成します。

models/marts/fct_customer_orders.sql:

{{ config(materialized='table') }}

with order_items as (
    select
        order_id,
        product_id,
        quantity
    from {{ ref('stg_order_items') }}
),

order_prices as (
    select
        oi.order_id,
        sum(p.price * oi.quantity) as order_total
    from order_items oi
    join {{ ref('stg_products') }} p on oi.product_id = p.product_id
    group by 1
)

select
    o.customer_id,
    count(distinct o.order_id) as number_of_orders,
    sum(op.order_total) as total_order_value
from {{ ref('stg_orders') }} o
join order_prices op on o.order_id = op.order_id
group by 1

LTV 計算ロジックの定義

LTV 計算のロジックを別のモデルとして定義します。

models/marts/customer_ltv.sql:

{{ config(materialized='table') }}

with customer_orders as (
    select * from {{ ref('fct_customer_orders') }}
),

ltv_calc as (
    select
        customer_id,
        total_order_value as ltv,
        total_order_value / nullif(number_of_orders, 0) as average_order_value
    from customer_orders
)

select
    c.customer_id,
    c.first_name,
    c.last_name,
    c.email,
    coalesce(l.ltv, 0) as customer_ltv,
    coalesce(l.average_order_value, 0) as average_order_value
from {{ ref('stg_customers') }} c
left join ltv_calc l on c.customer_id = l.customer_id

テストの実行

各ステップでデータの整合性を確認するためのテストを追加します。

models/staging/schema.yml:

version: 2

models:
  - name: stg_orders
    columns:
      - name: order_id
        tests:
          - unique
          - not_null
      - name: customer_id
        tests:
          - not_null
          - relationships:
              to: ref('stg_customers')
              field: customer_id

  - name: stg_customers
    columns:
      - name: customer_id
        tests:
          - unique
          - not_null

  - name: stg_products
    columns:
      - name: product_id
        tests:
          - unique
          - not_null

models/marts/schema.yml:

version: 2

models:
  - name: fct_customer_orders
    columns:
      - name: customer_id
        tests:
          - unique
          - not_null
      - name: total_order_value
        tests:
          - not_null

  - name: customer_ltv
    columns:
      - name: customer_id
        tests:
          - unique
          - not_null
      - name: customer_ltv
        tests:
          - not_null

定期的な更新と提供

最後に、dbt Cloud のジョブ機能を使用して、この LTV モデルを定期的に更新し、ビジネスユーザーに最新のデータを提供します。dbt Cloud でジョブを設定し、例えば毎日午前 5 時にモデルを更新するようにスケジュールします。

このプロセスにより、データチームは LTV 計算の自動化を実現し、計算ロジックの改善や新しい指標の開発に注力できるようになります。また、dbt の利点である版管理、テスト、ドキュメンテーションなどの機能を活用して、より信頼性の高いデータパイプラインを構築できます。

自社での dbt 活用事例

当社でも、dbt を社内のデータ基盤に導入し、成果を上げています。導入前は各担当がバラバラに SQL スクリプトを管理し、データの不整合や分析の遅延が問題となっていました。dbt の導入後、以下のような改善が見られました：

データモデルの標準化により、部署間のデータ解釈の違いが解消
テスト自動化による数値の信頼性向上
ドキュメント自動生成によるナレッジ共有の促進

まとめ：dbt がもたらすデータ文化の変革

dbt は、SQL を知っているデータ専門家にとって非常に強力なツールです。データの信頼性向上、チームの協働促進、分析プロセスの効率化を通じて、組織全体のデータ活用レベルを引き上げます。

SQL の知識を持つ方々にとって、dbt の学習曲線は比較的緩やかであり、すぐに生産性の向上を実感できるでしょう。データを真の資産として活用したい組織にとって、dbt は強力な味方となります。

あなたの組織でも、dbt の導入を検討してみてはいかがでしょうか？データエンジニアリングの世界に新しい風を吹き込む dbt の魅力を、ぜひ体験してください。

参考：dbt と他のデータ変換ツールの比較

特徴	dbt	Apache Airflow	Talend	Informatica
主な用途	データ変換	ワークフロー管理	ETL	ETL/データ統合
言語	SQL, Jinja	Python	独自 GUI, Java	独自 GUI
学習曲線	中	高	中	高
オープンソース	○	○	×	×
バージョン管理	優れている	可能	限定的	限定的
テスト機能	組み込み	プラグイン	限定的	あり
コスト	無料/有料版あり	無料	有料	有料

dbt は特に SQL 中心のデータ変換に特化しており、バージョン管理やテスト機能が充実している点が特徴です。

注意点としては下記の通りです。

データの抽出・ロードは別のツールで行う必要がある(Fivetran, Airbyte、Azure Data Factory など)
ジョブスケジューラは別のツールで行う(Airflow, Prefect, cron, GCP Cloud run など)
CUI ツールである

逆に、様々な既存ツールと組み合わせることができる柔軟性も持ち合わせているツールとも言えます。

参考：よくある質問（FAQ）

Q1: dbt を導入するのに、どのくらいの期間がかかりますか？

A1: 組織の規模やデータの複雑さによりますが、一般的に小規模なチームであれば 1-2 週間、大規模な組織でも 1-3 ヶ月程度で基本的な導入が可能です。

Q2: dbt は無料で使えますか？

A2: はい、dbt Core は無料のオープンソースソフトウェアです。ただし、dbt Cloud の一部の機能は有料プランでのみ利用可能です。

Q3: どのデータベースをサポートしていますか？

A3: Snowflake、BigQuery、Redshift、PostgreSQL など、主要なデータウェアハウスやデータベースをサポートしています。最新の対応状況は公式サイトで確認してください。

Q4: dbt を使用するのに、プログラミングのスキルは必要ですか？

A4: 日常的には基本的な SQL の知識があれば十分ですが、より高度な使用には Python や Jinja2 の知識が役立ちます。また、ソフトウェア開発のプラクティス（git, CI/CD など）を理解していると、より効果的に dbt を活用できます。

Q5: 既存の ETL プロセスを dbt に移行するのは難しいですか？

A5: 既存の SQL を段階的に dbt モデルに変換していくことができるため、比較的スムーズに移行できます。ただし、ベストプラクティスに従った再構築が推奨される場合もあります。