データ基盤

Databricksとは？できること・構成・料金の仕組みを公式資料から解説

2026/10/7 シリーズ「Databricks 入門」 第1回 / 全2回

🤖 AIが執筆しています

Databricks でできること

Databricks の公式の文書は、Databricks を、企業向けのデータ・分析・AI の仕組みを大規模に作り、動かし、共有し、保守するための、統合されたオープンな分析の基盤と説明している⁶。同じ文書は用途として、レイクハウスの構築、ETL とデータエンジニアリング、機械学習と AI、大規模言語モデル、データウェアハウスと BI、データガバナンスと安全なデータの共有、CI/CD と処理の自動化、リアルタイムの分析、オンラインの取引の処理を挙げている。最後の取引の処理は、Databricks が管理するストレージに置かれる PostgreSQL のデータベース Lakebase が担う。

レイクハウスの文書は、Databricks の中心を三つの技術で説明する⁷。Databricks は Apache Spark の上に作られており、Spark は保存の場所と切り離された計算資源の上で、大規模な処理を動かす。そのうえで、ACID トランザクション（複数の変更を全部か無かのどちらかで確定させる仕組み）とスキーマの強制を担う保存の層 Delta Lake と、データと AI をきめ細かく管理する Unity Catalog を使う。表のデータは主にクラウドのオブジェクトストレージに置く。

成り立ちを短くまとめると、Spark は 2010 年に公開され⁸、カリフォルニア大学バークレー校の研究者らによる 2012 年の論文で、その中心の仕組みが発表された⁹。Spark を作ったチームは 2013 年に、Spark を中心とする会社として Databricks を立ち上げた⁸。Delta Lake は 2019 年にオープンソースとして公開され¹⁰、Databricks の研究者ら（創業者を含む）は 2021 年の論文で、オブジェクトストレージの上にデータベースの機能を持たせたレイクハウスを提唱した¹¹。

構成：Databricks のアカウントとクラウドのアカウント

Databricks の構成を読むには、「アカウント」という語の二つの意味を分けておく必要がある。一つは Databricks のアカウントで、会社が Databricks と契約して持つ管理の単位である。もう一つはクラウドのアカウントで、会社が AWS・Azure・Google Cloud のいずれかと契約して持つ単位を指す（Azure ではサブスクリプションと呼ぶ）¹²。公式の文書も、コントロールプレーンは利用者のクラウドのアカウントではなく Databricks のアカウントにある、というように二つを区別して書いている³。計算資源と保存先を自社のクラウドのアカウントに置くのはクラシックの方式で¹³、サーバーレスのワークスペースでは、既定でどちらも Databricks が用意する。そのため、クラウドの基盤を用意する権限を持たない管理者でも、サーバーレスのワークスペースなら作れる¹⁴。個人向けの無料版 Free Edition も、登録すれば Databricks がワークスペースを用意し、計算資源はサーバーレスに限られ、既定の保存先が付いてくる¹⁵。

構成：アカウント、ワークスペース、メタストア

Databricks の管理の単位は、アカウント、ワークスペース、メタストアの三つで、一つのアカウントの中に複数のワークスペースとメタストアを置ける³。東京リージョンだけで Databricks を使う会社が、分析のチーム用と機械学習のチーム用に、二つのワークスペースを作る場合を例に取る。

Databricks のアカウントは、組織全体の Databricks を管理する最上位の単位である。管理者はここで、利用者とグループを登録し、ワークスペースを作り、メタストアを作ってワークスペースにつなぎ、利用料の請求を確かめる。

ワークスペースは、利用者がログインして実際に作業する場である。ノートブック（コードと実行結果を一つの画面に並べて書き進める文書）で対話的に分析し、決まった時刻に自動で動く処理であるジョブを動かし、機械学習のモデルを学習させる。会社は、ワークスペースを一つだけ持つことも、用途に応じて複数持つこともできる¹⁶。先の会社は、チームごとに二つを持つ。

メタストアは、Unity Catalog の中で、どの表やモデルがあり、だれが何をしてよいかを管理する最上位の入れ物である。メタストアは一つのリージョンに一つで、そのリージョンのワークスペースはそれを共有する¹⁷。先の会社は、東京リージョンのメタストア一つを、二つのワークスペースにつなぐ。データは、カタログ・スキーマ・表の 3 段の名前で呼ぶ。分析のチームが作った表 sales.retail.orders（カタログ sales、スキーマ retail、表 orders）は、読む権限を与えられた利用者なら、機械学習のチームのワークスペースからも同じ名前で読める。あるワークスペースで与えた権限は、同じメタストアにつながる他のワークスペースでも効く¹⁷。既定ではカタログはつながる全ワークスペースから使え、特定のワークスペースに限ることもでき、限ったカタログは、結びつけていないワークスペースからは権限があっても使えない¹⁷。ワークスペースは作業の場を分け、メタストアはデータとその権限をまとめる、という役割の分担である。

構成：コントロールプレーンとコンピュートプレーン

次に、どこで何が動くかで整理できる。公式の文書によれば、Databricks はコントロールプレーンとコンピュートプレーンで動く³。コントロールプレーンは、Databricks が管理する裏側のサービスで、ブラウザで開く画面もここで動く。コントロールプレーンは Databricks が運用し、会社の Databricks のアカウントに属するが、会社のクラウドのアカウントの中には無い。

コンピュートプレーンは、データを実際に処理する仮想マシンが動く場所で、二つの種類がある。クラシックのコンピュートプレーンは、会社のクラウドのアカウントの中にある。新しい計算資源は、会社のクラウドのアカウントにある、ワークスペースごとの仮想ネットワークの中に作られ³¹²、処理はそれらの仮想マシンを組にしたクラスターで動く¹⁸。サーバーレスのコンピュートプレーンも、ワークスペースと同じリージョンにあるが、会社のクラウドのアカウントではなく、会社の Databricks のアカウントの側にある³。会社のクラウドのアカウントには計算資源を用意せず、Databricks が必要な計算資源を割り当てて管理する⁴。

ワークスペースにも、クラシックとサーバーレスの二種類がある。クラシックのワークスペースでもサーバーレスのコンピュートを使えるが¹³、逆に、サーバーレスのワークスペースでは全ての処理がサーバーレスのコンピュートで動く¹⁴。ワークスペースの種類は保存先も変える。ワークスペースが内部で使うデータの保存先は、クラシックのワークスペースでは会社のクラウドのアカウントのオブジェクトストレージ（AWS なら S3 のバケット）で、サーバーレスのワークスペースでは Databricks が管理する既定の保存先である³。サーバーレスのワークスペースからも、会社のオブジェクトストレージにあるデータに接続できる¹³。

したがって、クラシックのワークスペースでクラシックのコンピュートを使えば、計算と保存先を会社のクラウドのアカウントの中に置ける。それでも、画面やワークスペースの管理に使うデータベースはコントロールプレーンにあり³、機械学習のモデルを動かす Model Serving も Databricks が管理する側で動くので¹⁹⁴、すべてが会社のクラウドのアカウントに収まるわけではない。

エンジンと形式：オープンなのは形式で、エンジンには独自の部分がある

Databricks の文書は、Databricks の基盤では独自のデータの形式は使わないと書く²⁰。表は Delta Lake の形式で保存し、Apache Iceberg のクライアントからも読める。一方で、処理のエンジンには独自の部分がある。Spark についての公式の説明によれば、Databricks で動く Databricks Runtime は、Apache Spark を基にした追加の最適化と独自の機能を含み、その一つが、クエリをベクトル化して速く実行する層 Photon である²¹。オープンなのはデータの形式であり、エンジンや管理のサービスまでオープンとは限らない。

料金の仕組み：DBU と仮想マシンの代金

Databricks の料金は、DBU という単位で数える。公式の文書は DBU を、仮想マシンの種類に応じた、1 時間あたりの処理能力の単位と説明する¹⁶。一方、料金のページは DBU を、処理能力を正規化した単位とし、消費する DBU の量を決める指標には、使った計算資源や処理したデータの量などが含まれうると書き、利用は秒単位で計算すると説明している²²。前者は仮想マシンの種類と時間で数える場合を述べ、後者は処理したデータの量で数える場合も含めている。

DBU のほかに、クラウドの事業者への支払いがある。費用の最適化の文書は、総費用は DBU に仮想マシン・ディスク・ネットワークの費用を加えたもので、サーバーレスのサービスでは DBU の費用に仮想マシンの費用が含まれると書く⁵。同じ文書は、対話的でない処理をジョブ用のコンピュートで動かすと、汎用のコンピュートより大幅に安くなるとも書いている。サーバーレスのワークスペースでは既定の保存先も会社のクラウドのアカウントの外にあり、その利用は Databricks の利用として記録され、クラウドの事業者のクレジットや割引は効かない¹⁴。料金のページは、保存の使用量を数える単位として DSU（Databricks ストレージユニット）も定めている²²。コンピュートの選び方の文書は、多くの自動化された処理にはサーバーレスを勧め、自動化された処理に汎用のクラシックのコンピュートを使うのは一般に避けるよう書いている²³。ただし実務者の Beach は 2025 年 4 月の記事で、サーバーレスは中の動きが見えにくいとして、数分で終わる短い処理を除けばたいていは避けるよう書いており、公式の推奨と意見が分かれている²⁴。

試しに使うための Free Edition もある。2025 年 6 月に発表され²⁵、同じ年に終了した Community Edition に代わった¹⁵。ただし、サーバーレスのみで使う量に上限があり、R と Scala は使えず、ワークスペースは一つで、商用の利用はできない²⁶。

6つの基本原則：Databricks を使うときの判断の基準

Databricks は、構成の選び方の前提として、6つの基本原則を示している²⁷。公式の文書はこれを、アーキテクチャを定め、それに影響を与える「レベル 0」のルールと呼ぶ。

1. データをキュレーションし、信頼できるデータを製品として提供する。
2. データサイロを排除し、データの移動を最小化する。
3. セルフサービスによる価値の創造を広げる。
4. 組織全体のデータと AI のガバナンスの方針を採る。
5. オープンなインターフェースとオープンなフォーマットを奨励する。
6. 性能と費用のために、規模に応じて伸縮し最適化できるように作る。

原則の本文は、原則 1 でデータを層に分けて段階ごとに品質を上げること、原則 2 で業務が依存する写しを作らず共有の仕組みでデータを渡すこと、原則 6 で保存と計算を分け、必要なときだけ計算資源を足すことを求めている²⁷。原則を Unity Catalog や Delta Lake といった個々の製品に結びつける対応表は公開されていない。本稿は、原則 4 は Unity Catalog に、原則 5 は Delta Lake の形式に現れると考える。ジョブの管理や CI/CD のような運用の仕組みに対応する基本原則は無く、運用は、基本原則とは別に Databricks が示す 7 つの評価の柱の一つ「運用の優秀性」で扱われる²⁸。

外から見た Databricks

独立した研究者の Stonebraker と Pavlo は 2024 年の論文で、クラウドの大手のサービスとは別にデータレイクのデータを処理するシステムとして、Dremio・PrestoDB・Trino と並べて Databricks を挙げた²⁹。同じ論文は、オープンな形式でオブジェクトストレージに置く方式が、今後 10 年の分析用データベースの典型になると見ている。Pavlo は 2024 年を振り返る 2025 年 1 月の記事で、Databricks と Snowflake の争いが、かつての問い合わせの速さをめぐるものから、大規模言語モデルやカタログといったデータ管理の他の領域へ広がったと書いている³⁰。

実務者からは、Databricks の説明の仕方への批判もある。分析ツールの業界で発信している Stancil は 2022 年の記事で、Databricks は AI のための新しい全部入りの基盤として売るより、SQL と Python で使える大きく速いデータベースとして売るほうが伝わるだろうと推測した³¹。

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。