Databricks Delta Sharing

Databricks Delta Sharingを使用すると、Brazeのライブエンゲージメントデータやキャンペーンデータをお使いのDatabricks環境に安全に共有できます。この記事では、データプロバイダーとしてのBrazeから受信者としてのDatabricksアカウントへの共有の仕組みと、共有テーブルのクエリ方法について説明します。

Databricks Delta SharingはBrazeデータ配信の一部です。データ配信オプションの全体的な概要については、データ配信を参照してください。

前提条件

要件	説明
クローズドベータアクセス	参加をご希望の場合、またはこの機能がワークスペースで有効になっているか確認したい場合は、カスタマーサクセスマネージャーにお問い合わせください。
Brazeワークスペースの権限	データ共有を表示するには、Currents連携の表示権限が必要です。Deltaシェアの作成、更新、削除を行うには、Currents連携の編集権限が必要です。

Delta Sharing の設定

Databricks では、データプロバイダーとデータ受信者の間でデータ共有が行われます。Braze アカウントは共有を作成して送信するためデータプロバイダーであり、Databricks アカウントは共有を利用してクエリ可能なカタログを作成するためデータ受信者です。詳細については、Databricks のドキュメント「Databricks 間の Delta Sharing を使用して共有されたデータの読み取り（受信者向け）」を参照してください。

ステップ1：Braze から共有を設定する

1. Braze で、パートナー連携 > Data Sharing > Databricks Delta Sharing に移動します。
2. Databricks の共有識別子を入力します。
3. 完了したら、Create Datashare を選択します。Braze が Databricks アカウントに共有を送信します。

ステップ2：Databricks でカタログを作成する

1. 数分後、Databricks アカウントでインバウンド共有を受信します。

2. インバウンド共有を使用して、テーブルを表示およびクエリするためのカタログを作成します。例：

   
   1
   
    CREATE CATALOG [IF NOT EXISTS] <catalog-name> USING SHARE braze.<share-name>;
   
   

3. 適切なユーザーやグループが新しいカタログをクエリできるように権限を付与します。

使用方法と可視化

データ共有がプロビジョニングされたら、受信した共有からカタログを作成して、共有テーブルがDatabricksワークスペースに表示され、他の保存データと同様にクエリできるようにします。共有データは読み取り専用のままです。

Currentsと同様に、Databricks Delta Sharingを使用して以下のことが可能です。

• 複雑なレポートの作成
• アトリビューションモデリングの実行
• 社内での安全な共有
• 未加工のイベントデータやユーザーデータをCRM（Salesforceなど）にマッピング
• その他多数

Databricksで利用可能なテーブルとカラムの完全なリストについては、テキストファイルとしてDatabricksローテーブルスキーマをダウンロードしてください。このファイルはDatabricks Delta Sharingスキーマを反映しています（例：取り込み時刻のDB_CREATED_AT）。SnowflakeローテーブルスキーマやSQLテーブルリファレンスとは互換性がありません。これらはSnowflakeの命名規則とフィールドを記述するものです。

ユーザーIDスキーマ

ユーザーIDに関するBrazeとDatabricksの命名規則の違いに注意してください。

Brazeスキーマ	Databricksスキーマ	説明
braze_id	USER_ID	Brazeが自動的に割り当てる一意の識別子です。
external_id	EXTERNAL_USER_ID	Brazeで設定するユーザープロファイルの一意の識別子です。

重要な情報と制限事項

クローズドベータの利用可能性

クローズドベータ期間中、共有データには Databricks 生テーブルスキーマファイルのすべてのテーブルが含まれない場合があります。また、共有データは Snowflake Data Sharing とカラム名や型が異なることがあります。たとえば、Databricks 共有では取り込み時刻に DB_CREATED_AT を使用しますが、Snowflake 共有では SF_CREATED_AT を使用します。

破壊的変更と非破壊的変更

非破壊的変更

非破壊的変更はいつでも発生する可能性があり、一般的に追加機能を提供します。非破壊的変更の例:

• 新しいテーブルまたはビューの追加
• 既存のテーブルまたはビューへのカラムの追加

破壊的変更

可能な場合、破壊的変更は事前の告知と移行期間が設けられます。破壊的変更の例:

• テーブルまたはビューの削除
• 既存のテーブルまたはビューからのカラムの削除
• 既存カラムの型またはnull許容性の変更

Databricks リージョン

クローズドベータ期間中、サポートされるクラウドプロバイダーとリージョンはワークスペースやロールアウトによって異なる場合があります。お使いのアカウントに適用されるオプションについては、Brazeのカスタマーサクセスマネージャーにお問い合わせください。

リテンションポリシー

クローズドベータ期間中、標準のリテンション期間を超える過去データのバックフィルは制限される場合があります。

各イベントの対応する USERS_*_SHARED ビューで、直近2年間のデータに対してクエリを実行できます。

一般データ保護規則 (GDPR) コンプライアンス

Braze に保管されているほぼすべてのイベントレコードには、ユーザーの個人を特定できる情報 (PII) を表すいくつかのフィールドが含まれています。一部のイベントには、メールアドレス、電話番号、デバイスID、言語、性別、および位置情報が含まれる場合があります。ユーザーの削除依頼がBrazeに送信された場合、これらのユーザーに属するイベントのPIIフィールドを無効化します。この方法では、イベントの履歴レコードは削除されませんが、イベントが特定の個人に結び付けられることは一切ありません。

共有データのクエリ: TIME とクエリパフォーマンス

データ共有ビュー（たとえば USERS_BEHAVIORS_CUSTOMEVENT_SHARED）のイベントデータは、TIME フィールドでクラスタリングされています。イベントの発生時刻でフィルタリングする場合は、TIME を優先フィルターとして使用してください。TIME で行を制限するクエリは、クラスタリングがイベント時刻に沿っているため、DB_CREATED_AT でフィルタリングするクエリよりも一般的にパフォーマンスが高くなります。

フィールド	意味
TIME	イベントが発生した Unix タイムスタンプ。発生時刻でフィルタリングする場合はこちらを優先してください。
DB_CREATED_AT	行が Databricks に読み込まれたタイムスタンプ（取り込み時刻）。

クエリの速度、パフォーマンス、コスト

データに対して実行するクエリの速度、パフォーマンス、コストは、使用する SQL ウェアハウスのサイズによって異なります。アクセスするデータ量によっては、クエリを正常に完了するためにより大きなウェアハウスが必要になる場合があります。詳細については、Databricks のドキュメント「SQL ウェアハウスの作成と構成」（クラスターサイズとスケーリングを含む）を参照してください。