マッピング データ フローでの行の変更変換

適用対象: Azure Data Factory Azure Synapse Analytics

ヒント

企業向けのオールインワン分析ソリューション、Microsoft Fabric の Data Factory をお試しください。 Microsoft Fabric は、データ移動からデータ サイエンス、リアルタイム分析、ビジネス インテリジェンス、レポートまで、あらゆるものをカバーしています。 無料で新しい試用版を開始する方法について説明します。

データ フローは、Azure Data Factory および Azure Synapse Pipelines の両方で使用できます。 この記事は、マッピング データ フローに適用されます。 変換を初めて使用する場合は、概要の記事「マッピング データ フローを使用してデータを変換する」を参照してください。

行の変更変換を使用して、行の挿入、削除、更新、アップサート ポリシーを設定します。 一対多の条件を式として追加できます。 各行は一致する最初の式に対応したポリシーでマークされるので、これらの条件は優先度の順に指定する必要があります。 これらの条件によってそれぞれ、行が挿入、更新、削除、アップサートされます。 行の変更では、ご利用のデータベースに対して DDL と DML の両方を生成できます。

行の変更変換は、自分のデータ フローのデータベース、REST、または Azure Cosmos DB シンクでのみ動作します。 行に割り当てるアクション (挿入、更新、削除、upsert) は、デバッグ セッション中に発生することはありません。 データ フローの実行アクティビティをパイプラインで実行し、データベース テーブルに行の変更ポリシーを適用します。

注意

行の変更変換は、SQL Server や SAP などのネイティブ CDC ソースを使う変更データ キャプチャ データ フローには必要ありません。 それらのインスタンスでは、ADF によって行マーカーが自動的に検出されるため、行の変更ポリシーは必要ありません。

既定の行ポリシーを指定する

行の変更変換を作成し、true() の条件を持つ行ポリシーを指定します。 以前に定義された式のいずれにも一致しない行はそれぞれ、指定された行ポリシー用にマークされます。 既定では、どの条件式にも一致しない行はそれぞれ、Insert 用にマークされます。

Note

すべての行を 1 つのポリシーでマークするには、そのポリシーの条件を作成し、条件を true() として指定します。

データのプレビューでポリシーを表示する

デバッグ モードを使用して、[データのプレビュー] ペインで行の変更ポリシーの結果を表示します。 行の変更変換のデータのプレビューでは、ターゲットに対する DDL または DML アクションは生成されません。

挿入、更新、upsert、または削除アクションが発生するかどうかを示すアイコンによって、それぞれの行の変更ポリシーが表されます。 上部ヘッダーは、プレビューの各ポリシーによって影響を受ける行数を示しています。

シンクで行の変更ポリシーを許可する

行の変更ポリシーを機能させるには、データ ストリームがデータベースまたは Azure Cosmos DB シンクに書き込む必要があります。 シンクの [設定] タブで、そのシンクで許可する行の変更ポリシーを有効にします。

既定の動作では、挿入のみが許可されます。 更新、upsert、または削除を許可するには、その条件に対応する、シンクのチェックボックスをオンにします。 更新、upsert、または削除が有効になっている場合は、シンク内のどのキー列を照合するかを指定する必要があります。

Note

挿入、更新、または upsert によりシンクのターゲット テーブルのスキーマが変更される場合、データ フローは失敗します。 データベース内のターゲット スキーマを変更するには、テーブル アクションとして [Recreate table](テーブルの再作成) を選択します。 これにより、新しいスキーマ定義でご利用のテーブルがドロップされ、再作成されます。

シンク変換では、一意の行 ID を表す 1 つのキーまたは一連のキーがターゲット データベースに必要です。 SQL シンクの場合、キーの設定は、シンク設定タブで行います。Azure CosmosDB の場合は、それらの設定にパーティション キーを設定したうえで、Azure CosmosDB のシステム フィールド "id" をシンクのマッピングで設定します。 Azure CosmosDB で update、upsert、delete を行う場合は、システム列である "id" を含める必要があります。

Azure SQL Database と Azure Synapse を使用したマージと upsert

データ フローでは、upsert オプションを使用した Azure SQL Database と Azure Synapse データベース プール (データ ウェアハウス) に対するマージがサポートされています。

しかし、ターゲット データベース スキーマでキー列の ID プロパティが使用されているシナリオが発生する場合があります。 サービスでは、更新と upsert の行の値を一致させるために使用するキーを識別する必要があります。 しかし、ターゲット列に ID プロパティが設定されていて、upsert ポリシーを使用している場合、ターゲット データベースでは列への書き込みが許可されません。 分散テーブルのディストリビューション列に対して upsert を実行しようとすると、エラーが発生する場合もあります。

これを修正する方法を次に示します。

1. シンク変換の設定に移動し、"キー列の書き込みのスキップ" を設定します。 これにより、マッピングのキー値として選択された列を書き込まないようにサービスに通知します。

2. このキー列が ID 列の問題の原因となっている列でない場合は、シンク変換の前処理の SQL オプション SET IDENTITY_INSERT tbl_content ON を使用できます。 次に、後処理の SQL プロパティ SET IDENTITY_INSERT tbl_content OFF を指定してこれをオフにします。

3. ID ケースとディストリビューション列ケースの両方について、条件分割変換を使用して別の更新条件と別の挿入条件を使用する Upsert からロジックを切り替えることができます。 この方法では、更新パスにマッピングを設定して、キー列のマッピングを無視できます。

データ フローのスクリプト

構文

<incomingStream>
    alterRow(
           insertIf(<condition>?),
           updateIf(<condition>?),
           deleteIf(<condition>?),
           upsertIf(<condition>?),
        ) ~> <alterRowTransformationName>

例

以下の例は、受信ストリーム SpecifyUpsertConditions を受け取り、行の変更条件を 3 つ作成する、CleanData という行の変更変換です。 前の変換では、データベース内で行の挿入、更新、削除を実行するかどうかを決定する alterRowCondition という列が計算されます。 列の値に、行の変更ルールと一致する文字列値が含まれている場合、そのポリシーが割り当てられています。

UI では、この変換は次の図のようになります。

この変換のデータ フロー スクリプトは、次のスニペットに含まれています。

SpecifyUpsertConditions alterRow(insertIf(alterRowCondition == 'insert'),
	updateIf(alterRowCondition == 'update'),
	deleteIf(alterRowCondition == 'delete')) ~> AlterRow

関連するコンテンツ

行の変更変換の後に、自分のデータと配布先データ ストアをシンクする必要がある場合があります。