BigQuery で実現する、サービスの成長をリードするデータ基盤

ツール導入前の課題

事業規模の拡大に伴い、調達・販売が最適化された取引を目指していたが、下記のような課題を抱えていた。

• 属人化
  • IT リテラシーの高い経営陣や事業責任者が Google Sheets や BI ツールを使いこなしており、データの集計・分析作業が属人化していた
• データ連携の手間
  • 自動でのデータ収集・加工・集計する仕組みがなかったため、データ利用までに手間がかかっていた

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

データ収集・加工・集計の自動化により、

• 調達・販売価格の最適化
• ユーザ行動の分析

を行い、データを活用した効率的な事業運営を行える状態を目指していた

• Snowflake

• 運用負荷の低さ
  • チームが少数であったため、運用コストの低いサーバレスプロダクトである必要があった
• 大規模なデータへの処理耐性
  • 将来的なデータ量の増加に対し、スケーラブルな対応が必要だった
• ビジネスインパクトを早期創出できること
  • ユーザの望むユースケースを素早く実現し、ビジネス価値への貢献までの速度を求めていた

• データソースとのシームレスな連携
  • データソースとなる Service 及び、その DB が Google Cloud 上にあるため、Federated Query の利用によりシームレスな連携が実現可能だった点
• フルマネージドかつサーバレスである点
  • この特性により、インフラ運用から解放され、少ない人数でも高い運用効率が実現できると判断した
• スケーラビリティ
  • BigQuery ではデータ量の増加に対する懸念がほとんどない
• SQL で対応可能なデータ加工ニーズがほとんどだった点
  • 取り扱うデータが SQL で十分加工可能なものがほとんどだったため、BigQuery 上で処理が可能で、シンプルにデータ変換プロセスを構築できる

• データ収集・加工・集計の効率化
  • BigQuery にデータを集約し、dbt を用いてデータ加工プロセスを構築したことにより、データの蓄積・加工・集計作業が自動化され、データ活用までのリードタイム削減に繋がった
• データ活用プロセス・ロジックの集約による属人性の解消
  • Google Sheets などに散っていたデータ分析上のロジックが BigQuery 上に集約されることで、属人かされていたロジックの共有が進んだ
• データ種類の増加
  • DWH の活用が進んだことにより、蓄積されるデータ種類も増え、横断的な分析が可能になった

• Application との連携における、データソースの DB のスキーマ変更の影響

Application の DB との連携では、DB のスキーマ変更の影響により、データ連携プロセスが停止してしまうリスクがある。 この影響を最小限とするため、Data Contract の考え方を参考にし、DWH と Application の間で連携用のインターフェースを定めた。 また、Data as a Product の考え方を参考に、プロダクトの文脈と中央 DWH の間で責任範囲を分けることで、Application DB の変更を素早く取り入れられるようにした。

• Universal Catalog 利用によるデータ利活用の推進
• BigQuery Pipeline や Data Canvas、各種 Agent の活用
• データ基盤の Agent 化