Databricks Serverless SQL Warehouseのコストは、workloadごとの課題に適切な設定項目を対応させることで削減できます。自動停止（auto-stop）はアイドル状態での稼働時間を減らし、ウェアハウスサイズは単一クエリのパフォーマンスに影響し、最大クラスター数はウェアハウスが処理できる同時実行数を制御します。
難しいのは、こうしたシグナルが混同されがちな点です。短いジョブの合間に稼働し続けるウェアハウスに必要なのは、処理能力の増強ではありません。キャパシティ待ちが発生しているworkloadsには、より大きなウェアハウスではなくクラスター数の追加が必要かもしれません。また、Power BIのDirectQueryは、SQL自体がすでに十分最適化されていても、Databricks SQLのアクティビティを生成し続けることがあります。
本記事では、これらのケースの見分け方、DBU単価だけでなく総コストでServerlessとPro・Classicを比較する方法、そして実際に観測している挙動に合った設定の選び方を解説します。こうしたウェアハウスレベルの判断は、サイジング・使用率・コスト帰属・自動化が連携するDatabricksコスト最適化の全体フレームワークの一部に位置づけられます。
TL;DR
- 自動停止は、SQL処理のバースト間のアイドル時間を削減します。
- ウェアハウスサイズは、個々のクエリが利用できるコンピュートを制御します。
- 最大クラスター数は、ウェアハウスが処理できる同時実行数を制御します。
- Serverless、Pro、Classicは、DBU単価だけでなくworkload全体の総コストで比較する必要があります。
- ビジネス上不要な鮮度のために
DirectQueryを使用している場合、Power BIの接続モードはSQL Warehouseのアクティビティを大きく変化させる可能性があります。
起動とアイドル時間がDatabricks SQL Warehouseのコストを押し上げる理由
短いジョブでも起動とアクティブ時間が発生するため、SQL Warehouseの請求額はクエリの実行時間から想像する以上に膨らむことがあります。スケジュールされたアラートがあると、この問題は見落とされがちです。別々のスケジュールで実行される1分未満のクエリが複数あるだけで、Databricks Serverless SQL WarehouseはSQL自体の実行時間よりはるかに長くアクティブな状態を維持してしまいます。設定次第でこのギャップはさらに広がります。実際に報告されたバンドルデプロイの事例では、auto_stop_minsの指定が漏れた結果、120分という値になっていました。現在のDatabricks Declarative Automation Bundlesのドキュメントでは、Serverlessのデフォルトは10分とされているにもかかわらずです。
私たちの見解では、隠れた設定ミスは実行のたびに繰り返されるため、1本の遅いクエリよりも大きなダメージを与えかねません。SQL Warehouseの請求額のうち、どれだけが高コストなクエリによるもので、どれだけが誰も見直していない設定によるものでしょうか。同じパターンはDatabricksの請求額を左右する5つの習慣や、コスト最適化の全体フレームワークにも登場します。
Databricks SQLウェアハウスの種類：Serverless vs. Pro vs. Classic
主要なSQLウェアハウスの種類の中で、Serverlessは基盤となるインフラの料金を含むため、表示上のDatabricksユニット（DBU）単価が最も高くなっています。Pro SQLウェアハウスのDBU単価はそれより低く、Classicが最も低いものの、どちらもクラウドインフラの料金は別途請求されます。サーバーレスコンピュートでは、ユーザーが管理すべきクラウドインフラ料金が個別に発生するのではなく、Databricksが基盤インフラを管理します。
例えば、公開されている米国東部のAWS Premiumの定価では、2026年時点でServerlessが1 DBUあたり約0.70ドル、Pro SQLウェアハウスが0.55ドル、Classicが0.22ドルです。実際の料金はクラウド、リージョン、エディション、契約によって異なります。これらの数字は特定リージョンの価格例に過ぎませんが、DBU単価だけではどの選択肢が総合的に安いか判断できない理由を示しています。
| 種類 | DBU単価（相対） | インフラ課金 | コールドスタート | 適した用途 |
|---|---|---|---|---|
| Serverless | 最も高い | 料金に含まれる | 通常は数秒 | バースト型・インタラクティブなBIやDirectQueryのworkloads |
| Pro | 中程度 | 別途請求 | 通常は数分 | Proの機能が必要な、需要が予測可能なBI workloads |
| Classic | 最も低い | 別途請求 | 通常は数分 | 需要が予測可能なスケジュール実行のworkloads |
Serverless SQLウェアハウスは数秒で起動し、需要の変化に素早く対応できるため、バースト型の需要に適しています。また、Databricks SQL ServerlessはIntelligent Workload Management（IWM）を利用してクエリのリソース需要を予測し、需要の変化に応じてキャパシティを管理します。これにより、長い起動遅延を避けるためだけにコンピュートをウォーム状態に保つ必要性が減ります。
Pro SQLウェアハウスとClassic SQLウェアハウスは、需要が予測可能な場合に有力な選択肢となります。Databricksは、需要の計画が立てやすく迅速な起動の重要性が低い、スケジュールされたImportやExtractジョブに対してこれらのSQLウェアハウスを推奨しています。Pro SQLウェアハウスはClassic SQLにはない機能を備えており、Classicは引き続き、よりシンプルなユースケース向けの低DBU単価の選択肢です。
有用な比較の軸は、インフラ、起動時の挙動、ウェアハウスがアクティブであり続ける必要のある時間を含めた、workload実行の総コストです。DBU単価だけを見ると、請求額の半分しか見ないのと同じ過ちにつながり、Serverlessが実際よりも高く見えてしまいます。
こうしたコストをウェアハウスレベルで比較したい場合は、SELECT for Databricksを使うことで、設定を変更する前にSQL Warehouseの支出、サイジング、使用率がどこから生じているかを把握できます。
SQLウェアハウスの自動停止：UIとAPIで下限が異なる
Serverless SQLウェアハウスは、ProやClassic SQLウェアハウスよりも自動停止を短く設定する余地があります。Databricks UIではServerlessの最小値は5分ですが、APIとDeclarative Automation Bundlesではauto_stop_minsを1分まで短縮できます。ProとClassicの最小値は10分です。
最短の設定が常に正解とは限りません。1分の自動停止は単独で実行されるスケジュールジョブに適している一方、インタラクティブなDirectQueryのworkloadsは、より長くウォーム状態を保つほうが有利な場合があります。私たちのSQL Warehouse自動停止のガイダンスでは、一般的なSQL用途にはおおむね10分を推奨しています。
Databricks CLIを使えば、Serverlessウェアハウスの自動停止を1分に設定できます。
databricks warehouses edit <WAREHOUSE_ID> \ --auto-stop-mins 1デフォルト値は、SQLウェアハウスの作成方法によっても異なります。Databricks UIのデフォルトはServerlessが10分、ProまたはClassicが45分ですが、Declarative Automation BundlesではServerlessが10分、ProまたはClassicが120分です。デプロイがその構成経路のデフォルトに依存しないよう、auto_stop_minsは必ず明示的に設定してください。
SQLウェアハウスのサイジング：サイズ vs. クラスター数
Databricks SQLにおいて、ウェアハウスサイズと最大クラスター数は異なるパフォーマンス問題を解決します。サイズは個々のクエリが利用できるコンピュートを制御し、最大クラスター数はウェアハウスが処理できる同時実行数を制御します。Serverlessでは、Intelligent Workload Managementがリソース割り当ての一部を自動的に処理します。
どの設定を調整すべきかは、クエリとキューのシグナルで判断します。
| 症状 | 調整すべき設定 |
|---|---|
| 単一のクエリが遅い、またはディスクへのスピルが多い | ウェアハウスサイズを拡大 |
| クエリがキャパシティ待ちに長い時間を費やしている | 最大クラスター数を増加 |
| Peak Queued Queriesがゼロを上回ったままになっている | ウェアハウスサイズと最大クラスター数の両方を確認 |
| クエリ間のアイドル時間が長い | 自動停止を短縮 |
Peak Queued Queriesだけでは正確な対処法は特定できません。waiting_at_capacity_duration_msが高い場合はキャパシティの圧迫を示し、遅いクエリやスピルの多いクエリはウェアハウスサイズの問題を示唆します。私たちとしては、コンピュートを追加する前に、圧迫がクエリレベルなのか同時実行レベルなのかを確認することをおすすめします。
アイドル時間は別の問題を示しています。クエリ実行中のキャパシティは十分なのに、ジョブの合間もウェアハウスがアクティブなままの場合、確認すべき設定は自動停止です。
Power BIのDirectQueryがサーバーレスコストの計算を変えるとき
Power BIのDirectQueryは、操作のたびにDatabricksへ新たなクエリが送信される可能性があるため、ダッシュボード自体から想像するよりはるかに多くのウェアハウスアクティビティを生み出すことがあります。DatabricksはDirectQueryとLiveQueryにServerless SQL Warehouseを推奨しており、インタラクティブなworkloadsには15〜30分の自動停止を推奨しています。
ビジネス上、数分おきの更新で十分な場合は、ImportまたはHybridモデルによってPower BI側でより多くのレポート操作を処理し、Databricks SQLのアクティビティを削減できます。マテリアライズドビューも繰り返されるSQL処理を事前計算できますが、その更新には引き続き別のサーバーレスコンピュートが使用されます。
私たちの見解では、Serverlessのコストがダッシュボードの複雑さと釣り合わないと感じたとき、最初に調査すべき対象の一つがDirectQueryです。Serverlessの価格を疑う前に、BIの接続モードが、実際に必要な鮮度要件を超えるアクティビティを生み出していないか確認してください。
設定の調整を運用に落とし込む
SQL Warehouseのコストを管理し続けるには、サイジング、アイドル時間、キャパシティの圧迫を継続的に可視化する必要があります。私たちのSQL Warehouseコストビューはこれらのシグナルを一元化し、どの設定を見直すべきかを把握できるようにします。
Automated Savingsは、需要の変化に応じて、SQL Warehouseのサポート対象となるワーカー数設定とオートスケーリング設定を調整できます。自動停止は独立した設定項目であるため、デプロイ後は引き続きauto_stop_minsを確認し、アクティビティがビジネス上の鮮度要件と合わなくなったときはBI接続モードを監査してください。
次の段階のコスト削減は、こうしたチェックを運用習慣に変えることです。判断すべきは、サイズ、最大クラスター数、自動停止、BIモードを手作業で見直すことがまだ妥当なトレードオフなのか、それともその繰り返し作業の負担が積み重なり始めているのか、という点です。
Databricks Serverless SQL Warehouseのコスト：最初に調整すべき設定
観測しているシグナルに応じて設定を選びましょう。アイドルの間隔は自動停止、キューの圧迫はキャパシティ、個々の遅いクエリはウェアハウスサイズ、想定外のBIアクティビティは接続モードを示しています。Serverless、Pro、Classicの比較は、DBU単価だけでなく総コストで行ってください。
設定を変更する前に、まず根拠を確認しましょう。私たちのDatabricksコストビューは、SQL Warehouseのコスト、サイジング、アイドルコンピュート、使用率を一元化し、どの設定に最初に注目すべきかを明らかにします。