dbtとDataformを比較し、dbtを使うことにした

Authors
  • avatar
    Twitter
    @__Attsun__
    Published on

最近、業務で DWH / Datamart の整備やデータ品質の担保を効率的に行いたくなる事情があり、調査したところ dbt と Dataform がツールとして有力そうだったので、比較してみました。

TL;DR

  • dbt は機能が充実しており、カスタマイズするポイントも多く様々な要件に対応できそうです。反面、理解し使いこなすための学習コストがかかります。
  • Dataform は Web ビューによる開発体験が非常に良いです。機能もほとんどはわかりやすく、迷うことも少ないです。一方、dbt に比較して融通はききづらいです。
  • どちらも十分な機能は備えている素晴らしいツールだと感じるので、どちらが良いかは要求や組織の置かれた状況次第でしょう。
  • 私の所属する会社 (Ubie, inc) では、既存のスケジューラに組み込めることや、機能の充実度・外部との接続性を評価し、dbt を選択しました。

dbt, Dataform について簡単に紹介

どちらも、ELT (Extract / Load / Transform) における T (Transformation) を担当するツールです。

つまりは、様々なデータソースからデータレイクにロードされたデータを、分析などに使いやすい形に変換する部分を担います。

dbt

公式ドキュメント

fishtown analytics という組織により、2016 年頃から開発されています。dbt とは、 data build tool の略です。

CLI として利用する OSS 版と、dbt Cloud という統合開発環境+実行環境が付属した商用版があります。CLI の場合、スケジューラーや実行環境がないため、cron や Airflow などとともに利用することになるでしょう。

※ この記事では CLI 版の dbt のみ扱います。

Dataform

公式ドキュメント

2020 年 12 月、Google による買収が発表され、界隈では非常に話題になりました。いつからサービスを開始しているのかわかりませんが、私自身は存在すらしりませんでした。

こちらは統合開発環境と実行環境をセットで提供したバージョンのみがあります。CLI や REST API もありますが、できることは限られているため基本的には GUI を利用します。

比較

いくつかの候補軸で比較をしていこうと思います

対応するプラットフォーム

  • dbt
    • Postgres, RedShift, BigQuery, Snowflake, Apache Spark, Databricks, Presto, (その他、サードパーティ製のコネクタあり)
  • Dataform
    • BigQuery, Snowflake, Redshift, Azure SQL DW, Postgres

どちらも必要十分なカバーはできている印象です。dbt は OSS であるため、独自のコネクタを開発することが可能です。

主要な機能

  • dbt, Dataform 共通
    • データモデルの定義
    • データソースの定義
    • スナップショットの作成
    • データ品質テストの定義
    • モデル間依存関係の自動的な解決
    • プラットフォームにデータ定義(カラムディスクリプションなど)を反映
    • github でのバージョンコントロール
  • dbt のみ
    • データソースの鮮度チェック
    • マクロによる拡張コード
    • ドキュメントやリネージの自動生成
    • 分析用 SQL の管理
    • 実行前後の Hook
    • model selection syntax による柔軟な実行管理
  • Dataform のみ
    • 付属のスケジューラと実行環境
    • ウェブ上の統合開発環境と管理画面
    • Javascript による拡張コード

どちらも必要十分な機能は備えていますが、dbt のほうが幅広い機能群を持っています。

特に、dbt で管理しないデータソースに対しても品質チェックできるのが便利です。また、メタデータやリネージなどが記載されたドキュメントを自動生成することも可能です。(メタデータをどこで管理するか、という別の問題がありそうですが)

dbt が生成するドキュメント

dbt-doc

dbt が生成するリネージ

dbt-lineage

Dataform の Web 画面は便利

Dataform はなんといっても Web 画面が非常に使いやすく、開発を加速してくれます。

以下のような良い点があります。

  • コードの補完
  • 開発している SQL のアドホックな実行
  • 品質テストに失敗した場合、どの行で失敗したかをデータベースに格納されるため調査がしやすい
  • ソースのバージョンコントロール
  • 実行スケジュールの設定
  • 実行履歴の閲覧やリラン

Dataform の Web 画面

Dataform web view

外部ツールとの接続性

  • dbt
  • Dataform
    • CLIがあるが、特定の環境でジョブを実行することはできなさそう(開発用?)
    • REST APIがあり、外部から起動することは可能。こちらは CLI とは違い、環境指定が可能です。
    • Dataform の実行後に何か任意のコマンドを実行する、ということは現状できなさそう

外部との接続性は、dbt と Dataform で大きな違いがあると感じた点でした。

dbt は CLI ということもあり非常にモジュラリティが高く、様々なツールとの組み合わせが考えられます。例えば、Airflow 用のオペレータもその賜物ですし、manifest.json などを活用することで実行情報のビュアーを開発したりすることもできます。

また、Fivetran との接続Stitch 用のパッケージ など、ELT における E/L の部分を担うツール群との相性も良さそうです。

一方、Dataform は単体で閉じられているという印象です。Dataform だけ使えば効率よく実装と管理ができますが、他ツールと組み合わせたり、外部のイベントと依存関係を組みたい場合は制約が多いように感じました。

運用時のあれこれ

環境の分離 (Production / Staging / QA など)

dbt

接続情報など環境固有の設定値は、profiles.ymlに環境ごとの接続情報を記載し、

adhoc:
  target: dev
  outputs:
    dev:
      type: bigquery
            ...
      prod:
        type: bigquery
        ...

実行時にオプションで制御可能です。

dbt run -t prod

実行環境の分離については利用する実行環境次第です。例えば Cloud Composer であれば、開発用と本番用にクラスタを建て、環境に応じて実行オプションを変更すれば良いでしょう。

Dataform

environment.jsonに環境を記載します。設定は生 json を書かずに web で簡単に作れます。

Dataform の環境設定画面

dataform-env-config

Dataform で手動実行する場合は環境を明示的に変更する必要があるのですが、UI が少々わかりづらいです。

Dataform の環境切り替え

dataform-env

些細なことですが、うっかり忘れて別の環境で実行してしまった、ということはあり得そうだなと感じました。また、実行履歴の画面でも環境を選択する必要があります。

実行履歴管理とリラン

dbt

実行履歴をどう管理するかは、実行環境によります。

リランについては、model selection syntax を利用し特定のジョブを実行することができます。これは非常に便利で、tag と selector を駆使すれば様々な条件を管理できます。

一方、airflow の Operator を利用する場合、dbt の構築する DAG が airflow の DAG として表現されず一つのタスクになってしまうため、特定のジョブのみリランするという作業が難しいです。具体的には以下のような DAG になってしまうため、dbt_run タスクを実行すると、dbt が構築するすべての DAG が再実行されてしまいます。処理の実行コストが高い場合は注意が必要です。

dbt-dag

ただ、こちらのブログにあるように、manifest.json を使って dbt の DAG を airflow の DAG として表現する実装をすることは可能です。

Dataform

画面に実行履歴が残ります。DAG の表示もあり、パッとみのわかりやすさがあります。

一方、dbt と同じく特定のタスクのみを再実行したいとなった場合、1) エディタの画面まで遷移し、2) 正しい環境を選択し、3) 実行する、というステップになり、やや煩雑です。また、これは新しいジョブの起動であって、リランとして記録されるわけではありません。

両者の Pros/Cons まとめ

ここまでの比較も踏まえて、ざっくりと特徴を比較するとこのようになりそうです。

dbt

  • Pros
    • 機能充実度の高さ
    • 他ツールやスケジューラとの接続性、拡張性の高さ
    • コミュニティの大きさ
  • Cons
    • 学習コストの高さ
    • scheduler や実行環境は自前で準備
    • より便利に使うには、ある程度の追加開発が必要

Dataform

  • Pros
    • Web view による開発効率の高さ
    • 学習コストの低さ
    • (GCP を使っている場合) Google に組み込まれたことによる期待
  • Cons
    • 環境分離のわかりづらさ
    • 他ツールとの接続性の悪さ、拡張性の低さ
    • すでに実行環境やスケジューラを有している場合、一つの環境への統合ができない

私たちの選択

どちらを使うべきなのか?

どちらも、DWH / Datamart を管理するためのツールとして十分な機能を有していると思います。

それを踏まえた上で、どちらを選択すべきか?という問いには以下のように答えられると感じました。

(これは単純化した区分けなので、ツールに求める要求や組織の状況に応じて柔軟に判断すべきです)

dbt が適していそうなケース

  • データエンジニアリングに成熟した開発チームを有しており、ツールの学習や管理を妥当なコストで行うことができる
  • Airflow などのスケジューラーをすでに運用しており、可能な限り管理する環境は増やしたくない
  • BigQuery 以外でデータ基盤を構築している

Dataform が適していそうなケース

  • アナリストなど、エンジニアリングが得意でないメンバーが中心となり管理・利用する
  • スケジューラーを特に運用していない
  • BigQuery を中心にデータ基盤を構築している

選ばれたのは、dbt でした

dbt を選択しました。背景や理由は以下です。

背景

前提として、私自身は以下のような環境に置かれています。

  • toB / toC の自社ウェブサービスを運営する企業 (Ubie, inc)
  • データ活用が根幹となるサービスであり、プリミティブなデータ基盤は BigQuery 上に存在
  • データの活用方法は、ML、カスタマーサクセス、サービスの利用状況やアクション分析、など多岐に渡ります。
  • GCP を全社的に利用
  • 安定したエンジニアリング組織を持つ。データ基盤周辺を担当するデータエンジニアも数名いる。筆者はデータエンジニア。
  • 様々なジョブの管理に Cloud Composer を利用している

データの利用用途やニーズがひしひしと増しており、それに伴ってデータ品質の担保も重要な課題となっていました。

「運用コスト」「機能充実度」 > 「学習コスト」

こういった背景を踏まえると、「運用コスト」「機能充実度」が、 「学習コスト」 よりも大事であると考えました。

  • ジョブ管理は Cloud Composer を利用しており、今回のために新しい実行環境を増やしたくない。
  • 事業におけるデータ利用の重要性が高く、多様なニーズが生じているため、できるだけ柔軟な選択肢をとりたい
    • ツール間のスイッチングコストが高そうなので、あとで機能が足りなくて乗り換えるということは極力やりたくない
  • 初期の学習コストは十分短い期間で支払い切れる自信
    • ドキュメントがよく整備されていること、コミュニティも発展していること、OSS でありコードが公開されていることから、わからないことがあっても十分自力で調べられそうと感じた
    • dbt の運用経験を持つメンバーがおり、初動の速度も高い

まとめ

以上、dbt / Dataform の比較と、私たちの選択を例として紹介しました。

2020 年末の Dataform の登場により、この分野への注目は強くなっていると感じます。双方ともすでに素晴らしいツールですが、今後も、ツール・コミュニティともにさらなる発展を期待します。