Databricks とレイクハウスの全体像 — なぜ必要か、何がどこに属し、どの計算資源で動くか

1.1データ基盤とレイクハウス — なぜ Databricks という製品が要るのか

同じ「昨日の注文数」が二つ出てきて、どちらが正しいか誰も言えない

経理は売上テーブルを見て「昨日の注文は 12,430 件」と言い、分析チームは Amazon S3 の JSON ログを数えて「12,502 件」と言う。現場でいちばん多い揉め事です。原因は同じ事実が二か所に別々のコピーとして置かれていることで、片方だけ再取り込みが走った瞬間から数字はずれ始めます。

置き場が二つに分かれたのにも理由があります。ひとつ目のデータウェアハウスは、列と型を先に決めた表しか受け付けません。集計は速く数字も必ず合いますが、アクセスログ、センサーの生データ、PDF、画像、音声は入りません。保存単価も高く、生ログを何年も置く用途には向きません。

もうひとつがデータレイクです。Amazon S3、Azure Data Lake Storage、Google Cloud Storage といったオブジェクトストレージにファイルをそのまま置くだけなので、何でも入り、容量単価は桁違いに安く済みます。困るのはここからで、置き場には表という概念もトランザクションという概念もありません。次の四つが壊れます。

• 書きかけが読まれます。数百ファイルを書いている途中で読み手が来ると、半分だけのデータを正しい結果として返します。
• 失敗が戻せません。上書きが途中で落ちると、古くも新しくもない中途半端な状態が残ります。
• 列が揃いません。同じフォルダのファイルに列が一本増えても型が変わっても、誰も止めません。
• 行の更新と削除ができません。個人情報の削除依頼が来ても、ファイルを丸ごと作り直すしかありません。

この四つはまとめて「ACID トランザクションがない」と言い換えられます。ACID とは原子性 (途中まで反映された状態を残さない)、一貫性、分離性 (他人の書きかけが見えない)、永続性の頭文字で、データベースなら当たり前に備える性質です。読むたびに壊れていないか確かめる必要があるレイクを、データスワンプ (沼) と呼びます。レイクハウスとは、データレイクの安さと自由さを保ったまま ACID を取り戻した状態を指します。

Delta Lake は新しい形式ではなく、Parquet の隣に置いた台帳

先に土台のファイル形式を押さえます。Databricks が扱うデータ本体は Parquet です。行ごとにテキストが並ぶ CSV と違い、列ごとにまとめて格納・圧縮し、データブロックごとに最小値や最大値の統計を埋め込みます。`SELECT amount FROM sales WHERE dt = '2026-08-01'` のようなクエリで、不要な列を読み飛ばし、条件に合わないブロックを開かずに済ませられます。

Delta Lake がやったのは、新しいファイル形式の発明ではありません。データ本体は Parquet のままで、テーブルのディレクトリ直下に `_delta_log/` という台帳を一つ置いただけです。いまのテーブルがどのファイルでできているかを、ファイルの存在ではなく台帳で決めます。

`_delta_log/` にはコミットのたびに `00000000000000000001.json` のような 20 桁ゼロ埋めの JSON が積まれ、「このファイルを追加した」「このファイルを外した」という操作が記録されます。JSON が増えると読み直しが遅くなるので、途中までを畳み込んだチェックポイントファイルが書かれます。この間隔は従来 10 コミットごとと説明されてきましたが、現在の Databricks はデータ量とワークロードに応じて自動調整しており、固定値の保証はありません。形式も Parquet 一択ではなく、UUID 名の V2 チェックポイントは JSON でも書けます。同じディレクトリには位置を示す `_last_checkpoint` や検証用の `<version>.crc` も入り、「二種類だけ」ではありません。

読み手はデータファイルを直接列挙しません。台帳を再生して「このバージョン時点で有効なファイルはこれとこれ」という一覧を組み立て、そのファイルだけを読みます。書きかけのファイルは台帳に載らないので、原理的に読まれません。逆に Parquet が全部残っていても、`_delta_log/` を消した時点でテーブルは失われます。台帳はテーブルと同じクラウドストレージに残るので、計算資源を落としても消えません。処理の途中データが置かれるワーカーのローカルディスク `/local_disk0` とも、権限定義を持つメタストアとも役割は別です。

同時に書かれたら後発を失敗させ、過去は台帳から読み直す

二つのジョブが同じテーブルに同時に書いたらどうなるか。Delta Lake はリレーショナルデータベースのような行ロックで直列化しません。オブジェクトストレージでロックを取るのは高くつくからです。代わりに楽観的同時実行制御を使います。各書き手は読み始めた時点のバージョンを覚えておき、コミットする瞬間に `_delta_log/` の最新バージョンと突き合わせ、衝突していれば後から来たほうが `ConcurrentAppendException` などを投げて自分を失敗させ、再試行に回ります。「最後に書いた人が勝つ」方式でも、後から辻褄を合わせる結果整合性でもないので、他人の書き込みが黙って消えることはありません。

台帳が残るので過去も読めます。`SELECT * FROM sales VERSION AS OF 12` や `SELECT * FROM sales TIMESTAMP AS OF '2026-01-01T00:00:00'` は、その時点のスナップショットを読むだけで、テーブルの現在の状態は変えません。実際に巻き戻すのは `RESTORE TABLE sales TO VERSION AS OF 12` という別の DDL、履歴の一覧は `DESCRIBE HISTORY sales` です。読むだけ・書き戻す・一覧する、この役割分担がそのまま出題されます。

戻れる期間は無限ではありません。ログの保持期間 `delta.logRetentionDuration` の既定は 30 日、削除済みデータファイルの保持期間 `delta.deletedFileRetentionDuration` の既定は 7 日 (interval 1 week) です。`VACUUM` は後者を過ぎた不要ファイルを実際に削除するので、実行後は 7 日より前へのタイムトラベルが失敗します。

台帳が一本あるだけで、できることが四つ増える

ひとつ目はスキーマ強制です。列が足りない、型が違うという書き込みはコミットの手前で弾かれ、沼になる前に止まります。意図して列を増やすときだけ `.option("mergeSchema", "true")`、型や分割まで作り替えるときは `.option("overwriteSchema", "true")` を明示します。ふたつ目は行単位の更新です。オブジェクトストレージのファイルは本来置き換えることしかできませんが、Delta なら `UPDATE`、`DELETE`、条件に応じて更新か挿入かを振り分ける `MERGE INTO` が書けます。個人情報の削除依頼に応える運用も、これがないと成り立ちません。

三つ目は、ストリーミングの書き込みと日次バッチの読み出しが同じ台帳の上で矛盾なく同居することです。四つ目がメダリオンアーキテクチャで、生データをそのまま受けるブロンズ、型と重複を整えたシルバー、集計して BI に出すゴールドの三段で磨き上げる作り方です。各段がすべて Delta テーブルなので、途中で失敗しても手前の段は壊れず、過去バージョンから作り直せます。この四つはいずれも `_delta_log/` 一本の上に成り立っており、台帳を持たない素の Parquet ディレクトリを「テーブル」と呼んでも何ひとつ使えません。

計算エンジンとガバナンスまで束ねたのが Databricks

置き場所が決まっても、計算する仕組みと、誰に見せるかの管理はまだありません。Databricks Data Intelligence Platform は、その三つを一枚にまとめた製品です。計算を担うのは Apache Spark という分散処理エンジンで、一台では終わらない処理を多数のマシンに分けて並列に走らせます。Python から呼ぶ API が PySpark、SQL で書いても同じエンジンが動きます。この Spark の実行環境をひとまとまりにしたものがクラスタで、第 3 節で選び分ける対象がこれです。

製品の構成は二層です。コントロールプレーンは Web 画面、ノートブックの管理、ジョブのスケジューラなど、Databricks が自社のアカウントで運用する部分です。コンピュートプレーンは実際にデータが処理される部分で、クラシックコンピュートプレーンは利用者自身のクラウドアカウントの中に仮想マシンが立ち、サーバーレスコンピュートプレーンは Databricks 側のアカウントで動きます。どちらでもテーブルの本体は利用者のクラウドストレージに置かれたままです。

この分かれ方が請求の形をそのまま決めます。クラシックでは仮想マシンが自社アカウントで動くので、Databricks からの請求とクラウド事業者からの請求が別々に届きます。土台の上には、ノートブック、スケジュール実行を担う Lakeflow Jobs、宣言的なパイプライン、BI 用の SQL ウェアハウス、そして権限を一手に握る Unity Catalog が並びます。入口が違ってもテーブルは同じ Delta テーブルで、権限判定も同じ Unity Catalog です。だからこそ「Databricks を使う」ことと「データを Databricks に移す」ことは別で、クラスタを消してもテーブルは消えませんし、テーブルを消してもクラスタの設定は残ります。

1.2アカウント・ワークスペース・Unity Catalog 三層 — 何がどこに属するか、Workspace 検索の type: フィルタで何を探せるか

「権限をもらったのに見えない」の半分は、層を取り違えている

同僚に本番テーブルの権限を付けたのに「一覧に出てこない」と言われる。逆にクラスタは作れるのにテーブルが空に見える。Databricks でよく起きるこの手のすれ違いは、権限の付け方が下手なのではなく、その資産がどの層に属しているかを取り違えていることが原因です。層は三つあり、管理画面もそれぞれ別です。

この表が読めると、冒頭のすれ違いが解けます。テーブルが見えないのは Unity Catalog の `GRANT` の話、ノートブックが開けないのはワークスペースの ACL の話、クラスタが作れないのはポリシーの `Can Use` の話で、三つはまったく別系統です。片方をいくら足しても、もう片方は開きません。ポリシーの `Can Use` はテーブルの `SELECT` とは無関係で、逆も同じです。

Unity Catalog は catalog.schema.object の三階建て

Unity Catalog のメタストアはリージョンごとに一つ作るのが原則で、作成できるのはアカウント管理者です。同じリージョンなら何個のワークスペースにでも紐づけられ、紐づいたワークスペースはどれも同じデータの見え方になります。ワークスペースを作り直してもテーブルと `GRANT` はメタストア側に残り、消えるのはクラスタやジョブ定義のほうです。

メタストアの下は `catalog.schema.object` という三階層の名前空間で、`SELECT * FROM sales_prod.bronze.orders` のように三つ繋げて書きます。object にはテーブルやビューだけでなく、関数、機械学習モデル、そしてボリュームも並びます。ボリュームは CSV、PDF、画像、初期化スクリプトのような表にならないファイルの置き場で、テーブルと同じく `GRANT` の対象になり監査ログに残ります。「表になるものはテーブル、ならないものはボリューム」で迷いません。ボリュームはコードを実行する仕組みではなく、あくまでファイルの置き場です。テーブルとボリュームにはマネージドと外部の二種類があり、マネージドは保存場所も Unity Catalog が面倒を見ます。なおストレージ資格情報、外部ロケーション、接続、共有はカタログの下ではなくメタストア直下に置かれます。

ワークスペースの中を探すときは type: で絞る

ワークスペースが育つと、半年前に誰かが作ったノートブックが行方不明になります。画面上部のグローバル検索バーはキーワードだけでなく絞り込み構文を受け付けます。

• `type:notebook` `type:dashboard` `type:query` `type:job` `type:table` `type:file` `type:folder` `type:alert` — 種別で絞ります。
• `owner:me` — 自分が所有するものだけに絞ります。
• `tag:<key>` / `tag:<key>:<value>` — 付与したタグで引きます。
• `trashed:true` — ごみ箱の中を探します。二重引用符で囲めば完全一致です。

索引の対象はファイル名だけではありません。ノートブックはコードセルと Markdown セルの本文まで索引されているので、うろ覚えの関数名から引き当てられます。Unity Catalog が有効なら、テーブル名に加えてコメントや列名も引っかかります。ただし顧客管理キーで暗号化したワークスペースではノートブック本文とクエリ本文が検索できず、`type:table` でヒットするのは Unity Catalog に登録されたテーブルだけです。検索は管理者専用ではなく、閲覧権限のあるユーザーなら誰でも使えます。

コードはワークスペースの中にも外にも置ける

三層で整理しても、ひとつ残る問いが「コードはどこにあるのか」です。Git フォルダ (旧 Repos) は GitHub などのリポジトリをワークスペース内にクローンする機能で、コード本体はワークスペース側に置かれ、ブランチ操作をブラウザから行えます。

ノートブックどうしを繋ぐのが `%run ./notebook_b` です。これは対象ノートブックを呼び出し元と同じ Python グローバルスコープで実行するマジックコマンドで、独立したプロセスは立ちません。A で `x = 10` と定義してから B を `%run` し、B に `y = x + 5` があれば `y` は `15` になります。セルに単独で書く必要があり、引数は渡せず、ライブラリのバージョン解決もしません。引数を渡して戻り値を受け取りたいなら `dbutils.notebook.run()` を使います。こちらは別ジョブとして起動し、`timeout_seconds` を指定でき、`dbutils.notebook.exit()` の文字列が戻ります。

三つ目が Databricks Connect です。VS Code や PyCharm といったローカルの IDE でコードを書き、DataFrame API の呼び出しだけを Databricks のコンピュートへ送って実行します。必要なのは Databricks Runtime 13.3 LTS 以上 (LTS は長期サポート版の意味) で、対応言語は Python と Scala、接続先はクラシックなクラスタでもサーバーレスでも構いません。手元では補完、型検査、ブレークポイント、`pytest`、CI/CD がそのまま使えます。誤解しやすいのは、これが速くなる仕組みでもガバナンスの抜け道でもないことです。計算はクラスタ側で走り、認証も Unity Catalog の権限もそのまま適用されます。`%run` はノートブック専用のマジックなので、Databricks Connect からは使えません。

1.3コンピュートの選び分け — All-Purpose / Job / Serverless / SQL Warehouse と課金の考え方

請求書は二通届く。まずそこから理解する

Databricks で最初に驚くのは、請求が一本ではないことです。Databricks からは DBU の請求が、クラウド事業者からは仮想マシンとストレージの請求が、別々に届きます。クラシックコンピュートプレーンでは仮想マシンが自社のクラウドアカウントに立つからです。

DBU (Databricks Unit) は処理能力の消費量を表す単位です。消費量を決めるのは仮想マシンのサイズと種類で、1 DBU-hour あたりの米ドル単価をワークロード種別とプランが決めます。Azure Databricks の Premium ティアでは All-Purpose Compute が $0.55/DBU-hour、Jobs Compute が $0.30/DBU-hour で、対話用はバッチ用の約 1.8 倍です。Standard ティアは $0.40 と $0.15 で約 2.7 倍と、比率はティアで変わります。

使った量は `system.billing.usage` システムテーブルで見ます。`usage_date`、`sku_name`、`usage_quantity`、`usage_unit` (通常は `DBU`)、`workspace_id`、`custom_tags`、`usage_metadata.job_id` といった列があり、単価表 `system.billing.list_prices` と `sku_name` で結合すれば金額になります。クラスタに付けたタグはここへ伝播するので、チーム別の按分はタグ設計で決まります。反映には最大 24 時間ほどの遅れがあります。

四種類ある理由は「いつ起きて、いつ止まるか」の違い

選定の軸は二つだけです。ワークロードの種別 (バッチか、対話的か、共有か) と、起動レイテンシおよびアイドル時の課金の扱い。リージョンやテーブルの保存形式は決定打になりません。

All-Purpose はアクセスモードで性格が変わります。標準 (Standard、旧 Shared) アクセスモードなら複数ユーザーで一台を共有でき、データ分離は Unity Catalog が担保します。専用 (Dedicated、旧 Single user) は一人またはグループの専有です。毎晩一度の ETL は Lakeflow Jobs の `new_cluster` 指定で Job Compute として起こします。SQL 専用のウェアハウスで PySpark ノートブックは実行できません。

クラスタはドライバ 1 台とワーカー N 台でできている

クラシックなクラスタは、指揮役のドライバ 1 台と、実際に処理を走らせるワーカー N 台という構成です。タスクの実体はワーカーが実行し、台数・コア数・メモリが処理能力を決めます。ドライバは処理の依存関係グラフ (DAG) の構築とスケジューリング、`collect()` や `toPandas()` の結果集約を担い、原則タスク実行には参加しないので、ワーカーより一段小さくしても通常は問題ありません。

大規模な JOIN では、同じキーのデータを同じノードへ集め直すシャッフルが起きて最大のボトルネックになります。メモリ最適化型 (AWS の r5 系、Azure の E シリーズ) を複数台並べるのが定石です。中間ファイルは直付けのローカル SSD に置かれ、高速な代わりにインスタンスが止まれば消えます。Single Node はドライバ 1 台が兼務する構成で、小規模検証向きです。

自動終了 `autotermination_minutes` は 10〜10,000 分 (約 7 日) の範囲で、UI の既定は 120 分、`0` で無効です。終了処理の間もクラスタが Running なら課金は続きます。起動待ちを減らすならインスタンスプールで、`min idle instances` の在庫は自動終了の設定に関わらず残り、スケールアウトはまず在庫から割り当てます。プールで待機中は DBU が課金されず、クラウドの仮想マシン料金だけがかかります。

サーバーレスは待たない代わりに、握れるつまみが減る

サーバーレスは Databricks 側の在庫から即座に割り当てるため起動が秒単位で、終われば解放されアイドル課金もありません。`spark.stop()` も停止ボタンも不要です。余裕を持たせた容量 (オーバープロビジョニング) のコストは Databricks 側が吸収し、利用者は消費した分だけ払います。

連続実行の上限は 7 日です。SQL ウェアハウスも同じ考え方で、Auto stop の既定はサーバーレスが 10 分 (UI の最小は 5 分)、Pro と Classic が 45 分 (最小 10 分)。サイズは 2X-Small (ワーカー 1 台) から倍々で 4X-Large の 256 台まで。クラスタ数の既定は最小・最大とも 1 で、同時実行クエリ 10 件につき 1 クラスタが増設の目安、待ち行列 5 分でスケールアウト、低負荷 15 分でスケールインします。

管理者が全体に効かせる三つの道具

クラスタの暴走を止めるのがコンピュートポリシーです。JSON で属性ごとに制約を宣言します。縛れるのは `node_type_id`、`num_workers`、`autoscale.max_workers`、`spark_version`、`runtime_engine`、`autotermination_minutes`、`custom_tags.*` などで、仮想属性の `dbus_per_hour` も使えます。SQL ウェアハウスはポリシーの対象外で、ストレージへの書き込み可否も対象外です (Unity Catalog の外部ロケーションとストレージ資格情報の責務)。権限は `Can Use` で、「そのポリシーを選んでクラスタを作れる」という意味にすぎず、JSON 定義の編集権限ではありません。

`randomize` のような型は存在しません。二つ目が init script、クラスタ起動時にドライバとワーカーで走る bash です。スコープは cluster-scoped と global の二つで、notebook-scoped という分類はありません (それはライブラリの話です)。global は管理者だけが登録でき、上限 64KB、cluster-scoped より先に実行されますが、動くのは専用 (dedicated) アクセスモードと従来の no-isolation shared モードのクラスタだけで、標準アクセスモードでは走りません。保存先は Unity Catalog の Volumes (Databricks Runtime 13.3 LTS 以上で推奨。LTS は長期サポート版)、ワークスペースファイル (500 MB まで)、クラウドストレージで、DBFS (旧来のファイルシステム) 上の init script はサポート終了済みで動きません。消すと以後の起動が失敗します。

三つ目がライブラリで、クラスタスコープ (クラスタ設定の Libraries、全ノートブックで共有) とノートブックスコープ (`%pip install`) の二本立てです。全ワークスペースへ強制配布する独立機能はありません。クラスタ設定は Clusters UI の `JSON` タブや Clusters API で書き出せ、消したクラスタも同一構成で作り直せます。

1.4Photon は何を速くし、何を速くしないか — 効くケースと -photon / runtime_engine による有効化

「Photon を入れたのに速くならず、単価だけ上がった」の正体

Photon はチェックボックス一つで有効になるので、とりあえず入れてみる人が多い機能です。そして一定の割合で「実行時間は変わらないのに DBU の消費だけ増えた」という結果になります。原因はほぼ例外なく、そのジョブの重い部分が Photon の守備範囲の外にあることです。

Photon は Databricks が C++ で書き直したベクトル化クエリエンジンです。JVM 上で動く Spark の実行部分を差し替え、列単位でまとめて処理して CPU を使い切ります。API は変わらないので、既存の SQL や DataFrame のコードは書き換えなしでそのまま速くなります。効くのは Delta や Parquet のスキャン、フィルタ、集計、結合、書き込みといったベクトル化できる処理で、SQL 分析、ETL、パイプライン、ステートレスなストリーミングが対象です。大きなデータを長い時間かけて舐めるクエリほど差が出ます。GPU は使いません。あくまで CPU 上で動く別実装です。

効かないケースをはっきりさせる

Photon は UDF (ユーザー定義関数)、RDD API、Dataset API、ステートフルなストリーミングをサポートしません。RDD は DataFrame より低水準の古い API で、UDF は自分で書いた関数を SQL から呼ぶ仕組みです。非対応の演算に当たると、その部分だけ透過的に従来の Spark ランタイムへ切り替わります。エラーにはならず、静かに遅いままになるのがやっかいなところです。Python UDF や `mapInPandas` が処理時間の大半を占めるジョブで体感が変わらないのは、この仕様どおりの挙動です。効かせたいなら、まず UDF を組み込み関数や SQL 式に書き換えるのが先です。

もともと 2 秒未満で終わるクエリも、立ち上がりの分が支配的で恩恵が見えません。小さいファイルが大量にあって I/O が律速なら、Photon より先に `OPTIMIZE` でファイルをまとめるほうが効きます。よくある誤解もここで潰します。Photon はノートブック専用でも SQL ウェアハウス専用でもなく、ジョブでも汎用クラスタでも動きます。有効にしてもオートスケールは無効になりません。両者は独立していて、併用すれば「同じ処理をより少ない資源で終え、負荷が引いたら縮む」形になります。

有効化は runtime_engine か -photon 入りの Runtime

サーバーレスコンピュート、SQL ウェアハウス、サーバーレスのパイプラインでは Photon が既定で有効で、切り替える設定はありません。クラシックな汎用・ジョブコンピュートでは Databricks Runtime 9.1 LTS 以上で使え、UI の Performance にある「Use Photon Acceleration」で切り替えます。

API や Asset Bundle から設定するときは、Clusters API / Jobs API の `runtime_engine` に `PHOTON` を渡します (無効化は `STANDARD`)。Runtime 側で指定する従来の方法もあり、その場合は `spark_version` に `13.3.x-photon-scala2.12` のような `-photon` を含むビルドを書きます。この二つは併用できません。`runtime_engine` を使うなら `spark_version` から `-photon` を外します。パイプラインは Pipelines API の `photon` を `true` にします。ここで間違えやすいのが Spark の設定キーで、`spark.databricks.cluster.profile = photon` のようなキーで Photon が有効になることはありません。スイッチは Spark conf ではなく、`runtime_engine` か Runtime のビルドです。

最後にコストです。Photon 付きインスタンスの DBU 消費レートは非 Photon と異なり、時間あたりの単価は上がります。処理時間が縮む分だけ総 DBU が下がるかはワークロード次第なので、`system.billing.usage` で切り替えの前後を比べて判断します。効かないジョブに付ければ純粋な値上げです。組織全体で徹底したいなら、コンピュートポリシーで `runtime_engine` を `fixed` にして強制または禁止します。