次の方法で共有


パラメーター化されたデータフロー Gen2

Fabric Dataflow Gen2 のパラメーターを使用すると、データフローの設計方法を形成する再利用可能な入力を定義できます。 パブリック パラメーター モード では、これらの入力をパイプラインまたは API を介して実行時に設定できます。 単一のデータフローは柔軟性が高く、汎用性が高く、さまざまな値を渡すだけで多くのシナリオで同じロジックを再利用できるため、変換を書き換えたり複製したりする必要なく、動的で自動化されたワークフローを実現できます。

このチュートリアルでは、次の方法を示す例について説明します。

  • ソースのパラメーター化: WideWorldImpoters サンプル データセットをソースとして Lakehouse を使用する
  • パラメーター化ロジック: データフロー エクスペリエンス全体で使用できる入力ウィジェットの使用
  • 宛先のパラメーター化: 宛先としてウェアハウスを使用する
  • パラメーター値を使用して実行要求を送信する: Fabric パイプライン内のデータフロー アクティビティ エクスペリエンスを通じてパラメーター値を渡す

Dataflow Gen2 のパラメーター化されたデータフロー ソリューション アーキテクチャの図。

この記事で紹介する概念は、Dataflow Gen2 に共通であり、ここに示されている以外のソースと宛先にも適用できます。

シナリオ

Dataflow Gen2 内のシナリオのdimension_cityという名前のクエリのスクリーンショット。

このシナリオで使用されるデータフローは単純ですが、説明されているコア 原則はすべての種類のデータフローに適用されます。 これは、Lakehouse に格納されている Wide World Importers サンプル データセットから dimension_city という名前のテーブルに接続します。 SalesTerritory 列が Southeast と等しい行をフィルター処理し、結果を Warehouse の City という新しいテーブルに読み込みます。 すべてのコンポーネント (Lakehouse、Warehouse、Dataflow) は、同じワークスペースに配置されます。 データフローを動的にするには、ソース テーブル、フィルター値、および変換先テーブルをパラメーター化します。 これらの変更により、ハードコーディングされた値ではなく、特定の値でデータフローを実行できます。

先に進む前に、[ ホーム ] タブに移動し、[ オプション] を選択し、[ パラメーター ] セクションで、[パラメーターの検出とオーバーライドを有効にする] というラベルの付いたボックスをオンにして 、実行 中にデータフローがパラメーターを受け入れるようにします。

Dataflow Gen2 のオプション ダイアログのスクリーンショット。[パラメーター] セクションに [Enable to be discovered and overriden for execution]\(検出して実行をオーバーライドできるようにする\) 設定が表示されています。

ソースのパラメーター化

いずれかの Fabric コネクタ (Lakehouse、Warehouse、Fabric SQL など) を使用する場合、それらはすべて同じナビゲーション構造に従い、同じ入力形式を使用します。 このシナリオでは、接続を確立するために手動入力を必要とするコネクタはありません。 ただし、それぞれが、クエリのナビゲーション手順を通じて接続するワークスペースと項目を示します。 たとえば、最初のナビゲーション ステップには、クエリが接続する workspaceId が含まれます。

dimension_city クエリの数式バーに workspaceId 値が表示されたナビゲーション 1 ステップのスクリーンショット。

目的は、数式バーのハードコーディングされた値をパラメーターに置き換することです。 具体的には、 WorkspaceId 用に 1 つのパラメーターを作成し、 LakehouseId 用に別のパラメーターを作成する必要があります。 パラメーターを作成するには、リボンの [ ホーム ] タブに移動し、[ パラメーターの管理] を選択し、ドロップダウン メニューから [ 新しいパラメーター ] を選択します。

新しいパラメーターを作成するための [ホーム] タブのエントリのスクリーンショット。

パラメーターを作成するときは、両方とも 必須 としてマークされ、 テキスト 型に設定されていることを確認します。 現在の値には、特定の環境の対応する値と一致するものを使用します。

[パラメーターの管理] ダイアログ内に作成された LakehouseId パラメーターのスクリーンショット。

両方のパラメーターが作成されたら、ハードコードされた値の代わりに使用するようにクエリ スクリプトを更新できます。 これには、数式バーの元の値をワークスペース ID パラメーターと Lakehouse ID パラメーターへの参照に手動で置き換える必要があります。 元のクエリ スクリプトは次のようになります。

let
  Source = Lakehouse.Contents([]),
  #"Navigation 1" = Source{[workspaceId = "8b325b2b-ad69-4103-93ae-d6880d9f87c6"]}[Data],
  #"Navigation 2" = #"Navigation 1"{[lakehouseId = "2455f240-7345-4c8b-8524-c1abbf107d07"]}[Data],
  #"Navigation 3" = #"Navigation 2"{[Id = "dimension_city", ItemKind = "Table"]}[Data],
  #"Filtered rows" = Table.SelectRows(#"Navigation 3", each ([SalesTerritory] = "Southeast")),
  #"Removed columns" = Table.RemoveColumns(#"Filtered rows", {"ValidFrom", "ValidTo", "LineageKey"})
in
  #"Removed columns"

ナビゲーション手順で参照を更新すると、新しく更新されたスクリプトは次のようになります。

let
  Source = Lakehouse.Contents([]),
  #"Navigation 1" = Source{[workspaceId = WorkspaceId]}[Data],
  #"Navigation 2" = #"Navigation 1"{[lakehouseId = LakehouseId]}[Data],
  #"Navigation 3" = #"Navigation 2"{[Id = "dimension_city", ItemKind = "Table"]}[Data],
  #"Filtered rows" = Table.SelectRows(#"Navigation 3", each ([SalesTerritory] = "Southeast")),
  #"Removed columns" = Table.RemoveColumns(#"Filtered rows", {"ValidFrom", "ValidTo", "LineageKey"})
in
  #"Removed columns"

データフロー エディターでデータ プレビューが正しく評価されていることがわかります。

ロジックのパラメーター化

ソースでパラメーターが使用されたので、データフローの変換ロジックのパラメーター化に重点を置くことができます。 このシナリオでは、フィルター ステップはロジックが適用される場所であり、現在 は南東部としてハードコーディングされているフィルター処理される値をパラメーターに置き換える必要があります。 これを行うには、Territory という名前の新しいパラメーターを作成し、そのデータ型を テキストに設定し、必須ではないとしてマークし、現在の値を Mideast に設定します。

[パラメーターの管理] ダイアログ内に作成された Territory パラメーターのスクリーンショット。

ユーザー インターフェイスを使用してフィルター ステップが作成された場合は、[フィルター処理された行] ステップに移動し、それをダブル選択して、フィルター ステップの設定ダイアログを取得できます。 このダイアログでは、静的な値の代わりにパラメーターを使用する場合は、入力ウィジェットを使用して選択できます。

パラメーターを参照するオプションを含むフィルター行ダイアログの入力ウィジェットのスクリーンショット。

[ パラメーターの選択] オプションを選択すると、ドロップダウンが表示され、必要なデータ型に一致するすべての使用可能なパラメーターが表示されます。 この一覧から、新しく作成された Territory パラメーターを選択できます。

フィルター行ダイアログの入力ウィジェット内で選択された Territory パラメーターのスクリーンショット。

[OK] を選択すると、ダイアグラム ビューによって、新しく作成されたパラメーターと使用中のクエリの間のリンクが既に作成されていることに注意してください。 それだけでなく、データ プレビューに 中東 地域の情報が表示されるようになりました。

Mideast SalesTerritory のデータを示すdimension_city クエリのダイアグラム ビュー、クエリ設定、およびデータ プレビューのスクリーンショット。

変換先をパラメーター化する

Dataflow Gen2 のデータ変換先の概念と、データ変換先と管理設定に関する記事からマッシュアップ スクリプトがどのように作成されるかを理解することをお勧めします。

このシナリオでパラメーター化する最後のコンポーネントは、変換先です。 データフロー エディターでデータ変換先の情報を確認できますが、データフローのこの部分をパラメーター化するには、Git または REST API を使用する必要があります。

dimension_city クエリのデータ変換先の設定を含むポップアップのスクリーンショット。

このチュートリアルでは、Git を使用して変更を行う方法について説明します。 git を使用して変更を行う前に、次のことを確認してください。

  • WarehouseId という名前のパラメーターを作成します。ウェアハウスの対応する ID を現在の値として使用し、必要に応じてテキスト データ型に設定してください。
  • データフローを保存する: リボンの [ホーム] タブにある [保存] ボタンを使用します。

[データフローの保存] ボタンのスクリーンショット。

データフローが保存されたら、Git リポジトリに変更をコミットし、リポジトリに移動して、データフローの mashup.pq ファイルを確認してください。 mashup.pq ファイルを確認するときは、データの送信先を関連付けたクエリを探します。 このシナリオでは、そのクエリの名前がdimension_city。 このクエリ名の上にレコード属性が表示されます。

[DataDestinations = {[Definition = [Kind = "Reference", QueryName = "dimension_city_DataDestination", IsNewTarget = true], Settings = [Kind = "Manual", AllowCreation = true, ColumnSettings = [Mappings = {[SourceColumnName = "CityKey", DestinationColumnName = "CityKey"], [SourceColumnName = "WWICityID", DestinationColumnName = "WWICityID"], [SourceColumnName = "City", DestinationColumnName = "City"], [SourceColumnName = "StateProvince", DestinationColumnName = "StateProvince"], [SourceColumnName = "Country", DestinationColumnName = "Country"], [SourceColumnName = "Continent", DestinationColumnName = "Continent"], [SourceColumnName = "SalesTerritory", DestinationColumnName = "SalesTerritory"], [SourceColumnName = "Region", DestinationColumnName = "Region"], [SourceColumnName = "Subregion", DestinationColumnName = "Subregion"], [SourceColumnName = "Location", DestinationColumnName = "Location"], [SourceColumnName = "LatestRecordedPopulation", DestinationColumnName = "LatestRecordedPopulation"]}], DynamicSchema = false, UpdateMethod = [Kind = "Replace"], TypeSettings = [Kind = "Table"]]]}]
shared dimension_city = let

この属性レコードには、QueryName という名前のフィールドがあります。このフィールドには、このクエリに関連付けられているすべてのデータ変換先ロジックを含むクエリの名前が保持されます。 このクエリは次のようになります。

shared dimension_city_DataDestination = let
  Pattern = Fabric.Warehouse([HierarchicalNavigation = null, CreateNavigationProperties = false]),
  Navigation_1 = Pattern{[workspaceId = "8b325b2b-ad69-4103-93ae-d6880d9f87c6"]}[Data],
  Navigation_2 = Navigation_1{[warehouseId = "527ba9c1-4077-433f-a491-9ef370e9230a"]}[Data],
  TableNavigation = Navigation_2{[Item = "City", Schema = "dbo"]}?[Data]?
in
  TableNavigation

Lakehouse のソースのスクリプトと同様に、宛先のこのスクリプトにも、使用する必要がある workspaceid と warehouseId をハードコーディングするパターンが似ていることがわかります。 これらの固定値をパラメーターの識別子に置き換えます。スクリプトは次のようになります。

shared dimension_city_DataDestination = let
  Pattern = Fabric.Warehouse([HierarchicalNavigation = null, CreateNavigationProperties = false]),
  Navigation_1 = Pattern{[workspaceId = WorkspaceId]}[Data],
  Navigation_2 = Navigation_1{[warehouseId = WarehouseId]}[Data],
  TableNavigation = Navigation_2{[Item = "City", Schema = "dbo"]}?[Data]?
in
  TableNavigation

これで、この変更をコミットし、ワークスペースのソース管理機能を通じてデータフローからの変更を使用してデータフローを更新できるようになりました。 データフローを開き、データ変換先と、追加された以前のパラメーター参照を確認することで、すべての変更が行われているかどうかを確認できます。 これにより、データフローのすべてのパラメーター化が完了し、実行用のパラメーター値を渡すことで、データフローの実行に進むことができます。

パラメーター値を使用して要求を実行する

Fabric REST API を使用して、その特定の実行操作のパラメーター値を含むカスタム ペイロードを含む実行要求を送信できます。また、REST API を使用してデータフロー パラメーターを検出し、データフローが期待する内容を理解して、実行をトリガーすることもできます。 このチュートリアルでは、Fabric パイプラインのデータフロー アクティビティ内にあるエクスペリエンスを使用します。 まず、パイプラインを作成し、キャンバスに新しい データフロー アクティビティ を追加します。 アクティビティの設定で、データフローが配置されているワークスペースを見つけて、ドロップダウンから [データフロー] を選択します。

パイプライン内のパラメーターを含むデータフロー アクティビティのスクリーンショット。

[データフロー パラメーター] セクションを展開すると、データフローで使用可能なすべてのパラメーターとその既定値を表示できます。 ここでは、任意の値を置き換えることができます。渡された値は、データフローの実行を評価するために使用するソース、ロジック、および変換先を定義するために使用されます。 新しい Warehouse を作成し、評価のために WarehouseId を変更するか、対応する環境内の正しい項目を指すように WorkspaceId やその他のパラメーターを渡す必要があるデプロイ パイプラインでこのパターンを使用して、新しいシナリオを試すこともできます。