SalesforceデータエンジニアのためのCRM Analytics（旧Einstein Analytics）データパイプライン徹底解説

執筆者：Salesforce データエンジニア

背景と応用シナリオ

Salesforce データエンジニアの皆さん、こんにちは。私たちの主な役割は、ビジネス上の意思決定を促進するために、信頼性が高く、クリーンで、利用可能なデータを準備することです。Salesforceエコシステムにおいて、この役割を最も効果的に果たせる場所の一つが CRM Analytics (旧称: Einstein Analytics (アインシュタイン・アナリティクス)) の世界です。

CRM Analyticsは、Salesforceの標準レポート＆ダッシュボード機能を超える、高度な分析と可視化を提供するプラットフォームです。単にデータを表示するだけでなく、Salesforce内外の大量のデータを統合し、複雑な変換処理を施し、高速なクエリが可能なデータセットを構築することで、深い洞察を得ることを目的としています。

データエンジニアとして私たちが直面する課題は、まさにこの「データを準備する」プロセスにあります。例えば、以下のようなシナリオを考えてみましょう。

応用シナリオ：全社的な営業パフォーマンス分析

営業部門のリーダーが、四半期ごとの営業パフォーマンスを多角的に分析したいと考えています。分析要件は以下の通りです。

商談データ（商談オブジェクト）と顧客情報（取引先オブジェクト）を結合する。
各営業担当者の売上目標データ（外部CSVファイルで管理）を取り込む。
売上実績と目標を比較し、達成率を算出する。
顧客の業種や地域といった属性で、達成率をドリルダウン分析できるようにする。

この要件を満たすためには、Salesforceの標準レポートでは限界があります。複数のデータソースを統合し、新たな指標（達成率）を計算するETL (Extract, Transform, Load) 処理が必要です。CRM Analyticsのデータパイプラインは、このような複雑なデータ準備プロセスをSalesforceプラットフォーム上で完結させるための強力なツールセットを提供します。

原理說明

CRM Analyticsの心臓部は、データを取り込み、変換し、最終的な分析用Dataset (データセット) を作成するデータパイプラインです。データエンジニアとして、私たちは主にこのパイプラインの設計と実装に責任を持ちます。パイプラインを構成する主要なツールは「Dataflow」と「Recipe」の2つです。

Dataflow (データフロー)

Dataflow (データフロー) は、CRM Analyticsの伝統的なデータ準備ツールです。JSON形式の定義ファイルによって、一連のデータ変換処理を記述します。各処理は「ノード」と呼ばれ、ノードを繋ぎ合わせることでデータの流れを定義します。データエンジニアにとっては、コードベースでパイプラインを厳密に管理できるという利点があります。

主なDataflowノード

sfdcDigest: Salesforceオブジェクトからデータを抽出（Extract）するノードです。どのオブジェクトから、どの項目を抽出するかを指定します。
edgemart: 既存のデータセットをデータフローの入力として使用するためのノードです。
augment: 2つのデータストリームを結合（Join）するためのノードです。SQLのJOINに似ており、左側のデータに右側のデータを付加します。
computeExpression: 新しい項目を計算して追加します。例えば、`Amount - Cost` のような計算式を定義できます。
computeRelative: グループ化されたデータ内で、レコード間の相対的な値を計算します。例えば、前のレコードとの差分などを計算できます。
filter: 条件に基づいてレコードをフィルタリングします。
sfdcRegister: 処理結果を最終的なデータセットとして登録（Load）します。データセット名や表示ラベルをここで定義します。

Recipe (レシピ)

Recipe (レシピ) は、Dataflowに代わる新しい世代のデータ準備ツールです。直感的なGUI（グラフィカル・ユーザー・インターフェース）を提供し、ユーザーは画面上でプレビューを見ながら、インタラクティブにデータ変換のステップを追加していくことができます。

RecipeはDataflowよりも多くの変換機能（例：センチメント分析、クラスタリング）、機械学習に基づいたデータ補完（スマート変換）、そしてより優れたパフォーマンスを提供します。Salesforceは新規のデータ準備タスクにはRecipeの使用を強く推奨しており、データエンジニアとしても、生産性とメンテナンス性の観点からRecipeを第一選択とすべきです。

SAQL (Salesforce Analytics Query Language)

SAQL (Salesforce Analytics Query Language) は、CRM Analyticsのデータセットに対してクエリを実行するための言語です。SQLに似た構文を持ちますが、ピボットテーブルのような集計処理や時系列分析など、分析用途に特化した機能が強化されています。

通常、ダッシュボード上のウィジェットは裏側でSAQLを生成・実行していますが、データエンジニアはDataflowの`computeExpression`ノード内で複雑なウィンドウ関数を使用したり、ダッシュボードのJSONを直接編集して高度なクエリを実装したりする際にSAQLを直接記述することがあります。データパイプラインの知識に加え、SAQLを理解することで、より高度な分析要件に対応できます。

示例代码

ここでは、Dataflowの具体的な構造を理解するために、公式ドキュメントで解説されている構文に基づいたJSONのサンプルを示します。この例では、「商談」オブジェクトと「取引先」オブジェクトのデータを抽出し、「取引先」の業種情報を「商談」データに付加して、新しいデータセットを作成します。

Dataflow定義ファイル (Opportunity_Account_ETL.json)

{
  "Extract_Opportunities": {
    "action": "sfdcDigest",
    "parameters": {
      "object": "Opportunity",
      "fields": [
        { "name": "Id" },
        { "name": "Name" },
        { "name": "Amount" },
        { "name": "CloseDate" },
        { "name": "AccountId" }
      ]
    }
  },
  "Extract_Accounts": {
    "action": "sfdcDigest",
    "parameters": {
      "object": "Account",
      "fields": [
        { "name": "Id" },
        { "name": "Name" },
        { "name": "Industry" }
      ]
    }
  },
  "Augment_Opps_with_Account_Info": {
    "action": "augment",
    "parameters": {
      "left": "Extract_Opportunities",
      "left_key": [
        "AccountId"
      ],
      "right": "Extract_Accounts",
      "right_key": [
        "Id"
      ],
      "right_select": [
        "Name",
        "Industry"
      ],
      "relationship": "Account"
    }
  },
  "Register_Opps_With_Accounts_Dataset": {
    "action": "sfdcRegister",
    "parameters": {
      "alias": "Opps_With_Accounts",
      "name": "Opportunities With Account Information",
      "source": "Augment_Opps_with_Account_Info"
    }
  }
}

コード詳細解説

1-13行目 (Extract_Opportunities): `sfdcDigest`アクションを使用して、`Opportunity`オブジェクトからデータを抽出します。`fields`パラメータで、`Id`, `Name`, `Amount`, `CloseDate`, `AccountId`の5つの項目を指定しています。このノードはデータパイプラインの起点の一つとなります。
14-25行目 (Extract_Accounts): 同様に`sfdcDigest`アクションを使い、`Account`オブジェクトから`Id`, `Name`, `Industry`の3項目を抽出します。
26-42行目 (Augment_Opps_with_Account_Info): `augment`アクションを使用して2つのデータストリームを結合します。
- `left`: 主となるデータストリーム（`Extract_Opportunities`ノードの結果）を指定します。
- `left_key`: 左側のキー項目（ここでは`AccountId`）を指定します。
- `right`: 結合する右側のデータストリーム（`Extract_Accounts`ノードの結果）を指定します。
- `right_key`: 右側のキー項目（ここでは`Id`）を指定します。
- `right_select`: 右側のデータからどの項目を結合結果に含めるかを指定します。ここでは、`Account.Name`と`Account.Industry`を追加しています。
- `relationship`: 結合した項目グループに名前を付けます。これにより、最終的なデータセット内で`Account.Name`のように項目が整理されます。
43-50行目 (Register_Opps_With_Accounts_Dataset): `sfdcRegister`アクションを使用して、これまでの処理結果をデータセットとして保存します。
- `source`: データソースとなるノード（`Augment_Opps_with_Account_Info`）を指定します。
- `alias`: データセットのAPI参照名を指定します。
- `name`: データセットの表示ラベルを指定します。

このJSONファイルをCRM Analytics Studioにアップロードし、データフローを実行すると、「Opps_With_Accounts」という名前のデータセットが作成されます。

注意事項

CRM Analyticsのデータパイプラインを運用する上で、データエンジニアが留意すべき点がいくつかあります。

権限 (Permissions)

データフローやレシピの作成・編集・実行には、「CRM Analytics Plus Admin」または同等の権限を持つ権限セットが必要です。また、ダッシュボードやデータセットを閲覧するユーザーには、「CRM Analytics Plus User」権限セットが必要になります。データソースとなるSalesforceオブジェクトや項目へのアクセス権（項目レベルセキュリティ）も適切に設定されている必要があります。

API制限 (API Limits)

CRM AnalyticsはSalesforceの他の機能と同様に、Governor Limits (ガバナ制限) の対象となります。特に注意すべきは以下の点です。

データフロー/レシピの実行回数: 24時間あたりの実行回数には上限があります。組織のエディションによって異なります。
データセットの行数: 1つのデータセットに格納できる行数には上限があります（例: 5,000万行）。これを超える場合は、データを分割するか、Salesforceサポートへの上限緩和申請が必要です。
SalesforceコネクタのAPIコール: `sfdcDigest`ノードはSalesforce APIを消費してデータを抽出します。大規模なデータ抽出を頻繁に行うと、組織全体のAPIコール上限に影響を与える可能性があります。可能な限り、増分同期（Incremental Sync）を活用して、変更があったデータのみを抽出するように設計することが重要です。

エラー処理 (Error Handling)

データパイプラインは失敗することがあります。データ型の不一致、数式のエラー、リソース不足、権限の欠如などが一般的な原因です。「データマネージャ」の「監視」タブで、各ジョブの実行状況（成功、失敗、警告）を確認できます。ジョブが失敗した場合は、エラーログを詳細に確認し、原因を特定して対処する必要があります。特に、結合キーの不一致や予期しないNULL値がエラーの一般的な原因となるため、データクレンジングのステップをパイプラインに組み込むことが推奨されます。

まとめとベストプラクティス

CRM Analyticsは、Salesforceデータエンジニアにとって非常に強力な武器です。データパイプラインを駆使することで、散在するデータを価値ある洞察へと昇華させることができます。最後に、効果的なデータパイプラインを構築・運用するためのベストプラクティスをいくつか紹介します。

Recipeを第一に選択する (Recipe First): 新規のデータ準備タスクには、必ずRecipeを検討してください。その直感的なUI、豊富な変換機能、優れたパフォーマンスは、Dataflowに対する明確なアドバンテージです。Dataflowは、既存のレガシーな実装をメンテナンスする場合にのみ使用を限定すべきです。
早期にフィルタリングし、不要な列を削除する (Filter and Drop Early): パイプラインのパフォーマンスを最適化する最も簡単な方法は、処理するデータ量を減らすことです。データソースのできるだけ早い段階で不要なレコードをフィルタリングし、分析に使用しない列は削除しましょう。
増分更新を積極的に活用する (Leverage Incremental Updates): データソースが対応している場合、常に増分更新を検討してください。毎回全件データをロードするのではなく、前回の実行以降に変更されたデータのみを処理することで、実行時間を大幅に短縮し、API消費を抑えることができます。
パイプラインをモジュール化する (Modularize Your Pipelines): 巨大で複雑な一つのデータフロー/レシピを作成するのではなく、複数の小さなパイプラインに分割し、それらを連携させる（Chaining）ことを検討してください。例えば、まず基本的なデータクレンジングを行うパイプラインを作成し、その結果データセットを、集計や結合を行う別のパイプラインの入力として使用します。これにより、再利用性、管理性、デバッグの容易さが向上します。
ドキュメントと命名規則を徹底する (Documentation and Naming Conventions): データセット、項目、パイプラインには、その目的が明確にわかるような一貫した命名規則を適用してください。また、複雑な変換ロジックについては、レシピ/データフローの説明欄や外部ドキュメントにその内容を記録しておくことが、将来のメンテナンスにおいて非常に重要になります。

これらの原則に従うことで、私たちはスケーラブルで、効率的で、信頼性の高いデータ基盤をCRM Analytics上に構築し、ビジネスの成功に直接貢献することができるでしょう。

にゃんこのSalesforce日記

このブログを検索