積ん読記事に残っていた dbt の記事が面白かったのでご紹介です。
Pivot 社という会社のアナリティクスエンジニアによる記事で、いくつものプロジェクトで dbt を導入した経験から、dbt を使う上での5つの指針が紹介されています。私は dbt を実際のプロジェクトで導入したことはないのですが、この記事は細かい技術的な点ではなく、dbt をどういった場面で使うべきかという話なので今後も参考になりそうです。
5 Lessons I Have Learned Using dbt
1. Follow the dbt style guide
dbt にはスタイルガイドが公開されているので、これを利用した方がよいとのこと。
https://github.com/dbt-labs/corp/blob/main/dbt_style_guide.md
staging（ソースからデータを抽出、クレンジング）, marts（モデルを組み合わせたり、複雑な変換処理を行う） というレイヤリングは分かりやすいですね。データがクレンジングされ、共通利用できる状態に持っていくことで価値を高めていく Databricks のメダリオンアーキテクチャにも似ています。
他には SQL や変数、ファイルの命名規則などもスタイルガイドに書かれています。
2. Don’t overdue it with jinja or macros
マクロや Jinja テンプレートを使いすぎないことを述べています。これらは dbt のコアとなる機能ですが、使いすぎて複雑になってデバッグが難しくなったり、新しいエンジニアのキャッチアップに時間を要したり、dbt から他の ETL ツールに移行する際の妨げになるとのこと。
3. Only Self Manage With DevOps Support
dbtCloud などではなく、Astronomer or Google Composer を利用して dbt を動かす、そのために DevOps チームやクラウドエンジニアの力を借りようと述べています。理由はコスト削減と "reducing PHI risk" と書かれています。
dbtCloud のアカウントは Developer(free), Team($100/month per developer seat), Enterprise(custom prise) の3種類あり、基本的な機能は Developer(free) で提供されています。ただし Browse Metrics in external tools, dbt Cloud API Access などの機能は Team アカウント以上で提供されており、以前ご紹介したセマンティックレイヤの機能を提供する Query SQL Proxy は現在はパブリックプレビューとして Developer アカウントで利用可能ですが、GAとなると Team アカウント以上での機能提供となるようです:
"reducing PHI risk" という理由における PHI ですが、私の知る限りだとHIPIAA 法により規定される「保護対象保健情報」protected health information (PHI) のことを指しているかと思われますが、文脈的には PII でもよい気もします。わざわざ SaaS で ETL 処理を動かしてセキュリティリスクを高める必要はないという指摘だと読み取りました。
https://www.getdbt.com/security/#data-storageについて記載を見つけましたが、（当たり前ですが）生データは保有せず、アカウント情報、ジョブ定義、DBへの接続情報、各種ログなどが含まれるとのことです。
4. Don’t Build a Giant Spider Web
dbt プロジェクトを構築する際は計画性をもち、プロジェクトを複雑にしすぎないことを提案しています。
便利だからと中長期的な計画なしに導入すると、利用者が集まって "Giant Spider Web" となってしまう可能性は十分ありそうです。プロジェクト間で依存関係が発生すると扱いが難しそうですが、ある程度のドメインに閉じた運用がよいのでしょうか。
5. Don’t Use dbt for Use Cases Outside of Analytics
ストリーム処理, MLプロジェクト, OLTP に関する ETL 処理も、恐らくマクロを組み合わせると dbt で実現できるのでしょうが、筆者は dbt アナリティクス用途に特化した ETL ツールであるため、それ以外の用途には使わないことを述べています。
