dbtとDataformを比較し、dbtを使うことにした
- Authors
- @__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 が生成するリネージ
Dataform の Web 画面は便利
Dataform はなんといっても Web 画面が非常に使いやすく、開発を加速してくれます。
以下のような良い点があります。
- コードの補完
- 開発している SQL のアドホックな実行
- 品質テストに失敗した場合、どの行で失敗したかをデータベースに格納されるため調査がしやすい
- ソースのバージョンコントロール
- 実行スケジュールの設定
- 実行履歴の閲覧やリラン
Dataform の Web 画面
外部ツールとの接続性
- dbt
- Hookにより、前後に任意の処理を挟むことが可能
- airflow に専用の Opeartorがある
- manifest.json などの実行情報を活用することで、様々な活用が可能
- 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 で手動実行する場合は環境を明示的に変更する必要があるのですが、UI が少々わかりづらいです。
Dataform の環境切り替え
些細なことですが、うっかり忘れて別の環境で実行してしまった、ということはあり得そうだなと感じました。また、実行履歴の画面でも環境を選択する必要があります。
実行履歴管理とリラン
dbt
実行履歴をどう管理するかは、実行環境によります。
リランについては、model selection syntax を利用し特定のジョブを実行することができます。これは非常に便利で、tag と selector を駆使すれば様々な条件を管理できます。
一方、airflow の Operator を利用する場合、dbt の構築する DAG が airflow の DAG として表現されず一つのタスクになってしまうため、特定のジョブのみリランするという作業が難しいです。具体的には以下のような DAG になってしまうため、dbt_run
タスクを実行すると、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 の登場により、この分野への注目は強くなっていると感じます。双方ともすでに素晴らしいツールですが、今後も、ツール・コミュニティともにさらなる発展を期待します。