Dataflow Gen2 で最高のパフォーマンスを得るためのベスト プラクティス

この記事では、Fabric Data Factory の Dataflow Gen2 のパフォーマンスを最適化するためのベスト プラクティスについて説明します。 これらのガイドラインに従うことで、データ統合プロセスの効率と速度を向上させることができます。

学習内容

この記事では、次の項目について説明します。

• 主要なパフォーマンス最適化領域: データフローのパフォーマンスに影響を与える 3 つの重要なコンポーネント (データ ソース、データフロー エンジン、およびデータ変換先) について
• コア最適化手法: 高速コピー、クエリ フォールディング、ステージングを活用して効率を最大化する方法
• 実際のシナリオ: 一般的なパフォーマンスの課題とその特定のソリューション
• ベスト プラクティス: さまざまなデータ統合パターンとユース ケースに対する実用的なガイダンス

パフォーマンスの最適化に重点を置く重要な領域は何ですか?

データフローのエンド ツー エンド エクスペリエンス内には、パフォーマンスの最適化に重点を置くいくつかの重要な領域があります。 これらの領域には、データ移動、データフロー エンジン、およびデータ変換が含まれます。 これらの各コンポーネントとその間のパスは、データフローの全体的なパフォーマンスに重要な役割を果たし、最適化することで、実行時間とリソース使用率が大幅に向上する可能性があります。

データの移動

データ移動は、データフローパフォーマンスの重要な側面です。 これには、データ ソース、ステージング領域、最終変換先など、さまざまなコンポーネント間でのデータの転送が含まれます。 効率的なデータ移動により、実行時間とリソースの消費量を大幅に削減できます。 Dataflow Gen2 では、データ移動は高速コピーなどの手法によって最適化されます。これにより、ソース システムにフォールドされない変換のオーバーヘッドなしで、高スループットのデータ転送が可能になります。 高速コピーの詳細を確認します。

データ変換

データ変換は、ある構造から別の構造にデータを変換するプロセスであり、多くの場合、フィルター処理、集計、結合などの操作が含まれます。 Dataflow Gen2 では、変換は効率的であり、可能な限りクエリ フォールディング機能を適用するように設計されています。 クエリ フォールディングを使用すると、変換をソース システムにプッシュダウンして、Dataflow Gen2 で転送および処理されるデータの量を減らすことができます。 この削減は、データフロー エンジンのワークロードを最小限に抑え、実行時間を短縮するため、大規模なデータセットでは特に重要です。 クエリフォールディングの詳細については、「クエリ フォールディング」を参照してください。 また、クエリの最適化に関するその他のベスト プラクティス (早期および頻繁のフィルター処理、パラメーター化を使用したデータ プレビューの制限、データフローでの不要な変換の回避など) にも従います。 クエリの最適化の詳細については、「クエリの 最適化」を参照してください。

ステージングデータとウェアハウスコンピュート

ステージング データは、中間結果をステージング領域に一時的に格納することでパフォーマンスを向上させるために使用される手法です。 Dataflow Gen2 には、ステージング Lakehouse とステージング ウェアハウスが付属しています。これは、変換をより効率的に実行するために使用できます。 データをステージングすることで、これらのステージング領域のコンピューティング リソースを使用して、複雑なデータフローを管理可能な手順に分割し、全体的な処理時間を短縮できます。 この分割は、大規模なデータセットや複雑な変換に特に役立ちます。そうしないと、1 つのステップで実行するのに長い時間がかかります。 ステージング場所は、変換を折りたたむことができる一時的な記憶域と考えることができます。 この方法は、クエリ フォールディングをサポートしていないデータ ソースを操作する場合や、変換が複雑すぎてソース システムにプッシュダウンできない場合に特に便利です。 ステージングを効果的に適用するには、データフロー エディターの折りたたみインジケーターに注目して、変換がソースにプッシュダウンされていることを確認できます。 変換が折りたたまれていないことに気付いた場合は、クエリを 2 つのクエリに分割し、2 番目のクエリに変換を適用することを検討してください。 初回のクエリでステージングを有効化し、ステージングのための Lakehouse または Warehouse コンピューティングを使用して変換を実行します。 このアプローチを使用すると、ステージング領域で利用できるコンピューティング リソースを活用しながら、データフローを効率的かつ応答性の高い状態に保ちます。

既に Lakehouse または Warehouse でステージングされているデータがあり、次のクエリで完全にフォールドする変換を適用すると、データフローによって出力がステージング ウェアハウスに書き込まれます。 これは、データセットを DW によって並列に書き込むことができるため、ステージング Lakehouse への書き込みよりも高速になる可能性があり、対応するシリアル化手順を使用してネットワーク ホップが少なくなります。

シナリオと考慮すべき最適化

Dataflow Gen2 を使用する場合は、発生する可能性があるさまざまなシナリオと、それぞれのケースでパフォーマンスを最適化する方法を理解することが不可欠です。 次の考慮事項は、ベスト プラクティスを実際の状況に適用する方法に関する実用的なガイダンスを提供します。 データと変換の特定の特性に基づいてアプローチを調整することで、データ統合ワークフローで最適なパフォーマンスを実現できます。 Dataflow Gen2 を使用するときに発生する可能性のある一般的なシナリオと、パフォーマンスを最適化するための推奨されるアクションを次に示します。 パフォーマンスの最適化は進行中のプロセスであり、シナリオに非常に固有であることに注意してください。 独自のデータと変換の特定の特性に基づいてアプローチを調整する必要がある場合があります。

考慮事項 1: 高速コピーによるデータ移動の改善

このシナリオでは、データ ソースとステージング領域間、または最終的な宛先へのデータ移動に予想以上に時間がかかっていることがわかります。 ネットワーク待機時間、大規模なデータセット サイズ、非効率的なデータ転送方法など、いくつかの要因が関係する可能性があります。

この場合は、データ移動パスを評価し、パフォーマンスを向上させるために最適化することを検討してください。 1 つの方法は、高速コピーを使用して高スループットのデータ転送を行い、実行時間を大幅に短縮できることです。 高速コピーは、大量のデータを効率的に処理するように設計されており、従来のデータ転送方法に関連するオーバーヘッドを最小限に抑えます。 ただし、高速コピー操作と同じクエリに変換を追加する場合は、変換がソース システムにフォールドされない場合、高速コピーを無効にできます。 このような場合は、クエリを 2 つの手順に分割することを検討してください。1 つは高速コピー操作用、もう 1 つはステージング Lakehouse または Warehouse コンピューティングを使用した変換です。 この方法では、高速コピーを利用して、別の手順で必要な変換を実行しながら、高スループットのデータ移動を実現できます。 高速コピーの詳細を確認します。

データフロー設定で高速コピーを有効にすることができます。 この設定は既定で有効になっていますが、データフロー内の特定のクエリに高速コピーを使用するように要求することもできます。 これを行うには、クエリ設定で [高速コピーが必要 ] オプションを選択します。 このアクションにより、選択したクエリに高速コピーが使用され、高速コピーの最小サイズしきい値が無視されます。 この設定は、データ サイズやその他の条件に関係なく、特定のクエリに高速コピーを確実に使用する場合に特に便利です。 高速コピーが必要な場合は、データ ソースが高速コピーと互換性があり、クエリ内の変換をソース システムにプッシュダウンできることを確認します。 高速コピーと互換性のないクエリで高速コピーが必要な場合、データフローは失敗します。 高速コピーを必要としない場合でも、データフローは実行されますが、既定のデータ移動方法にフォールバックする可能性があります。高速コピーほど効率的ではない可能性があります。 この柔軟性により、データ統合プロセスの特定の要件に基づいてデータフローを最適化できます。

考慮事項 2: ステージングを使用して複雑な変換の実行時間を短縮する

このシナリオでは、結合、集計、フィルター処理など、複数の複雑な変換を含むデータフローがあります。 実行時間が必要以上に長く、これらの変換のパフォーマンスを最適化する必要があります。

この場合は、データフローをより小さく管理しやすい手順に分割することを検討してください。 すべての変換を 1 つのクエリで実行する代わりに、ステージング Lakehouse または Warehouse でデータをステージングしてから、後続のクエリに変換を適用できます。 この方法では、複雑な変換にステージング領域のコンピューティング リソースを適用できるため、全体的な実行時間を短縮できます。 さらに、変換は可能な限りソース システムにフォールドするように設計されていることを確認します。これにより、Dataflow Gen2 で転送および処理されるデータの量を減らすことでパフォーマンスが大幅に向上します。 特定の変換がフォールドされない場合は、それらを個別のクエリに分割し、データをステージングした後に適用することを検討してください。

次の図では、データフロー エディターの折りたたみインジケーターが、ソース システムにプッシュダウンされている変換を識別するのにどのように役立つかを確認します。

ステージングを効果的に実装するには、データフローを 2 つのクエリに分割します。 これを行うには、ソース システムにフォールドしない最初の手順を右クリックし、[ 前 の抽出] オプションを選択します。 このアクションにより、ステージング Lakehouse または Warehouse コンピューティングでデータをステージングする新しいクエリが作成され、別の手順で変換を実行できます。 この方法を使用すると、ステージング領域で使用できるコンピューティング リソースを活用しながら、データフローの効率と応答性を維持できます。

次に、新しいクエリの名前を指定し、[OK] を選択します。

新しいクエリが作成されたので、最初のクエリでステージングが有効になっているかどうかを確認できます。 ステージングが有効になっていない場合は、クエリ設定で [ ステージングを有効にする] オプションを選択して有効にすることができます。 このアクションを使用すると、ステージング Lakehouse または Warehouse コンピューティングで変換を実行し、データフローのパフォーマンスを最適化できます。 2 番目のクエリのステージングは省略可能ですが、最終的な出力を変換先に書き込む前にステージング領域で追加の変換を実行できるようにすることで、パフォーマンスをさらに向上させることができます。

データフロー エディターで折りたたみインジケーターを確認すると、最初のクエリの変換がソース システムにプッシュダウンされます。 2 番目のクエリは、実行時にのみステージング領域とその領域にプッシュダウンできる変換を認識するため、同じフォールディングインジケーターを反映されない可能性があります。

データフロー変換を最適化し、それらがソース システムにプッシュダウンされていることを確認する方法の詳細については、「 クエリ フォールディング」を参照してください。

考慮事項 3: Lakehouse を宛先として使用する場合のデータ移動に対するステージングへの影響

このシナリオでは、データフローに Lakehouse 変換先を使用しており、最終出力を書き込む前に変換を実行するステージングを有効にしています。 ただし、全体的な更新時間が予想よりも長くなっていることに気付き、このプロセスのパフォーマンスを最適化する必要があります。

この場合、ステージング ウェアハウスから Lakehouse 宛先へのデータ移動がボトルネックになる可能性があります。 パフォーマンスを向上させるには、Lakehouse ではなく Warehouse に宛先を変更することを検討してください。 この変更により、変換にステージング ウェアハウスのコンピューティング リソースを使用し、最終的な出力を Warehouse 変換先に直接書き込むことができます。 データ移動のパスは、Lakehouse への書き込みの追加オーバーヘッドを回避するため、より効率的になります。 Lakehouse デスティネーションが必要な場合は、Lakehouse に書き込むクエリのステージングを無効にすることを検討してください。 このアクションを使用すると、ステージングのオーバーヘッドを増やすことなく、最終的な出力を Lakehouse に直接書き込むことができます。これにより、パフォーマンスが大幅に向上します。 ただし、ステージングを無効にすると、ステージング領域で変換を実行できなくなるため、変換が可能な限りソース システムにフォールドするように設計されていることを確認してください。 このシナリオでは、データ移動パスを理解し、パフォーマンスを向上させるために最適化することの重要性を強調しています。 ステージングが無効になっている Lakehouse の宛先と比較して、Warehouse の宛先を使用する場合の実行時間の違いを確認します。 宛先とステージングのオプションを慎重に検討することで、データフローの効率を高め、全体的な更新時間を短縮できます。

考慮事項 4: 設計時の大規模なデータ プレビュー

このシナリオでは、大規模なデータセットを含むデータフローに取り組んでおり、データ プレビューのサイズが原因でデザイン時のエクスペリエンスが遅くなります。 このプロセスにより、データフローを効果的に作成してテストすることが困難になる場合があります。

この場合は、スキーマ ビューまたはパラメーター化を使用して、データ プレビューのサイズを制限することを検討してください。 日付範囲や特定の ID などのパラメーターに基づいてフィルターを適用することで、デザイン時環境に表示されるデータの量を減らすことができます。 このアプローチは、設計環境の応答性と効率性を維持するのに役立ちます。これにより、大規模なデータ プレビューによって妨げられることなく、データフローの作成とテストに集中できます。 さらに、実行時にパラメーターを調整して、必要に応じて完全なデータセットを取得できます。

たとえば、大規模なトランザクション データセットを使用している場合は、特定の日付範囲に基づいてデータをフィルター処理するパラメーターを作成できます。 これにより、デザイン時には、現在の作業に関連するデータのサブセットのみが表示されます。 データフローを実行する準備ができたら、パラメーターを調整して完全なデータセットを含め、データ統合プロセスの効率と応答性を維持できます。 次の例は、Dataflow Gen2 でパラメーターを設定する方法を示しています。

1. データフロー エディターで [ パラメーターの管理 ] オプションを選択します。

2. [ パラメーターの追加] ボタンを選択して、新しいパラメーターを追加します。

   

3. 名前、型、値などのパラメーターの詳細を入力します。 たとえば、データ プレビューを特定の日付範囲に制限する既定値を使用して、型の DateTime という名前のパラメーターを作成できます。

   

4. フィルター条件で使用して、データフロー クエリにパラメーターを適用します。 たとえば、 DesignDateFilter パラメーターに基づいてデータをフィルター処理して、データ プレビューを特定の日付範囲に制限できます。 この場合、データをフィルター処理して、"Date" 列が DesignDateFilter パラメーターより大きいレコードのみを含めます。

   

5. これで、データフロー クエリで DesignDateFilter パラメーターを使用して、デザイン時のデータ プレビューを制限できるようになりました。 データフローを実行する準備ができたら、パラメーター値を調整して完全なデータセットを含め、データ統合プロセスの効率と応答性を維持できます。

   

もう 1 つのオプションは、スキーマ ビューを使用することです。これにより、データセット全体を読み込まずにデータの構造を確認できます。 このビューでは、データセット内のデータ型と列の概要を示します。これにより、大規模なデータ プレビューの影響を受けることなく、データフローを設計およびテストできます。 スキーマ ビューに切り替えるには、データフロー エディターで [スキーマ ビュー ] オプションを選択します。

考慮事項 5: Dataflow Gen2 ランタイム特性と Dataflow Gen1 の比較

このシナリオでは、Dataflow Gen2 のパフォーマンスが、特に実行時間とリソース使用量の点で、Dataflow Gen1 のパフォーマンスよりも遅くなっていることがわかります。 このパフォーマンスの違いは、最適化手法や Dataflow Gen2 で使用される出力形式の違いなど、いくつかの要因が原因である可能性があります。

Dataflow Gen2 は、ステージング宛先または Lakehouse 宛先を使用する場合に Delta Parquet 形式でデータを出力します。これにより、Dataflow Gen1 の CSV 出力とは異なります。 Delta Parquet では CSV と比較して ETL ランタイムが長くなる可能性がありますが、Direct Lake、Lakehouses、Warehouse などの強力なダウンストリーム機能が可能になり、これらのサービスは追加の処理やコストなしで効率的にデータを使用できます。 このストレージ方法の違いは、最初の実行時間が長くなる可能性がある一方で、ダウンストリーム プロセスの全体的なパフォーマンスと効率を大幅に向上させ、データ統合ワークフローの長期的なパフォーマンスを向上させる可能性があることを意味します。 Delta Parquet 形式の詳細を確認します。

考慮事項 6: 増分更新を使用した大規模なトランザクション データセットの更新時間の最適化

このシナリオでは、頻繁に更新される大規模なトランザクション データセットを処理しており、データフローの更新時間を最適化する必要があります。 この最適化は、データの量と、新しいレコードまたは変更されたレコードのみを処理する必要があるため、困難な場合があります。

この場合は、増分更新またはパターンを使用してデータを増分的に蓄積することを検討してください。 増分更新を使用すると、前回の更新以降に新しいデータまたは変更されたデータのみを処理できるため、処理されるデータの量が減り、全体的な実行時間が短縮されます。 この方法は、トランザクション システムなど、データが頻繁に更新されるシナリオに特に役立ちます。 増分更新を実装することで、データフローのパフォーマンスを最適化し、データ統合プロセスの効率と応答性を維持できます。 増分更新の詳細を確認するか、増分データ の蓄積パターンについて学習します。

考慮事項 7: ゲートウェイを使用してオンプレミスのデータ ソースに接続しており、データフローのパフォーマンスを最適化したい

このシナリオでは、ゲートウェイを使用してオンプレミスのデータ ソースに接続し、データフローのパフォーマンスを最適化する必要があります。 ゲートウェイによって待機時間とオーバーヘッドが増える可能性があり、データフローの全体的なパフォーマンスに影響を与える可能性があります。

この場合は、データフローを 2 つの異なるデータフローに分割することを検討してください。1 つはオンプレミスのデータ ソースからデータ変換先 (Lakehouse や Warehouse など) へのデータ移動用、もう 1 つは変換と最終的な出力用です。 このアプローチを使用すると、高速コピーを利用して高スループットのデータ転送を行い、変換手順はデータの効率的な処理と全体的な実行時間の短縮に集中しながら、データ移動ステップを最適化できます。 データ移動と変換の手順を分離することで、ゲートウェイの待機時間と容量の制限の影響を軽減できます。 その理由は、ゲートウェイがデータフロー全体を実行しているためです。データフローが複雑な場合や変換が多い場合は、ゲートウェイがゲートウェイをホストしているコンピューター上のすべての変換を処理するため、パフォーマンスが低下する可能性があります。 データフローを分割することで、ゲートウェイがデータ移動ステップのみを担当するようにすることができます。これにより、パフォーマンスが大幅に向上し、実行時間が短縮されます。

考慮事項 8: データフロー コネクタを使用してデータフローのデータを使用し、データ統合プロセスを最適化する

このシナリオでは、データフロー コネクタを使用してデータフローのデータを使用し、データ統合プロセスを最適化します。 データフロー コネクタは、データにアクセスして使用する便利な方法を提供できます。

この場合は、データフローからデータを使用するために、データフロー コネクタの代わりにデータ宛先の使用を考慮することをお勧めします。 Lakehouses や Warehouse などのデータ変換先は、データを効率的に格納して提供するように設計されており、ダウンストリームで使用するためにそれらの機能を適用できます。 データ変換先を使用する主な利点は、多くの場合、SQL エンドポイントなどのデータに接続する一般的な方法を提供したり、Direct Lake 機能を使用したりすることで、パフォーマンスを大幅に向上させ、リソース消費量を削減できることです。

考慮事項 9: クエリ実行のパフォーマンスを向上させるためにモダン エバリュエーターを有効にする

このシナリオでは、特に複雑な変換やクエリ フォールディングをサポートしていないコネクタを使用する場合に、データフローの全体的なパフォーマンスを向上させる必要があります。

この場合は、CI/CD を使用して Dataflow Gen2 のモダン クエリ評価エンジン (モダン エバリュエーター) を有効にすることを検討してください。 モダン エバリュエーターは、データフロー実行のパフォーマンスを大幅に向上させることができる、.NET Core 8 で実行される新しいクエリ実行エンジンです。 サポートされているシナリオでは、次のような重要な利点があるため、常にこの機能を有効にすることをお勧めします。

• データフローの実行の高速化: 最新のエンジンにより、クエリの評価時間を大幅に短縮できます。 多くのデータフローは非常に高速に実行されるため、データをより頻繁に更新したり、タイトな更新ウィンドウを満たしたりできるようになります。
• より効率的な処理:エンジンは、改良されたアルゴリズムと最新のランタイムを使用して、効率のために最適化されています。 つまり、オーバーヘッドが少なく複雑な変換を処理できるため、データ 量の増加に合わせてパフォーマンスを維持できます。
• スケーラビリティと信頼性: 実行を高速化し、ボトルネックを減らすことで、最新のエバリュエーターは、データフローをより大きなボリュームに拡張し、安定性を高めます。 大規模なデータフローでは、一貫性のある更新期間が長くなり、タイムアウトの問題が少なくなります。

モダン エバリュエーターは、次のような場合に特に役立ちます。

• 折り畳み不可能な、または部分的に折り畳み可能なコネクタを使用している
• フィルター、列の派生、またはデータ クレンジング操作を適用している
• 大量のデータまたは複雑な変換を処理している
• データフローは 1 日に複数回実行されるため、時間の節約を蓄積する必要があります

Modern エバリュエーターを有効にするには:

1. Power Query エディターでデータフローを開きます。
2. メニューから [オプション] を 選択します。
3. [ スケール ] タブに移動します。
4. モダン クエリ評価エンジン オプションをオンにします。
5. データフローを保存して実行します。

モダン エバリュエーターは、増え続けるコネクタの一覧をサポートしています。 サポートされているコネクタと現在の機能の状態の完全な一覧については、「 CI/CD を使用した Dataflow Gen2 のモダン エバリュエーター」を参照してください。 サポートされている一覧にないコネクタがデータフローで使用されている場合、これらのクエリは引き続き標準エンジンで実行されます。

モダン エバリュエーターの詳細については、「 CI/CD を使用した Dataflow Gen2 のモダン エバリュエーター」を参照してください。

Conclusion

これらのベスト プラクティスに従い、データと変換の特定の特性を考慮することで、Fabric Data Factory の Dataflow Gen2 のパフォーマンスを最適化できます。 大規模なデータセット、複雑な変換、または特定のデータ統合パターンを使用する場合でも、これらのガイドラインは、データ統合プロセスの効率と速度を向上させる実用的な分析情報を提供します。 パフォーマンスの最適化は進行中のプロセスであり、データ統合ワークフローの進化するニーズに基づいてアプローチを調整する必要がある場合があります。 データフローを継続的に監視および最適化することで、ビジネス要件に対して効率的で応答性を維持できます。