正解: B. 容量を増やす。解説:問題のシナリオでは、ファクトテーブルのデータ量が2億行から5億行へと大幅に増加したことが、パフォーマンス低下とエラーの主な原因と考えられます。Microsoft Fabric の容量は、コンピューティングパワー (CU) を決定します。データ量が増加すると、クエリの処理や Direct Lake モードでのデータ読み込みに必要なリソースも増加します。
F32 容量では、増加したデータ量を処理するためのリソースが不足している可能性が非常に高いです。特に、レポートでエラーが表示されるという事実は、メモリ不足やクエリのタイムアウトなど、深刻なリソース制約を示唆しています。
したがって、最も直接的かつ効果的な解決策は、容量をより大きな SKU (例: F64) にスケールアップすることです。これにより、利用可能なコンピューティングリソースが増加し、クエリパフォーマンスが向上し、リソース不足によるエラーが解消されます。
その他の選択肢の評価:- A. MD5 ハッシュを SHA256 に変更する: ハッシュアルゴリズムを変更しても、パフォーマンスが向上する保証はありません。むしろキーのサイズが大きくなり、パフォーマンスが低下する可能性があります。
- C. V-Order を有効にする: V-Order は Fabric Warehouse のテーブルでデフォルトで有効になっている最適化機能です。パフォーマンス向上に寄与しますが、データ量が容量の限界を超えた場合の根本的な解決策にはなりません。
- D. 代理キーを異なるデータ型に変更する: 文字列ベースのハッシュキーを整数キーに変更することは、一般的に結合パフォーマンスを向上させるベストプラクティスです。しかし、これは大規模なデータ移行とETLプロセスの変更を伴うため、即時の問題解決にはならず、コストもかかります。まずはリソース不足を解消することが優先されます。
- E. ビューを作成する: ビューはクエリの複雑さを隠蔽しますが、基になるテーブルのパフォーマンス問題を解決するものではありません。
「運用コストを最小限に抑える」という要件はありますが、システムがエラーを発生させている現状では、安定稼働させるための容量増強は必要な投資と判断されます。