コンテンツに移動
データ分析

Bigtable および Dataflow を使用したストリーミング データの拡充が可能に

2024年4月3日
Google Cloud Japan Team

Try Gemini 1.5 Pro

Google's most advanced multimodal model in Vertex AI

Try it

※この投稿は米国時間 2024 年 3 月 28 日に、Google Cloud blog に投稿されたものの抄訳です。

データ エンジニアは、イベント処理に速さ、規模、効率が重要であることを知っています。イベント ストリームは、POS システムなどのデバイスやステートレスなクリックストリーム アクティビティを記録するウェブサイトなどから送信される大量のデータフィードです。各イベントを独自に実行できるようにするための情報が不足していることの多い軽量のイベント ペイロードを処理します。これらのイベントを変換および拡充し、特定のユースケースに応じてさらに処理するかどうかは、イベント ストリームの消費者によって異なります。

https://storage.googleapis.com/gweb-cloudblog-publish/images/Enrich_your_streaming_data_using_Bigtable_.max-2200x2200.jpg

このようなワークロードには、Bigtable などの Key-Value ストアの使用をおすすめします。1 秒間に数十万件のイベントを、極めて低いレイテンシで処理できるからです。しかし、Key-Value ルックアップを使用して低いレイテンシかつ高い運用パフォーマンスで処理を行うには、慎重に検討した本番環境への移行およびスケーリングのコードが必要になる場合が多いです。

新しい Apache Beam 拡充変換を使用すると、この処理をわずか数行のコードで実施できるようになるため、Pub/Sub Apache Kafka などのメッセージング システムに含まれるイベントを処理し、さらなる処理が行われる前に Bigtable のデータで拡充できます。

これはストリーミング アプリケーションにとって重要です。なぜなら、ストリーミングの結合によってデータが拡充され、ストリーミング イベントに意味を付加されるからです。たとえば、ユーザーのショッピング カートの中身や、そのユーザーが類似商品を以前に閲覧したかどうかがわかっていれば、そのような貴重なコンテキストを、レコメンデーション モデルにフィードされるクリックストリーム データに付加できます。また、店舗でのクレジット カードによる不正取引を特定するには、現在の取引に関する情報よりもさらに多くの情報が必要になります。たとえば、前回の購入場所、最近の取引回数、旅行予定について事前連絡があるかどうかなどです。同様に、製造現場にあるハードウェアからのテレメトリー データを、同じデバイスからの過去のシグナルまたはフリート全体の統計で拡充すると、ML モデルによって、障害を発生前に予測できるようになります。

Apache Beam 拡充変換では、クライアントサイドのスロットリングを使用して、Bigtable インスタンスに送信されるリクエスト数を必要に応じてレート制限できます。リクエストは構成可能な再試行戦略によって再試行されますが、この戦略はデフォルトで指数バックオフに設定されています。自動スケーリングを併用すると、Bigtable Dataflow でスケールアップとスケールダウンが連携して行われるため、自動的に平衡状態に達します。Beam 2.5.4.0 は指数バックオフに対応していますが、この設定を無効にしたり、カスタム実装に置き換えたりすることもできます。

これを実際に見てみましょう。

読み込んでいます...

上のコードでは、Pub/Sub サブスクリプションから読み取り、Bigtable クラスタに対して Key-Value ルックアップを実施することでデータ拡充を行う Dataflow ジョブを実行しています。拡充されたデータは、次に ML モデルにフィードされ RunInference が実行されます。

以下の図は、Dataflow Bigtable が連携し、負荷に基づいて適切にスケールしている状態を示しています。ジョブの開始後、Dataflow ランナーが 1 個のワーカーを開始します。Bigtable クラスタには 3 つのノードが含まれ、Dataflow Bigtable では自動スケーリングが有効になっています。Dataflow では、午後 5:21 に入力の負荷が急増したため、ワーカーが 40 個にスケールされています。

https://storage.googleapis.com/gweb-cloudblog-publish/images/2_yJOWQ1b.max-600x600.png

これにより、Bigtable クラスタに対する読み取り回数が増加します。Bigtable は、読み取りトラフィックの増加に対してノードを 10 個に自動的にスケールすることで、ユーザーが定義した CPU 使用率の目標値を維持しています。

https://storage.googleapis.com/gweb-cloudblog-publish/images/3_je4LBFv.max-600x600.png

これらのイベントは、Dataflow ワーカーの埋め込みモデルまたは Vertex AI による推論に使用できます。

このような Apache Beam 変換は、マルチテナントの SaaS プロダクトや部門をまたがる基幹業務アプリケーションなど、同じ Bigtable データベースからのバッチ ワークロードとリアルタイム ワークロードの両方に対応するアプリケーションでも役立ちます。これらのワークロードでは、各種ワークロードが相互に与える影響を最小限に抑えられるよう、Bigtable の組み込みメカニズムが活用される場合もよくあります。レイテンシの影響を受けやすいリクエストは、優先度の低い大規模なバッチ リクエストとスロットリング リクエストを並行処理しつつ、必要に応じて自動スケーリングされるクラスタで優先的に実行できます。これらの機能は、大量データを長時間にわたって一括取り込みするか、ストリームをリアルタイムで処理するかに関わらず、Dataflow Bigtable を使用する場合に役立ちます。

まとめ

わずか数行のコードで、数千行の内部コードを使用した場合と同じように本番環境パイプラインを構築して Pub/SubDataflowBigtable でシステムをシームレスにスケールすることで、ビジネスニーズを満たせるようになります。ML モデルが今後進化するにつれ、柔軟なスキーマを備えた Bigtable のような NoSQL データベースを使用することで、より大きなメリットを得られるようになります。今後リリースされる Beam 2.55.0 では、特定のキャッシュに合わせて構成できる、Redis 向けキャッシュ サポートも拡充変換に追加される予定です。使用を開始するには、ドキュメント ページをご覧ください

-Dataflow 担当シニア デベロッパー アドボケイト Reza Rokni
-
Bigtable 担当グループ プロダクト マネージャー Bora Beran
投稿先