目次
株式会社IVRy: プロダクトへのデータ転送パイプラインでの dbt Core 導入事例
参考になった
7
会員限定コンテンツです。無料登録すると制限なしでお読みいただけます。
レビュー投稿日の情報になります
株式会社IVRy / wxy-zzz
メンバー / データアナリスト
最終更新日投稿日
| ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
|---|---|---|
| 10名以下 | 2024年10月 | B to B |
| ツールの利用規模 | 10名以下 |
|---|---|
| ツールの利用開始時期 | 2024年10月 |
| 事業形態 | B to B |
アーキテクチャ
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
- バッチで実行されるプロダクトへのデータ転送のためのデータパイプラインを TROCCO にクエリを直接登録する形で実現していたが、クエリを更新する際にエラーのないクエリを正しく登録するプロセスが整備されていなかった
より詳細な背景はこちらをご確認ください。
どのような状態を目指していたか
- GUI 操作によるヒューマンエラーを低減し、お客様に影響のあるデータ転送処理の品質を担保できる状態
- stg/prd の環境別のクエリが正しく設定されているか
- クエリの結果が意図したものであるか
選定理由
- dbt はエコシステムが充実しており、TROCCO の機能に依存した構成にするよりも、データ加工部分を dbt に寄せておくことで今後アーキテクチャ変更があっても柔軟に対応可能だと判断した
導入の成果
改善したかった課題はどれくらい解決されたか
- 【解決】stg/prd の環境別のモデルを一元的に GitHub で管理し、それぞれの環境にデプロイできるようになった
- 【半分くらい解決】データ転送前にデータテストが行われ、問題がある場合に処理を停止できるようになった（テスト項目の整理がまだ完璧ではない）
導入に向けた社内への説明
上長・チームへの説明
メリット・デメリットをそれぞれ説明
- メリット
- 社内に既に導入事例（分析用データパイプラインでの dbt 利用）があり、導入に対するハードルが低い
- プロダクトへのデータ転送前に、データの加工結果をテストできる仕組みになる
- stg/prd などの環境別のモデルを一元的に管理できるようになる
- デメリット
- dbt というツールに加えて、モデル管理を GitHub で行うことになるので、一部メンバーにはラーニングコストが発生
活用方法
よく使う機能
- データ処理の実行 (dbt run)
- 実行自体は TROCCO からキックできるため、既存のアーキテクチャほぼそのままで dbt の実行だけを追加している
- データテスト (dbt test)
- プロダクトにデータを転送する前に最低限の品質をチェックできるため、意図しないデータが転送されてお客様影響が出てしまうことを防げる
ツールの良い点
- SQL だけでデータパイプラインが構築できるので、PdM でも加工処理を調整したりできる
- CI や dbt test で、クエリや加工結果のデータのエラーチェックができる
ツールの課題点
- dbt そのものよりも、クエリを管理する GitHub など周辺のツールに対して、慣れていない人への負荷（ラーニングコスト）が少しあるように思う
株式会社IVRy / wxy-zzz
メンバー / データアナリスト
よく見られているレビュー
株式会社IVRy / wxy-zzz
メンバー / データアナリスト
