「分析用のDWHと、機械学習用のデータ基盤を別々に持っていて、データを二重に管理している」。大規模なデータ処理や機械学習に踏み込むと、こうした分断に悩むことがあります。Databricksは、この分析と機械学習を一つの基盤に統合する「レイクハウス」という発想で広まりました。まず、レイクハウスとは何かを押さえてください。

従来、データの置き場には2種類ありました。安価に何でも貯められる「データレイク」と、整って高速に分析できる「データウェアハウス（DWH）」です。レイクは柔軟だが分析しづらく、DWHは分析しやすいが大量の生データや非構造化データに弱い。この両者のいいとこ取りを狙うのがレイクハウスで、Databricksはその代表格です。

データレイクDWHレイクハウス
貯められるもの何でも（生・非構造化も）整った構造化データ中心何でも（生から整形まで）
分析のしやすさ低い高い高い
機械学習向く不得手なことも向く
代表クラウドストレージSnowflake等Databricks

Spark と Delta Lake が土台

Databricksは、大規模分散処理エンジン「Apache Spark」を開発したメンバーが作った会社・基盤です。Sparkは、大量のデータを多数のマシンで分割して並列処理する仕組みで、巨大なデータの変換や機械学習の前処理を得意とします。

その土台にあるのが「Delta Lake」です。安価なデータレイク（ただのファイルの集まり）に、DWHのような信頼性——トランザクション、更新・削除、過去にさかのぼる参照——を後付けする仕組みです。これにより、レイクに貯めたデータを、DWH並みの確かさで扱えます。レイクハウスが成り立つ鍵が、このDelta Lakeです。

# Spark（PySpark）で生データを読み、整えてDelta形式で保存する例
df = spark.read.json("/data/raw/events/")
clean = df.dropDuplicates(["event_id"]).filter("user_id IS NOT NULL")
clean.write.format("delta").mode("overwrite").save("/data/silver/events")

# SQLでも同じデータを分析できる
spark.sql("SELECT event_name, COUNT(*) FROM delta.`/data/silver/events` GROUP BY 1")

このように、Python（Spark）での処理とSQLでの分析を、同じデータに対して行き来できます。データ処理から機械学習、分析までを一つの基盤で完結できるのが、Databricksの世界観です。

DWHとの使い分け

「DatabricksとSnowflakeはどちらがいいか」とよく聞かれますが、出発点が違います。SnowflakeやBigQueryは「SQLで分析するDWH」から出発し、DatabricksはSparkでの「大規模処理・機械学習」から出発して、互いに領域を広げてきました。いまは機能が重なる部分も増えていますが、得意の中心は次のように分かれます。

こういう場合相性
SQLでの分析・BIが中心SnowflakeやBigQueryが扱いやすい
機械学習・大規模なデータ処理が中心Databricksが力を発揮
生データや非構造化データを大量に扱うレイクハウス（Databricks）
データエンジニアにPython/Sparkの素養があるDatabricksを活かしやすい

SQL中心の分析が主役で、機械学習はあまり使わないなら、SnowflakeやBigQueryのほうが学習コストは低くなります。逆に、機械学習や大規模なデータ加工が中核なら、Databricksの一気通貫が効きます。メダリオンアーキテクチャ（Bronze/Silver/Gold）は、もともとDatabricksが提唱した整理で、Delta Lakeと相性が良い考え方です。詳しくはメダリオンアーキテクチャの解説をご覧ください。

課金と注意点

Databricksの計算課金は、使った計算量を表す「DBU（Databricks Unit）」が軸です。これに、動かすクラウド側のサーバー費用が加わります。クラスタを動かしている間、課金が発生するので、自動停止（アイドルで止める）の設定が費用管理の基本です。

注意点として、SparkやPythonを前提とする場面が多く、SQLだけのチームには学習コストがかかります。シンプルなSQL分析が目的なら、オーバースペックになりがちです。一方で、機械学習や大規模処理まで見据えるなら、その投資に見合う力があります。自社のワークロードの中心がどこかで判断してください。

まとめ

  • Databricksはデータレイクとデータウェアハウスを統合する「レイクハウス」の代表格。
  • Spark（大規模並列処理）とDelta Lake（レイクに信頼性を付与）が土台。
  • データ処理・機械学習・分析を一つの基盤で完結できるのが強み。
  • SQL分析中心ならDWH、機械学習・大規模処理中心ならDatabricks、と中心で使い分ける。

3つのクラウドDWHの位置づけと選び方はクラウドDWH入門に、ほかの選択肢はSnowflakeとは・BigQueryとはにまとめています。レイクハウスの導入やDWHとの使い分けを一緒に詰めたいときは、DE-STKの初回スポット相談を壁打ち相手に使っていただけたらうれしいです。

よくある質問（FAQ）

Q. レイクハウスがあれば、DWHはもう要らないのですか？

A. 一概には言えません。SQLでの分析やBIが中心の組織では、SnowflakeやBigQueryのほうが手早く、学習コストも低く済みます。レイクハウスが効くのは、大量の生データや非構造化データ、機械学習まで一つの基盤で扱いたい場合です。両者を併用する組織も多く、「どちらか」でなく「中心のワークロードに合うほう」を選ぶのが現実的です。

Q. SQLしか書けないチームでも使えますか？

A. DatabricksにもSQLで分析する機能（SQLウェアハウス）があり、SQLだけでも使えます。ただ、Databricksの真価は大規模処理や機械学習にあり、そこはSparkやPythonが前提になりがちです。SQL分析だけが目的なら、SnowflakeやBigQueryのほうが素直です。将来、機械学習や大規模加工に踏み込む見込みがあるかで判断するとよいです。

Q. Delta Lakeとは結局、何ですか？

A. データレイク（安価なファイル置き場）に、DWHのような確かさを足す仕組みです。ふつうのファイルの集まりでは、更新の途中で壊れたり、過去の状態に戻せなかったりします。Delta Lakeは、トランザクション・更新削除・過去への参照（タイムトラベル）を可能にし、レイクのデータをDWH並みに安心して扱えるようにします。これがレイクハウスを支える中核技術です。

Q. Sparkの知識がないチームには、導入は難しいですか？

A. ハードルはありますが、越えられないものではありません。日々の分析はSQLで進められますし、Sparkも「大量データを分割して並列処理する」という考え方を押さえれば、基本的な加工は書けるようになります。とはいえ、本格的に活かすにはPython/Sparkの素養があると有利です。SQLだけで完結させたいなら、まずSnowflakeやBigQueryで運用し、機械学習や大規模処理が必要になった段階でDatabricksを足す、という選択もあります。