こんにちは。株式会社IVRy（アイブリー）のデータアナリストの wada です。
IVRy ではデータモデルの管理のために dbt Core を導入し始めているのですが、今回はプロダクトへのデータ転送パイプラインに dbt を導入した事例を紹介します。
プロダクトについて
IVRy は電話業務を効率化する対話型音声 AI SaaS です。
プロダクトには、自動対応した着電件数や IVRy を使うことによって削減した時間などの統計情報を確認できる機能があります。
ちょうど今月、閲覧できる統計情報を大幅にアップデートしたダッシュボード機能がリリースされました。この機能では、IVR（音声自動応答）の各分岐の流入数や長期の統計情報など、より詳細な情報を確認することができます。
機能イメージ
やったこと - dbt 導入
dbt 導入前 - 課題
IVRy では解析用の各種データを BigQuery に集約しており、統計情報の元となる発着電イベントログも BigQuery に取り込んでいます。BigQuery 上の発着電イベントログから統計データを計算し、その結果を定期的にプロダクトに転送するデータパイプラインを TROCCO を使って実現しています。
データの流れのイメージ（Before）
ダッシュボード機能実現のために統計データ計算用クエリを大幅にアップデートする必要がありましたが、それにあたり、
- stg 環境で検証したクエリを正しく prd 環境にデプロイしたい
- クエリの計算ロジックの正しさをテストしたい
の 2 点が改善したいこととして挙がりました。
既存のクエリは TROCCO の GUI から手動で直接登録する形をとっていましたが、よりヒューマンエラーの起こりにくい管理形態に移行することが一つの課題でした。
dbt 導入後 - 改善されたこと
上記課題を解消するため、データモデリングの部分を dbt に寄せて「統計データモデルの作成」と「データの転送」を切り分けることで、集計処理の検証がしやすい環境に変更しました。
データの流れのイメージ（After）
データ転送時のクエリに計算ロジックを持たせないようにしたので、集計クエリの開発自体は dbt に閉じて行えるようになりました。
クエリは GitHub を用いてバージョン管理できるようになり、さらに GitHub Actions での CI/CD によって stg/prd 環境毎のデプロイができるようになったため、稼働しているデータモデルの管理のしやすさも向上しています。
また、TROCCO のワークフローの中で dbt test を実行するようにしたことで、クリティカルなエラーが起きていないかをプロダクトへの転送前に検査できるようになりました。
input 側のデータに発生したエラーによってバッチ処理の結果が突然おかしくなるというのはあるあるだと思いますが、誤ったデータの転送を防ぐ仕組みが入っていると安心感があります。
今後の課題
プロダクトへのデータ転送パイプライン単体としてはシンプルに良くなったなという感想なのですが、全社横断的に dbt Core を導入するという視点で dbt project の管理体制をどうしていくべきかちょっと悩んでいます。
dbt は導入され始めたばかりで社内にツールそのものに詳しい人はまだ多くないため、知見を集約しておく目的で、複数の dbt project を一つの GitHub リポジトリにまとめて管理しています。
(リポジトリ内のイメージ)
./dbt/
├ analysis/ (分析用の dbt project)
│ ├ dbt_project.yml
│ └ ...
├ dashboard/ (今回紹介したデータ転送パイプライン用の dbt project)
│ ├ dbt_project.yml
│ └ ...
└ 他の dbt project ...
悩んでいるのは、上記のように複数の dbt project をモノレポで管理している時に、各 project の開発環境別のデプロイをどのように実現すべきかという点です。
一旦、main ブランチは、全 project について prd 環境にリリース可能な状態のものが入っているとしているのですが、問題は各 project の検証状態のもののデプロイをどう実現するかです。TROCCO は設定したブランチの最新の状態の dbt を実行するので、とりあえずは各 project に対して stg 環境用のコードに対応するブランチをそれぞれ作成して TROCCO から dbt 実行ができるようにしているのですが、この方針だと dbt project と同じ数の stg 環境用ブランチが増えてしまうので、今後管理が複雑になるのではないかと懸念しています。
現状のブランチ運用のイメージを図にすると以下のような状態です。
今は dbt project の数が多くないため、この形式でも運用できそうではあるのですが、今後 IVRy では 複数のプロダクトを立ち上げていく ことが予想されるため、負荷なくスケールする仕組みに移行していきたいところ……
最後に
とまぁ、まだまだ改善するところもあるのですが、IVRy のデータ活用シーンに dbt が導入されたことで着実にデータの利活用が改善されているという実感があります。
IVRy では社会により大きなインパクトを与えるために、データを整備し、データを活用して事業やプロダクトを改善する仲間を募集しています。特に、この記事に興味を持ってくださったあなた！きっとデータアナリストだったりデータ基盤エンジニアだったりするに違いないと思いますので、是非ご検討ください！
カジュアル面談はこちらから！私が迷っている dbt project の管理体制について何かコメントくださるだけでも大歓迎です！
Discussion