CROOZ TECH BLOG

~読んだらわかるSHOPLISTの裏側~

CROOZ TECH BLOGとはクルーズ株式会社の開発チームが技術について共有するブログです
開発の中での発見や知識を広めてオモシロカッコイイ〇〇をツクリます。

troccoでGoogle BigQueryへのETL処理を整備している話①

こんにちは。クルーズ株式会社CTOの鈴木です。

先月よりBigQueryへのデータ集約処理を実現する手段として、クラウドのETLサービスのtroccoの導入を検討していて、現在テストを実施しています。

当社データ基盤の現状課題

データの鮮度問題

データソースは複数ありますが、現状最もデータ転送に時間がかかっているものはサービスの基幹DB(MariaDB)です。

現状、深夜に作成されるDBバックアップファイルをもとに、社内集計用DB(個人情報をマスクしたもの)を作成しており、それをデータソースとしてPHPの転送プログラム経由で各テーブルごとにBigQuery上にデータの転送を行なっているため、前日のデータの集約完了が、当日の夕方以降になってしまいリアルタイム性が悪い状態となっています。

もっともビジネス上の要件として本当の意味でのリアルタイム性の要求があるわけではなく前日分が翌日に見れればよいのですが、現状だとその翌日が翌日夕方だったり、バッチが失敗した場合にリカバリ時間が確保できなかったりするので、早められるのであれば早めたいという状態になっています。

現状Data LakeとData Ware Houseだけがあり、DataMartが存在し無い構成

正確にいうと、DataLakeとしてBigQueryが存在していて、Data Ware Houseというよりはデータマートに近いテーブルがBigQuery上に存在していて、それを各種管理画面やMetaBaseなどのレポートツールが参照している現状になっています。

設計上きれいじゃないという部分以外にもコスト面の問題があります。事実1年前比較でBIgQueryの利用料は約5倍に増えてしまっていました。(勿論BigQueryを活用し、データに基づく意思決定ができる環境整備を行なっているため、一定のコストが増える事は正しいことであるという認識ですがそれにしても増えすぎていて削減余地があるのではないかと考えています)

実現を検討している構成

要件の整理

当社環境について改めて要件を整理してみると要件は以下になります

1.データソース

  • Google Anaiytics
  • FireBase
  • 社内DB(MariaDBAWS内のプライベートサブネットに配置)
  • フラットファイル(Amazon S3
  • 外部Web API

2.データ統合先

  • BigQuery

3.求められるデータ更新頻度

実現方式の検討

データの転送方式

  • Google Anaiytics  :Google Analyticsの機能でBigQueryに連携(変わらず)
  • FireBase        :FireBaseの機能でBigQueryに連携(変わらず)
  • 社内DB        :SSをインストールしたEC2を設置しMySQLコネクタ経由
    • ログ:分割テーブルに対してInsertで転送
    • マスタ:シャーディングテーブルに対してInsert転送
  • S3          :S3コネクタ経由
  • 外部Web API               :検討中。何かしらの方法でS3にPUTを検討

現時点では方式の検討を行っっているのとトライアル申し込みを株式会社primeNumberに行いアカウント開設を待っている状態です。

検証結果については別記事にてまた公開したいと思います。