メインコンテンツまでスキップ
に最終更新

BIワークロードのSQL設定

ビジネスインテリジェンスのワークロードには、特定のSQLウェアハウス構成の考慮事項を必要とする独特の特性があります。 このページでは、 BIワークロードの要件を分析し、最適なパフォーマンス、コスト効率、信頼性を実現するためのSQLウェアハウスの構成に関するガイダンスを提供します。

ワークロード分析とSLA要件​

すべての BI ワークロードは固有であるため、構成前に慎重な分析が必要です。要件を評価するときは、次の質問を考慮してください。

  • 移行か新しい実装か: このワークロードは別のプラットフォームから移行されるものか、それとも新しい実装か?移行されたワークロードでは、SLA とパフォーマンス ベースラインが確立されている可能性があります。
  • サービスレベルアグリーメント ( SLA ): レイテンシ、スループット、可用性の要件は何ですか? 技術 SLA とビジネス SLA の両方を文書化します。
  • アクセス パターン: ユーザーはどのようにデータと対話しますか?一般的なクエリ パターンを理解すると、ウェアハウス構成を適切なサイズに調整し、特定のワークロードに合わせてデータ レイヤーを最適化するのに役立ちます。

典型的なBIアクセスパターン​

通常、 BIワークロードは 2 つの異なるアクセス パターン カテゴリに分類され、それぞれに異なるSQLウェアハウス構成が必要です。

DirectQuery / LiveQuery パターン​

DirectQuery パターンは、インタラクティブな分析のための低遅延応答を必要とする、オンラインでデータをクエリします。

特徴:

  • クエリ数が多い
  • クエリは通常、小さな結果セット（1,000件未満のレコード）を返します。
  • 通常は営業時間内に実行されます
  • 低レイテンシーを期待する厳格なSLA要件
  • 予測できないクエリパターン（ダッシュボード、レポート）
  • クエリごとにアクセスされるデータは通常5GB未満です
  • スパイクパターンに対応するには、高度にスケーラブルなコンピュートが必要

パフォーマンスの期待値:

  • クエリ応答時間: 秒 (インタラクティブ ダッシュボードでは通常 5 秒未満)
  • データの鮮度: 最新のデータを反映した最新のデータ

ワークロード プロファイル:

  • 営業時間中に頻繁にスパイクが発生する
  • 予測不可能な負荷変動（ユーザー主導）
  • グローバル組織向けに24時間365日対応可能

パターンのインポート/抽出​

インポート パターンは、レイテンシよりもスループットを優先して、下流のシステムのデータを抽出します。

特徴:

  • クエリ数が少ない（スケジュールされた更新）
  • 通常、結果セットは大きくなります（1,000,000 件を超えるレコード）
  • 通常はオフピーク時間帯にスケジュールされます
  • 予測可能なクエリパターン（多くの場合、ドリルダウン主導）
  • クエリごとにアクセスされるデータ: 最大数十 GB

パフォーマンスの期待値:

  • クエリ応答時間: 数分から数時間 (バッチ指向)
  • データの鮮度: 日次スナップショットまたは前日

ワークロード プロファイル:

  • スケジュールされた予測可能な実行ウィンドウ
  • 既知のワークロード特性とリソース要件
  • バッチ指向処理

DirectQuery ワークロードにおけるクエリの組み合わせ​

スター スキーマ データ モデルで DirectQuery パターンを使用する場合は、次のクエリ分散が想定されます。

  • ディメンション クエリ: ディメンション テーブル (顧客、製品、時間) をスキャンする多数の小さなクエリ
  • ファクトクエリ: 結合と集計を使用してファクトテーブルをスキャンする大規模なクエリが多数あります
  • 抽出クエリ: 大規模データ抽出のための、シンプルだが長時間実行されるクエリ

この多様なクエリの組み合わせには、小規模で頻繁に実行されるクエリと大規模な分析クエリの両方を同時に効率的に処理できるSQLウェアハウスが必要です。

ワークロード分離のためのマルチウェアハウス戦略​

Databricks 、次のことを達成するために複数のSQLウェアハウスをプロビジョニングすることをお勧めします。

適正規模化と最適なコスト​

  • 特定の作業負荷パターンに合わせて各ウェアハウスのサイズを適切に設定する
  • リソース要件が異なるワークロードを分離することで、過剰なプロビジョニングを回避します。
  • 開発とテストには小さいウェアハウスを使用し、本番運用には大きいウェアハウスを使用します
  • ウェアハウスのスケーラビリティを使用して、パフォーマンスとコストの理想的なバランスを見つけます

全体的なパフォーマンスの向上​

  • DirectQuery とインポート/抽出パターン間のリソース競合を防ぐ
  • インタラクティブダッシュボードをバッチ更新操作から分離する
  • ワークロードの需要に基づいて独立したスケーリングを可能にする

相互請求と費用配分​

  • 事業部門、プロジェクト、チームごとに使用状況とコストを追跡します
  • 正確なチャージバックモデルを有効にする
  • コストの可視性と説明責任を向上

より効率的な管理と運営​

  • チームまたはプロジェクトごとに所有権と管理責任を割り当てる
  • 使用パターンに基づいて異なる自動停止ポリシーを適用する
  • 個別のアクセス制御とモニタリングを構成する

推奨される倉庫構成​

DirectQuery / LiveQueryワークロードの場合​

  • 自動リソース管理にはサーバレスSQLウェアハウスを使用する
  • コスト最適化のために積極的な自動停止（15～30分）を設定する
  • クエリの複雑さとデータ量に基づいてクラスター サイズを設定します (中から始めて、必要に応じてスケールアップします)
  • 予想されるワークロードに基づいてクラスターの最小数と最大数を設定する
  • Peak Queued Queries メトリクスを監視し、それに応じて最大クラスターを調整します

インポート/抽出ワークロードの場合​

  • 予測可能でスケジュールされたジョブには Pro または Classic SQLウェアハウスを使用する
  • 複数のジョブが連続して実行される場合は、自動停止時間を長く設定します（1～2時間）。
  • 複雑な集計には、より大きなクラスター サイズ (Large、X-Large) を使用します。
  • バッチウィンドウに合わせて固定スケジュールを検討する
  • クエリの実行時間を監視し、SLA 要件に基づいてサイズを調整する

SQLウェアハウスのサイジングとスケーリングの動作の詳細については、 SQLウェアハウスのサイジング、スケーリング、およびキューイングの動作」を参照してください。

BI サービスのベスト プラクティスのクイック リファレンスについては、 「BI サービスのチート シート」を参照してください。