Dataflow Gen2のコストとパフォーマンス:能力ベンチマークとCUコスト

Microsoft Fabric Dataflow Gen2は、データを効率的に取り込み、変換し、ロードするための複数の方法を提供します。 これらの方法は、 パフォーマンス、 スケーラビリティ、 コストのバランスを取るのに役立ちます。

この記事はDataflow Gen2のパフォーマンスおよびコストの参考資料です。 このツールは、バルクコピー、ヘビーデータシェーピング、最適化されたレイクハウスへの書き込み、パーティションファイルの組み合わせという4つの一般的なワークロードをベンチマークし、実行時間と各が消費した容量ユニット(CU)を容量テレメトリーから測定して報告します。 自分のリフレッシュコストを推定し、各ワークロードに合った能力を選ぶために使ってください。

大規模に見ると、Dataflow Gen2は速度とコストの両面でDataflow Gen1を大きく上回っており、ワークロードが大きいほどその差は広がります。 同じMスクリプトを同じデータ、同じFabric容量で実行したDataflow Gen2は、この記事のすべてのベンチマークをDataflow Gen1の基準よりも速く終えました。これは1.7×から21×の基準よりも速く達成しました。 両世代の容量消費が測定されたすべてのシナリオにおいて、Dataflow Gen2は 82% 台から95台% 少ない容量 ユニットを消費しながら、より高速な処理を行いました。これにより、速度向上は追加の容量を犠牲にしません。 クエリを書き直すことなく、両方のメリットを同時に得られます。

どれだけ得られるかは作業量によりますが、最大の要因はクエリの実行時間です。 Standard Computeでは、各クエリの最初の10分を1秒あたり12CUで請求し、その後1秒ごとに1.5CUで請求するため、クエリが長く実行されるほど平均コストは低くなります。 短いデータフローはその第一層内で終了し、より安価なレートには届かないため、両世代間の差は小さいです。 この成果はデータ量や実行時間とともに拡大するため、本記事のベンチマークは大規模で大量のデータセットと長期的な更新を用いています。

Dataflow Gen2は、それ自体でもさらに低コスト化が進んでいます。現在の価格と機能では、同じワークロードを2026年以前に実行した場合と比べて、ワークロードに応じてCU消費量を推定14%～84%削減できます。

次の機能は、データフローの最適化に役立ちます。

• ファストコピー – 変換前に大量データの移動を加速します。
• 最新のエバリュエーター – 折りたたみ不可能なクエリで大量のデータシェイプを高速化します。
• ステージング クエリ – 変換を適用する前に中間レイヤーにデータを格納し、ELT パターンを有効にします。
• 最適化されたLakehouseへのコピー – ELTワークロードでLakehouse宛先への段階的なデータの書き込みを高速化します。
• パーティション分割コンピューティング（プレビュー）– 大規模なパーティション分割データセット全体にわたって変換をスケールできます。

この記事では、一般的なユースケース、実例、ベンチマーク結果を解説し、あなたのワークロードに最適な機能選択をサポートします。

Dataflow Gen2は各エンジンを個別に請求し、現在の料金は以下の通りです:

• 標準計算 (マッシュアップエンジンのクエリ) - 1秒ごとに最大10分まで12CU、さらに追加1秒ごとに1.5CUです。
• 高速コピー (データ移動) - コピー活動1秒あたり1.5 CU、使用されたすべてのコアで測定。

完全なレートモデルについては、 Dataflow Gen2の価格設定を参照してください。

クイック リファレンス

ワークロードを適切な Dataflow Gen2 機能と一致させます。 それぞれのベンチマークの例については、リンクされたシナリオを参照してください。

ベンチマーク結果の概要

この記事のほとんどのシナリオは、 ニューヨーク市タクシー・リムジン委員会(TLC)のトリップデータ – TLCトリップレコードデータ データセットを使用しています。これは、2021年から2025年(8月まで)をカバーする、ADLS Gen2にParquetファイルとして保存された数十億件のタクシートリップ記録です。 シナリオ3は、2017年から2018年中頃までの約1億1,300万件のニューヨーク市タクシー旅行記録をまとめたFabric lakehouseの表を使用しています。 宛先は、シナリオに応じて、Fabricのレイクハウスまたは倉庫です。

次の表は、すべてのシナリオのベンチマーク結果をまとめたものです。 各シナリオには、比較用の Dataflow Gen1 ベースラインも含まれています。

以下のチャートは、実行時間ではなく容量消費量で同じシナリオを比較しています。

各機能の詳細、データセットの構成、および設計パターンの詳細については、次のシナリオのセクションを参照してください。

これらのベンチマークをどのように測定したか

各シナリオは同じMスクリプトを2回実行します。1回はDataflow Gen1でベースラインを確立し、もう1回はテスト対象の機能を有効にしたDataflow Gen2で実行します。

この記事のすべてのランは同じテスト条件を共有しています:

• すべてのシナリオと両世代は同じFabric容量で動作しているため、結果は容量サイズやSKUの違いを反映していません。
• データゲートウェイ は一切使われていません。 すべての接続はFabricサービスから直接クラウドのデータソースへとつながっていました。
• 各シナリオは、Dataflow Gen1とDataflow Gen2の両方で同じソースデータと同じMスクリプトを使用していました。

報告された数字は以下の意味を持ちます:

• ランタイム とは、データフロー実行で報告された総リフレッシュ時間のことです。
• 消費されたCUとは、Microsoft Fabricのキャパシティメトリクスアプリから読み取った、実行が容量に対して請求された容量単位秒数のことです。 Dataflow Gen2 では各エンジンが個別に課金されるため、シナリオの合計値は、リフレッシュ中に実行されたすべてのエンジンの合計となり、CU の値は最も近い整数の CU 秒に丸められます。 完全なレートモデルについては、 Dataflow Gen2の価格設定を参照してください。

両世代を比較する際は、以下の建築的な違いを念頭に置いてください。

• Dataflow Gen1はDataflow Gen2とは根本的に異なるアーキテクチャを採用しており、Fast Copy、Modern Evaluator、Optimized copy to Lakehouse、Partitioned Computeなどの機能をサポートしていません。
• Dataflow Gen1はCSVファイルとしてしかデータを読み込みできませんが、Dataflow Gen2はこれらのシナリオでParquetファイルとしてデータを読み込みます。

シナリオ 1: データをコピーする

NYCタクシーの分析チームは、ADLS Gen2 から数百万件の生の Parquet 形式の乗車記録を Fabric のレイクハウスに読み込む必要があります。 チームは変換を必要とせず、ダウンストリーム分析をサポートするための直接コピーのみが必要です。

Challenges

• 大量のParquetデータを迅速に湖畔ハウスに移動させましょう。
• 毎日の更新の取り込み時間を短縮します。
• 単純な抽出負荷 (EL) ワークロードのコンピューティング コストを最小限に抑えます。

Dataset

2021年から2025年8月までの年ごとに統合されたNYCイエロータクシーのパーケットファイル、5つの統合パーティション。

解決策

チームはDataflow Gen2で Fast Copy を有効にしました。 高速コピーは、データ移動パスを最適化し、サポートされているコネクタの書き込みを並列化します。

Design

このクエリは、5 年ごとの Parquet ファイルを結合し、結果を lakehouse に読み込みます。

ファストコピーの考慮事項

• .csv ファイル形式と .parquet ファイル形式をサポートします。
• Azure SQL Databaseでは、実行ごとにテーブルあたり最大1M 行をサポートします。
• 変換前の 抽出負荷(EL) ワークフローに最適です。

Results

Fast Copyを有効にすると、Dataflow Gen2は Dataflow Gen1のベースライン( 00:09:08 vs. 01:38:59)より約11×速くこのデータセットを取り込み、計算使用量を削減します。 Fast Copyがなければ、Dataflow Gen2は同じワークロードでGen1より約2.8×速いです。

Fast Copyを有効にすると、このシナリオに最適なDataflow Gen2構成ですが、シナリオ1の5つの統合されたParquetファイルをレイクハウスに高速コピーで取り込むと14,593 CU秒が消費されます。 以下の表は、その合計を演算ごとに分解しています。

Fast Copyのデータ移動は、コピー活動の1秒あたり1.5 CUの料金で請求され、コピーが動作するすべてのコアをまたぐ合計時間として測定されます。 Dataflow Gen2 は、各 Fast Copy シナリオで使用されるコア数を自動的に調整するため、実時間ではすばやく完了するコピーでも、多くのコア秒を要する場合があります。 残りのクエリ時間はStandard Computeで請求されます(1秒ごとに最大10分、その後追加1秒ごとに1.5CU)。 完全な料金モデルについては、 Dataflow Gen2の価格設定を参照してください。

重要な習得事項

• Fast Copyを有効にすることで、99分の取り込み時間を約9分に短縮し、同じデータセットとMスクリプトの1桁の改善となりました。
• また、Dataflow Gen2は同じ作業でDataflow Gen1より 83分% 少ない容量 (14,593 対 84,411 CU秒)を使用していたため、速度向上は追加の計算コストを伴うものではありませんでした。
• この速度アップは、マッシュアップエンジンをバイパスするネイティブの並列データ移動によるもので、 Fast Copyの前提条件を満たす抽出負荷ステップにのみ適用されます。 折りたたみを中断する変換は、標準エンジンにフォールバックし、利益を失います。
• サポートされているソースの場合は、高速コピーをインジェストの既定値として扱い、実際にデータを整形する手順について、(次のシナリオで説明する) より重い変換エンジンを予約します。

シナリオ 2: 大量のデータ整形

取り込み後、チームはフィルタリング、ヌル置換、コードマッピングを適用し、その後レイクハウスにデータを読み込みます。 これらの変換は Parquet に完全に統合されるわけでもなく、さらにメモリ内では動作が遅いです。

Challenges

• 半折り可能または非折りたたみ型のクエリの変換速度を向上させます。
• コードなしの Power Query 作成を維持します。
• 全体的な更新時間とコストを削減します。

Dataset

2021年から2025年8月までのすべてのParquetファイルは統合ファイルに統合されました。

解決策

このチームは、特に ADLS Gen2 や SharePoint などのコネクタ向けに効率的な変換用に設計された高性能実行エンジンである Modern Evaluator を実現します。

Design

このクエリは、統合 Parquet ファイルからデータを取り込み、 trip_distance 列と fare_amount 列をフィルター処理して値を 0 より上に保ち、 passenger_count の null を 1 に置き換え、データを lakehouse に読み込む前に支払いの種類をマッピングして新しい payment_method 列を作成します。

現代評価者の考察

• 予想される更新時間が 大幅に短縮 される可能性があります (データセットと変換によって異なります)。
• 大量 (数百万行) 用に最適化されています。
• 折りたたみ不可能なクエリに役立ちます。
• Faster は湖畔の家のような目的地に書き込みます。

Results

Modern Evaluatorを有効にすると、Dataflow Gen2はこのシェーピングワークロードをDataflow Gen1のベースライン(00:46:29 vs. 01:19:56)より約1.7×速く実行しつつ、ノーコードPower Query体験を維持します。 Modern Evaluatorがなければ、同じ作業量はGen1より約1.2×速い程度です(01:08:37対01:19:56)。

このシナリオに最適な Dataflow Gen2 の構成である Modern Evaluator を有効にすると、シナリオ 2 で Modern Evaluator を使用して 1 つの大規模な Parquet ファイルをレイクハウス向けに整形するのに、10,485 CU 秒を消費します。 以下の表は、その合計を演算ごとに分解しています。

この作業は完全にStandard Compute上で運営されており、2つの階層で請求されます:1秒ごと12CU(最大10分)、さらに追加1.5CUです。 以下の表は、請求期間とCU合計がこれらの階層間でどのように分布しているかを示しています:

この表では、各層の合計がぴったり一致するように、測定された総計を小数点以下1桁まで示しています。この記事の他の部分では、これを 10,485 CU 秒に丸めています。

この内訳は、第1ティアが請求額の大半を占めていることを示しています。最初の10分間は実行時間の約22%にすぎませんが、CU秒の約69%を占めています。というのも、その最初の10分間の1秒ごとのコストは、第2ティアの1秒の8倍だからです。 10分を超えるすべての時間、つまり長いシェイピングランの大部分は、はるかに低い1.5 CUレートで請求されます。 Modern Evaluatorは、料金を変更するのではなく、請求期間自体を短縮することで請求額をさらに下げています。 完全な料金モデルについては、 Dataflow Gen2の価格設定を参照してください。

重要な習得事項

• Modern Evaluatorがなければ、Dataflow Gen2はこのシェイピングワークロードにおいてDataflow Gen1のベースラインより約1.2×速くしかありませんでした。 Modern Evaluatorを有効にすると、同一のMスクリプトとデータセットでGen1より約1.7×速くパフォーマンスが向上しました。
• 容量削減は時間短縮を上回っており、Dataflow Gen2は1.7×速く完成し、消費容量はDataflow Gen1より 82秒% 少ない (10,485秒対56,855 CU秒)でした。
• このパフォーマンス向上は、非折りたたみクエリや半折りたたみクエリの実行経路がより効率的になることによるものです。 Power Queryは伝統的にこれらのクエリに最も多くの時間を費やします。特にADLS Gen2やSharePointのようなコネクタを使う場合です。 行のボリュームを使用してスケーリングを行い、複雑さを形成します。
• クエリがソースに完全にはフォールドバックされない、シェイピング処理の多いフローでは、Modern Evaluator を既定として使用します。 データセットが大きく、エンジン内で変換を多く施すほど、より大きな影響が期待できます。

シナリオ3:最適化されたコピーをLakehouseに送る

NYCタクシーの分析チームは、大きなテーブルを変換し、その結果をFabric lakehouseに書き込みます。 そのボリュームを宛先に書き込むのはリフレッシュの中で最も遅い部分なので、チームは変換ロジックを変えずに書き込みを速めたいと考えています。

Challenges

• 大規模な変換結果をレイクハウスの保存先にすばやく書き込む。
• 宛先の書き込みがリフレッシュのボトルネックにならないようにしましょう。
• ノーコードのPower Query体験と既存の変換ロジックを維持しましょう。

Dataset

2017年から2018年中頃までの約1億1,300万件のニューヨーク市タクシー旅行記録を収めたFabric lakehouseのテーブル。

解決策

チームは、Lakehouse の宛先に書き込む単一のクエリで、ステージングを有効にし、Lakehouse への最適化されたコピーを有効にします。 最適化されたコピーをLakehouseに送ると、ステージ化された結果が加速された経路でLakehouseに移動します。

Design

ベンチマークのデータフローは、ステージングを有効にした単一のクエリと、V-Orderを使用するレイクハウス宛先を使用しています。 クエリはFabricの湖畔ハウスにある約1億1300万行のニューヨーク市タクシーテーブルを読み取り、行をピックアップ日時で並べ替え、さらに2つの派生列(ピックアップ月の開始とMTA税と改善サーチャージの合計)を追加します。 ステージングがオンになっているため、 Lakehouseへの最適化コピー は変換された結果を加速経路でlakehouse宛先に書き込み、高速実行時間を推進します。

Lakehouse への最適化コピーに関する考慮事項

• クエリで ステージングを有効にする ことと、レイクハウスの宛先が必要です。 詳細については、「 Dataflow Gen2 のステージング データ オプション」を参照してください。
• 変換ロジックを変えずにレイクハウスへの書き込みを加速します。
• 宛先で V-Order と組み合わせて、下流分析のために出力を最適化しましょう。

Results

Lakehouseへの最適化コピーを有効にすると、Dataflow Gen2は変換ロジックを変更することなく、Dataflow Gen1の基準(00:03:34対00:53:20) より約15×速 くこのリフレッシュを完了します。 これがなければ、同じ段階データフローはGen1より約3.6×速くなります。

ステージング、Lakehouseへの最適化コピー、そしてこのシナリオに最適なDataflow Gen2構成のV-Orderを有効にすると、シナリオ3の1億1300万行のNYCタクシーテーブルをレイクハウステーブルにリフレッシュし、00:03:34で完了し、2,391 CU秒を消費します。 以下の表は、その合計を演算ごとに分解しています。

作業は全額Standard Computeで請求されており(10分以内1秒ごとに12 CU、さらに追加1秒ごとに1.5 CUです)。 レイクハウスへの最適化コピーはマッシュアップ エンジンを経由するため、個別のメーターはありません。 完全な料金モデルについては、 Dataflow Gen2の価格設定を参照してください。

重要な習得事項

• 最適化されたコピーをLakehouse に送ると、変換済みの結果をLakehouse宛先に書き込む速度が加速され、リフレッシュ時間は00:14:45(なし)から00:03:34まで短縮されます。これは、同じデータフローの更新なしより約4×速く、Dataflow Gen1のベースライン(00:53:20)より約15×速く更新されます。
• この記事によると、このシナリオはDataflow Gen1に対して最大の容量節約をもたらしました。Dataflow Gen2はDataflow Gen1より 95% 少ない容量 を消費しました(2,391 対 50,788 CU秒)。
• クエリとレイクハウスの宛先で ステージングを有効にする 必要があり、変換ロジック自体は変わりません。
• このシナリオでは、宛先出力で V オーダー を明示的に使用します。
• Lakehouse 宛先にステージング済みデータを書き込む際に、書き込み時間がリフレッシュ時間の大半を占める場合は、Lakehouse への Optimized copy を使用してください。

シナリオ4:ファイルを組み合わせる

チームは、数百の Parquet ファイル (月単位のパーティション) にわたって旅行データを集計して強化する必要があります。 データセット全体のチップの割合を計算することが変換に含まれます。

Challenges

• 何百もの大きなファイルを処理する必要があります。
• 変換には、パーティション間でのグループ化、集計、エンリッチメントが必要です。
• 順次実行がボトルネックになります。

Dataset

56件のParquetファイル(2021年–2025年8月)。

解決策

チームはパーティション間の処理を並列化し、結果を効率的に統合する Partitioned Compute (プレビュー)を有効にしています。

Design

このクエリは56のParquetファイルを統合し、データをウェアハウスに読み込む前に Transform Sampleファイル 上でチップパーセンテージ「Tip Pctg」の新しいカスタムカラムを作成します。

パーティション分割コンピューティングに関する考慮事項

• 現在 プレビュー段階で 、Dataflow Gen2のCI/CDでのみ利用可能です。この機能は現在も改善が続けられています。
• ソースが折りたたみをサポートしていない場合に使用します。
• ステージングまたはウェアハウスにデータを読み込むときに最適なパフォーマンスを提供します。
• サンプル変換ファイルをファイルの結合から使用して、一貫した変換ロジックを確保しましょう。
• 変換のサブセットをサポートします。パフォーマンスは異なります。

Results

Partitioned Computeは、大規模でパーティション分割された複数ファイルデータセットにおいて、Dataflow Gen1のベースライン(00:04:48対01:40:57) より約21×速いパフォーマンス を提供します。

分割された計算はコストではなくウォールクロックの時間を目標としています。 パーティションを並列に動かすためリフレッシュが早く完了しますが、その並列処理は作業を減らすどころか計算量を増やすため、コストは通常、機能なしで同じワークロードと同等かそれ以上になります。 このシナリオではCU消費量は測定されていなかったため、この記事では実行時間のみを報告しています。

重要な習得事項

• パーティション分割されたコンピューティングは、Dataflow Gen1 ベースラインに対して 21 ×の高速化を実現し、5 分以内に完了しました。 この機能はプレビュー段階で、まだ改善が進んでいるため、これらの数値は今後進化していくことが予想されます。
• 分割計算は、費用削減ではなく、早く終わらせるための手段として扱いましょう。 並列処理はパーティションを同時に実行することでウォールクロック時間を短縮するため、通常は同じワークロードと同等かそれ以上にコストがかかります。
• 各パーティションを並列で処理し、結果をマージすることで得られるので、折りたたみが使用できないマルチファイルまたはパーティション分割されたソースで最も効果的であり、シーケンシャル評価がボトルネックになります。
• コンバインファイルの サンプル変換ファイル パターンを使い、各パーティションごとに変換ロジックを一貫して適用してください。 Partitioned Computeは現在、一部の変換をサポートしているので、シェーピングステップが互換性があるか確認してから依存し、プレビューが進化するにつれて再度確認してください。
• ステージングまたはウェアハウスへの大量のパーティション分割インジェストの場合は、パーティション分割コンピューティングをデフォルトに設定し、可能な限りモダンエバリュエーターと組み合わせます。 まだプレビュー段階なので、本番の刷新に導入する前に、自分のワークロードと比較して検証してください。

時間経過によるコスト(当時と現在)

Dataflow Gen2は時間をかけてよりコスト効率が良いものになりました。 同じロジックで同じデータで、現在は過去よりもCUを消費せず、クエリの変更も不要です。

この比較では、2026年以前に一般的に利用可能な価格と機能のもとで同じ作業負荷を意味します。 今は、Modern EvaluatorやFast Copyなどの最良の一般設定で今日と同じワークロードが実行されることを意味します。 両柱とも、その時代で最も一般的に入手可能な配置を使用しています。 現在の数値は容量テレメトリーから測定されています。 当時の数値は、当時同じ作業量がどれほど消費されていたかの推定値であり、以前のサービス条件は現在では再現できないためです。

例えば、シナリオ2のヘビーシェーピング作業は2026年以前には推定66,164 CU秒を消費していましたが、現在は10,485 CU秒を消費しています。 この変更は84% の削減で、同じ論理を持ち、変更は不要です。 2つの改良が複合的にそれを生み出します。 まず、Standard Compute の料金体系が段階制になりました。実行全体のすべての秒に一律 16 CU がかかるのではなく、最初の 10 分間は 1 秒ごとに 12 CU が課金され、それ以降は 1 秒ごとにわずか 1.5 CU のみが課金されるため、シェーピング ワークロードの長いテール部分にかかるコストは、以前のほんの一部で済むようになりました。 次に、Modern Evaluatorは2026年4月から一般に利用可能で、請求時間自体を短縮するため、どちらのティアでも請求する秒数が少なくなります。 実行時間が短くなり、しかもはるかに安価なロングテール料金が適用されるため、CU消費は大幅に低下します。さらに、整形処理の多いデータフローでは、Modern Evaluator を現行の段階制料金体系と組み合わせることが非常に重要になるのも、そのためです。

シナリオ1のFast Copyインジェスメントは2026年以前には推定17,055 CU秒を消費し、現在は14,593 CU秒を消費しています。 この変更は14% の削減であり、標準計算のレートが1秒ごとに16CUの固定から10分までの12CUに減少したことが原因です。Fast Copyのデータ移動部分は変更されていません。 シナリオ3の最適化コピーをLakehouseに更新した場合、2026年以前には推定14,173 CU秒を消費していましたが、現在は2,391 CU秒を消費しています。 この変更は83の% 削減です。 各比較は同じ作業負荷を使い、その時代の最良の一般利用可能な設定を使用します。

よく寄せられる質問

Dataflow Gen2はどのように請求されますか?

Dataflow Gen2は各エンジンに対してFabric Capacity Units(CU)で個別に請求します。 Standard Compute(マッシュアップエンジン)は、各クエリの1秒間最大10分ごとに12CUを請求し、さらに追加1秒ごとに1.5CUを請求します。 Fast Copy(データ移動)はコピー活動1秒ごとに1.5 CUを請求し、コピーが動作するすべてのコアで測定されます。 各クエリが実際に使用する計算量だけが請求され、固定のリフレッシュ料金やアイドル時間の料金はありません。 完全なレートモデルについては、 Dataflow Gen2の価格設定を参照してください。

Dataflow Gen2の価格設定は弾力的ですか?

Yes. Dataflow Gen2は、各クエリが実際に使用する計算量(Fabric Capacity Units(CU)で測定)のみを請求します。 更新ごとの固定料金はなく、アイドル状態の時間に対する料金もなく、ネイティブ機能についてはオーサリング中に直接料金が発生することもありません。 この記事のベンチマークでは、フルリフレッシュでFast Copyインジェスションで14,593 CU秒、重いシェーピング作業で10,485 CU秒を消費しました。

全ワークロードを実行する前に、Dataflow Gen2のコストをどう見積もればいいですか?

全体を組み立ててからコストを把握するのではなく、小さく代表的なリフレッシュを実行し、消費する量を測定しましょう。 コストを次のように推定するには:

• データフローは、データセット全体ではなく、サンプルや単一のパーティションに対して構築してください。
• 一度リフレッシュし、その後Microsoft Fabricのキャパシティメトリクスアプリで消費したCU秒数を読み取ってください。
• どのエンジンが稼働したかデータ フローの更新履歴 を確認してください。Standard ComputeとFast Copyは別々に請求されているからです。
• 測定されたCU秒を処理した行数やGB数で割って単位あたりのレートを得て、さらに全体のデータボリュームで割ります。

詳細な方法は、Fabric Metricsアプリを使った推定コストの計算とデータフローの更新履歴をご覧ください。

Dataflow Gen2のリフレッシュにはどのくらい時間がかかりますか?

それはデータ量や適用する変換によって異なります。 この記事のベンチマークでは、Dataflow Gen2 の更新処理は、1億1300万行のテーブルをレイクハウスにコピーする最適化済み処理では 00:03:34、大規模な統合 Parquet ファイルに対する負荷の高い整形処理では 00:46:29 でした。 5つの統合されたParquetファイルの一括コピーはFast Copyで00:09:08で完了し、56個のパーティションファイルの組み合わせはPartitioned Compute(プレビュー)で00:04:48で完了しました。 シナリオごとの完全なタイムについては 、ベンチマーク結果の概要をご覧ください。

どのDataflow Gen2機能が最もコストを下げるのでしょうか?

これはワークロードによります。各機能は異なるボトルネックをターゲットにしています。変換不要の取り込みにはFast Copy、非折りたたみ可能なデータシェーピングにはModern Evaluator、Lakehouse宛先への書き込みを加速するためのOptimized Copy to Lakehouse、大規模な多ファイルデータセットにはPartitioned Compute(プレビュー)があります。 Dataflow Gen1のベースラインと比較して測定すると、Optimized copy to Lakehouseはこれらのベンチマークで最も大きな節約効果を示し、CU秒が95秒% 少ないと言えます。 2026年以前の同等のDataflow Gen2実行と比較して、Modern Evaluatorは重いシェーピング作業で84% CU秒減少という最大の推定削減を実現しました。 能力をあなたのワークロードに合わせるには、 クイックリファレンスを参照してください。

Dataflow Gen2のリフレッシュを速くするにはどうすればいいですか?

ボトルネックに合わせて機能に合わせる:サポートされた抽出-ロードソースにはFast Copyを有効にし、非折りたたみ変換にはModern Evaluatorを有効にし、Lakehouse宛先に段階データを書き込む際にOptimized copy to Lakehouseを有効にし、大規模なパーティションまたはマルチファイルデータセットにはPartitioned Compute(プレビュー)を使用。 本記事では、各機能がDataflow Gen1ベースラインに対して提供した具体的な速度向上とベンチマークされています。

これらの改善を得るためにクエリを変更する必要がありますか?

No. この記事のすべてのベンチマークは、両世代とすべての構成で同じMスクリプトを実行していました。 Fast Copy、Modern Evaluator、Optimized Copy to Lakehouseはオンにする設定で、クエリ自体ではなくエンジンのクエリの実行方法を変えます。 ただし、Fast Copyは前提条件を満たすステップにのみ適用されるため、クエリ折りたたみを壊す変換は標準エンジンに戻り、その利点を失います。 これらの前提条件については、 Dataflow Gen2のFast Copyを参照してください。

Dataflow Gen2はDataflow Gen1よりも速くて安いのでしょうか?

この記事でベンチマークされているような大量ワークロードには、両方の点で可能です。 Dataflow Gen2は同じデータとMスクリプトでDataflow Gen1のベースラインより1.7×から21×の速度で動作し、両世代を測定したシナリオでは82% から95% 少ない容量単位を消費しました。 例えば、Dataflow Gen1で01:38:59だった一括コピーがFast Copyで00:09:08で完了したのに対し、Fast Copyで約11×速いです。 短時間データフローでは差は小さくなります。なぜなら、最初の10分以内に完了したクエリは安価な1.5 CU層には届かないため、データボリュームや実行時間とともに利益が増えていくからです。 シナリオごとの詳細な比較については 、ベンチマーク結果の概要をご覧ください。

Dataflow Gen1はDataflow Gen2と比べてどれくらいの容量を消費していますか?

両世代を測定したシナリオでは、Dataflow Gen1は同じ大量作業に対してDataflow Gen2の数倍の容量を消費しました。 Fast CopyのインジェスはDataflow Gen1で84,411 CU秒を消費し、Dataflow Gen2では14,593 CU秒となり、83% の短縮となりました。 重いデータシェーピング作業負荷はDataflow Gen1で56,855 CU秒を消費し、Dataflow Gen2では10,485 CU秒で82% 削減されました。 最適化されたLakehouseへのコピーワークロードはDataflow Gen1で50,788 CU秒を消費し、Dataflow Gen2では2,391 CU秒で95% 削減されました。 これら3つのリフレッシュはすべて10分を大きく超えるため、Dataflow Gen2のほとんどの時間は1.5CUの低いレートで請求されます。 シナリオごとの数値については 、ベンチマーク結果の概要をご覧ください。

Dataflow Gen1のデータフローをDataflow Gen2に移すべきでしょうか?

Yes. Dataflow Gen2はMicrosoft Fabricにおける現在のデータフロー世代なので、Dataflow Gen1のデータフローは必ずそちらに移行する計画を立ててください。 この記事のベンチマーク全体で、Dataflow Gen2は同じMスクリプト1.7×から21×より速く完成しつつ、Dataflow Gen1より82% から95個% 少ない容量ユニットを消費しました。これは同じ論理で、より高速で動作し、容量の使用も少なくなっています。 これらの利点をもたらす機能、すなわちFast Copy、Modern Evaluator、Optimized copy to Lakehouse、Partitioned ComputeはDataflow Gen2でのみ利用可能であり、これらの機能が向上するにつれて差は広がり続けています。 大量で長期的なリフレッシュで最大の利益が期待されます。 移行する際には、代表的なワークロードをテストして、自社のデータや容量の向上を確認しましょう。 始めるには、 Dataflow Gen2の概要をご覧ください。

Dataflow Gen2は時間とともにコスト効率が良くなったのでしょうか?

Yes. シナリオ2の重いシェーピング作業は、2026年以前には推定66,164 CU秒を消費していましたが、現在の一般利用可能な能力では10,485 CU秒を消費し、同一の論理で変更なしで約84% 削減が見込まれています。 シナリオごとの数値については「 Cost over time(当時と現在)」を参照してください。

古いDataflow Gen2のコストとパフォーマンスの数値はまだ正確なのでしょうか?

必ずしもその必要はありません。 この記事の数字は現在のDataflow Gen2の料金モデルを反映しており、標準計算で最大10分までの1秒あたり12CU、さらに追加1秒ごとに1.5CUとなります。さらにFast CopyやModern Evaluatorなどの現行機能も含まれます。 Dataflow Gen2は時間とともにより高速かつコスト効率が向上したため、2026年以前に発表されたベンチマーク数値やコスト見積もりは現在のコストを過大表示したり、パフォーマンスを過小評価したりすることがあります。 自社のワークロードをMicrosoft FabricのCapacity Metricsアプリと比較して検証してください。

関連するコンテンツ

• Dataflow Gen2の料金設定
• Dataflow Gen2でのファストコピー
• CI/CD 対応の Dataflow Gen2 用最新評価ツール
• Dataflow Gen2のステージングデータオプション
• Partitioned Compute for Dataflow Gen2 (プレビュー)