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

ツール導入前の課題

弊社では BigQuery を中心としたデータ基盤を構築しており、アプリケーションの RDB のデータを BigQuery に取り込み、Looker Studio やスプレッドシートによる可視化や集計に役立てています。社内のデータ分析だけではなく、提携している倉庫の業務などミッションクリティカルな用途でも活用されています。

Datastream を導入する前は Embulk によりアプリケーションの RDB から BigQuery への差分同期を行っていました。Embulk を使った旧来のデータ基盤（以下、旧データ基盤）には以下のような課題があり、特に 1, 2 がデータ基盤の活用を大きく制限していました。

1. データ不整合：RDB と BigQuery のデータに矛盾があり、信頼性に課題がありました。Embulk は RDB の各テーブルにある更新日時カラムが前日のレコードを BigQuery に INSERT する仕組みで差分更新を行っています。様々な事情により更新日時カラムがレコードの更新に連動して変更されないケースがあり、差分更新が正しく稼働しない状況に陥っていました。
2. データ鮮度：弊社では商品の出荷など 1 日に数回ほど重要な業務イベントが発生するので、当日データを見たいという要望がありましたが、Embulk は日次で同期する設定になっており、前日までのデータしか確認できませんでした。Embulk の同期を 1 日数回に増やすと、アプリケーションで利用している RDB に数時間ほど負荷がかかるため、業務影響が懸念されていました。
3. Embulk の運用の手間：Embulk 自体のバージョンアップやテーブルのスキーマ変更への追従などでしばしば運用の手間が発生していました。

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

今後、データ活用を推し進めていく上で、「データ不整合」と「データ鮮度」の課題は確実に解決する必要がありました。また、データ基盤に関わるエンジニアの人数が少ないため、少人数でも運用できるサービスを使うことが求められます。特に、RDB のスキーマ変更は度々発生するため、手間をかけずにスキーマを連携できる仕組みが必要です。

• Embulk

BigQuery に対して、リアルタイムに近いデータ鮮度でデータ同期できるということが大きな魅力でした。事前に調査を行い、データ整合性が極めて高く、RDB のスキーマ変更が自動で反映されることがわかり、Embulk の課題を解決できると感じました。

改善したかった課題はどれくらい解決されたか

「ツール導入前の課題」で挙げた課題は全てクリアできました。アプリケーション側の RDB でレコードの追加や変更・削除があれば、短時間で BigQuery に同期され、データの不整合も現時点では確認されていません。

どのような成果が得られたか

データ不整合の問題が解決したことで、データ活用はさらに促進されたと感じています。今では、倉庫の作業計画などのデータ信頼性が必要になる用途でも BigQuery が利用されています。

当時、Datastream for BigQuery は GA 版が出たばかりで資料が少なく、RDB のスキーマ変更に対してどのような挙動になるか資料が少なかったため、調査に時間がかかりました。調査結果はこちらのブログで詳細を書いています。

また、Datastream の料金の試算にも苦労しました。私は検証環境と本番環境の binlog ファイルの大きさを比較して、本番環境の料金を試算しましたが、実際に稼働すると数倍の乖離がありました。

Datastream は総じて非常優れたサービスです。ほぼリアルタイムで RDB を BigQuery に同期できるため、データ活用の幅を大きく広げてくれます。インフラ構成もシンプルであり、運用にも手間がかかりません。個人的には強くお勧めしたいサービスです。

一方で、導入を検討されるのであれば、ツールの課題点に挙げた点を押さえておいた方が良いと思います。料金とバックフィルによる RDB の負荷は事前に見積もることが難しいので、心配であれば少しずつ同期するテーブルを増やすことで、見通しが立てやすくなります。