Google Analytics 未加工データ コネクタの概念
Google Analytics 未加工データ コネクタを使用すると、 Databricks Lakeflowコネクト と Google BigQueryを使用して、Google Analytics 4(GA4)から未加工のイベントレベルのデータを取り込むことができます。
GA4の取り込みはどのように機能しますか?
まず、Google が提供するBigQuery API または UI を使用して、GA4 データを にエクスポートする必要があります。次に、Databricksは次のAPIを使用して BigQueryからのデータを消費します。
- メタデータ オペレーション(テーブルやスキーマのリスト作成など)用の BigQuery API
 - データ取り込み用の BigQuery Storage API
 - スキーマ探索のための Cloud リソース マネージャー API
 
コネクタ データ モデル
GA4 コネクタは、特定の GA4 プロパティから次のテーブルを取り込むことができます。
eventsevents_intradayuserspseudonymous_users
GA4 にデータが到着する日ごとに、BigQuery に日付パーティション テーブルが自動的に作成されます。BigQuery テーブル名の形式は <table_name>_YYYYMMDD です(例: events_20241024)。
Lakeflowコネクト パイプラインの更新ごとに、コネクタは前回の更新以降の新しいテーブルを自動的に取り込みます。また、既存のテーブルの新しい行を最大 72 時間取り込みます。
コネクタの基本
- パイプラインの初回実行時に、コネクタは、選択したテーブルについてBigQueryにエクスポートしたすべてのデータを取り込んでいます。
 - 後続のパイプラインの実行では、コネクタは新しく挿入された行を取り込みますが、この記事で説明されている注意事項を示します。
 - 更新と削除は取り込まれません。
 - 最初の読み込みでは、GA4 / BigQuery プロジェクトに存在するすべての日付のデータが取得されます。
 - コネクタは、各行が一意であることを前提としています。Databricks では、予期しない重複がある場合、正しい動作を保証できません。
 
ウィンドウとスケジュールの更新
GA4 は、テーブルが作成されてから最大 72 時間、テーブルを更新し続けることができます。したがって、Databricks はこれらのテーブルの更新を 72 時間追跡して取り込みます。コネクタは、72 時間の更新期間後にテーブルへの更新を自動的に取り込むことはありません (たとえば、GA4 がヒストリカルデータを再処理する場合)。
Lakeflowコネクト パイプラインは少なくとも 72 時間ごとに実行する必要がありますが、Databricks では毎日パイプラインを実行することをお勧めします。同期の頻度が低いと、コネクタがデータを再フェッチする必要が生じるリスクが高まります。
また、Databricks では、BigQuery のデフォルトのタイムトラベル ウィンドウである 7 日間を維持することも推奨しています。これにより、インジェストの効率が向上します。
テーブルレベルのデータモデル
eventsとevents_intradayテーブル
events テーブルと events_intraday テーブルの場合、Databricks の 1 行は BigQuery の 1 行に対応します。
events_intraday テーブルの場合、同じ日付のデータが events テーブルで使用可能になった後、特定の日付のデータが存在する保証はありません。これは、 events_intraday テーブルが、 events テーブルがその日の準備ができるまでの暫定的な使用のみを目的としているためです。
users テーブル
users テーブルから取り込むために、コネクタはuser_idを主キーとして、last_updated_dateをカーソル キーとして使用します。その結果、各 users テーブルからユーザー ID ごとに 1 つのロー ( last_updated_dateが最大のエントリ) のみが取り込まれます。
宛先テーブルでユーザー ID ごとに複数のローを保持するには、テーブル設定で SCD モード をタイプ 2 に設定します。
pseudonymous_usersテーブル
pseudonymous_users テーブルから取り込むために、コネクタはpseudo_user_idとstream_idを主キーとして使用します。カーソルキーとして last_updated_date を使用します。その結果、各 pseudonymous_users テーブルから疑似ユーザー ID ごとに 1 つのロー ( last_updated_dateが最大のエントリ) のみが取り込まれます。
宛先テーブルでユーザー ID ごとに複数のローを保持するには、テーブル設定で SCD モード をタイプ 2 に設定します。