Datastreamの導入背景と活用事例

ツール導入前の課題

当社が開発・運営するレシート買取アプリONEは、分析基盤としてBigQueryを使用しており、2023年9月にDB(AlloyDB)移行プロジェクトがあり、そのタイミングでDatastreamを導入しました。

課題としては以下の通り

• DBの移行となり既存のBigQueryへのデータ転送を使えなくなること
• 自前のGKEにAirflow + Digdagの環境を作成していて管理が大変になってきている
• アプリケーション側のDBのschemaの変更にBigQuery側の対応が追いつけない

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

• なるべくGCPのフルマネージドなサービスを使用して管理や運用を簡潔にしたい
• アプリケーション側のDBのschemaの変更に対応できる

上記のような状態を目指しており、会社のや事業が成長するに比例して、新規プロダクトや新機能に使われる新しいテーブルやカラムを連携できるようにしたいと思っていました。

• BigQueryへのデータ転送が簡素化され運用が楽になった
• ServerSideの開発によるスキーマの変更に対応できるようになりData Engineerの対応が無くなった
• ほぼリアルタイム分析を行えるようになった
• BigQueryにデータが同期されるのでCloudComposer等によるETL処理との親和性が上がった

パーティションの設定ができない

DatastreamをAlloyDBとBigQueryの接続を完了し、データがBigQueryに連携されるようになりました。連携が開始すると連携元のテーブルと同様の名前で各テーブルが作成されます。 しかし、大規模なテーブルになるとテーブルにパーティションの設定を行いクエリのコストを抑えることを行いますが、作成されるテーブルにパーティションの設定を行うことができません。

こちらで各種検証を行い、BigQueryのテーブルが作成されたらそれをパーティションテーブルにするスクリプトを作成して、各テーブルに対してその処理を実行していきました。

データが多いとバックフィルに時間がかかる

Datastreamはデータソース元のDBにあるテーブルにinsert, update, deleteのイベントが発生するとそのイベントをもとにBigQueryに同期される仕組みになっています。しかし、これだと過去のデータが同期されないという問題があり、これを解決するためにバックフィルという過去のデータを連携する機能があります。

当時(2023/09)はレシート買取枚数が9億枚を超えておりそれに関連したテーブルをバックフィル機能を使用して過去分を全て連携しようとしたと1ヶ月ほどかかってしましました。データの転送の順番も設定できない(2018年から転送 or 直近1年を先に送るなど)ので実際のデータの集計等の業務を行うのに1ヶ月ラグが発生してしましました。

詳しくはWED Engineering Blogに記載されています。

• Datastream for BigQueryを本格導入した話
• Datastreamで作成されたテーブルをパーティション化するスクリプトを作った

今回は既存のサービスに対してDatastreamを導入しましたが、新しくサービスを立ち上げたり、データ量が少ないタイミングで使用や移行するのはとてもいいと感じました。 アーキテクチャ的にもシンプルに作れるところや、DBのスキーマの変更に柔軟に対応できるところを私は強くお勧めしたいです。

弊社ではDBとしてAlloyDBを使用しましたが、それ以外のDBも対応しています。パーティションやコネクションの設定などには課題がありますが、同じGCPのサービスなので今後の親和性の向上に期待しています。