株式会社オープンロジの BigQuery 導入事例

ツール導入前の課題

• 過去データの調査コストが高かった
  • データベースの変更前の値を調査
  • データ量増加に伴いアーカイブされた過去データの調査
• 集計・分析などに膨大な時間がかかるものが増えてきた
  • Redash 経由でデータベースのデータ活用していたが、何時間もかかったり、いつまで経っても返ってこなかったり、他のクエリーの影響で実行できなかったりと困るケースが多くなっていた
• 社内データの分散化により業務運用負荷も高まっていた
  • データベース以外のCRMなどの業務データがそれぞれ独立して存在しているため業務分析に手間がかかっていた

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

• データベースのデータ量は必要最小限にしつつ、必要になった際にはすぐにアクセスできる手段を用意したかった
• 社内のデータを集約する場所を用意したかった
• 柔軟かつ高速なデータ分析を実現したかった
• スケーラビリティーを確保し、性能面で悩まされたくなかった
• データベース変更履歴の追跡と分析ができるようにしたかった

• Amazon Athena
  • 現在はシステムログの分析用として併用中
• Amazon Redshift
• Amazon Redshift Spectrum

• メンテナンス性（いかに楽に運用できるか）
• スケーラビリティ（クエリ速度・データ量）
• コスト面
• 他社実績

• 特に自分たちよりも多くのデータを扱っている企業での運用実績が豊富にあり、利用しているエンジニアの話を聞いても評判が良かった
• コスト面でも固定費がかからず使った分だけの請求だったので評価・導入しやすかった
• 従量課金のコスト設定もかなり低く、実際の運用を想定してもほぼ影響のない範囲だった
• Google Workspace や Data Studio (現 Looker Studio) との親和性の高さ

• Data Studio (現 Looker Studio) を活用した業務分析がビジネスメンバー主導で進められるようになった
• 過去データの調査効率が高まった

• データの信頼性をどこまで担保するかを決め、利用者とコンセンサスとること

今なら Snowflake も検討すべき有力な選択肢かと思いますが、BigQuery は依然強力なサービスであることには変わりないので、データ基盤作ろうとしている方は気軽に試してみることをお勧めします。

変更履歴について ORM のメタフィールド基準での差分更新だと、イレギュラーオペレーションなどで更新されないケースがあることがわかり信頼性が低いデータとなっているため、今後は Datastream のメタフィールド基準に移行していきたいと思っています。