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

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

概要

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

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

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

必要な権限と役割

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

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

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

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

使用可能なデータ型

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

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

詳細については、データ同期のスキーマ定義を参照してください。標準のウェアハウステーブルスキーマの詳細については、Snowflake ERDへのデータ同期をご覧ください。ERDにアクセスするには、「datasync」というパスワードを入力する必要があります。アクセスに問題がある場合は、Pendoサポートにお問い合わせください。

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

Pendoは、取得したデータを顧客ごとに固有の場所に保存します。データ同期が任意の宛先に実装されると、要求されたすべてのデータに対してAvroファイルが作成され、Pendo GCPの一時的なストレージ場所にロードされます。Snowflakeの宛先の場合、データは、一連のSnowflakeストアドプロシージャを使用して、14日間のリテンションポリシーが適用されたPendoが所有するGCSバケットからSnowflakeにロードされます。

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

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

イベントオブジェクト

特定のアプリケーションのイベントデータの転送を有効にすると、Pendoは指定されたデータベースにSUB_{SUBID}_APP_{APPID}という名前のスキーマを作成します。PendoからSnowflakeに同期される各アプリケーションは、Snowflake内でそれぞれ固有のスキーマを持つことになります。Pendoは、各アプリケーション固有のスキーマ内に以下のテーブルを作成します。

• すべてのイベント
• フィーチャー
• ページ
• ガイド（Guides）
• TrackTypes
• MatchedFeatureEvents
• MatchedPagesEvents
• 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の遡及処理ジョブは、更新されたlastUpdatedAtタイムスタンプを付けて再エクスポートすることで、アクティブなマッチを定期的に再確認します。このタイムスタンプを使用して、古いデータを検出して除外します。

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

以下のクエリを使用して、一致したイベント行が最新の一致ルールを反映しているか、古い一致ルールを反映しているかに基づいてフィルタリングします。これらの例ではMATCHEDFEATUREEVENTSテーブルを使用していますが、同じパターンはページやイベント追跡にも適用できます。

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

-- フィーチャーイベント（ページイベントとトラックイベントにも同じパターンが適用されます）
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の行は移行より前のものであり、陳腐化評価には含まれません。