Google タグ マネージャー データのクリックストリーム処理による Beam のパターンを紹介

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

デベロッパーにとって最初のパイプラインの構築は大変な作業です。業務遂行に利用できるツールがこれだけ多くあるなか、まず何から始めるべきでしょうか。Apache Beam と Dataflow の組み合わせはパワー、柔軟性、使いやすさに優れ、デベロッパー独自のニーズに合わせてさまざまな方法でデータ処理パイプラインを作成することが可能です。これをさらに簡単にするために、Google はサンプルの e コマース アナリティクス アプリケーションをビルドし、リファレンス実装の提供を開始しました。このリファレンス実装は、Apache Beam を使い始めたばかりのデベロッパーだけでなく、難易度の高い問題の解決を迫られている経験を積んだデベロッパーにとっても有用です。タスク達成のために使用できる有効な方法が複数ある場合もありますが、ここでは最も簡単だと思われる方法に絞っています。

このブログでは、サンプル アプリケーションで使用されているいくつかのパターンを紹介します。たとえば、サーバーサイドの Google タグ マネージャーで収集したクリックストリーム データの初期処理などです。また、サンプル アプリケーションを通して、パイプライン内の非シリアル化とシリアル化の両方に JSON スキーマと Apache Beam スキーマを使用する例を確認することもできます。

注: アプリケーションは Java でのみ実装されていますが、この投稿で紹介されているパターンの多くは他の SDK 言語でも役立ちます。

サンプル アプリケーションについて

サンプル アプリケーションは、Google タグ マネージャーからのクリックストリーム データの処理を実装するとともに、イベントの発生時に分析と対応を実施することでお客様のアクションに動的に対応する方法を示すものです。リアルタイムで更新されるシンクとして BigQuery を使用し、戦略的な意思決定を行えるようイベントデータの保存、分析、可視化を行います。市場で実際に提供されているエンタープライズ アプリケーションと同様に、他のプロダクトと連携する機能も備えています。また、ソースとして PubSub を、シンクとして Cloud Bigtable を使用しています。

Dataflow を使用したクリックストリーム処理

たとえば、御社が小売企業のデベロッパーだと仮定してみましょう。その小売企業は、e コマースサイト、モバイルアプリ、実店舗を運営しています。ここでは、e コマースとモバイルのアプリケーションに焦点を当てます。アプリケーションは、クリックストリーム イベントをウェブ階層に送信し、次いでサーバーサイド タグ設定（GTM）経由で PubSub に転送します。サーバーサイド タグ設定を使用すると、お客様は単一の Google タグをウェブサイトで使用して、すべての測定ツールの利用に必要なクリックストリーム イベントのスーパーセットを収集できます。このデータはお客様所有のサーバーに送信され、最後に、Google アナリティクスや他のサードパーティ、その他のデータ ストレージや配信ツール（例: BigQuery、PubSub）など、多くの送信先にファンアウトされます（サーバーサイド GTM について詳しくは、こちらをご覧ください）。

以下のアーキテクチャ図は、サーバーサイド タグ設定を使用したインテグレーションを示しています。

イベントは PubSub に公開され、以下の例のように JSON 形式で公開されます。

ここまでで、クリックストリーム データの収集元と供給先について説明しました。次に、データを役立てるために必要な 2 つの作業について考えましょう。

• データを検証して修正する

• セッション ウィンドウを作成し、アクティビティが正しくグループ化されていることを確認する

1 つ目のタスク: データを検証して修正する

データが解析されたからといって、データのタイプやスキーマが事業ドメインに最適なものであるとは限らず、プロパティの欠落や、内容の不整合がある可能性があります。そのため、優れたデータ パイプラインには必ず検証と修正が含まれます。今回の小売企業向けアプリケーションでは、これらを別々の変換としてモデル化することで、検証ステップではクリーンなデータがそのまま通過するだけで済むようにしています。

データ検証については、パイプラインの一部として実施する場合の一般的なアプローチがいくつかあります。ここでは、いくつかのオプションとそれぞれの長所および短所を説明し、サンプルの小売企業向けアプリケーション内でそれを実現する方法を紹介します。

その際、プロパティ a,b を持つオブジェクト Foo {Foo:{a:'bar',b:'baz'}} を例として使用します。企業には検証ロジックがあり、このロジックを使って a と b のプロパティの値が正しいかどうかを確認する必要があります。

アプローチ A: 単一の変換

このアプローチでは、検証と修正のコードはすべて単一の DoFn に組み込まれ、修正できないアイテムは deadletter キューに渡されます。

• 長所: 正攻法であり、多くのケースで非常に有効です。

• 短所: Beam 変換は Foo に固有であり、ビジネスの他の部分で再利用するための変換ライブラリには適しません。たとえばプロパティ b が小売企業の組織内にある多くのオブジェクトで使用される場合、将来的に同じ作業を何度も行う必要が生じる可能性があります。

アプローチ B: ルーター検証の変換とブランチの修正

このアプローチでは、異なるプロパティ（または類似したプロパティのグループ）を 1 つの変換で検証してから、他の変換で修正します。

• 長所: 変換をより広範な変換ライブラリに統合できます。

• 短所: アプローチ A と比べると、より多くのボイラープレート コードの記述が必要になります。場合によってはパフォーマンス上のデメリットが伴います（ただし、Dataflow による融合によって影響はかなり抑えられます）。このアプローチのもう一つの欠点として、要素でプロパティ a と b の両方の修正が必要な場合、要素のすべての部分を元に戻すためにダウンストリームで JOIN オペレーションを実施しなければなりません。結合にはシャッフル オペレーション（キーに基づいたデータの再分配）が必要になります。これは比較的時間と費用のかかるオペレーションなので、できれば回避することをおすすめします。

アプローチ C: シリアル検証と修正変換

このアプローチでは、要素は一連の検証ステップを通過してから、一連の修正ステップに渡されます。マルチ出力変換を使用すると、エラーのない要素はダウンストリームの変換に直接渡されます。要素にエラーがある場合、要素は修正を行う変換に送信されます（ただし、修正不可能と判断された場合は deadletter シンクに送信されます）。Dataflow による融合のおかげで、どの場合もすべての変換を有効に活用して要素を効率的に処理することができます。

このプロセスには他にも多くのバリエーションがありますが（アプローチ A と C を組み合わせれば、現実の複雑なシナリオの大部分を解決できます）、ここではプロセスの説明に適したコードを多く含むアプローチ C を小売企業向けアプリケーションに使用します。それでは、要素のプロパティの使用方法を理解したところで、実際に例を見ていき、必要に応じて確認と修正を行います。

Event DateTime

すべてのクリックストリーム オブジェクトには Event DateTime プロパティがアタッチされています。この日付はアプリケーションのクライアントサイドで設定されるため、いくつかの点は、企業側で確認したほうがよいでしょう。

• 日付の形式: 文字列自体は正しいはずですが、このプロパティはスキーマ内の文字列であるため、エラーが発生しなかったとしても日付の形式は間違っている可能性があります。

• 日付の精度: 日付は現在より後であってはいけません。日付はクライアントサイドで設定されるため、正しく設定されていない可能性があります。日時の誤りをどのように処理するかは、企業が選択することになります。ここでは、要素がパイプラインで最初に確認された時刻（イベント時刻）ではなく、要素が PubSub に公開された時刻（処理時刻）になるよう時刻を修正します。

なお、event datetime フィールドそのものではなく、クリックストリーム イベントのタイムスタンプ プロパティを修正している点に注意してください。これにより、元のデータを維持しつつ、このデータを使ったその後の分析には正しい時間の値が使用されるようになります。  

Items

add_to_cart や purchase などの特定のイベントでは、Items 配列に少なくとも 1 つのアイテムが入力されている必要があります。通常であれば、こうしたアイテムのフィールドはすべて正しく入力されますが、item_name、item_brand、item_category などの一部の記述的なフィールドは正しく入力されていない場合があります。これらのいずれかが入力されていない場合は、修正する必要があります。

実装

特定の変換を連続的に使用することで、要素に修正が必要かどうかの判定が容易になります。そのためには、問題に応じて要素をタグ付けする方法が必要になります。新しいプロパティを ClickStreamEvent 要素など検証が必要な要素すべてに追加することも一つの方法ですが、これでは要素自体を変更することになり、ダウン ストリームの出力に含まれてしまいます（例: 要素が BigQuery に渡された場合）。そこで代わりに、問題に応じて要素をタグ付けするための配列を含む別のスキーマで要素をラップすることにしました。

上のコード スニペットでは、エラー フィールドを使用して、問題のリストをクリックストリームに追加してから、修正の変換内で確認しています。その後、ValidateAndCorrectCSEvt 変換を使用してすべての検証と修正の変換を作成します。その部分を以下に示します。

Row.withSchema を使用して新しい行の要素を作成しています。また、PCollectionTuple は行のスキーマを推測できないため、withSchema を使用して行のスキーマを明示的に設定しています。

修正できないアイテムについては、deadletter パターンに従い、今後の修正のためにシンクに送信します。このプロセスは多くの場合、手動で行う必要があります。

利用できるもう一つのモジュラー パターンは、複数の「verifier」/「corrector」を挿入できるよう DoFn を作成することです。verifier / corrector は、システム全体で再利用するライブラリ（つまり PTransform ではない）にすることもできます。失敗した corrector のみがオブジェクトを deadletter キューにトリガーします。

このステップで検証と修正が終了し、セッション ウィンドウの作成に移ることができます。

2 つ目のタスク: セッション ウィンドウの作成

セッション ウィンドウは特別なタイプのデータ ウィンドウで、固定ウィンドウ（個別の時間間隔に依存している）とは異なり、データ自体を使用してウィンドウを閉じるタイミングを決定します。Apache Beam ドキュメントでは以下のように記載されています。

「セッション ウィンドウ機能は、他の要素の特定のギャップ時間内にある要素を含むウィンドウを定義します」

この意味を理解するために、ユーザーが朝、仕事前に御社のモバイル ショッピング アプリケーションにログインして、今日の夕食に使う商品アイテムを注文し、配送を依頼したと想定しましょう。同じ日に同一ユーザーはもう一度ログインし、週末に使用したいと思っているスポーツ用品をブラウジングしました。固定ウィンドウなどの他のウィンドウ処理オプションでは、セッションが部分的に欠落する可能性があります。また、時間差を確認し、セッションを定義するには、データを手動で並び替える必要があります。しかし、セッション ウィンドウでは、この 2 つのアクティビティを 2 つの異なるセッションとして扱うことができます。朝のアクティビティが終わってから夜のアクティビティが始まるまでには長い遅延（「ギャップ」時間）があるため、セッション ウィンドウは朝のアクティビティを別のセッションとして出力し、ユーザーが夜のアクティビティを開始した際には新しいセッションを開始します。

ウィンドウ変換をパイプラインに適用する際には、ギャップ時間の値を指定します。この期間に完璧な値はありませんが、慣例的には 1 桁台前半の時間が妥当です。

Apache Beam を使用すると、このようなセッション ウィンドウを作成できます。コードは以下のようにかなり簡単です（ClickStreamSessions）。検証してクレンジングしたデータにセッション ウィンドウを適用し、group.by オペレーションで複数の異なるセッション イベントをまとめて指定します。このグループ化に使用するキーは client_id で、タグ マネージャーから提供されます。

ITERABLE[ROW[ClickstreamEvent]] は、そのセッションのすべてのイベントを保持し、さらなる分析作業に使用できます。たとえば、どのような順序でブラウジングして最終的に購入に至ったのかを調査したい場合には、この小売企業向けアプリケーション内の ClickStreamSessions 変換で確認できます。

結論

Google タグ マネージャーのクリックストリーム データを利用して、正常なストリーミング パイプラインに必要なデータの検証と修正に関するいくつかの基本概念とパターンを説明しました。また、セッション ウィンドウを使用してユーザーの異なるジャーニーを区別し、実践的な方法でデータをセグメント化する方法も紹介しました。

次の投稿では、データの取り込みの流れと、Apache Beam スキーマを使用してパイプライン内の要素を表現する方法について説明します。また、スキーマを使用して簡潔で管理しやすいパイプラインを記述する方法についても見ていきます。それまでの間に、今回ご紹介したアプローチが日々のワークフローにどのように役立ったかを教えていただけると幸いです。他にも、Dataflow パイプラインやアプリケーションについて確認したいことがありましたらお知らせください。

- スタッフ デベロッパー アドボケイト Reza Rokni

- プロダクト マネージャー Shan Kulandaivel