Databricks Lakehouse: データレイクがついにウェアハウスと出会う場所

この10年間、まともなデータプラットフォームはどれも2つのシステムで動いていた。すべてを安価なオブジェクトストレージに投げ込むデータレイクと、ビジネスが実際にクエリするクリーンでモデル化されたテーブルを提供するデータウェアハウスだ。データのコピーが2つ、パイプラインが2セット、請求書が2枚、そしてどちらが真実を保持しているのかという終わりのない論争がついてくる。

lakehouse は、その分裂を1つに畳み込もうとする試みだ。Databricks はストレージもファイルフォーマットも発明していないが、そのパターンをチームが本番で運用できる形に仕立て上げた。この種の構築をいくつか手がけたうえで、何が本物で何がマーケティングなのかをここで示そう。

2つの世界、そしてなぜチームは両方を使ったのか

データレイクはオブジェクトストレージ——Azure Data Lake Storage Gen2、S3、GCS——であり、あらゆる形式の生ファイルを保持する。安価で、無限にスケールし、schema-on-read だ。つまり構造を決めるのは書き込み時ではなくクエリ時である。その代償として、規律のないレイクは沼になる。トランザクションもなければスキーマの強制もなく、1行だけ更新する簡単な方法もない。

ウェアハウスはその正反対だ。構造化されたテーブル、ACID 保証、高速な SQL、本物のガバナンス。その代償は硬直性と価格だ。データを取り込むのに金を払い、専有ストレージに金を払い、生ファイルを求める機械学習ワークロードはこのモデルに収まらない。

両方を使うということは、両者間でデータをコピーし、そのコピーを永遠に整合させ続けることを意味する。lakehouse の問いはシンプルだ。もしレイクが2つ目のコピーなしにウェアハウスのように振る舞えたら?

lakehouse とは実際のところ何か

その仕掛けは、オブジェクトストレージ上のファイルに重ねられたオープンなテーブルフォーマットだ。Databricks ではそれが Delta Lake であり、Parquet のデータファイルにトランザクションログを加えたものである。そのログこそがすべてだ。これが与えてくれるのは:

• ACID トランザクション — 並行書き込みがテーブルを破損させることはもうない。
• スキーマの強制と進化 — 不正なデータは拒否され、良い変更はバージョン管理される。
• Time travel — 先週の火曜日の状態でテーブルをクエリしたり、不良ロードをロールバックしたりできる。
• Upsert と削除 — MERGE が機能する。これは GDPR の削除要求や change-data-capture にとって重要だ。

データは自分のストレージアカウント内でオープンな Parquet のまま残るので、単一のコピーがすべてを賄う。SQL ダッシュボード、ストリーミングジョブ、ML の学習が同じテーブルを読む。バイトに対するロックインもなければ、エクスポートの工程もない。それが見返りだ。

medallion アーキテクチャ

lakehouse はプリミティブを与えてくれる。medallion アーキテクチャはそれを整然と保つ方法だ。データは3つの品質階層を流れていく:

1. Bronze — 生の取り込み、到着したそのまま。追記専用、監査可能、決して編集しない。
2. Silver — クレンジング、重複排除、整形済み。結合され型付けされているが、まだ粒度は細かい。
3. Gold — ビジネスレベルの集計とスタースキーマで、ダッシュボードやレポートが消費する。

ツールよりも規律のほうが重要だ。Bronze はあなたの保険証券である——Silver の変換が間違っていたら、ソースから再取り込みするのではなく Bronze から再処理する。これを省くと、履歴を修正する能力を失う。

Unity Catalog: 後から付け足せないガバナンス

Unity Catalog は、多くのチームが過小評価するピースだ。これはすべてのワークスペースにまたがる単一のガバナンス層である。きめ細かなアクセス制御、列・行のマスキング、そして——監査であなたを救う部分——自動的なリネージだ。どのレポートがどの Gold テーブルに依存し、それがどの Silver ジョブに依存し、生ファイルまで遡れるのかを見通せる。

ガバナンスは、テーブルが500個になり誰が何を読めるのか誰も分からなくなってから後付けするような機能ではない。テーブル1個目で有効にせよ。後から移行するコストは残酷だ。

パフォーマンス: Photon と SQL warehouse

レイクへの古い反論は速度だった。ファイルへのクエリはチューニングされたウェアハウスに太刀打ちできない、と。2つのものがその差を埋めた。Photon は C++ で書かれたベクトル化クエリエンジンで、コードを変えずに SQL や DataFrame のワークロードを高速化する。そして Databricks SQL warehouse はアナリストに馴染みのあるエンドポイントを提供する。彼らは BI ツールをつないで Gold テーブルをクエリするが、その下にオブジェクトストレージがあることには気づかない。

ストレージとコンピュートは分離されているので、重い月末処理のためにクエリクラスタをスケールアップし、その後データに触れることなくスケールダウンできる。その弾力性こそ、クラウドの経済性が本当にあなたに有利に働くところだ——穏やかな AI プラットフォームで私が主張するのと同じ規律である。

lakehouse が間違った答えになるとき

これは万能のアップグレードではない。スケールについて正直になろう:

• 小さく、純粋にリレーショナルなデータ。 すべてが Postgres に余裕で収まり、BI だけを提供するなら、マネージドウェアハウスのほうがシンプルで安い。lakehouse は必要のない機械仕掛けだ。
• エンジニアリングの余力がない。 Delta、クラスタ、medallion のフローは、いずれも現実の運用負担だ。小さすぎるチームは溺れる。
• 純粋で安定したスタースキーマだけで、ML もストリーミングもない。 lakehouse はワークロードが混在するときに輝く。あなたのそれが決して混在しないなら、その柔軟性は死荷重だ。

---

lakehouse がその居場所を勝ち取るのは、本当に両方の世界を抱えているとき——生データとストリーミングデータが ML を養い、かつクリーンなテーブルがビジネスを養っているとき——そして両者を同期させ続けるために二重に払うことにうんざりしているときだ。Delta と medallion の階層から始め、Unity Catalog をすぐに有効にし、速度は Photon に任せよう。このシリーズの次回は、Microsoft がFabric、OneLake、Copilot Studio で同じ勝負をどう戦うかを見ていく。