mmuulan
Data EngineeringBackend

Databricks vs Snowflake キャッチアップメモ

Created 2026-07-05

Databricks vs Snowflake 技術スタック比較

1. 概要

このドキュメントでは、データ基盤の二大プラットフォームである Databricks と Snowflake を、データエンジニアリング（ETL、Lakehouse、テーブルフォーマット）の観点を中心に比較する。両者は「クラウド上でデータを保存・処理する」という目的は共通しているが、生まれた背景も、得意とするワークロードも、思想的な出発点も大きく異なる。

読了目安：15〜20分。読んだ後、「どちらが自社/自チームに向いているか」の一次判断ができ、AIコーディングツールに実装方針を指示する際の語彙（Delta Lake、Unity Catalog、仮想ウェアハウス、マイクロパーティションなど）が理解できる状態を目指す。

なお、両社とも機能追加のスピードが非常に速い領域であり、本ドキュメントの個別機能の詳細は今後数ヶ月で変わりうる。方向性・思想の理解に主眼を置き、確定的な機能仕様は必ず一次情報を確認してほしい。

2. 生まれた背景と全体思想の違い

このセクションで分かること：なぜ2つの異なるアーキテクチャ思想が生まれたのか、その出発点の違い。

Snowflake：データウェアハウスの再発明

Snowflakeは2012年創業、「クラウドネイティブなデータウェアハウス」として設計された。伝統的なオンプレミス型DWH（Teradataなど）が抱えていた「ストレージとコンピュートが一体でスケールしづらい」という課題を、クラウド上でストレージとコンピュートを完全に分離することで解決した。SQLベースの構造化データ分析を出発点とし、「セットアップの手間なく、誰でも高速にSQLを実行できる」体験を強みとしてきた。

Databricks：データサイエンス基盤からのLakehouse

Databricksは、Apache Sparkの開発チームが創業した会社であり、出発点は「大規模データに対する分散処理・機械学習」にある。当初は非構造化データも扱えるデータレイク（安価なオブジェクトストレージ）を主戦場としていたが、データレイクには「ACID保証がない」「スキーマが崩れやすい」という弱点（いわゆる”データスワンプ”問題）があった。そこでDatabricksは、データレイクの安さ・柔軟性とデータウェアハウスの信頼性・ガバナンスを両立するLakehouseという概念を提唱し、その中核技術としてACIDトランザクション、スキーマ強制、タイムトラベルをクラウドオブジェクトストレージに追加するオープンソースのストレージレイヤーであるDelta Lakeを開発した。

現在の収斂：両者とも「Lakehouse」を志向

興味深いのは、この2つが現在ほぼ同じゴールに向かって収斂している点である。Databricksは元々SQL分析にも力を入れ（Databricks SQL / Photonエンジン）、Snowflakeは元々のDWHにApache Iceberg™テーブル形式の仕様を使用するIcebergテーブルのサポートを追加し、オープンなテーブルフォーマットを取り込んでいる。つまり「Lakehouse的な性質（オープンフォーマット・ガバナンス・BIとMLの統合）をどちらの入口から実現するか」が両者の設計思想の違いだと理解すると分かりやすい。

観点 Databricks Snowflake
出発点 データレイク＋分散処理（Spark） クラウドDWH（SQL）
核となる思想 Lakehouse（レイクの上にDWHの機能を足す） ストレージ/コンピュート分離のDWH＋オープンフォーマット対応
得意領域（伝統的に） ETL、ML/AI、非構造化データ BI、SQL分析、運用の手軽さ
デフォルトのテーブル形式 Delta Lake Snowflake独自形式（マイクロパーティション）

3. ストレージ・テーブルフォーマットの設計思想

このセクションで分かること：データがどう物理的に保存され、なぜそれが設計判断に影響するか。

Databricks：Delta Lakeがデフォルト、Icebergも選べる

Databricksでは明示的に指定しない限り、Databricks上のすべてのテーブルはDelta Lakeテーブルになる。Delta LakeはParquetファイルにファイルベースのトランザクションログを拡張し、ACIDトランザクションとスケーラブルなメタデータ処理を提供するオープンソースソフトウェアである。近年はApache Icebergへの対応も進んでおり、Delta LakeとApache Icebergの両方を用いてマルチクラウドのLakehouseアーキテクチャを運用できる。

データの物理配置についてはUnity Catalog（後述）によるガバナンス下で、ほとんどのワークロードにはマネージドボリュームとマネージドテーブルの利用が推奨される。外部テーブルは、規制対応や外部システムとの直接連携が必要な場合の選択肢という位置づけである。

Snowflake：独自形式のマイクロパーティションが基本、Icebergは選択肢

Snowflakeの標準テーブルは、Snowflakeがデータの整理・ファイルサイズ・構造・圧縮・メタデータ・統計情報などすべての保存方法を管理し、すべてのデータは自動的にマイクロパーティションと呼ばれる連続した保存単位に分割される独自形式である。これは「何も考えなくても高速」という体験を生む一方、他のエンジンから直接読めない、という制約でもあった。

これに対応する形で、Snowflakeもデータファイル・Icebergメタデータ・マニフェストファイルを外部クラウドストレージに保存するIcebergテーブルを提供している。さらに2026年にはSnowflakeがストレージを管理してくれるため外部クラウドストレージへのアクセス設定が不要になる、Snowflakeストレージを使うApache Icebergテーブルのプレビューが登場し、「オープンフォーマットを使いつつ運用の手間はSnowflakeに任せる」という中間的な選択肢も生まれている。

Good/Bad：テーブルフォーマット選択の考え方

  • Databricks案件でDelta Lakeを使う：Good。エコシステムとの親和性が最も高く、迷ったらこれがデフォルト。
  • マルチエンジン前提（Spark/Trino/Snowflakeなど複数から読みたい）でIcebergを選ぶ：Good。ある移行事例ではAWS＋Snowflake＋将来の選択肢の広さを考えるとIcebergが唯一の選択肢だったが、Azure＋Fabric中心ならDeltaが現実的、Databricksネイティブなら抵抗の少ない道としてDeltaを選ぶという判断がなされている。これは一般的な実務判断の一例であり、公式が特定のフォーマットを推奨しているわけではない点に注意。
  • Icebergで頻繁な行レベルの更新・削除を行う：Bad寄り。外部ファイルに対する頻繁な行レベルの更新・削除は従来型テーブルの変更よりかなり遅く、単一の小さなデータ変更でも基盤となるファイル全体を書き換える必要があるため、追記中心のパイプライン設計が望ましいとされる。

4. コンピュート・実行エンジンの設計思想

このセクションで分かること：処理をどう分割・スケールさせる思想なのか。

Databricks：Sparkクラスタが基本単位

Databricksの実行エンジンはApache Sparkであり、1つのSparkランタイムがバッチジョブ・ストリーミング・SQL・機械学習を処理できるため、チームは種類ごとに異なるシステムを維持するのではなく単一のエンジンを運用できる。ETLパイプラインは、生データを段階的に整形していくメダリオンアーキテクチャ（bronze/silver/gold の3層構成）が標準的な設計パターンとして推奨されており、bronze層は加工前の生データ、silver層は整形済みデータ、gold層はビジネス利用可能なデータという3層構成が基本形となる。

ETL構築にはLakeflow Spark Declarative Pipelinesを使ったETLパイプライン構築や、クラウドストレージからの増分取り込みを行うAuto Loaderなどのツール群が用意されている。

Snowflake：仮想ウェアハウスによるコンピュート分離

Snowflakeはストレージとコンピュートを分離しており、これによりインフラ管理やパフォーマンスチューニングといった従来のデータエンジニアリングの課題の一部が単純化される。処理の実行単位は「仮想ウェアハウス」と呼ばれるコンピュートクラスタで、仮想ウェアハウスはSQL文を処理するほか、SnowparkによりJava・Python・Scalaなどの言語のコードも実行できる。

データ取り込みについてはファイルからテーブルへ読み込むCOPY INTOコマンド、ファイルが到着次第読み込むSnowpipe、行レベルのデータを低遅延で継続的に取り込むSnowpipe Streamingなど複数の方式が用意されている。

設計判断への影響

Databricksは「1つのエンジンで多様なワークロード（バッチ・ストリーミング・ML）をカバーする」という思想が強く、複雑な変換ロジックやPythonベースの処理と親和性が高い。一方Snowflakeは「SQLを中心に、必要な処理単位ごとに独立したコンピュート（ウェアハウス）を立てて課金・スケールする」という思想であり、BIダッシュボードのような比較的定型的なクエリ負荷に強みがある。ある移行事例では数千件のBIダッシュボードのクエリが、BIツールへのデータ転送ではなく計算時間分のみ課金される点がコスト面のメリットとして評価されている。

5. ガバナンス・カタログの考え方

このセクションで分かること：メタデータ管理・アクセス制御をどこで一元化する設計か。

DatabricksではUnity Catalogが中心的なガバナンス機構であり、データとAIに対する業界唯一の統合されたオープンなガバナンスソリューションと位置づけられている。テーブルだけでなく、構造化されていない生データはUnity Catalogのボリュームに保存すべき（外部ロケーションではなく）という規約があり、非構造化データもカタログ配下で一元管理する設計思想が徹底されている。

SnowflakeではHorizon Catalog（内部的なガバナンス機能）と、Iceberg向けにApache Polaris準拠のSnowflake Open Catalogという2系統のカタログ概念がある。Snowflakeが必要とするカタログはIcebergテーブルの管理・整理を行い、テーブルの現在のメタデータポインタやスナップショットなどを保持する役割を担う。外部カタログ（AWS Glueなど）との連携も可能で、Horizon CatalogがIcebergのメタデータ・アクセス・相互運用性を管理する形で、外部エンジンとのブリッジ役を果たす。

両者に共通する実務上の注意点として、「カタログ＝単なるメタデータ置き場ではなく、権限管理・監査・データ品質チェックの起点である」という認識を持つことが重要である。AIにテーブル設計を指示する際も、カタログ配下のどこに置くか（スキーマ／データベース構成）を先に決めておく必要がある。

6. データ品質・ガバナンスの実装パターン

このセクションで分かること：パイプライン内でデータ品質をどう担保する設計になっているか。

Databricksのメダリオンアーキテクチャでは、層を経るごとに品質を上げていく設計が明示的に推奨されている。bronze取り込み時にスキーマ検証やNULLチェックなどの品質チェックを実装し、silver・gold層に進むにつれてより厳格な品質ルールを適用し、品質メトリクスと傾向を継続的に監視するという段階的な設計が基本パターンである。品質担保の仕組みとしてはテーブルに追加されるデータの品質と整合性を自動検証する制約、フィールド間の関係をエンコードする主キー・外部キー、下流へのデータ品質問題の伝播を防ぐExpectations機能が用意されている。

Snowflakeにおいても、Iceberg採用時のクラスタリング機能で品質・性能を担保する設計が一般的である。WHERE句・JOIN条件・GROUP BY操作で頻繁に使われるカラムに対して自動クラスタリングを実装し、クラスタリングメトリクスを監視してコストと効果のバランスを見るという運用が推奨される。ただしこの機能はGB/日あたり約0.5〜2クレジットで別料金として課金される点に注意が必要で、Databricksの「オープンソースの一部として提供される最適化」とはコスト構造がやや異なる。

7. AIコーディングを見据えた注意点

このセクションで分かること：AIツールに実装を指示する際、両プラットフォーム特有につまずきやすいポイント。

  • バージョン・GA時期の混同に注意：SnowflakeのIcebergサポートは機能追加が非常に速い領域である。「Snowflakeストレージを使うIcebergテーブル」のような新しめの機能は、学習データの古いAIが存在を知らない、あるいは古い制約（外部ストレージが必須、など）を前提に回答することがある。実装前に必ず最新のリリースノートを確認する。
  • 「Delta LakeかIcebergか」を先に決めてから指示する：この選択はプロジェクト全体のエコシステム（どのエンジンから読み書きするか）に関わる大きな設計判断であり、AIに丸投げすると自明でない前提（例：Databricks単独利用を想定してDeltaを提案する等）で進めてしまうことがある。マルチエンジン要件の有無を明示して指示するとよい。
  • Databricksのメダリオン層構成を指示に含める：ETLパイプラインの実装を依頼する際、「bronze/silver/gold のどの層の処理か」を明示しないと、AIが層をまたいだ責務混在のコードを生成しがちである。
  • Snowflakeのコンピュート課金モデルを踏まえた指示：仮想ウェアハウスは処理単位ごとに課金が発生するため、「1つの巨大なウェアハウスで全処理を回す」提案をAIがしてくる場合がある。ワークロード（ETL用／BI用など）ごとにウェアハウスを分ける設計思想を伝えると、より実務に即したコードになりやすい。
  • Icebergの行レベル更新の弱点を前提にした設計を促す：Icebergテーブルに対して頻繁なUPDATE/DELETEを行うコードをAIが素朴に生成することがあるが、これは性能面で問題になりやすい。追記型（append-only）を優先する設計を明示的に指示するとよい。
  • 公式情報と実務ブログの区別：本ドキュメントでも触れた個別のベストプラクティス（クラスタリング対象カラムの選び方、外部ボリュームの分割方針など）の多くは公式ドキュメントというより実務者のブログ・事例記事に基づく内容である。AIが自信満々に断定してくる細かいチューニング手法は、一次情報での裏取りを習慣にするとよい。

8. まとめ：どちらを検討すべきかの大まかな見取り図

厳密な優劣ではなく、出発点の違いに基づく傾向として整理する。

観点 Databricksが向きやすい傾向 Snowflakeが向きやすい傾向
チームの主な役割 データエンジニア・MLエンジニア中心 アナリスト・BI中心
主要ワークロード 複雑なETL、ML/AI、非構造化データ処理 SQL分析、BIダッシュボード、定型レポーティング
コードの主言語 Python/Scala + SQL SQL中心（Snowparkで他言語も可）
オープンフォーマットへの向き合い方 Delta Lakeがネイティブ、Icebergも標準サポート 独自形式が基本、Icebergは追加オプションとして進化中

なお、両者は競合というより機能面で急速に接近しており、「DatabricksでSQL分析を強化する」「SnowflakeでML/AIワークロードを強化する（Cortex AI等）」という双方向の拡張も進んでいる。技術選定の最終判断は、既存のクラウド環境・チームのスキルセット・コスト構造まで含めた総合的な検討が必要であり、本ドキュメントはその前提となる思想理解を目的としている。

9. 参考文献一覧