Snowflakeアーキテクチャへのデータ同期

最終更新日:

この記事では、PendoデータをSnowflakeに同期するためのアーキテクチャとデータフローについて説明します。インテグレーションを支えるインフラストラクチャ、転送プロセス、およびストアドプロシージャの概要が含まれます。宛先の設定方法については、「Pendoデータ同期をSnowflakeに設定する」を参照してください。

概要

Pendoデータ同期を使用すると、開発者のリソースを必要とせずに、PendoサブスクリプションからSnowflakeアカウントにデータテーブルを直接同期できます。これにより、データの保存方法、クエリ方法、分析方法を含め、データに対する完全な所有権が得られます。

データはSnowflake環境に保存されるため、すべてのSnowflakeストレージとデータ処理に関連するコストはお客様の負担となります。

Snowflakeへのデータ同期は、クラウドストレージへのデータ同期と同じデータを提供し、同じ基盤データインフラストラクチャを使用します。

必要な権限と役割

以下のエンティティ作成および権限付与操作が必要です。Pendoは、以下の操作を容易にするためのSQLスクリプトを提供しています。

  • Pendoによって生成された公開鍵に関連付けられたユーザーを作成します。
  • Pendo専用のウェアハウスとデータベースを作成します。
  • Snowflakeで以下の権限が付与される役割を作成します。

各種権限とその目的は以下のようにまとめられます。

オブジェクト 必要な権限 備考
アカウント権限 CREATE INTEGRATION CREATE STORAGE INTEGRATIONに使用される権限。Snowflakeの宛先が作成された後に取り消すことができます。
データベース権限(Pendoデータ用に作成されたデータベース内) 使用
MONITOR
CREATE SCHEMA

Pendoには、Pendoが作成したスキーマ、およびPendoが作成するスキーマ内のすべてのオブジェクトに対するOWNERSHIP権限が付与されます。詳細については、この記事のPendoが作成したSnowflakeオブジェクトをご覧ください。

CREATE SCHEMA権限は、必要な同期がすべて作成された後に取り消すことができます。追加の同期を作成するには、CREATE SCHEMAが必要です。

データウェアハウスの権限(Pendoデータ用に作成されたデータウェアハウス内) 使用
MONITOR
スキーマ権限(Pendoデータ用に作成されたスキーマ内) 所有権

Pendoによってスキーマが作成された場合に許可されます。スキーマ作成時のみ必要です。

使用

スキーマ作成後の継続的な同期に必要です。スキーマが存在すると、所有権は取り消され、USAGEに置き換えることができます。

スキーマが作成されると、転送役割にOWNERSHIP権限が付与されます。継続的な同期の場合、転送役割に必要なのはスキーマに対するUSAGE権限のみであるため、スキーマ作成後に役割からスキーマOWNERSHIP権限を取り消すことができます。

Pendoによるデータの取り扱い

Pendoは権限を利用してデータ同期オブジェクトを作成および維持します。Pendoはテーブルの行を完全に削除することはありません。削除やタグ付けルールの変更は、行を削除する代わりにこれらのフィールドで表されます:

  • deletedAtは、削除されたページ、フィーチャー、トラックイベント、またはガイドを示します。
  • lastUpdatedAtは、転送によって一致したイベントが最後に確認された時刻を記録します。
  • rulesUpdatedAtは、ページ、フィーチャー、またはトラックイベントのタグ付けルールが最後に変更された日時を記録します。
  • softDeleteMethodは、オブジェクトに適用される有効性ルールを指定します。これは削除フラグではありません。

現在のデータのみをクエリするには、この記事の遡及処理と古いデータで説明されているように、これらのフィールドでフィルタリングしてください。

使用可能なデータ型

Snowflakeの宛先が設定されると、イベントデータ、アカウント、訪問者のメタデータの同期を開始できます。

  • イベントデータはアプリケーションレベルで設定されます(どのアプリケーションを含めるかを選択できます)。
  • アカウントや訪問者のメタデータは任意で、サブスクリプションレベルで設定されます。

詳細については、データ同期スキーマの定義を参照してください。標準ウェアハウステーブルのスキーマの詳細については、Snowflake ERDへのデータ同期を参照してください。

PendoからSnowflakeへのデータフロー

Pendoは顧客ごとに一意の場所に収集したデータを保存します。データ同期を任意の保存先に設定すると、リクエストされたすべてのデータのAvroファイルが作成され、Pendo GCP内の一時的なストレージロケーションに読み込まれます。Snowflakeを保存先とする場合、Pendoが所有するGCSバケットから一連のSnowflakeストアドプロシージャを使用して、データがSnowflakeに読み込まれます。一時的なステージングファイルは、3日後に一時バケットから削除されます。

これらのストアドプロシージャは下の図に詳細に示されており、Snowflakeアカウント内でも確認できます。datasync-snowflake-dataflow-diagram.png

Pendoによって作成されるSnowflakeオブジェクト

イベントオブジェクト

特定のアプリケーションのイベントデータの転送を有効にすると、Pendoは指定されたデータベース内にSUB_{SUBID}_APP_{APPID}という名前のスキーマを作成します。PendoからSnowflakeに同期される各アプリケーションには、Snowflake内にそれぞれ独自のスキーマが割り当てられます。アプリケーション固有の各スキーマ内で、Pendoは以下のテーブルを作成します。Snowflakeはこれらの名前を大文字で保存および解決します(例:MATCHEDPAGEEVENTS)。

  • すべてのイベント
  • フィーチャー
  • ページ
  • ガイド(Guides)
  • TrackTypes
  • MatchedFeatureEvents
  • MatchedPageEvents
  • MatchedTrackTypeEvents

これらのストアドプロシージャはセットアップ時にSnowflakeアカウント内で作成されます。それぞれが特定の種類のデータを読み込み、統合します。

  • AllEvents_Load_And_Merge
  • Features_Load_And_Merge
  • Guides_Load_And_Merge
  • Pages_Load_And_Merge
  • TrackTypes_Load_And_Merge
  • MatchedFeatures_Load_And_Merge
  • MatchedPages_Load_And_Merge
  • MatchedTrackTypes_Load_And_Merge

Pendoによって作成およびロードされるその他のオブジェクト:

  • Pendo_Avro_Formatという名前のファイル形式。
  • Pendo_Stageという名前のステージ。

アカウントオブジェクトと訪問者オブジェクト

訪問者データの転送を有効にすると、Pendoは指定されたデータベースにSUB_{SUBID}_VISITORというスキーマを作成します。スキーマ内で、Pendoは以下のテーブルを作成します。

  • 訪問者
  • 訪問者メタデータ

これらのストアドプロシージャはセットアップ時にSnowflakeアカウント内で作成されます。それぞれが特定の種類のデータを読み込み、統合します。

  • Visitors_Load_And_Merge
  • VisitorsMetadata_Load_And_Merge

同様に、アカウントデータの転送を有効にすると、Pendo は指定したデータベースにSUB_{SUBID}_ACCOUNTというスキーマを作成します。スキーマ内で、Pendoは以下のテーブルを作成します。

  • アカウント
  • アカウントメタデータ

これらのストアドプロシージャはセットアップ時にSnowflakeアカウント内で作成されます。それぞれが特定の種類のデータを読み込み、統合します。

  • Accounts_Load_And_Merge
  • AccountsMetadata

Pendoによって作成およびロードされるその他のオブジェクト:

  • Pendo_Avro_Formatという名前のファイル形式。
  • Pendo_Stageという名前のステージ。

遡及処理と古いデータ

Pendoでフィーチャー、ページ、またはトラックイベントのタグ付けルールを更新すると、以前に一致したイベントが新しい定義を満たさなくなることがあります。同様に、ビジネスオブジェクトを削除しても、関連付けられた一致イベントの行はテーブルに残ります。Pendoはこれらの行を削除しません。

Pendoの遡及処理ジョブは、更新されたlastUpdatedAtタイムスタンプを付けて再エクスポートすることで、アクティブな一致を定期的に再確認します。このタイムスタンプを、deletedAt、rulesUpdatedAt、softDeleteMethodと併せて使用して、古いデータを検出し、除外します。

古いイベントと有効な一致イベントを識別する

現在のルールまたは過去の一致ルールのどちらが反映されているかに基づいて、一致したイベントの行を絞り込むには、次のクエリを使用します。これらの例ではMATCHEDFEATUREEVENTSテーブルを使用していますが、同じパターンがMATCHEDPAGEEVENTSおよびMATCHEDTRACKTYPEEVENTSにも適用されます。

古い一致イベント行を検索するには:

-- フィーチャーイベント(ページイベントとトラックイベントにも同じパターンが適用されます)
SELECT mfe.*
FROM MatchedFeatureEvents mfe
JOIN Features f ON f.featureId = mfe.matchableId
WHERE f.deletedAt IS NOT NULL
   OR (f.softDeleteMethod = 2
       AND (mfe.lastUpdatedAt IS NULL OR mfe.lastUpdatedAt < f.rulesUpdatedAt));

有効な一致イベント行を見つけるには:

SELECT mfe.*
FROM MatchedFeatureEvents mfe
JOIN Features f ON f.featureId = mfe.matchableId
WHERE f.deletedAt IS NULL
  AND (f.softDeleteMethod = 1
       OR (f.softDeleteMethod = 2 AND mfe.lastUpdatedAt >= f.rulesUpdatedAt));

一致したイベントは、次のすべてが当てはまる場合に有効とみなされます。

  • ビジネスオブジェクトが削除されていない(deletedAt IS NULL)。
  • ビジネスオブジェクトは従来のソフト削除メソッド(softDeleteMethod = 1)を使用するか、最新のルール変更(lastUpdatedAt >= rulesUpdatedAt)の後に一致が確認された。

lastUpdatedAtがNULLの行は移行より前のものであり、陳腐化評価には含まれません。

この記事は役に立ちましたか?
0人中0人がこの記事が役に立ったと言っています