トップ > dbt > 個人的なdbtの推しポイントを書いてみる

個人的なdbtの推しポイントを書いてみる

dbt

dbtや同じ系統のDataformなど、ELTの特にTransform部分に強みを持つツールを使い始めて大体3年になる。主観だけど、それなりに使い倒している部類だと思う。

これらのツールで巷でよく言われる

  • データリネージの可視化ができる
  • データに対するテストが簡単に書ける
  • エンジニア以外の人ともコラボレーションしやすい

あたりの話は耳にタコができるくらい聞いていると思うので、ニッチではあるもののそれ以外のdbtの個人的に推しなポイントをダラダラと書いてみたいと思う。データエンジニアやデータガバナンスを推進する人には共感してもらえる内容かもしれない。

推しポイント: 捨てやすい

推しポイントにいきなり捨てる話で恐縮だけど、プロダクトやDWHの運営において捨てやすい / 他のツールに乗り変えやすいというのは重要な観点だと思う*1。特にこの分野は進化が早く、5年後どういったツールが生き残っているかを予想するのは至難の技だと思う。分かる人がいたら、その会社に投資しといてください。

もし仮にdbtよりずっといいツールが出てきた場合においても、多少時間がかかったとしても何とかできるかと思う。

  • jinjaで書かれているSQLはdbt compileでSQLにすぐ変換できるから、なんとかできる
    • macroやautomate_dvのようなフレームワークは悩ましくはあるんだけども...
  • yamlで書かれているメタデータはyqのようなコマンドラインツールやスクリプト言語で他ツール用のフォーマットに変換するのは容易
    • 特にテーブルやカラムのdescriptionは組織にとっての資産であるため、これを簡単に移行できるのは大きいと思う

推しポイント: 大体の操作がCLIやAPIから実行可能

仕事柄、自動化することを考えることが多いが、ツールによってはそもそもCLIがなかったり、特定の操作はWebコンソール経由でしかできないといったことも多い。こういったことは地味にペインポイントになりやすく、イライラが溜っていくことも多い。

dbtはCLIがしっかりとしているし、APIも充実しているため、この辺でストレスを抱えることがかなり少ない。

推しポイント: 成果物が使いやすい

ここでいう成果物は以下のようなものを指す。

  • target/manifest.json
  • target/catalog.json
  • target/run_results.json

これらの成果物にはモデル間の依存関係やDWH側の情報(例えばテーブルサイズや生成にかかったスロット量など)、実行の成否といった情報が含まれている。jsonという枯れたフォーマットでこれらの情報にさっとアクセスできるというのは非常に重要で、これによってサードパーティの強力なツールやコミュニティが育っているといっても過言ではない。jq経由でこれらの成果物を触りまくった結果、成果物のデータ構造が大体頭に入ってきつつある。

これらの成果物はdbt-core(CLI)で動かしているときはもちろん、dbt CloudのAPI経由で取得できるというのも非常に大きい。これらは目立ちにくい存在ではあるけど、データエンジニアリングをしたり、データガバナンスを強化していく人間にとっては潤滑油のような存在になるものだと思う。

成果物を利用した例として、不要そうなテーブルの判定やBIツールまで考慮したリネージの可視化などがある。

推しポイント: サードパーティツールが盛ん

「成果物が使いやすい」ことの結果かは分からないが、成果物を利用した強力なサードパーティツールが多く登場している。最近の推しサードパーティツールとしてはdbt-osmosis / elementary / dbterdの3つがある。これらのツールはかなりしゃぶり尽していて、もうこれなしで仕事できる気がしなくなっているし、仮にdbtから離れたとしても、同様のツールを自分で作ると思う。

それぞれの推しポイントを簡単に紹介すると

  • dbt-osmosis:
    • dbtを使ってモデリングする場合、レイヤリングが多段になることが多いと思うが、そうするとカラムのdescriptionを複数箇所にコピペしないといけない
      • 運用が大変でdescriptionがどんどん古びてしまう
    • dbt-osmosisはtarget/catalog.jsonの情報を使ってテーブやカラムの依存関係を推定し、その結果を元にdescriptionの情報を伝播してくれる
      • 最低限の場所にdescriptionを記述すればあとはそれを利用しているカラムにも伝播されるのでメタデータ管理が非常に楽になる
  • elementary:
    • dbtが出力してくれる(ほぼ全ての?)成果物を使いやすいように加工した上でDWH側のテーブルとしてアップロードしてくれる
    • dbtのメタな情報(例: タグやどういったテストが実装されているか)に簡単にアクセスできるようになるため、データ品質の可視化を簡単にできたりデータ基盤の運用に貢献してくれる
  • dbterd:
    • target/manifest.jsonの情報を使って、ER図を生成してくれる
    • dbtのrelationshipsテストを書いていると、それを元にER図を生成してくれるので、とても楽

といった感じ。これらのツール自体も強力であるが、足りないところがあったとしてもdbtの成果物とこれらのツールを組み合わせたスクリプトを書けば何とかなることがほとんどなので、取り回しが非常にしやすい。

推しポイント: コミュニティやエコシステムが盛ん

人によってはここが一番大きいのかもしれない。dbt-tokyoのようなコミュニティがあることで色んな相談ができたり知見をもらえたりする。

また、Modern Data Stackと呼ばれるものが最近流行っているみたいだが、こういったツールやSaaSはdbtと連携しているものが多い。自前で連携のスクリプトを書いたり運用しなくていいというのはデータエンジニア的には楽だし、こういったエコシステム周りはdbtはやっぱり現時点では飛び抜けていると思う。

所感

dbt自体が何でもやるツールになるわけじゃなくて、使いやすい形で成果物を提供することで補完してもらうようなツールをコミュニティが開発したり、Modern Data Stackと連携したりといったそういう立ち位置なのも気にいってるポイントだと思う。何でもできるようにしようとして、どんどん動きが遅くなっていってしまったものとかもあるので。

もちろんこれ以外にも推しポイントはあると思うけど、各位書いてみてください。

*1:Transformのツールで何が生き残るかは分からないけど、SQLはまあ生き残っているだろう...くらいしか想像できない