Dataflow Gen2 データの格納先とマネージド設定

Dataflow Gen2 を使用してデータをクリーンアップして準備した後は、便利な場所に保存する必要があります。 Dataflow Gen2 では、Azure SQL、Fabric Lakehouse などの複数の宛先から選択できます。 宛先を選択すると、Dataflow Gen2 によってそこにデータが書き込まれます。分析とレポートに使用できます。

次の一覧には、サポートされているデータの転送先が含まれています。

• Azure SQL データベース
• Azure Data Explorer (Kusto)
• Azure Datalake Gen2 (プレビュー)
• ファブリック レイクハウス テーブル
• Fabric Lakehouse Files (プレビュー)
• Fabric Warehouse
• Fabric KQL データベース
• Fabric SQL データベース
• SharePoint ファイル

エントリ ポイント

Dataflow Gen2 内のすべてのデータ クエリには、データの格納先を含めることができます。 表形式のクエリにのみ変換先を適用できます。関数とリストはサポートされていません。 各クエリのデータ変換先を個別に設定でき、同じデータフロー内で異なる変換先を使用できます。

データ変換先を設定するには、次の 3 つの方法があります。

• 上部のリボンを使用します。

  

• クエリ設定を使用します。

  

• ダイアグラム ビューを使用します。

  

データ格納先に接続する

データ変換先への接続は、データ ソースへの接続と同様に機能します。 データ ソースに対する適切なアクセス許可がある限り、データの読み取りと書き込みの両方に接続を使用できます。 新しい接続を作成するか、既存の接続を選択してから、[ 次へ] を選択する必要があります。

ファイルベースの宛先を設定する

ファイルベースの宛先 (SharePoint など) を選択する場合は、いくつかの設定を構成する必要があります。 設定する必要がある内容を次に示します。

• ファイル名: コピー先で作成されるファイルの名前。 既定では、ファイル名はクエリ名と一致します。
• ファイル形式: 変換先で作成されるファイルの形式。
• ファイルの配信元: 宛先でファイルを作成するために使用されるエンコード。 既定では、これは UTF-8 に設定されています。
• ファイル区切り記号: コピー先にファイルを作成するために使用される区切り記号。 既定では、これはコンマに設定 されます。

新しいテーブルを作成するか、既存のテーブルを選択します。

データ変換先に読み込むときは、新しいテーブルを作成するか、既存のテーブルを選択できます。

新しいテーブルの作成

新しいテーブルを作成することを選択すると、Dataflow Gen2 は更新中にデータ変換先に新しいテーブルを作成します。 後でテーブルが削除された場合 (手動で宛先に移動して削除した場合)、次の更新時にデータフローによってテーブルが再作成されます。

既定では、テーブル名はクエリ名と一致します。 テーブル名に変換先でサポートされていない文字がある場合、テーブル名は自動的に調整されます。 たとえば、多くの格納先では、スペースや特殊文字がサポートされていません。

次に、宛先コンテナーを選択する必要があります。 いずれかの Fabric データ変換先を選択した場合は、ナビゲーターを使用して、データを読み込む Fabric 項目を選択できます。 Azure の格納先の場合は、接続の作成時にデータベースを指定するか、ナビゲーターでデータベースを選択できます。

既存のテーブルの使用

既存のテーブルを選択するには、ナビゲーターの上部にあるトグルを使用します。 既存のテーブルを選択する場合は、ナビゲーターを使用して Fabric 項目/データベースとテーブルの両方を選択する必要があります。

既存のテーブルを使用する場合、どのシナリオでもテーブルを再作成することはできません。 データ変換先からテーブルを手動で削除した場合、Dataflow Gen2 は次回の更新時にテーブルを再作成しません。

レイクハウス ファイルまたはテーブル

Lakehouse には、レイクハウスにファイルまたはテーブルを作成するオプションがあります。 これはほかにはない特徴です。ほとんどの目的地は、片方しかサポートしていません。 これにより、レイクハウスでデータを構造化する方法の柔軟性が向上します。

ファイルとテーブルを切り替えるには、レイクハウスを参照するときにトグルを使用できます。

新しいテーブルのマネージド設定

新しいテーブルに読み込むと、既定で自動設定が有効になります。 自動設定を使用すると、Dataflow Gen2 によってマッピングが自動的に管理されます。 自動設定の機能を次に示します。

• Update メソッドの置換: データは、データフローの更新ごとに置き換えられます。 格納先のデータはすべて削除されます。 変換先のデータは、データフローの出力データに置き換えられます。

• マネージド マッピング: マッピングが管理されます。 データ/クエリに変更を加えて別の列を追加したり、データ型を変更したりする必要がある場合、データフローを再発行すると、この変更に対してマッピングが自動的に調整されます。 データフローに変更を加えるたびにデータ変換先エクスペリエンスに移動する必要はありません。これにより、データフローを再発行するときにスキーマの変更が簡単になります。

• テーブルを削除して再作成する: これらのスキーマの変更を許可するために、テーブルは削除され、データフローの更新ごとに再作成されます。 データフローの更新により、以前にテーブルに追加されたリレーションシップまたはメジャーが削除される可能性があります。

手動設定

[ 自動設定を使用する] をオフにすると、データをデータ変換先に読み込む方法を完全に制御できます。 列マッピングを変更するには、ソースの種類を変更するか、データ格納先に不要な列を除外します。

更新方法

ほとんどの格納先では、更新方法として追加と置換の両方がサポートされています。 ただし、Fabric KQL データベースと Azure Data エクスプローラーでは、更新方法としての置換はサポートされていません。

• 置換: すべてのデータフロー更新で、データは宛先から削除され、データフローの出力データに置き換えられます。

• 追加: すべてのデータフロー更新で、データフローからの出力データがデータ変換先テーブルの既存のデータに追加されます。

発行時のスキーマ オプション

発行時のスキーマ オプションは、更新メソッドが 置き換えられる場合にのみ適用されます。 データを追加する場合、スキーマを変更することはできません。

• 動的スキーマ: 動的スキーマを選択した場合、データフローを再発行するときに、データ格納先でスキーマの変更が可能です。 マネージド マッピングを使用していないため、クエリに変更を加えた場合でも、データフロー変換先ウィザードで列マッピングを更新する必要があります。 更新で宛先スキーマと予想されるスキーマの違いが検出されると、テーブルが削除され、想定されるスキーマに合わせて再作成されます。 データフローの更新により、以前にテーブルに追加されたリレーションシップまたはメジャーが削除される可能性があります。

• 固定スキーマ: 固定スキーマを選択した場合、スキーマを変更することはできません。 データフローが更新されると、テーブル内の行のみが削除され、データフローからの出力データに置き換えられます。 テーブル上のリレーションシップやメジャーはいずれも、そのまま残ります。 データフロー内のクエリに変更を加えた場合、クエリ スキーマがデータ格納先スキーマと一致しないことを検出すると、データフローの発行は失敗します。 スキーマを変更する予定がなく、リレーションシップまたはメジャーを宛先テーブルに追加する予定がない場合は、この設定を使用します。

[パラメーター化]

パラメーター は、Dataflow Gen2 内のコア機能です。 パラメーターが作成されるか、[ 常に許可 ] 設定を使用すると、入力ウィジェットを使用して変換先のテーブルまたはファイル名を定義できるようになります。

データ変換先クエリのマッシュアップ スクリプト

データ変換先機能を使用する場合、データを宛先に読み込む設定は、データフローのマッシュアップ ドキュメントで定義されます。 データフロー アプリケーションは、基本的に次の 2 つのコンポーネントを作成します。

• 移動先へのナビゲーション 手順を含むクエリ。 これは、最初のクエリ名のパターンに従い、サフィックス が _DataDestination になります。 例えば次が挙げられます。

shared #"Orders by Region_DataDestination" = let
  Pattern = Lakehouse.Contents([CreateNavigationProperties = false, EnableFolding = false]),
  Navigation_1 = Pattern{[workspaceId = "cfafbeb1-8037-4d0c-896e-a46fb27ff229"]}[Data],
  Navigation_2 = Navigation_1{[lakehouseId = "b218778-e7a5-4d73-8187-f10824047715"]}[Data],
  TableNavigation = Navigation_2{[Id = "Orders by Region", ItemKind = "Table"]}?[Data]?
in
  TableNavigation;

• データを宛先に読み込む方法に使用するロジックを含むクエリの DataDestinations 属性レコード。 レコードには、移動先へのナビゲーション 手順と、更新メソッド、スキーマ オプション、ターゲットの種類 (Table など) などの全体的な宛先設定を含むクエリへのポインターがあります。 例えば次が挙げられます。

[DataDestinations = {[Definition = [Kind = "Reference", QueryName = "Orders by Region_DataDestination", IsNewTarget = true], Settings = [Kind = "Automatic", TypeSettings = [Kind = "Table"]]]}]

これらの M スクリプトは、Dataflow アプリケーション内には表示されませんが、次の方法でこの情報にアクセスできます。

• GET データフロー定義用のファブリック REST API
• Git 統合を使用する場合の Mashup.pq ドキュメント

格納先ごとにサポートされているデータ ソースの種類

通貨やパーセンテージなどのデータ型を使用する場合は、通常、ほとんどの変換先の 10 進数に変換します。 ただし、これらの宛先に再接続し、既存のテーブル パスに従うと、通貨から 10 進列へのマッピングなどの問題が発生する可能性があります。 このような場合は、エディターのデータ型を 10 進数に変更してみてください。これにより、既存のテーブルと列へのマッピングが容易になります。

高度なトピック

格納先に読み込む前にステージングを使用する

クエリ処理のパフォーマンスを向上させるために、Dataflow Gen2 内でステージングを使用して、Fabric コンピューティングを使用してクエリを実行できます。

クエリでステージングが有効になると (既定の動作)、データはステージングの場所に読み込まれます。これは、データフロー自体のみがアクセスできる内部 Lakehouse です。

ステージング場所を使用すると、クエリを SQL 分析エンドポイントに折りたたむ方がメモリ内処理よりも高速な場合に、パフォーマンスが向上する可能性があります。

Lakehouse またはその他の非倉庫の宛先にデータを読み込む場合は、パフォーマンスを向上させるためにステージング機能が既定で無効になります。 データをデータ変換先に読み込むと、ステージングを使用せずにデータがデータ変換先に直接書き込まれます。 クエリにステージングを使用する場合は、もう一度有効にすることができます。

ステージングを有効にするには、クエリを右クリックし、[ステージングを有効にする] ボタンを選択してステージングを有効にします。 その後、クエリが青に変わります。

ウェアハウスにデータを読み込む

ウェアハウスにデータを読み込む場合は、データ格納先への書き込み操作の前にステージングが必要です。 この要件により、パフォーマンスが向上します。 現在、データフローと同じワークスペースへの読み込みのみがサポートされています。 ウェアハウスに読み込まれるすべてのクエリに対してステージングが有効になっていることを確認します。

ステージングが無効になっているときに、出力先にウェアハウスを選択すると、データ格納先を構成する前に、まずステージングを有効にするよう警告が表示されます。

格納先に既にウェアハウスがあり、ステージングを無効にしようとすると、警告が表示されます。 その場合は格納先のウェアハウスを削除するか、ステージング アクションを無視します。

Lakehouse、Warehouse、SQL データベースのスキーマサポート (プレビュー)

Microsoft Fabric の Lakehouse、Warehouse、SQL データベースはすべて、データのスキーマを作成する機能をサポートしています。 つまり、管理とクエリを容易にする方法でデータを構造化できます。 これらの宛先のスキーマに書き込むには、接続を設定するときに、詳細オプションで [完全階層を使用して移動] オプションを有効にする必要があります。 このオプションを有効にしない場合、変換先でスキーマを選択または表示することはできません。 完全階層を使用して Navigate を有効にするためのプレビューの制限は、高速コピーが正しく機能しない可能性があるということです。 この機能をゲートウェイと組み合わせて使用するには、少なくとも 3000.290 バージョンのゲートウェイが必要です。

Lakehouse データの保存先のバキューム

Microsoft Fabric で Dataflow Gen2 の宛先として Lakehouse を使用する場合は、最適なパフォーマンスと効率的なストレージ管理を維持するために定期的なメンテナンスを実行することが重要です。 重要なメンテナンス タスクの 1 つは、データの保存先をバキュームすることです。 このプロセスは、Delta テーブル ログによって参照されなくなった古いファイルを削除するのに役立ちます。これにより、ストレージ コストが最適化され、データの整合性が維持されます。

バキューム処理が重要な理由

1. ストレージの最適化: 時間の経過と共に、Delta テーブルには不要になった古いファイルが蓄積されます。 バキューム処理は、これらのファイルをクリーンアップし、ストレージ領域を解放し、コストを削減するのに役立ちます。
2. パフォーマンスの向上: 不要なファイルを削除すると、読み取り操作時にスキャンする必要があるファイル数が減り、クエリのパフォーマンスが向上します。
3. データ整合性: 関連するファイルのみを保持することで、データ整合性が維持され、閲覧者のエラーやテーブルの破損につながる可能性のある、コミットされていないファイルに関する潜在的な問題を防ぐことができます。

データの保存先をバキュームする方法

Lakehouse で Delta テーブルをバキュームするには、次の手順を実行します。

1. レイクハウスに移動する: Microsoft Fabric アカウントから、目的のレイクハウスに移動します。
2. テーブルのメンテナンスにアクセスする: Lakehouse エクスプローラーで、保守するテーブルを右クリックするか、省略記号を使用してコンテキスト メニューにアクセスします。
3. メンテナンス オプションを選択する: [メンテナンス] メニュー エントリを選択し、[バキューム] オプションを選択します。
4. バキューム コマンドを実行する: 保持しきい値 (既定値は 7 日) を設定し、[今すぐ実行] を選択してバキューム コマンドを実行します。

ベスト プラクティス

• 保持期間: 古いスナップショットとコミットされていないファイルが途中で削除されないようにするために、少なくとも 7 日間のリテンション期間を設定します。これによって、同時テーブル リーダーとライターが中断される可能性があります。
• 定期メンテナンス: データ メンテナンス ルーチンの一部として定期的なバキューム処理をスケジュールし、Delta テーブルを最適化し、分析の準備を整えます。
• 増分更新: 増分更新を使用している場合は、増分更新プロセスに干渉する可能性があるため、バキューム処理がオフになっていることを確認します。

データ メンテナンス戦略にバキュームを組み込むことで、Lakehouse の宛先がデータフロー操作に対して効率的でコスト効率が高く、信頼性が維持されるようにすることができます。

Lakehouse でのテーブル メンテナンスの詳細については、Delta テーブル メンテナンスのドキュメントを参照してください。

NULL 値の使用

null 許容列がある場合、Power Query によって null 非許容として検出される可能性があり、データ格納先に書き込むと、列の種類は null 非許容になります。 更新中に、次のエラーが発生します。

E104100 Couldn't refresh entity because of an issue with the mashup document MashupException.Error: DataFormat.Error: Error in replacing table's content with new data in a version: #{0}., InnerException: We can't insert null data into a non-nullable column., Underlying error: We can't insert null data into a non-nullable column. Details: Reason = DataFormat.Error;Message = We can't insert null data into a non-nullable column.; Message.Format = we can't insert null data into a non-nullable column.

null 許容列を強制するには、次の手順を試してください。

1. データ格納先からテーブルを削除します。

2. データフローからデータ格納先を削除します。

3. 次の Power Query コードを使用して、データフローに移動し、データ型を更新します。

   Table.TransformColumnTypes(
      #"PREVIOUS STEP", {
         {"COLLUMNNAME1", type nullable text}, 
         {"COLLUMNNAME2", type nullable Int64.Type}
      }
   ) 
   

4. データ格納先の追加

データ型の変換とアップスケーリング

場合によっては、データフロー内のデータ型が、データ変換先でサポートされているものと異なります。 データ変換先で引き続きデータを取得できるように、既定の変換をいくつか以下に示します。