最新の評価エンジンは、仮想ネットワーク (VNet) データ ゲートウェイ経由で接続するときにクエリの評価と更新の実行に使用できる、Fabricワークロードをサポートするオプトイン機能です。 [ 接続とゲートウェイの管理 ] ページからパブリック プレビュー設定として有効にすることができます。
最新の評価エンジンを使用すると、一部のワークロードの更新期間を短縮し、サポートされているシナリオで DirectQuery の起動待ち時間を向上させることができます。 実際のパフォーマンスは、コネクタ、データ ソース、クエリの形状、ゲートウェイの構成、ワークロードのコンカレンシーによって異なります。 パブリック プレビュー中は、この設定は既定でオフになり、既存のゲートウェイでは、オプションを有効にするまでレガシ エンジンが引き続き使用されます。
前提条件
- 構成された VNet データ ゲートウェイ。
- ゲートウェイまたは接続設定を管理するためのアクセス許可。
- ゲートウェイを使用する、1 つ以上のサポート対象の Fabric ワークロード。
- 更新期間、クエリ待ち時間、容量消費量の検証プラン。
サポートされているシナリオ
最新の評価エンジンは、次のような VNet データ ゲートウェイを使用するサポートされているワークロードに適用されます。
- セマンティック モデルが更新されます。
- データフロー Gen2 が更新されます。
- VNet データ ゲートウェイを介して接続する DirectQuery ワークロード。
サポートは、コネクタとワークロードによって異なる場合があります。 運用ゲートウェイの設定を有効にする前に、代表的なワークロードをテストします。
ヒント
最新の評価エンジンはオプトイン設定です。 既存のゲートウェイでは、オプションを有効にするまでレガシ エンジンが引き続き使用されます。
最新の評価エンジンを有効にする
ゲートウェイ管理者は、特定のゲートウェイのオプトイン設定として最新の評価エンジンを有効にすることができます。
- Fabricで、[接続とゲートウェイの管理] を開きます。
- 更新する VNet データ ゲートウェイを選択します。
- ゲートウェイの設定の詳細オプションで、[ 最新の評価エンジンを使用する] をオンにします。
- 変更を 保存 します。
- 代表的な更新と DirectQuery ワークロードを実行します。
- 設定を有効にする前後の更新期間、クエリ待機時間、容量メトリックを比較します。
最新の評価エンジンを無効にする
ゲートウェイをレガシー エンジンに戻す必要がある場合は、モダンな評価エンジンを無効にします。
- [ 接続とゲートウェイの管理] を開きます。
- VNet データ ゲートウェイを選択します。
- [ 最新の評価エンジンを使用する] をオフにします。
- 変更を 保存 します。
- 影響を受けるワークロードを再実行して動作を確認します。
パフォーマンスに関する考慮事項
最新の評価エンジンでは、一部の更新とクエリのシナリオで経過時間を向上させることができます。 次の例は、ベンチマーク実行の結果を示しています。 これらの結果は単に例であり、特定の環境の保証として使用しないでください。
更新シナリオ
| Scenario | コネクタ | 雲 | VNet データ ゲートウェイ - レガシ | VNet データ ゲートウェイ - モダン |
|---|---|---|---|---|
| セマンティック モデルの更新 | Azure Blob Storage (10 GB) | 35:10 | 42:26 | 26:59 |
| セマンティック モデルの更新 | SQL (1 億行) | 7:50 | 13:18 | 7:40 |
| データフロー Gen2 の更新 | Azure Blob Storage (10 GB) | 19:30 (モダン) | 46:09 | 25:31 |
DirectQuery のシナリオ
| Metric | Legacy | モダン |
|---|---|---|
| セマンティック モデル DirectQuery コールド スタートアップ、エンド ツー エンド | 10 秒 | 200 ミリ秒 |
| セマンティック モデル DirectQuery の安定した状態(エンドツーエンド) | 200 ミリ秒 | 200 ミリ秒 |
注
これらの結果は、ベンチマーク シナリオの例です。 実際のパフォーマンスは、コネクタの動作、ソース システムの待機時間、クエリの形状、ゲートウェイの構成、モデルの設計、ワークロードのコンカレンシーによって異なります。
容量と課金に関する考慮事項
最新の評価エンジンを使用すると、一部のワークロードのウォールクロック更新時間を短縮できます。 容量への影響は、実行中のワークロードとそのワークロードの使用状況によって異なります。
更新期間が短くなるか、CPU 時間が短縮されると、一部のシナリオでは容量の使用量に影響を与える可能性がありますが、実際の影響は異なります。 管理者は、Fabric容量メトリック アプリと、独自の環境の代表的なワークロードを使用して、前後の動作を比較する必要があります。
ワークロードの検証
最新の評価エンジンを有効にした後、ゲートウェイを使用するワークロードを検証します。
- 代表的なセマンティック モデルの更新を実行します。
- 代表的なデータフロー Gen2 更新を実行します。
- ゲートウェイ経由で接続する DirectQuery レポートをテストします。
- 更新履歴でエラーまたは回帰を確認します。
- 実時間と容量のメトリクスをベースラインと比較します。
- ワークロードが期待どおりに動作しない場合は、[最新の評価エンジンを使用する] をオフにして、ゲートウェイ診断Microsoftサポートにお問い合わせください。
Troubleshooting
再読み込みのパフォーマンスが向上しない
パフォーマンスの向上は、コネクタ、クエリの形状、ソース システム、使用可能なゲートウェイ リソースによって異なります。 設定を有効にする前と後に複数の実行を比較し、ワークロードでサポートされているコネクタとゲートウェイ パスが使用されていることを確認します。
容量の消費量が減少しない
壁時計の継続時間が短いほど、比例容量が減少するとは限りません。 ゲートウェイのアップタイム、クールダウン動作、ワークロードの CPU 時間、コンカレンシーは、監視された容量の使用量に影響を与える可能性があります。
DirectQuery のコールド スタートアップが遅い
レポートで VNet データ ゲートウェイ パスが使用されていること、およびコネクタがサポートされていることを確認します。 また、起動時間が、ゲートウェイ パス外のソース システムの待機時間、認証、またはモデルの初期化の影響を受けるかどうかを確認します。