はじめに
株式会社オズビジョンにてエンジニア8年目のテラシマユウコ (@terra_yucco) です。
通常開発の他、オフショア開発のブリッジエンジニアや運用保守作業、企画のためのデータ出しなども担当させてもらっています。
（ここまでテンプレ）
前回記事「新米データサイエンスチームのこれまでとこれから」の他、いくつかのエントリでも触れていたように、今までオズビジョンでは分析基盤には BigQuery を利用していました。
BI 用途では Looker、Re:dash、Google Data Studio あたりが乱立していましたが、このたび「基盤も BI も AWS に統合しよう」という話になったため、これから直面する色々を含めて備忘録を書いていこうと思います。
なお、2021-10-14 現在、この話は現在進行形です。
なぜ統合することになったのか
下に色々書いたのですが、「分析者の要望を満たせているのは Looker だが、お値段が高すぎてデータが全員のものにできていない」「他の基盤は基本 AWS なのにここだけ GCP にあるのが将来のリスク」というあたりが主な理由でした。
- BI ツール乱立事件
- Looker（パワフルだけどとにかく高い、なので使えるユーザ制限してた）
- Re:dash（自分でSQL書ける人向け）、
- Google Data Studio（まあ元データがBigQueryだからね…）
- アプリの基盤、分析したいデータのオリジナルはほぼ全て AWS にある
- GA や Firebase 関係は除く
- 「とにかくデータの見える化を！」で社内の色々な人が連携取らずに動いてしまったので、各々が正しいと思い込んでいるデータがあちこちにある状態になり、ガバナンスの効いていないデータから謎数値が提示されることが増えた
どんな風に構成を変えるのか
既存
- AWS Aurora の定期 snapshot から Parquet 生成
- Parquet を BigQuery 転送し、全件洗い替えでデータ反映
- BigQuery 側の Scheduled Query 機能で必要な ETL や集計を実施
- Looker をはじめとしたツールで可視化・分析
これから（希望）
- AWS Aurora の定期 snapshot から Parquet 生成【変更なし】
- AWS Glue Data catalog で database を定義し、上記 Parquet でテーブルを作成
- Athena を利用して ETL や集計を実施
- QuickSight を利用して可視化・分析
まとめ
データの民主化とコストの問題から、今まで GCP に寄っていた分析基盤を AWS に寄せることになりました。
次以降の記事では、移行検討でぶちあたっている壁について書こうと思います。