Microsoft Fabricのデータフロー Gen1とGen2の比較：適切なステージングとコンピュートのアーキテクチャの選び方

By Mirko Peters · 2026-10-28

Microsoft FabricのデータフローGen1とGen2を比較します。ストレージ、コンピュートのステージング、キャパシティがクラウドETL戦略にどう影響するかを解説します。

Automatically translated with AI from the original post. Read the English original

Microsoft Fabricへ ETLワークロードを移行する際、データフローGen1とGen2のどちらのステージングおよびコンピュートのアーキテクチャを選ぶかは、パイプラインのパフォーマンス、リソースコスト、データの信頼性に直接影響します。コンピュートの割り当てとストレージの扱いにおける根本的な違いを理解しておけば、チームがレポートの規模を拡大する前に、高くつくアーキテクチャ上のボトルネックを避けられます。

重要なポイント

• データフローGen2は、OneLakeとのネイティブ統合を導入しており、データのステージングと保存の方法がGen1から根本的に変わります。
• 作成時に不適切なコンピュートオプションを選ぶと、予期しないキャパシティの抑制や、Fabricワークスペースでのパフォーマンス低下を招く可能性があります。
• Gen1は外部ストレージの仕組みに大きく依存していましたが、Gen2は既定の出力先として、Fabric Lakehouseのテーブルへ直接書き込みます。
• 適切なステージング構成は、データ変換の重複を防ぎ、Power BIセマンティックモデルの更新を最適化します。
• ETL戦略をFabricのキャパシティユニットに合わせることで、組織はコンピュートコストの際限ない増加を防げます。

Fabricにおけるアーキテクチャの変化の理解

レガシーなPower BIデータフローからMicrosoft Fabricのデータフローへの移行は、単なる名称変更ではありません。クラウド上のデータの取り込み、変換、保存の方法を根本から作り直すものです。Gen1の世界では、データフローは主にPower BIセマンティックモデルにデータを供給するために設計されていました。Power Query Onlineでデータ変換を行い、出力はPower BIサービスが完全に管理する内部ストレージに保存される、比較的閉じたエコシステムの中で動作していました。

Microsoft Fabricの登場により、データフローGen2はOneLakeを中心的なデータリポジトリとして活用するように一から構築されています。つまり、Power Query Onlineで適用したすべての変換は、もはや独自のモデルコンテナ内に閉じ込められることはありません。代わりにGen2は、従来のセルフサービスのデータ準備とエンタープライズのデータエンジニアリングの間を埋め、Fabric Lakehouse内のオープン形式のDelta Parquetテーブルへ直接書き込みます。この根本的な変化により、クラウドアーキテクトがデータステージング、コンピュートの利用、下流のレポートの信頼性にどう取り組むかが変わります。

ストレージのパラダイムシフト

レガシー環境では、ビジネスアナリストが Excel のエクスポートを整形し、空白行を削除して日付を書式設定する場合、そのデータはデータフローのストレージ境界の内側に置かれていました。別の部門が同じクレンジング済みデータセットを使いたい場合は、レポートからデータを取得するか、クエリを作り直す必要があることが多くありました。Dataflows Gen2 は、Lakehouse を第一級の保存先として扱うことでこの問題を解決します。データフローが実行されると、クレンジング済みのデータはすぐに Delta テーブルとして利用できるようになります。追加のデータ移動なしに、Spark ノートブック、SQL 分析エンドポイント、DirectLake によるレポートでそのまま使えます。

多くのチームが見落とすコンピュートとステージングの判断

Dataflows Gen2 を構築する際にエンジニアが直面する最も重要なアーキテクチャ上の判断の 1 つが、コンピュートとステージングのフェーズの管理です。コンピュート管理がほぼ抽象化され、時には不透明だった Gen1 と異なり、Gen2 は基盤となる Fabric キャパシティユニット (CU) 上で動作します。クエリ評価フェーズでデータがどのようにいつステージングされるかを慎重に監視しなければ、想定より早くキャパシティを消費してしまうおそれがあります。

複雑な変換を適用すると、Power Query は、各ステップをデータソースにフォールディングできるか、データフローエンジン内でローカルに実行する必要があるかを評価します。Gen2 では、ステージング領域が中間の着地領域として機能します。設定を誤ると、大量のデータが繰り返しメモリに読み込まれ、処理され、書き出されることになり、不要なコンピュート負荷が生じます。アーキテクトは、ソースシステム、ネットワークの待ち時間、変換の複雑さを評価し、処理をソースデータベースにプッシュダウンするか、重い処理を Fabric に任せるかを判断する必要があります。

ETL ワークロードのためのキャパシティユニットの最適化

Fabric キャパシティは、組織全体で共有されるプールです。最適化が不十分な Dataflow Gen2 が業務のピーク時間帯にスケジュール更新を実行すると、キャパシティを消費してスロットリングを引き起こし、経営層のユーザーが利用する Power BI レポートの描画に影響を及ぼすことがあります。これを防ぐには、重い ETL ジョブを、適切なキャパシティ予約を割り当てた専用のワークスペースに分離するか、業務時間外にスケジュールすることをお勧めします。バックグラウンドのコンピュートジョブが対話型ワークロードとどのように相互作用するかを理解することは、安定した Fabric 環境を維持するうえで不可欠です。

一貫したアーキテクチャによる信頼の構築

データパイプラインを刷新する最終的な目的は、ビジネスレポーティングを悩ませてきた Excel による手作業の修正をなくすことです。レポートが失敗するのは、データが不足しているからであることはまれで、ほぼ例外なく信頼が不足しているからです。ある レポートは生の CSV からデータを取得し、別のレポートはレガシーのデータフローから取得しているために数値が食い違っていると、ユーザーの利用率は急落します。

Dataflows Gen2 を標準とし、Lakehouse アーキテクチャを活用することで、組織は単一の真実の情報源を確立できます。クレンジング済みの日付、標準化された列名、検証済みのビジネスロジックは、データフローで一度だけ定義され、下流へ自動的に伝播されます。これにより人為的なミスが減り、個人のデスクトップ PC への依存もなくなります。そして経営層がダッシュボードを開いたとき、その基礎となる数値は信頼でき、監査にも対応できるものになります。

まとめ

Dataflows Gen2 による移行と構築には、クラウドストレージ、コンピュート予算、データガバナンスについての考え方を見直すことが求められます。繰り返し発生する煩雑なスプレッドシートの処理を 1 つ選び、それを Fabric Lakehouse に正しくマッピングするところから始めることで、長く使える拡張性の高いパイプラインを構築できます。この変化の基礎となる概念を学び、現代の Microsoft クラウド戦略に関する専門家の知見に触れるには、M365 FM Podcast の エピソード全編をお聴きください。

よくある質問

ストレージに関する Dataflows Gen1 と Gen2 の主な違いは何ですか?

Dataflows Gen1 は、変換済みのデータを Power BI の内部ストレージ境界内に保存します。一方、Dataflows Gen2 は、OneLake を経由して Microsoft Fabric Lakehouse 内のオープン形式の Delta Parquet テーブルに直接書き込みます。

Dataflows Gen2 は Fabric キャパシティユニットにどのような影響を与えますか?

Gen2 のデータフローは、コンピュートおよびステージングのフェーズで基盤の Fabric キャパシティを消費します。最適化が不十分な変換や、ピーク時間帯に重い更新を実行すると、キャパシティの割り当てを使い果たし、他のワークロードがスロットリングされるおそれがあります。

Dataflows Gen2 は従来の Azure Data Factory パイプラインを置き換えられますか?

セルフサービスのデータ準備、軽量なETL、ローコードでのデータ変換には、Dataflows Gen2が優れた選択肢です。一方、複雑なエンタープライズ向けのオーケストレーション、分岐ロジック、高度なデータエンジニアリングには、Azure Data Factory や Fabric Pipelines が引き続き推奨されるツールです。

Dataflows Gen2 においてステージングのフェーズが重要なのはなぜですか?

ステージングのフェーズは、データ変換の中間的な着地領域として機能します。ステージングを適切に構成することで、冗長なデータ処理を防ぎ、クエリフォールディングを最適化し、出力先の Lakehouse への効率的な書き込みを確保できます。

Dataflows Gen2 はレポートにおけるデータの信頼性をどのように向上させますか?

乱雑な手作業によるエクスポートデータのクレンジングを自動化し、変換処理を再利用可能な Lakehouse テーブルに集約することで、Gen2 は Excel での手作業による回避策を不要にし、後続のすべてのレポートで一貫性のある信頼できるデータを確保します。