Sansan株式会社でのdbt導入事例

ツール導入前の課題

Sansanでは営業DXサービスであるSansanやインボイス管理サービスBill One、契約DXサービスContract OneなどのBtoBサービスと、個人向け名刺アプリEightをはじめとし、各事業を展開しています。これらのプロダクトのデータはAWSやGCPなどのクラウド環境上にそれぞれ蓄積されており、またその他にも社内CRMツールのデータや外部購入した企業マスタデータなどもそれぞれ異なる環境に存在していました。
このデータサイロを解消し、一元的にこれらのデータにアクセスできることにより、正確な意思決定を迅速に行えるデータ基盤の構築を目的として、2022/7頃より全社横断データ基盤の構築プロジェクトが発足しました。

アーキテクチャ概要としては、DWHとしてBigQueryを用い、Cloud Composerでワークフローを制御し、各種Operatorを用いてLoadやBigQueryへのクエリ実行をしています。
2022/8頃には社内の主要なデータが集まり、少数のデータマート(50-100程度。BIでのKPI可視化や社内CRMツールへのデータ連携用途)もCloud Composerからのクエリ実行で作成していましたが、それらはレイク→マートでの変換処理にとどまっていました。
データマート数の増加に伴い、共通ロジック(CTE句)の使いまわしや肥大化するTransformクエリなどが散見され、共通的に標準加工/モデリングされたウェアハウス層のニーズも高まったことから、dbtの導入に踏み切りました。

どのような状態を目指していたか

• 複数のデータマートで利用されるTransformロジックを管理し、再利用性の高いウェアハウス層を提供する。
• 主要なテーブルに対し、データ品質の担保を行う。
• リネージュを可視化し、データソースの変更や異常における影響範囲の特定を可能にする。
• SQLの読み書きさえできれば、安心してデータモデリングに取り組める環境を提供する。

• dbt Cloud
• Dataform

• 手軽に使える(初期投資コストが低い)
• ドキュメントやエコシステムが充実している&コミュニティが活発である
• 特定のDWH製品に依存しない(仮にBigQuery以外でデータ基盤を構築する際にも知見が活かせる)
• 非エンジニアでもカタログが見やすい

改善したかった課題はどれくらい解決されたか

• 当初の課題は概ね解決しました。

どのような成果が得られたか

• 共通的なデータウェアハウス層のテーブルが作成しやすくなり、データマートの提供までのリードタイムが下がり、データ利活用の速度が向上しました。
  • 執筆時点では1100程度のテーブルが作成されている(データウェアハウス&データマート)
• テストを実装することでデータソース〜データマートにおける異常を検知できています。
• Visual Studio Codeの拡張機能やdbt-osmosisなどを活用することで、アナリティクスエンジニアが素早く開発できています。

dbtは、データ基盤構築において、非常に優れたツールだと思います。
Building a Kimball dimensional model with dbt などで手軽に使用感もわかるので、導入を検討される際には一度触って見るのが良いかと思います。

今後、よりデータ活用が進み、モデル数が10倍以上にスケールした場合にも、耐えられるようなdbtプロジェクトやデータ基盤の進化が必要だと考えています。