次の方法で共有


ワークロードの管理

適用対象:✅ Microsoft Fabric の SQL 分析エンドポイントおよびウェアハウス

この記事では、Fabric Data Warehouse のアーキテクチャとワークロード管理について説明します。

データ処理

ウェアハウスと SQL 分析エンドポイントは、同じ基本処理アーキテクチャを共有しています。 Fabric がデータを取得または取り込むにつれて、分散エンジンは、小規模および大規模なデータと計算関数の両方を処理します。

処理システムは、そのバックエンドのコンピューティング容量がワークロードの需要に合わせて自律的にスケールアップおよびスケールダウンするという点でサーバーレスです。

SQL エンジンの図。

クエリが送信されると、SQL フロントエンド (FE) はクエリの最適化を実行して、データのサイズと複雑さに基づいて最適なプランを決定します。 プランが生成されると、分散クエリ処理 (DQP) エンジンに渡されます。 DQP では、バックエンド コンピューティング ノードで実行される小さなクエリに分割することで、クエリの分散実行が調整されます。 各小さなクエリは タスク であり、分散実行単位を表します。 OneLake からファイルを読み取り、他のタスク、グループ、または他のタスクから取得したデータの順序を結合します。 インジェスト ジョブの場合は、適切な宛先テーブルにもデータが書き込まれます。

データが処理されると、ユーザーまたは呼び出し元のアプリケーションにサービスを提供するために、結果が SQL フロントエンドに返されます。

弾力性と回復性

バックエンドのコンピューティング容量は、高速プロビジョニング アーキテクチャからメリットを得られます。 リソースの割り当てには SLA はありませんが、通常、新しいノードは数秒以内に取得されます。 リソースの需要が高まると、新しいワークロードではスケールアウトされた容量が活用されます。 スケーリングはオンライン操作であり、クエリ処理は中断されません。

リソースの高速プロビジョニングを示す図。

システムはフォールト トレラントです。ノードが異常になった場合、ノードで実行されている操作は正常なノードに再分散され、完了します。

ウェアハウスと SQL 分析エンドポイントは バースト可能な容量 を提供します。これにより、ワークロードはより多くのリソースを使用してパフォーマンスを向上させることができます。 また、スムーズ化を 使用して、ピーク時に急激なスパイクを発生させ、アイドル容量が他の時間に使用されないままにしておいたお客様に安心感を提供できます。 スムージングにより、コンピューティングの評価が分散されて、お客様のジョブが円滑かつ効率的に実行されるようになり、容量管理が簡素化されます。

スケジュール設定とリソース割り当て

分散クエリ処理スケジューラは、タスク レベルで動作します。 クエリは、タスクの有向非巡回グラフ (DAG) としてスケジューラに表されます。 この概念は、Spark ユーザーにはなじみ深い概念です。 DAG を使用すると、相互に依存しないタスクを同時にまたは順序どおりに実行できるため、並列処理とコンカレンシーが可能になります。

クエリが到着すると、先入れ先出し (FIFO) の原則に基づいてタスクがスケジュールされます。 アイドル容量がある場合、スケジューラはコンカレンシーを最適化するために "最適な" アプローチを使用する可能性があります。

スケジューラによりリソースの負荷が識別されると、スケール操作が呼び出されます。 スケーリングは自律的に管理され、コンカレンシーの増加に合わせてバックエンド トポロジが拡大します。 ノードの取得には数秒かかるため、分散処理を必要とするクエリの一貫した 1 秒未満のパフォーマンスに対しては、システムは最適化されません。

負荷が軽減されると、バックエンド トポロジはスケール ダウンし、リソースはリージョンに解放されます。

コンピューティング プールの分離

適用対象:✅ Microsoft Fabric のウェアハウス

ワークスペースに 割り当てられた容量 SKU によって、その SQL 分析エンドポイントで使用可能なコンピューティングの合計が決まります。 このコンピューティングは、ユーザー クエリが利用できるように、2 つの分離されたリソース プールに均等に (50/50) 分割されます。

  • SELECT プール - すべての SELECT クエリを処理します。
  • 非 SELECT プール - ETL やインジェスト操作など、SELECT 以外のすべてのクエリを処理します。

各プールはクエリの需要に基づいて個別にスケーリングされますが、SQL 分析エンドポイントの合計コンピューティングの 50% を超えることはありません。 この分離により、リソースの競合が回避され、読み取りクエリに影響を与えることなく、ETL 用に最適化された専用コンピューティングでインジェスト ワークロードが確実に実行されます。 その結果、両方のクエリの種類のパフォーマンスと信頼性が向上します。

インジェスト アクティビティの分離を示す図。

注意

SELECTSELECT以外のプール分離は、すべてのワークスペースに適用される既定の自律的なワークロード管理です。 ただし、ワークスペース管理者は、 カスタム SQL プールを使用してこれをカスタマイズできます。

セッション

Warehouse および SQL 分析エンドポイントのユーザー セッション制限は、ワークスペースあたり 724 です。 この制限に達すると、次のエラーが返されます: The user session limit for the workspace is 724 and has been reached

注意

Microsoft Fabric は SaaS プラットフォームであるため、環境を継続的に最適化するために実行されるシステム接続が多数あります。 DMV には、システムとユーザーの両方のセッションが表示されます。 詳細については、「DMV を使用して接続、セッション、要求を監視する」を参照してください。

ベスト プラクティス

Microsoft Fabric ワークスペースには、分散コンピューティング システムの自然な分離境界が備わっています。 ワークロードでは、この境界を利用して、コストとパフォーマンスの両方を管理できます。

OneLake ショートカットを使用すると、他のワークスペースにテーブルの読み取り専用レプリカを作成し、複数の SQL エンジンに負荷を分散させて、分離境界を作成することができます。 これにより、読み取り専用クエリを実行するセッションの最大数を効果的に増やすことができます。

2 つのワークスペース (例: Finance と Marketing ワークスペース) の分離を示す図。