ビジネス インテリジェンス ワークロードには、特定の SQL ウェアハウス構成に関する考慮事項を必要とする個別の特性があります。 このページでは、BI ワークロードの要件を分析し、最適なパフォーマンス、コスト効率、信頼性を実現するための SQL ウェアハウスの構成に関するガイダンスを提供します。
ワークロード分析と SLA の要件
すべての BI ワークロードは一意であり、構成前に慎重に分析する必要があります。 要件を評価するときは、次の質問を検討してください。
- 移行または新しい実装: このワークロードは別のプラットフォームから移行されていますか、それとも新しい実装ですか? 移行されたワークロードでは、SLA とパフォーマンス ベースラインが確立されている可能性があります。
- サービス レベル アグリーメント (SLA): 待機時間、スループット、可用性の要件は何ですか? 技術 SLA とビジネス SLA の両方を文書化します。
- アクセス パターン: ユーザーがデータを操作する方法 一般的なクエリ パターンを理解すると、ウェアハウス構成のサイズを適切に設定し、特定のワークロードのデータ 層を最適化するのに役立ちます。
一般的な BI アクセス パターン
通常、BI ワークロードは 2 つの異なるアクセス パターン カテゴリに分類され、それぞれに異なる SQL ウェアハウス構成が必要です。
DirectQuery/LiveQuery パターン
DirectQuery パターンはリアルタイムでデータにクエリを実行し、対話型分析に低待機時間の応答を必要とします。
特性:
- クエリの数が多い
- 通常、クエリは小さな結果セット (1,000 レコード未満) を返します
- 通常、営業時間中に実行されます
- 厳格な要求と遅延が少ないことを期待される SLA
- 予測できないクエリ パターン (ダッシュボード、レポート)
- クエリごとにアクセスされるデータは、通常 5 GB 未満です
- スパイクの多いパターンに対応するには、高度にスケーラブルなコンピューティングが必要です
パフォーマンスの期待値:
- クエリ応答時間: 秒 (通常、対話型ダッシュボードの場合は 5 秒未満)
- データの鮮度: 最新のデータを反映した最新のデータ
ワークロード プロファイル:
- 営業時間中に頻繁に急増する
- 予測できない負荷の変動 (ユーザー主導)
- グローバル組織向けに 24 時間 365 日まで拡張可能
インポート/抽出パターン
インポート パターンでは、ダウンストリーム システムのデータが抽出され、待機時間よりもスループットが優先されます。
特性:
- クエリの数が少ない (スケジュールされた更新)
- 通常、大きな結果セット (1,000,000 レコードを超える)
- 通常、ピーク時以外の時間帯にスケジュールされます
- 予測可能なクエリ パターン (多くの場合、ドリルダウン駆動型)
- クエリごとにアクセスされるデータ: 最大 10 GB
パフォーマンスの期待値:
- クエリ応答時間: 分〜時間 (バッチ処理)
- データの鮮度: 日のスナップショットまたは前日
ワークロード プロファイル:
- スケジュールされた予測可能な実行ウィンドウ
- 既知のワークロードの特性とリソース要件
- バッチ指向処理
DirectQuery ワークロードでのクエリ の組み合わせ
スター スキーマ データ モデルで DirectQuery パターンを使用する場合は、次のクエリ分散が必要です。
- ディメンション クエリ: ディメンション テーブル (顧客、製品、時刻) をスキャンする多数の小さなクエリ
- ファクト クエリ: 結合と集計を使用してファクト テーブルをスキャンする多くの大規模なクエリ
- クエリの抽出: 大規模なデータ抽出に対する単純で実行時間の長いクエリ
このさまざまなクエリ の組み合わせには、小規模で頻繁なクエリと大規模な分析クエリの両方を同時に効率的に処理できる SQL ウェアハウスが必要です。
ワークロードの分離のためのマルチウェアハウス戦略
Databricks では、次を実現するために複数の SQL ウェアハウスをプロビジョニングすることをお勧めします。
適切なサイズ設定と最適なコスト
- 特定のワークロード パターンに合わせて各ウェアハウスのサイズを適切に設定する
- リソース要件が異なるワークロードを分離して、過剰なプロビジョニングを回避する
- 開発とテストには小規模な倉庫を使用し、運用環境ではより大きな倉庫を使用する
- 倉庫のスケーラビリティを使用して、パフォーマンスとコストの理想的なバランスを見つける
全体的なパフォーマンスの向上
- DirectQuery と Import/Extract パターン間のリソース競合を防ぐ
- 対話型ダッシュボードをバッチ更新操作から分離する
- ワークロードの需要に基づいて独立したスケーリングを有効にする
クロス課金とコストの割り当て
- 事業単位、プロジェクト、またはチーム別に使用状況とコストを追跡する
- 正確なチャージバック モデルを有効にする
- コストの可視性とアカウンタビリティの向上
より効率的な管理と管理
- チームまたはプロジェクトごとに所有権と管理責任を割り当てる
- 使用パターンに基づいて異なる自動停止ポリシーを適用する
- 個別のアクセス制御と監視を構成する
推奨されるウェアハウス構成
DirectQuery/LiveQuery ワークロードの場合
- 自動リソース管理にサーバーレス SQL ウェアハウスを使用する
- コストの最適化のためにアグレッシブな自動停止 (15 ~ 30 分) を構成する
- クエリの複雑さとデータ ボリュームに基づいてクラスター サイズを設定する ([中] から開始し、必要に応じてスケールアップする)
- 予想されるワークロードに基づいてクラスターの最小数と最大数を設定する
- ピーク キュークエリメトリックを監視し、それに応じて最大クラスターを調整する
インポート処理/抽出処理のワークロード用
- 予測可能なスケジュールされたジョブに Pro または Classic SQL ウェアハウスを使用する
- 複数のジョブが順番に実行される場合に、より長い自動停止時間 (1 ~ 2 時間) を構成する
- 複雑な集計には、より大きなクラスター サイズ (Large、X-Large) を使用する
- バッチ ウィンドウに合わせて固定スケジュールを検討する
- クエリの期間を監視し、SLA 要件に基づいてサイズを調整する
SQL ウェアハウスのサイズ設定とスケーリングの動作の詳細については、 SQL ウェアハウスのサイズ設定、スケーリング、およびキューの動作に関する説明を参照してください。
BI サービスのベスト プラクティスのクイック リファレンスについては、 BI サービスのチート シートを参照してください。