RECRUIT

風音屋では、データエンジニア、データアナリスト、データコンサルタントを募集しています。

書籍執筆者やOSSコントリビューターなど、業界を代表する20名以上のアドバイザーと一緒にベストプラクティスを追求できる環境です。

ぜひカジュアルトークをお申し込みください。

5 minute read

風音屋 データエンジニアの濱田（@hrkhjp）です。

BigQuery Advent Calendar 2023 の 22 日目の記事です。

本記事では、Datastream を用いた Amazon Aurora MySQL から BigQuery へのデータ連携についてご紹介します。

結論を先に書いてしまうと、今回のケースでは実際に運用するところまでは至りませんでした。 まずは Datastream の概要とユースケースをご紹介し、その後、実運用における課題をご説明します。

Datastream とは

Datastream とは、GCP (Google Cloud Platform) で提供されている、CDC（変更データキャプチャ）サービスです。 CDC とは、元となるデータベースの変更（INSERT、UPDATE、DELETE）を追跡し、他のシステムやサービスへ連携できる仕組みです。

Datastream を利用することで、以下のような GCP の各サービスに、MySQL や PostgreSQL などのデータをロードできます。

  • BigQuery
  • Cloud SQL
  • Cloud Storage
  • Cloud Spanner

実現したいこと

まずは、今回 Datastream を活用して実現したい 2 つのユースケースについてご紹介します。

  • ニアリアルタイムでのデータ連携
  • すべてのデータ変更記録の保持

ニアリアルタイムでのデータ連携

異常検知や広告配信の最適化など、速報性が求められるシーンにおけるデータ活用の幅を広げるためには、ニアリアルタイムでのデータ連携は非常に有用です。

もしある程度の速報性（1 時間に 1 回、10 分に 1 回など）で十分であれば、マイクロバッチ処理による連携方式が第一候補として挙げられます。 一方で、さらにリアルタイムに近い鮮度が求められる場合には、ストリーム処理による連携方式を検討する必要が出てきます。 しかし、このような処理を自前で実装するには、データの整合性やスケーラビリティなど多くの面で課題があり、ハードルが高くなってしまいます。

Datastream はサーバレスなサービスなので、簡単な設定のみでこれを実現できます。 宛先を BigQuery に指定すると、ニアリアルタイムで元テーブルを BigQuery のテーブルとして同期できます。

すべてのデータ変更記録の保持

データソースとなる業務システムのデータベースでは、ステータスを更新する方法でイベントの進行を管理している場合があります。 例えば、EC サイトの業務システムにおいて、注文後のステータスが「注文済み」「支払い済み」「発送済み」「受け取り済み」のように変化していくようなケースが考えられます。

データ分析の観点では、「注文」「支払い」「発送」「受け取り」それぞれのイベントのログが欲しくなります。 ところが、業務システムのデータベースではステータスの遷移に伴ってレコードが UPDATE されてしまい、途中の記録が残っていないことがよくあります。 このような場合でも、定期的（日次など）にスナップショットを取得することで、ある程度は変更を追うことができます。 しかし、もし取得頻度より短い間隔でデータが更新された場合、その記録はどこにも残らず消えてしまいます。

Datastream では、宛先に Cloud Storage を指定すると、元テーブルのすべての変更（INSERT、UPDATE、DELETE）がファイルとして出力されます。 出力されたファイルをネイティブテーブルとしてロードするか、ソースとして指定した外部テーブルを作成することで、BigQuery から変更記録を参照できます。

注意点

宛先に BigQuery を指定した場合、元テーブルの変更は BigQuery のテーブルにそのまま反映されてしまうため、変更履歴を保持できません。 BigQuery の機能により、過去の状態を一部参照可能ですが、以下のような制約があります。

  • タイムトラベル機能を使えば過去時点のデータを参照できますが、最大でも 7 日までしか遡ることができません。
  • フェイルセーフ期間も含めればさらに 7 日間（タイムトラベルと合わせて 14 日間）遡ることができますが、サポートに問い合わせる必要があるため分析用途としては現実的ではありません。

課題

このように、Datastream を用いることで、難しいデータ連携をサーバレスで簡単に実現できます。

一方で、今回試してみた結果、Datastream を本番運用していく上では、以下のような課題があるとわかりました。

Cloud Storage の格納パス

Datastream は、以下のようなパスで Cloud Storage にデータを格納します。

[object_name]/yyyy/MM/dd/hh/mm/[filename]

これは、BigQuery にネイティブテーブルとして取り込む場合は特に問題にはなりません。 ところが、外部テーブルとして参照する場合、Hive パーティション形式になっていないため、クエリ実行時にパーティションを効かせることができません。

もちろん、以下のような形式のパスで再配置すればパーティションとして認識できますが、最初からこの形式で配置されているとありがたいなと感じました。

[object_name]/year=yyyy/month=MM/day=dd/hour=hh/minute=mm/[filename]

ライター エンドポイント指定の必要性

Amazon Aurora MySQL データベース用に CDC を構成する前に、既存の Aurora クラスタがあり、マスター データベース サーバーのライター エンドポイントに接続していることを確認してください。

Datastream 公式ドキュメントに上記の記載があるとおり、Amazon Aurora MySQL をデータソースとする場合はリードレプリカからデータを読み込むことができません。

業務システムのデータベースからデータを取得してデータ基盤に取り込む際は、本番環境への影響を考慮して、リードレプリカを参照することが推奨されます。 ところが、上記の制約により、Datastream によるデータ連携時は、ライターインスタンス（＝本番環境で書き込みを行っているインスタンス）を参照する必要があります。 これは binlog から変更履歴を取得するときだけではなく、初回連携など、全件取得によるレプリケーションを実施するときも同様です。

DB 負荷によるサービスへの影響が懸念されるため、今回、本番での運用は難しいと判断しました。

補足

まとめ

本記事では、Datastream による Aurora MySQL から BigQuery へのデータ連携についてご紹介しました。

今回は実運用には至りませんでしたが、シンプルな設定で、高度かつサーバレスなデータ連携を実現できる Datastream は非常に夢のあるサービスだと感じました。 解決すべき課題もいくつかありますが、今後データ連携の主流になるポテンシャルを十分に持ったサービスなので、今後の動向を注視していきたいですね。

You May Also Enjoy