dbt導入してデータ分析基盤のカオスを解消した話

• ビットキーでアナリティクスエンジニアをしている三河内です
• 2022年時点では以下のような業務を担当しています（アナリティクスエンジニアについての詳細はこちら）
  
• 今回は注力領域であるDWH構築において、2022年10月から取り組んできたdbtの導入について、その 導入背景や実際に使ってみた中でのメリットを紹介します！

想定読者

• データ分析基盤の構築 や データのパイプライン整備をしたいな と考えている方
• データ分析基盤のデータを用いて分析しているデータアナリスト/サイエンティストの方
• dbt(data build tool)の導入を検討している方
  • ちなみにdbtって何？については「Data Engineering Study 第13回」でとてもわかりやすく紹介されているので、ご参照ください！

TL;DR

• dbt導入以前のデータ分析基盤には、データ生成と開発体験の面で課題があった
• dbtでデータパイプラインを構築したところ、テーブル間の依存関係やテーブルや列の定義が可視化され、データの見通しがよくなった
  • それにより、データモデルのリアーキテクチャなど継続的な視点での開発もやりやすくなった
• データパイプライン開発においても、テストやCI/CDなどのソフトウェア開発のベストプラクティスを取り入れやすく、それにより開発体験が大幅に改善した
• 今後もdbtを用いて、データ分析基盤の開発やデータの信頼性向上に取り組んで行きたいと思っており、仲間を求めています！！！

目次

【前提】dbt導入以前のデータ分析基盤
【dbt導入前】データ分析基盤に溢れるカオス・・・
【dbt導入後】改善ポイント①：データの見通しが良くなる
【dbt導入後】改善ポイント②：GitHub連携周りの機能により、開発体験が向上した
結果：とにかく開発しやすい
今後の展望

【前提】dbt導入以前のデータ分析基盤

• Data LakeとData Martの2層構造で、データモデリングにはまだ取り組んでいない状態でした
  

【dbt導入前】データ分析基盤に溢れるカオス・・・

• データ生成の話
  • テーブル間の依存関係の把握が辛い

    例：XテーブルのY列の算出ロジックを変更したいんだけど、参照しているクエリって何個あるんだっけ？？？

  • データセット設計やデータモデルのリアーキテクチャをしようにも、結局テーブル間の依存関係の把握が辛い

    例：似たような役割を持つテーブルが何個かある、、、消して良いんだっけ？どのデータマートが、そのテーブルを参照しているんだっけ？クエリ全部見て調べないと・・・

  • BigQueryのスケジュールクエリだとパイプラインになってないので、1個クエリがコケてたときに、関連するテーブルの復旧作業が1手で出来ないので辛い

    例：データレイク層のテーブルの取り込みがコケてる、、、関連するテーブル全部再実行しないと、ダッシュボードの値が間違ったままだ・・・

• データそのものの話
  • ある列のTimezone が JSTなのかUTCなのかわからないといったような、データ理解が辛い
  • 意図してない ID重複やnullなど、見えない恐怖が辛い
• 開発体験の話
  • BigQueryのスケジュールクエリの設定が煩雑
  • クエリ管理が徹底できない
  • クエリRVを自然なフローで実施できない

【dbt導入後】改善ポイント①：データの見通しが良くなる

①：リネージュ機能 が良い！

• このようにrefでfrom句をくくると、dbtがテーブルの依存関係を自動で判別し可視化してくれます
  • 可視化されることで、テーブルに変更時、影響範囲を調査すべき対象が簡単に判別できるので、効率的かつ安心感です

-- サンプルデータです
SELECT
  *
FROM
  {{ ref("dim_customers") }} AS dim_customers

• このようなフォルダ構成のとき
  
• 下記のように依存するテーブルを認識し可視化してくれる
  

②：yaml と ドキュメント生成機能（データカタログ） が良い

• このようにyamlにテーブルの概要や列のスキーマ情報を記載していくことができます
  • その他テストを書くこともでき、例えば重複やnullが無い列であることが担保されている、といった情報も把握できます
    • ref. https://docs.getdbt.com/docs/build/tests

version: 2

models:
  - name: first_order_amounts_by_customer
    description: 顧客毎の初回購入日の購入金額
    columns:
      - name: customer_id
        description: customer_id
      - name: order_date_jst
        description: 注文日
      - name: amount
        description: 顧客ごとの最初の注文日における購入金額（単位：ドル）

• この状態でドキュメント生成すると以下のようなデータカタログが自動で生成されます
  
• dbtの閲覧アカウントを付与しておけば、データ分析基盤の開発者以外にもデータカタログを共有できます

【dbt導入後】改善ポイント②：GitHub連携周りの機能により、開発体験が向上した

• ①：Pull Requestしたタイミングで、その時点のコードをベースに、自動でデータパイプラインを実行できる
  • この過程でyamlに定義したテストが走るので、ここでテストがコケた場合デプロイしない、といったことが実現できる
    
• ②：全てがコードベースになるので、BigQueryのスケジュールクエリの設定も不要になる
• ③：全てがコードベースになるので、クエリ管理も自然にできる
• ④：開発フローがGitHubベースになるので、クエリRVも自然なプロセスでできる
• ⑤：開発フローがGitHubベースになるので、GitHub ActionsなどのCI/CDツールに様々な役割を持たせることが出来る
  • SQLのLintチェック や coverageの計測などもCIでできる

結果：とにかく開発がしやすい

• ①：データパイプライン全体の見通しが良くなるので、データモデリングをする気力が湧く
• ②：データパイプラインになるので、1個のコマンドでデータ生成が完了する
• ③：開発に付随するドキュメンテーションやデータ品質のテストの実装などかゆいところに手が届く

今後の展望

• 社内のデータ分析のアジリティを更に上げていきたいと思っており、2023年はdbt開発を軸に以下に取り組んでいく予定です
  • 全事業ドメインのデータをdbtに移行し、データ提供のアジリティを加速させる
  • データ分析基盤をビジネス側にも提供していく。誰でも「select * from hoge where〜」でデータを抽出し、分析が開始できるように
• 関連してデータパイプラインの品質のモニタリングと向上をしていきたいと思ってます（DRE的な活動）

ビットキーのデータ活用に興味がある方は是非devトークしましょう！

• https://jobs.qiita.com/employers/240/dev_talks/441

---

12/13は弊社UI/UXデザイナーの @hikari_yyy さんの投稿です。お楽しみに！