Lakehouse プラットフォームから高速で信頼性の高い分析を実現するには、最適な BI パフォーマンスを得るために SQL ウェアハウスを構成して運用することが不可欠です。 Azure Databricks の SQL ウェアハウスは、ビジネス インテリジェンス ワークロードを提供するために専用に構築されており、動的スケーリング、効率的なクエリ処理、堅牢なリソース管理を実現します。
このページでは、応答性の高いダッシュボード、コスト効率の高いリソースの使用、エンタープライズ BI ツールとのスムーズな統合を確保するために、SQL ウェアハウスのプロビジョニング、管理、監視に関する推奨されるプラクティスについて説明します。
このコンテンツは、分析とダッシュボードのパフォーマンスのために SQL ウェアハウスの構成、最適化、保守を担当するデータ エンジニア、BI 開発者、ワークスペース管理者を対象としています。 多くのタスクには、SQL ウェアハウスを作成または管理できる高度なワークスペースアクセス許可が必要です。
SQL サービス
| ベスト プラクティス | インパクト | Docs | アクションアイテム |
|---|---|---|---|
| サーバーレス コンピューティングを使用してリソースを自動的に開始、停止、スケーリングする | アイドル状態のリソースを停止することでコストを削減します。 | 開発倉庫の 自動停止 を有効にする | |
| 任意の BI ワークロードに SQL ウェアハウスを使用する (サーバーレスをお勧めします) | SQL ウェアハウスは、BI ワークロード用に最適化されています。 | BI ワークロード用に SQL ウェアハウスを構成する | |
| 倉庫のサイズを適切に設定する | ワークロードのパフォーマンスとコストのバランスを取ります。 | M サイズから開始し、パフォーマンスを監視し、必要に応じて調整する | |
| 大規模なデータセットに対してより大きなクラスター サイズを使用する | クラスター (M、L、XL など) が大きいほど、複雑なクエリの実行速度が速くなります。 単純で実行時間の短いクエリしかない場合は、サイズを大きくしないでください (データシャッフルが原因で遅くなる可能性があります)。 | クエリの複雑さとデータセットのサイズを評価する | |
| SQL ウェアハウスをスケールさせる | SQL ウェアハウスは、ワークロードの増加に対応するためにスケールアウトします。 ウェアハウスが制限に達した場合、クエリは拒否されるのではなく、キューに入れられます。 | 運用ワークロードのスケーリングを有効にする | |
| 多数の同時実行クエリが必要な場合は、クラスターの最小数を増やします | スケールアウトの待機中にクエリがキューに登録されないようにします。 | 予想されるワークロードに基づいて最小クラスターを構成する | |
| 異なるワークロードまたはビジネス ユニットに個別の SQL ウェアハウスを使用する | 分離とコスト属性を向上させるために SQL ウェアハウスのサイズを適切に設定します。 | ワークロードごとに専用のウェアハウスを作成する | |
| クエリ パフォーマンスを監視する | クエリ履歴を使用して、パフォーマンスのボトルネックと問題を識別します。 システム テーブルを使用すると、プログラムによってパフォーマンスを監視できます。 | 監視ダッシュボードを設定する |
関連するコンテンツ
BI ワークロードの要件を分析し、さまざまなアクセス パターン (DirectQuery とインポート/抽出) 用の SQL ウェアハウスの構成に関する詳細なガイダンスについては、 BI ワークロードの SQL ウェアハウス設定を参照してください。