ファインディ株式会社でのdbt-core活用事例
レビュー投稿日の情報になります
ファインディ株式会社 / ktagashira
メンバー / データエンジニア / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名
最終更新日投稿日
ツールの利用規模 | ツールの利用開始時期 |
---|---|
10名以下 | 2023年4月 |
ツールの利用規模 | 10名以下 |
---|---|
ツールの利用開始時期 | 2023年4月 |
アーキテクチャ
アーキテクチャの意図・工夫
source/staging/dwh/martの4層構造でデータ基盤を構成しています。
- source層: プロダクトのデータベースやGoogle Analyticsなどから取得したRawデータが格納される層
- staging層: 下流で使うためのクレンジングやデータ形式を揃える処理を行う層
- dwh層: staging層に対してディメンショナルモデリングを行い、dimensionやfactを格納する層
- mart層: SpreadsheetやLooker Studioに繋いで可視化を行う層
dbtのジョブはGithub Actionsで実行しています。
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
SpreadsheetやGASから利用されているBigQueryへのクエリが管理できておらず、分析クエリの質を担保できませんでした。 また、スケジュールクエリやSpreadsheet内でデータが変換されており、データリネージが追えない状態になっていました。
どのような状態を目指していたか
- 定常分析のクエリをデータエンジニア・データアナリストが適切にレビューできる
- データリネージを可視化し、変換処理を変更した際の影響範囲を特定できる
比較検討したサービス
- Dataform
- dbt Cloud
比較した軸
- ツールのコミュニティが活発で知見が探しやすいこと
- 導入コストが低いこと
選定理由
- dbtのエコシステムやコミュニティがDataformと比較して充実していること
- dbt利用者に開発経験のある人が比較的多く、ある程度運用コストを許容できること
導入の成果
改善したかった課題はどれくらい解決されたか
dbt-coreの導入で、定常分析のクエリを適切にレビューする体制が整いました。 dbtに処理を集約してdbt docsをGithub Pagesで公開することで、開発者・利用者がリネージを簡単に追うことが出来るようになりました。
どのような成果が得られたか
データ整備によりモデル開発が活発になり、dbtレポジトリへのコミッターは2人→7人になりました。
導入に向けた社内への説明
上長・チームへの説明
ツール選定の権限はチームにあったので、特に求められた要件はありませんでした。
活用方法
よく使う機能
- dbt run/dbt test/dbt snapshotの各種コマンド
- dbt docsによるデータリネージの可視化、データカタログの提供
- dbt-osmosisでカラムのdescriptionを伝搬
- Power User for dbtでローカルでの開発を容易に
ツールの良い点
- 導入コストが低い
- データモデリングに必要なパッケージが一通り揃っている
ツールの課題点
- dbt Cloudに比べると運用コストは高い
- カラムリネージまで確認したい場合はdbt Cloud Enterpriseや別ツールを検討する必要がある
今後の展望
Embulk・TROCCOによるデータ転送とdbtによる変換のタイミングを人手で合わせているので、全体を統括するワークフローエンジンを導入したいと考えています。
ファインディ株式会社 / ktagashira
メンバー / データエンジニア / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名
よく見られているレビュー
ファインディ株式会社 / ktagashira
メンバー / データエンジニア / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法