Delta テーブル内のデータに接続し、Dynamics 365 Customer Insights - Dataに取り込みます。
Delta 形式で保存されたデータに接続する主な理由は次のとおりです:
- Delta 形式のデータを直接インポートして、時間と労力を節約します。
- Lakehouse データのコピーの変換と保存に関連するコンピューティング コストとストレージ コストを排除します。
- Delta のバージョン管理によって提供されるCustomer Insights - Dataに対するデータ インジェストの信頼性を自動的に向上させます。
サポートされている Databricks の機能とバージョン
Customer Insights - Data は、サポートされている機能の一覧に従い、minReaderVersion が 3 以前の Delta テーブルをサポートしています。 サポートされていないリーダー機能を使うテーブルはサポートされていません。 データ ソース接続がサポートされていない機能を持つテーブルの読み取りを試みると、次のエラーが表示されます: "デルタ テーブルを読み取ることができません (A、B、C、D)。 サポートされていないデルタ リーダーのバージョン (X、Y、Y、X) が見つかりました。
1または2の minReaderVersion が必要なすべての機能がサポートされています。
以下の表は、 minReaderVersion 3が必要なサポート済みおよびサポートされないDatabricks機能を示しています。
| サポートされている機能 | サポートされていない機能 |
|---|---|
| 基本機能 | TimestampNTZ |
| データ フィードの変更 | 型の拡張 |
| 制約を確認する | Variant |
| 列マッピング | |
| ベクトルの削除 | |
| 列の生成 | |
| 列の認識 | |
| リキッド クラスタリング | |
| 行の追跡 | |
| テーブル機能読み取り | |
| テーブル機能の書き込み | |
| UniForm |
詳しくはこちら: DatabricksはどのようにしてDelta Lakeの機能互換性を管理しているのか?
Tip
最近の Databricks ランタイムを使用していて、Dynamics 365 Customer Insights との互換性が必要な場合は、Delta テーブル プロトコルのバージョンを下げて、特定の機能を無効にすることができます。 この変更はDatabricksのワークスペースレベルで行い、新しく作成されたテーブルにデフォルトで適用します。 必要に応じて既存のテーブルから機能を削除することもできます。
設定を適用してノートブックを再実行すると、テーブルは下位リーダー/ライタープロトコルに戻ります:
この変更により、Customer Insightsはテーブルを正常に読み取り取り込むことができます:
前提条件
Azure Data Lake Storage は、Customer Insights - Data と同じテナントおよび Azure リージョンに存在する必要があります。
ファイアウォールで保護されたストレージに接続するには、Azure プライベート リンクを設定します。
Customer Insights - Data サービス プリンシパルは、ストレージ アカウントにアクセスするためのストレージ Blob データ コントリビューターの権限を持っている必要があります。 詳細については、ストレージ アカウントにアクセスするためのアクセス許可をサービス プリンシパルに付与するを参照してください。
データ ソースを設定または更新するユーザーには、Azure Data Lake Storage アカウントに対するストレージ BLOB データ閲覧者のアクセス許可が少なくとも必要です。
オンライン サービスに保存されたデータは、データが処理または保存される場所とは異なる場所に保存される場合があります。 オンラインサービスに保存されたデータをインポートまたは接続することにより、ユーザーはデータが転送されることに同意するものとします。 詳細については、Microsoft Trust Center を参照してください。
Customer Insights - Data は、一覧に記載された機能サポートを前提として、
minReaderVersionが 3 以下の Delta テーブルをサポートしています。 詳細については、サポートされている Databricks 機能を参照してください。Delta テーブルはストレージ コンテナー内のフォルダーに存在する必要があり、コンテナーのルート ディレクトリに存在することはできません。
デルタ テーブルを入れ子フォルダーに入れることはできません。
各 Delta テーブルは、Delta テーブルのルート フォルダー内の独自のフォルダーに配置できます。 例えば次が挙げられます。
storageaccountcontainer/ DeltaDataRoot/ ADeltaTable/ _delta_log/ 0000.json 0001.json part-0001-snappy.parquet part-0002-snappy.parquet BDeltaTable/ _delta_log/ 0000.json 0001.json part-0001-snappy.parquet part-0002-snappy.parquet
- Customer Insights - Dataは、Deltaテーブルの履歴にあるバージョンプロパティに基づいて、インクリメンタルプロセッシングのための最新の変更を識別します。
Important
既存の Delta Lake データ ソースを保存した後にテーブルを追加することはできません。 テーブルを追加するには、新しいデータソースを作成してください。 保存する前に、テーブルの選択を慎重に計画してください。
Azure Data Lake Storage から Delta データに接続する
データ接続名、データ パス (コンテナー内のフォルダーなど)、およびテーブル名には、文字で始まる名前を使用する必要があります。 名前に含めることができるのは、英字、数字、アンダースコア (_) のみです。 特殊文字はサポートされていません。
データ>データ ソースにアクセスします。
データ ソースの追加を選択します。
Azure Data Lake デルタ テーブル を選択します。
データソース名とオプションの説明を入力します。 下流プロセスは名前を参照し、データソースを作成した後は名前を変更することはできません。
ストレージの接続方法について、次のいずれかを選択します。
- Azure サブスクリプション:サブスクリプション を選択し、リソース グループと ストレージ アカウントを選択します。
- Azure リソース: リソース ID を入力します。
データのフォルダーを含む コンテナーの名前を選択します。
オプションとして、Azure Private Link を介してストレージ アカウントからデータを取り込む場合は、プライベート リンクを有効にするを選択します。 詳しくは、プライべ―ト リンクへアクセスしてください。
Delta テーブルのデータが含まれるフォルダーに移動し、選択します。 さらに [次へ] を選択します。 利用可能なすべてのテーブルの一覧が表示されます。
含めるテーブルを選択します。
主キーが定義されていない選択されたテーブルの場合、主キーの下に必須が表示されます。 各テーブルについて:
- 必須を選択します。 テーブルの編集パネルが表示されます。
- 主キーを選択します。 主キーは、テーブルに固有の属性です。 属性を有効な主キーにするには、重複する値、欠落している値、または null 値を含めないようにする必要があります。 文字列、整数、および GUID データ型属性が主キーとしてサポートされています。
- 閉じる を選択し、パネルを保存して閉じます。
いずれかの列で データ プロファイルを 有効にするには、テーブルの 列 の数を選択します。 属性の管理ページが表示されます。
- テーブル全体または特定の列に対して データ プロファイリング を選択します。 既定では、データ プロファイルが有効になっているテーブルはありません。
- 完了を選択します。
保存を選びます。 データソース ページが開き、新しいデータソースが更新された状態で表示されます。
Tip
ステータスを選択して進行 状況 の詳細ペインを開き、タスクの進行状況を確認できるか、「 ジョブをキャンセル 」を選択してジョブを停止できます。
データの読み込みには時間がかかる場合があります。 更新が正常に完了したら、[ テーブル] ページから取り込まれたデータを確認できます。
一度データソースを保存したら、後からテーブルを追加することはできません。 他のテーブルを追加するには、テーブルを Customer Insights - Data に取り込む別のデータ ソースを作成します。
スキーマ変更の管理
Deltaフォルダのデータソースのスキーマからカラムを追加または削除すると、システムはそのデータの完全なリフレッシュを実行します。 完全更新は、増分更新よりもすべてのデータを処理するのに時間がかかります。
データソース接続を作成後に元のデータのスキーマを変更すると、スキーマの不一致またはデータミスマッチエラーが発生し、データソース接続の更新を求められます。 "ソース データの列が変更されました" というエラーがタスクの詳細に表示されます。 スキーマの変更には、列、列名、列データ型の更新が含まれます。
スキーマが変更されたときにデータ ソースを更新する
データ>データ ソースにアクセスします。 エラーがあるデータ ソースの横にある [編集] を 選択します。 さらに [次へ] を選択します。
エラーがあるテーブルを選択します。
[ 属性の自動生成] を 選択して確定します。
属性の生成が完了したら、[ 完了] を選択します。
テーブルで [含める ] を選択し、[ 保存] を選択して変更を適用し、[ データ ソース ] ページに戻ります。
統一の列を追加する
データソースにカラムを追加すると、リフレッシュが行われると自動的にCustomer Insights - Dataのデータに情報が付加されます。 もしテーブルの統合がすでに設定されている場合は、新しい列を統合プロセスに追加する必要があります。
顧客データ ステップから、テーブルと列の選択 を選択し、新しい列を選択します。
統合データ ビュー ステップで、列が顧客プロファイルから除外されていないことを確認してください。 除外 を選択し、列を読み取ります。
統合プロファイルの更新を実行するステップで、顧客プロファイルと依存関係を統合するを選択します。
列の変更または削除
データソースからカラムを削除すると、システムは他のプロセスの依存関係をチェックします。 カラムに依存関係がある場合、システムはリフレッシュを停止し、 依存関係を削除しなければならないというエラーを出します。 これらの依存関係は通知に表示され、依存関係を見つけて削除するのに役立ちます。
スキーマの変更を検証する
データ ソースの更新後、データ>テーブル ページに移動します。 データ ソースのテーブルを選択し、スキーマを確認します。
Delta Lake のタイム トラベルおよびデータリフレッシュ
デルタレイクのタイムトラベルとは、タイムスタンプやバージョン番号に基づいてテーブルのバージョンをクエリする機能のことです。 Delta フォルダーへの変更はバージョン管理され、Customer Insights - Data は、Delta フォルダーのバージョンを使用して、処理するデータを追跡します。 通常の差分テーブルの更新では、最後の更新以降のすべてのデータ テーブルのバージョンからデータが取得されます。 すべてのバージョンが存在する限り、Customer Insights - Data は変更された要素のみを処理し、より速く結果を提供できます。 タイム トラベルの詳細をご覧ください。
たとえば、Customer Insights – Data が最後に Delta フォルダー データのバージョン 23 と同期した場合、バージョン 23 と、場合によってはそれ以降のバージョンが利用可能であることが期待されます。 必要なデータ バージョンが使用できない場合、データの同期は失敗し、手動によるデータの完全更新が必要です。 Delta フォルダーのデータを削除してから再作成した場合、データの同期が失敗する可能性があります。 または、Customer Insights - Data のバージョン更新に伴い、Delta フォルダーに長期間接続できなかった場合です。
完全なデータ更新を避けるために、15日間などの合理的な履歴バックログを維持してください。
Delta テーブル フォルダーでデータの完全更新を手動で実行する
完全更新は、差分フォーマットのテーブルからすべてのデータを取り出し、差分テーブルのバージョン ゼロ (0) からリロードします。 Delta フォルダー スキーマを変更すると、自動完全更新がトリガーされます。 次の手順を実行して、完全更新を手動でトリガーします。
データ>データ ソースにアクセスします。
Azure Data Lake デルタ テーブル データ ソース を選択します。
更新するテーブルを選択します。 テーブルの編集 ウインドウが表示されます。
1 回限りの完全更新 を選択します。
保存 を選択して更新を実行します。 データ ソース ページが開き、データ ソースが 更新 ステータスになっていますが、選択したテーブルだけが更新されています。
該当する場合は、他のテーブルについてもこの手順を繰り返します。
データ同期の失敗
Delta フォルダーのデータを削除してから再作成した場合、データの同期が失敗する可能性があります。 または、Customer Insights - Data のバージョン更新に伴い、Delta フォルダーに長期間接続できなかった場合です。 断続的なデータパイプライン障害で完全な更新が必要になる場合の影響を最小限に抑えるために、合理的な履歴のバックログを維持してください。
Important
同期エラーを回避するために、少なくとも 15 日間 の差分バージョン履歴を保持します。
delta.logRetentionDurationとdelta.deletedFileRetentionDurationの両方のテーブル プロパティが 15 日以上に設定されていることを確認します。 バージョンの有効期限の最も一般的な原因は、積極的な保持設定で VACUUM を実行することです。
Upsert (増分更新) の動作
Customer Insights - Data では、Delta Lake のタイムトラベル機能によって、増分データの更新がサポートされます。 アップサートを正しく機能させる:
- データは デルタ形式 である必要があります (CSV または Parquet ではありません)。
- Delta テーブルでは 、バージョン履歴 を保持する必要があります (少なくとも 15 日間をお勧めします)。
- 各アップサートは 新しいデルタバージョンを作成しなければなりません。ファイルをその場で上書きすると、増分更新ではなく完全なリフレッシュが発生します。
- 主キー列は、バージョン間で存在し、一貫性がある必要があります。
一般的な問題:
- バージョンを追加する代わりにDeltaファイルを上書きした場合、Customer Insights - Dataはこれをスキーマ変更として扱い、完全なリフレッシュを実行します。
- Deltaバージョンが欠けている場合(例えばクリーンアップやVACUUMによる場合)、データソースの設定から 一度だけフルリフレッシュ を実行します。