MENU
  1. ホーム
  2. ナレッジ
  3. 【Databricks】DBUの料金算出方法

【Databricks】DBUの料金算出方法

ナレッジ
AI databricks データ分析 データ活用 料金計算
目次

はじめに

Databricksの料金は、DBU(Databricks Unit)の消費量に応じたDBU料金と、クラウド事業者が別に請求するインフラ料金の2本立てで、全体像をつかみにくいと感じる方も多いのではないでしょうか。

本記事では、AWS上のDatabricksを対象に、システムテーブル system.billing.usage を使って、DBU料金を実績ベースで確認する方法を紹介します。クラウドインフラ費用は対象外です。

料金体系

料金の基本構造

Databricksの料金は、請求元の異なる2つに分かれます。

  • Databricks料金(DBU料金): Databricksが請求する、プラットフォーム利用分の料金
  • クラウド事業者の料金: AWSが別途請求する、VM・ストレージ・ネットワークなどの料金

今回はDatabricks料金(DBU料金)のみを対象にします。

基本の計算式

DBU料金は、次の式で求められます。

DBU料金 = 消費したDBU数 × DBU単価

DBUはDatabricks独自の処理能力の単位で、秒単位で消費されます。単価は、ワークロードの種類・プラン・クラウドによって異なります。

DBU単価の確認方法

DBU単価は、system.billing.list_prices というテーブルで確認できます。このような system. で始まるテーブルは「システムテーブル」と呼ばれ、課金情報などを参照するためにDatabricksが提供しています。list_prices には単価(定価)の履歴が入っており、単価が変更されるたびにレコードが追加されます。

単価は、課金対象を区別する単位ごとに決められています。この単位を SKU(Stock Keeping Unit)と呼びます。

主な列は次のとおりです。

列名説明
sku_nameSKUの名前。どの課金対象の単価かを示します。
cloud単価が適用されるクラウド。AWS、AZURE、GCPのいずれかが入ります
currency_code単価の通貨。例としてUSD(米ドル)が挙げられています
usage_unit単価の基準となる単位。DBU単価の場合は DBU が入ります
pricing単価の情報をまとめた列。複数の種類の価格が入っています
price_start_timeその単価が有効になった日時。UTC(協定世界時)で記録されます
price_end_timeその単価が終了した日時。UTCで記録されます

pricing 列の中身は次のとおりです。

  • effective_list: 定価とプロモーション価格(期間限定の割引価格)を考慮した、最終的な定価です。料金の計算にはこちらを使います
  • default: 簡易的な見積もり向けの、長期的な定価です

レコードは単価が変わったときだけ追加されるため、特定の日の単価を知りたい場合は、その日以前で最も新しいレコードを取得します。

サンプルクエリ

では実際に以下のクエリを実行してみます。単価の開始日時が新しい順に、3件を取得します。

SELECT *
FROM system.billing.list_prices
ORDER BY price_start_time DESC
LIMIT 3

実行結果は次のとおりです。

以下では一部を仮データとして表示させています。

account_idprice_start_timeprice_end_timesku_namecloudcurrency_codeusage_unitpricing
—2026-08-21T00:00:00.000+00:00–sku_name1AWSUSDDBU0.0700(一部省略)
—2026-08-21T00:00:00.000+00:00–sku_name2AWSUSDDBU0.0700(一部省略)
—2026-08-12T00:00:00.000+00:00–sku_name3AWSUSDDBU0.0700(一部省略)

pricing 列は、3件とも同じ値でした。

{"default":"0.070000000000000000","promotional":{"default":null},"effective_list":{"default":"0.070000000000000000"}}

この結果から該当するSKUの単価1DBUあたり0.07USDであることが分かりました。

課金対象使用量テーブル：system.billing.usage

テーブルの概要

system.billing.usage は、アカウント全体で課金対象となった使用量が記録されるシステムテーブルで、実績ベースで料金を算出するためのテーブルです。

主な特徴は次のとおりです。

アカウント単位で一元管理

使用量のデータはリージョンをまたいで一元化されており、どのリージョンのワークスペースからでも、アカウント全体の使用量を確認できます

反映までの時間

該当テーブルに即時反映はされません。 レコードは通常12時間以内に参照できるようになります。

レコードの内容

system.billing.usage のスキーマ(列の定義)は、次のとおりです。

列名データ型説明
record_idstringこの使用レコードの一意のID
account_idstringこのレポートが生成されたアカウントのID
workspace_idstringこの使用レコードが関連付けられたワークスペースのID
sku_namestringSKUの名前
cloudstringこの使用状況に関連付けられたクラウド
usage_start_timetimestampこの使用レコードに関連する開始時刻。タイムゾーン情報は、UTCを表す +00:00 が値の末尾に付きます
usage_end_timetimestampこの使用レコードに関連する終了時刻。タイムゾーン情報は、UTCを表す +00:00 が値の末尾に付きます
usage_datedate使用状況レコードの日付。このフィールドを使用すると、日付による集計を高速化できます
custom_tagsmap使用状況レコードに関連付けられたカスタムタグ
usage_unitstringこの使用量が測定される単位
usage_quantitydecimalこのレコードで消費されたユニット数
usage_metadata構造体コンピュートリソースとジョブ(該当する場合)のIDなど、使用状況に関するシステム提供のメタデータ
identity_metadata構造体使用に関連するIDに関するシステム提供のメタデータ
record_typestringレコードがオリジナル(ORIGINAL)、撤回(RETRACTION)、修正(RESTATEMENT)のいずれであるか
ingestion_datedateレコードがテーブルに取り込まれた日付
billing_origin_productstring使用を開始した製品。一部の製品は、異なるSKUとして請求できます
product_features構造体使用されている特定の製品機能の詳細
usage_typestring課金目的で製品またはワークロードに割り当てられる使用状況のタイプ

これらのうち、usage_metadata 、identity_metadata 、billing_origin_product 、product_features の列に関しては対象の料金計算を正しく行うために重要な列です。以下について詳しく紹介します。

usage_metadata

概要

  • 使用に関わったワークスペースのオブジェクトやリソース(クラスター、ジョブ、SQLウェアハウス、エンドポイントなど)のIDや名前をまとめた列です。
  • 料金を、ジョブやクラスター、SQLウェアハウス、エンドポイントなどの単位に分けて、何にいくらかかったかを把握したいときに使います。

詳細

公式ドキュメントに記載されている項目は次のとおりです。

項目説明
cluster_id使用状況レコードに関連付けられたクラスターのID
job_id使用状況レコードに関連付けられたジョブのID
warehouse_id使用状況レコードに関連付けられたSQLウェアハウスのID
instance_pool_id使用状況レコードに関連付けられたインスタンスプールのID
node_typeコンピュートのインスタンスタイプ。ドライバーノードとワーカーノードは区別しません
job_run_id使用状況レコードに関連付けられたジョブ実行のID
notebook_id使用状況に関連付けられたノートブックのID
dlt_pipeline_id使用状況レコードに関連付けられた宣言型パイプラインのID
endpoint_name使用状況レコードに関連付けられたモデルサービングエンドポイントまたはAI Searchエンドポイントの名前
endpoint_id使用状況レコードに関連付けられたモデルサービングエンドポイントまたはAI SearchエンドポイントのID
dlt_update_id使用状況レコードに関連付けられたパイプライン更新のID
dlt_maintenance_id使用状況レコードに関連付けられたパイプラインメンテナンスタスクのID
metastore_idデフォルトストレージに関連付けられたメタストアのID
run_name使用状況レコードに関連付けられた基盤モデルのファインチューニング実行の、ユーザー向けの名前
job_name使用状況レコードに関連付けられたジョブの、ユーザー指定の名前
notebook_path使用状況に関連付けられたノートブックのワークスペースストレージパス
central_clean_room_id使用レコードに関連付けられたセントラルクリーンルームのID
source_region課金対象となるトラフィックの発生元のリージョン。ネットワーク関連の使用でのみ値を返します
destination_region課金対象となるトラフィックの受信先のリージョン。ネットワーク関連の使用でのみ値を返します
recipient_id使用状況レコードに関連付けられたOpenSharingの受信者のID
associated_product使用のきっかけとなった製品。例えば、データベース接続によってネットワーキングの料金が発生する場合があります。使用が上流のソース製品に完全に起因する場合にのみ値が入ります
networking_clientネットワーク使用を発生させたクライアント。SERVERLESS_WORKLOAD または EXTERNAL_CLIENT のいずれかです
app_id使用状況レコードに関連付けられたアプリのID
app_name使用状況レコードに関連付けられたアプリの、ユーザー指定の名前
private_endpoint_nameこの値はDatabricks on AWSでは入力されません
budget_policy_id非推奨です。代わりに usage_policy_id を使用してください。ワークロードに関連付けられたサーバーレス使用ポリシーのIDです
storage_api_typeデフォルトストレージで実行される操作の種類。TIER_1(PUT、COPY、POST、LIST)と TIER_2(その他の操作)があります
ai_runtime_workload_id使用状況記録に関連付けられたサーバーレスGPUワークロードのID
uc_table_catalog使用記録に関連付けられたUnity Catalogのカタログ名
uc_table_schema使用状況レコードに関連付けられたUnity Catalogのスキーマ名
uc_table_name使用状況レコードに関連付けられたUnity Catalogのテーブル名
database_instance_id使用状況レコードに関連付けられたデータベースインスタンスのID
sharing_materialization_id使用記録に関連付けられた共有マテリアライゼーションのID
usage_policy_id使用記録に関連付けられたサーバーレス使用ポリシーのID
agent_bricks_id使用状況レコードに関連付けられたAgent BricksワークロードのID
base_environment_id使用状況に関連付けられたベース環境のID
schema_id使用状況レコードに関連付けられたスキーマのID
table_id使用状況レコードに関連付けられたテーブルのID
catalog_idデフォルトストレージの使用に関連付けられたUnity CatalogのカタログのID

identity_metadata

概要

  • 使用に関わったID(ユーザーやサービスプリンシパル)の情報をまとめた列です。
  • 誰が実行したワークロードか、誰が所有・作成したものかを基準に、使用量を把握したいときに使います

詳細

identity_metadata には、次の項目があります。

項目説明
run_asワークロードを実行したユーザーを記録します。値の入り方はワークロードの種類によって異なります
owned_bySQLウェアハウスの使用状況にのみ適用されます。使用を担当するSQLウェアハウスを所有するユーザーまたはサービスプリンシパルを記録します
created_byDatabricks Apps、Knowledge Assistant、Supervisor Agentに適用されます。アプリまたはエージェントを作成したユーザーのメールアドレスを記録します

billing_origin_product

概要

  • 使用を発生させたDatabricks製品を示す文字列の列です。JOBS、SQL、APPS などの製品名が入ります
  • 一部の製品は、同じSKUで課金されます(例: データ品質モニタリング、予測最適化、サーバーレスワークフローは、すべて同じサーバーレスジョブのSKUで請求されます)。SKUだけでは製品を区別できないときに、製品別の使用量を把握するために使います

詳細

billing_origin_product には、次の値があります。

値説明
JOBSLakeflow Jobsワークロードに関連するコスト
DLTLakeflow Pipelinesワークロードに関連するコスト
SQLSQLウェアハウス上で実行されるワークロードやマテリアライズドビューを含む、Databricks SQLに関連するコスト
ALL_PURPOSEクラシック汎用コンピュートに関連するコスト
MODEL_SERVINGModel Servingに関連するコスト
INTERACTIVEサーバーレスのインタラクティブワークロードに関連するコスト
DEFAULT_STORAGEデフォルトストレージに関連するコスト
VECTOR_SEARCHAI Searchに関連するコスト
LAKEHOUSE_MONITORINGデータ品質モニタリングに関連するコスト
PREDICTIVE_OPTIMIZATION予測最適化に関連するコスト
ONLINE_TABLESオンラインテーブル(レガシー)に関連するコスト
FOUNDATION_MODEL_TRAINING基盤モデルのファインチューニングに関連するコスト
AGENT_EVALUATIONエージェント評価に関連するコスト
FINE_GRAINED_ACCESS_CONTROL専用コンピュート上のきめ細かいアクセス制御によるサーバーレス使用
EXTERNAL_COMPATIBILITYクロスエンジンABACによるサーバーレス使用
BASE_ENVIRONMENTSワークスペースのサーバーレスベース環境の構築または更新に関連する使用
DATA_CLASSIFICATIONデータ分類オペレーションに関連するコスト
DATA_QUALITY_MONITORING異常検出やデータプロファイリングを含む、データ品質モニタリングに関連するコスト
DATA_SHARINGOpenSharingに関連するコスト
AI_GATEWAYAI Gatewayの使用に関連するコスト
AI_RUNTIMEサーバーレスGPUワークロードに関連するコスト
NETWORKINGサーバーレスコンピュートをリソースに接続すること、およびパフォーマンス重視の製品でクライアントに戻す下り(エグレス)通信に関連するコスト
APPSDatabricks Appsの構築と実行に関連するコスト
DATABASELakebaseのオリジナルバージョンであるLakebase Provisionedデータベースインスタンスに関連するコスト
LAKEBASELakebaseの現行バージョンに関連するコスト
AI_FUNCTIONSAI Functionsの使用に関連するコスト。この製品は、AI_PARSE_DOCUMENT、AI_EXTRACT、AI_CLASSIFY の使用を記録します
AGENT_BRICKSKnowledge AssistantとSupervisor Agentのワークロードに関連するコスト
CLEAN_ROOMClean Roomsワークロードに関連するコスト
LAKEFLOW_CONNECTLakeflow Connectのマネージドコネクターに関連するコスト
GENIE従量課金制のAI/BI Genieの使用に関連するコスト
FEATURE_STOREFeature Storeに関連するコスト
SUPERVISOR_AGENTSupervisor Agentワークロードに関連するコスト
LAKEHOUSE_REAL_TIMELakehouse Real-Timeに関連するコスト

product_features

概要

  • 使用された製品の機能の詳細を、キーと値のペアでまとめた列です(jobs_tier、is_serverless、is_photon など)
  • 使うとき: billing_origin_product とあわせて、同じ製品の使用を、ティア(jobs_tier、sql_tier、dlt_tier)や、サーバーレスかどうか(is_serverless)、Photon(クエリを高速化するエンジン)を使ったか(is_photon)などの機能の違いごとに区別したいときに使います

詳細

product_features は、次のキーと値のペアを含むオブジェクトです。

フィールド説明
jobs_tier値には LIGHT、CLASSIC、null があります
sql_tier値には CLASSIC、PRO、null があります
dlt_tier値には CORE、PRO、ADVANCED、null があります
is_serverless値には true、false、null があります(サーバーレスとクラシックコンピュートを選択できる場合は true または false、それ以外は null)
is_photon値には true、false、null があります
serving_type値には MODEL、GPU_MODEL、FOUNDATION_MODEL、FEATURE、null があります
offering_type値には BATCH_INFERENCE、null があります
performance_targetサーバーレスジョブまたはパイプラインのパフォーマンスモードを示します。値には PERFORMANCE_OPTIMIZED、STANDARD、null があります。サーバーレス以外のワークロードは null です
ai_runtime.compute_typeサーバーレスGPUワークロードのコンピュートタイプ、または null を示します
model_serving.offering_typeモデルサービングのオファリングタイプ、または null を示します
ai_gateway.feature_typeAI Gatewayワークロードの機能タイプ、または null を示します
serverless_gpu.workload_typeAI Runtime(サーバーレスGPU)のワークロードタイプ、または null を示します
ai_functions.ai_functionAI機能の種類、または null を示します
networking.connectivity_type値には PUBLIC_IP と PRIVATE_IP があります
agent_bricks.problem_typeKnowledge Assistantワークロードの問題タイプを示します。値には AGENT_BRICKS_KNOWLEDGE_ASSISTANT、null があります
agent_bricks.workload_typeKnowledge Assistantのワークロードタイプを示します。値には AGENT_BRICKS_REAL_TIME_INFERENCE、null があります

実行結果では、上の表にない apps、lakeflow_connect、lakebase、ai_bi_genie、genie という項目も確認できました。公式ドキュメントに説明はありません。Databricks Appsの使用である3件目のレコードでは、is_serverless が true、apps の中の compute_size が MEDIUM でした。

実際の確認例

これまでの内容をもとに、3つの利用シーンを想定して、実際にクエリを実行して確認します。

  • 確認例1: 月の料金を、SKU別に確認する
  • 確認例2: 料金を、製品別に確認する
  • 確認例3: 料金の中心となっているリソースや作成者を特定する

確認例１

シーン

月次の料金を把握するため、特定の月のDBU料金を、SKUごとに確認したい。

使用量を記録する system.billing.usage と、単価を記録する system.billing.list_prices を結合して、料金を算出します。

クエリ

SELECT
  usage.sku_name,
  SUM(usage.usage_quantity) AS dbu,
  SUM(usage.usage_quantity * list_prices.pricing.effective_list.default) AS dbu_cost
FROM system.billing.usage
JOIN system.billing.list_prices
  ON list_prices.sku_name = usage.sku_name
WHERE usage.usage_end_time >= list_prices.price_start_time
  AND (list_prices.price_end_time IS NULL
       OR usage.usage_end_time < list_prices.price_end_time)
  AND usage.usage_unit = 'DBU'
  AND usage.usage_date BETWEEN '2026-09-01' AND '2026-09-30'
GROUP BY usage.sku_name
ORDER BY dbu_cost DESC

結果

実際に実行してみた結果は次のとおりです(料金が大きい上位3件を抜粋)。料金の通貨は、list_prices の currency_code に従います。

なお、以下の値は実際の値ではなく、仮の値に置き換えています。

sku_namedbudbu_cost
sku_name12000.02800.00
sku_name224.34526.35
sku_name318.35320.55

確認例２

シーン

料金を、製品ごとに確認したい。SKUだけでは、どの製品の使用か分からない場合があるため、billing_origin_product を使って製品別に集計します。

クエリ

SELECT
  usage.billing_origin_product,
  usage.sku_name,
  SUM(usage.usage_quantity) AS dbu,
  SUM(usage.usage_quantity * list_prices.pricing.effective_list.default) AS dbu_cost
FROM system.billing.usage
JOIN system.billing.list_prices
  ON list_prices.sku_name = usage.sku_name
WHERE usage.usage_end_time >= list_prices.price_start_time
  AND (list_prices.price_end_time IS NULL
       OR usage.usage_end_time < list_prices.price_end_time)
  AND usage.usage_unit = 'DBU'
  AND usage.usage_date BETWEEN '2026-09-01' AND '2026-09-30'
GROUP BY usage.billing_origin_product, usage.sku_name
ORDER BY dbu_cost DESC

確認例1のクエリに billing_origin_product を追加し、製品とSKUの組み合わせごとに集計しています。同じSKUに複数の製品が表示されるかどうかを確認できます。

結果

結果は次のとおりです(料金が大きい上位3件を抜粋)。

なお、以下の値は実際の値ではなく、仮の値に置き換えています。

billing_origin_productsku_namedbudbu_cost
VECTOR_SEARCHsku_name12000.02800.00
APPSsku_name224.34526.35
SQLsku_name31.35322.553

製品別に見ると、料金の大半は VECTOR_SEARCH と APPS が占めていることも分かります。

確認例３

シーン

どのリソースや、誰が作成したものの使用が料金の中心になっているかを特定したい。usage_metadata(エンドポイントやアプリなど)と、identity_metadata(作成者など)を使って集計します。

クエリ

SELECT
  usage.billing_origin_product,
  usage.usage_metadata.endpoint_name,
  usage.usage_metadata.app_name,
  usage.identity_metadata.created_by,
  SUM(usage.usage_quantity) AS dbu,
  SUM(usage.usage_quantity * list_prices.pricing.effective_list.default) AS dbu_cost
FROM system.billing.usage
JOIN system.billing.list_prices
  ON list_prices.sku_name = usage.sku_name
WHERE usage.usage_end_time >= list_prices.price_start_time
  AND (list_prices.price_end_time IS NULL
       OR usage.usage_end_time < list_prices.price_end_time)
  AND usage.usage_unit = 'DBU'
  AND usage.usage_date BETWEEN '2026-09-01' AND '2026-09-30'
GROUP BY
  usage.billing_origin_product,
  usage.usage_metadata.endpoint_name,
  usage.usage_metadata.app_name,
  usage.identity_metadata.created_by
ORDER BY dbu_cost DESC
LIMIT 10

結果

結果は次のとおりです(料金が大きい上位3件を抜粋)。

なお、以下の値は実際の値ではなく、仮の値に置き換えています。

billing_origin_productendpoint_nameapp_namecreated_bydbudbu_cost
VECTOR_SEARCHendpoint1nullA@—.jp2000.02800.00
APPSnullapp1B@—.jp24.34526.35
APPSnullapp2C@—.jp20.00121.665

おわりに

本記事では、AWS上のDatabricksを対象に、DBU料金を実績ベースで確認する方法を紹介しました。DBU料金は「消費したDBU数 × DBU単価」で求められ、使用量は system.billing.usage、単価は system.billing.list_prices で確認できます

月次の料金の確認や、料金の内訳の分析に、この方法を活用してみてください。

参考文献

CTA
ナレッジ
AI databricks データ分析 データ活用 料金計算
  • URLをコピーしました！
  • URLをコピーしました！
この記事を書いた人
小山佳祐のアバター 小山佳祐
関連記事
目次