Databricks はニッチで強い ── BigQuery・Redshift・Snowflake と補完層として組み合わせる設計判断

AWS や Google Cloud のマネージドサービスで構成されたデータ基盤の運用が安定していても、既存 Spark 資産の移行や ML パイプラインの統合要件が顔を出すたびに、Databricks の名前が選択肢として上がってきます。本記事では、Databricks に対する現状評価、採用が現実的になる 4 つの局面、AWS / Google Cloud / Azure / Snowflake との共存パターン、コスト構造を順に整理します。これらを踏まえて、自社のデータ基盤に Databricks をどう組み込むかの判断材料を揃えましょう。

Databricks が「重い・高い・他で十分」と言われる理由 ── フラットな現状評価

BigQuery / Redshift / Snowflake は SQL ワークロードに最適化された列指向 DWH であり、Databricks はオープンフォーマット (Delta Lake) と Apache Spark を起点とする統合データ処理基盤です。両者は設計の出発点が異なるため、「DWH の上位互換」として同じ物差しで比較すると、双方の評価がゆがみます。

AWS / Google Cloud / Azure はそれぞれ Spark 系処理のマネージドサービスを持っています。Amazon EMR、Google Cloud の Dataproc、Azure の HDInsight がその代表例です。Spark ジョブの実行環境を用意するだけであれば、これらのサービスで代替できる領域は広くあります。Databricks を選ぶ必要がある局面は、後述する 4 つの条件に絞られます。

非構造化データのカタログ化と LLM 関数経由の抽出という範囲は、DWH 側でも完結するようになっています。BigQuery の Object Tables は GCS 上の画像・動画・PDF を SQL からカタログ化し、Vertex AI モデルへの推論を直接呼び出せます。Snowflake Cortex は Directory Tables のファイルに対して SQL から LLM 関数を実行できます。Redshift Spectrum は S3 上の Parquet / JSON / Avro を SQL で処理できます。

オープンフォーマットの軸でも、Databricks の優位性は薄まっています。Iceberg と Delta Lake は BigQuery / S3 Tables / Snowflake のすべてが直接サポートしており、「Delta Lake を使うから Databricks」という理由は成り立たなくなっています。

DBU (Databricks Unit) 課金は、クラウドインフラ料金との二重構造になっています。Databricks への DBU 料金と AWS / Google Cloud / Azure へのコンピュート・ストレージ料金が別々に発生します。ワークロードタイプの中で最も単価が高い All-Purpose Compute を、ノートブック開発中に稼働させ続けると請求が増加します。

Jobs Compute で実行するよう設定しない場合、想定の数倍の請求が発生することがあります。

ただし、2024 年 7 月にサーバレス Notebook が GA になったことで、クラスタ起動に 5〜8 分かかるという従来の批判は緩和されています (出典: Serverless Compute GA 発表)。

Gartner Magic Quadrant for Cloud Database Management Systems 2025 で Databricks は Leader に位置付けられています。2025 年版は OLTP (Lakebase) も評価対象に加わっており、純粋な DWH 用途の評価軸ではありません (出典: Gartner Magic Quadrant Databricks Leader)。

ただし、この評価軸は「analytics + ML の統合」であり、一般的な DWH 用途の評価軸とは異なります。Leader 認定は「自社の DWH を Databricks に置き換えるべき」という意味ではなく、ML / データ統合の文脈での相対評価として読む必要があります。

「他で十分な場面が多い」というのはフェアな評価です。その上で、4 つの局面では他クラウドサービスで体験が分散するという事実があります。次のセクションでその局面を整理します。

あえて採用すべき 4 つの局面 ── 体験が分散しない、という根拠

既存 Spark / Hadoop 資産の移行先

Cloudera / Hortonworks の資産を持つ組織にとって、EMR や Dataproc への移行は「Spark 実行環境の置き換え」にとどまります。一方で Databricks への移行は、MLflow / Unity Catalog / Feature Store への直接接続という統合体験を同時に得られる点で異なります。

Databricks Labs から公式ツールとして提供されている Lakebridge は、既存コードの解析から変換・検証までを一貫して支援します (出典: Databricks Lakebridge)。Assessment (評価) → Conversion (変換) → Validation (検証) という 3 段階の構成で、1,000 を超える顧客・パートナーが利用しており、月次 20% の採用成長率を Databricks が公表しています。

実際の移行効果はコードの複雑さに依存するため、自社のコードベースで事前評価を行うことを推奨します。

Photon エンジンについても公式ベンチマークの数値があります。Databricks の公式主張では TPC-DS 1 TB で 2 倍の追加スピードアップ、顧客の観測値では平均 3〜8 倍の高速化とされています (出典: Photon エンジン)。既存 Spark ワークロードのコード資産をそのまま移行できる点が、EMR / Dataproc との実質的な差になります。

データサイエンティスト中心組織の統合開発体験

Vertex AI Pipelines / Feature Store / Vertex AI Model Registry を個別に運用する構成では、モデル開発・特徴量管理・実験追跡それぞれで異なる UI と権限モデルを扱うことになります。Databricks では MLflow / Feature Store / Unity Catalog / 協調 Notebook を同一基盤で扱え、ツール間の切り替え負荷が減ります。これが体験差の本質です。

サーバレス Notebook の GA (2024 年 7 月) により、クラスタ起動待ちの問題は解消されています。Databricks がウォームプールを維持する構成になっており、従来のコールドスタートは発生しません。ただし、カスタム Spark 設定プロパティの一部はサーバレス環境で設定できないという制約があります。

リアルタイム共同編集にも対応しており、複数のメンバーが同一ノートブックを同時編集できます。

この局面が成立するのは、ML エンジニアが多数を占める組織の場合に限られます。SQL 専業のチームが主体であれば、この統合体験の差は判断材料になりません。

Lakeflow Spark Declarative Pipelines (条件付き)

この局面には前提条件があります。「ストリーミング + Python 変換 + Auto CDC + 非 BigQuery 出力」のいずれかが必要な場合にのみ、Databricks の Lakeflow Spark Declarative Pipelines (旧称 Delta Live Tables、2025 年改称) が差別化を持ちます。これらが不要であれば、Dataform で要件が満たせます。

Dataform と Lakeflow の機能差を整理します。

ストリーミングソースから直接 Delta Lake に取り込み、Auto CDC で SCD Type 2 を宣言的に管理する構成は、Dataform / Cloud Composer / Glue などの組み合わせでは記述量が増えがちです。宣言型として完結する選択肢が少ない領域で、Lakeflow の差別化が成立します。

規制業界での Unity Catalog ガバナンス

金融・医療・政府機関など、列レベルの系譜管理 (lineage) と属性ベースアクセス制御 (ABAC) と Delta Sharing を 1 基盤で統合する必要がある場合、Databricks の Unity Catalog が対応します (出典: Unity Catalog 製品ページ)。

AWS Glue Data Catalog + Lake Formation + SageMaker、または BigQuery + Dataplex + Vertex AI を組み合わせる構成でも、同等の機能を実現することは原理的に不可能ではありません。ただし、UI / 権限モデル / lineage 表示がサービスをまたいで分散するため、統合的な管理画面を持てません。

Databricks の Data + AI Summit セッション (Governed Data Sharing at Scale: UBS RiskLab + LSEG via Unity Catalog and Delta Sharing) では、UBS RiskLab と LSEG が Unity Catalog と Delta Sharing を使ったガバナンス済み金融データ共有の事例を発表しています (出典: UBS RiskLab + LSEG 事例)。

クロス組織でのデータ共有に lineage と ABAC が必要な規制業界では、Unity Catalog の統合設計が判断材料になります。

DWH を主基盤として残す ── 4 クラウドの共存パターン

このセクションでは、Databricks を主基盤に置く前提を一切置きません。DWH が主基盤であり、Databricks は補完層として機能するという前提で各クラウドの共存パターンを整理します。

Google Cloud: BigQuery + Databricks

BigQuery は BI / SQL 分析 / ダッシュボード / Gemini in BigQuery (AI.IF / AI.CLASSIFY 等の AI 関数) の主基盤として残します。Databricks は Spark 重処理 / ML トレーニング / Lakeflow Pipelines の補完層として位置付けます。

連携は BigLake を介して実現します。GCS 上の Delta / Iceberg テーブルを BigQuery と Databricks の双方から読み書きできます (出典: BigQuery の Delta Lake サポート)。さらに Lakehouse Federation を介して BigQuery から Unity Catalog のテーブルを参照することも可能です (詳細は 公式ドキュメント 参照)。

スキャンコストの所在に注意が必要です。BigQuery → BigLake → GCS のパスでアクセスした場合は BigQuery 側のスキャンコストとして課金され、Databricks 側から同じ GCS のデータを処理した場合は Databricks クラスタのコストとして発生します。

実務的な役割分担としては、GCS 上の大規模特徴量前処理 (画像・音声・大規模 join) を Databricks の Spark で処理し、モデル学習を Vertex AI Custom Training または Databricks のどちらに置くかをチームのスキル・既存資産で決め、推論結果は BigQuery に書き戻して BI から参照する構成が選択肢の 1 つです。Vertex AI Pipelines を主軸として残すなら、Databricks は「重い前処理層」として境界を引くのが最も摩擦が少なくなります。

AWS: Redshift / Athena + Databricks

Redshift / Athena は BI / SQL 分析 / QuickSight 連携の主基盤として残します。Databricks は ML / Spark 処理 / 既存 Hadoop 資産の移行先として補完層に置きます。

AWS S3 Tables (2024 年末発表の Iceberg ネイティブストレージ) を Databricks から利用するには、AWS Glue Iceberg REST Catalog 経由でのアクセスが必要です (出典: S3 Tables + Databricks の連携手順)。Databricks Runtime 15.4 LTS と Apache Iceberg Spark Runtime 1.6.1 の組み合わせが必要です (出典: Databricks Runtime 15.4 LTS)。

この構成にはいくつかの前提条件があります。Lake Formation データレーク管理者権限の設定、外部エンジンへの完全テーブルアクセスの有効化、同一 AWS アカウント内での利用という 3 点を事前に確認しておく必要があります。

Snowflake + Databricks

Snowflake は SQL 分析 / Secure Data Sharing / Snowflake Marketplace の主基盤として残します。Databricks は ML / Spark 処理 / 大規模前処理の補完層として位置付けます。

連携は Delta UniForm を使います。Databricks の Delta テーブルに UniForm で Iceberg メタデータを生成し、Snowflake の REST Catalog Integration でそのテーブルを読み取る構成です (出典: Snowflake から Unity Catalog テーブルの読み取り)。

制約として、Snowflake の vended credentials は現時点で AWS S3 のみのサポートです。Azure ADLS / GCS 上のデータは external volume 経由での接続になります。双方向の書き込みを実現する機能 (Snowflake REST API catalog integration の拡張) は Public Preview / Private Preview の段階にあり、現時点では UniForm 経由の Databricks → Snowflake 読み取りが安定運用の経路です。

Data + AI Summit セッション「Breaking Silos: Enabling Databricks-Snowflake Interoperability With Iceberg」では、両社が公式連携を前面に出しています (出典: セッション詳細)。競合ではなく補完関係として整理が進んでいます。

Azure: Microsoft Fabric / OneLake + Azure Databricks

Microsoft Fabric (OneLake) は BI / Power BI / エンタープライズデータ管理の主基盤として残します。Azure Databricks は重い Spark 処理 / ML / 既存 Databricks 資産の維持に特化させます。

OneLake は Delta Parquet を標準フォーマットとして採用しており、Azure Databricks は ABFS (Azure Blob File System) 経由で直接読み書きできます (出典: Azure Databricks と OneLake の連携)。

Unity Catalog から OneLake へのミラーリングは GA になっており、Fabric 側から Databricks 管理データに直接アクセスできます (出典: Unity Catalog → OneLake ミラーリング GA)。

Microsoft 公式は「Fabric と Azure Databricks は better together」と訴求しており、競合でも代替でもない位置付けを明確にしています (出典: Microsoft Fabric × Azure Databricks)。

境界線の引き方 ── 部分導入の設計判断と DBU 課金の現実

4 条件による判断フロー

以下の 4 つの問いに照らして判断します。いずれにも該当しなければ、既存 DWH で完結します。

1. 既存 Spark / Hadoop 資産があるか ── Cloudera / Hortonworks からの移行先が必要か
2. DS 中心組織で MLflow + Feature Store + Unity Catalog の統合体験を優先するか ── ML エンジニアが多数を占める組織か
3. ストリーミング + Python + Auto CDC + 非 BigQuery 出力の条件に該当するか ── Lakeflow 固有の要件が存在するか
4. 規制業界で列レベル lineage + ABAC + Delta Sharing の統合ガバナンスが必要か ── クロス組織のデータ共有に監査証跡が求められるか

4 条件のいずれも該当しない場合は Databricks を導入しない判断が正当です。既存の BigQuery / Redshift / Snowflake で完結する設計を維持することが、運用コストと予測可能性の両面で合理的です。

DBU 課金の構造

DBU の単価はワークロードタイプによって異なります。

本番ジョブは必ず Jobs Compute で実行するよう設計することが、Databricks 運用の基本的なコスト管理です。All-Purpose Compute をノートブック開発後もそのまま稼働させ続けることが、請求が想定を超える最も多いパターンです。

接続コストの所在

共存構成では、DWH 側と Databricks 側のどちらにコストが発生するかを事前に把握しておく必要があります。

DBU の最新単価はワークロードタイプ・クラウドプロバイダ・リージョンによって異なります。Databricks 公式料金ページ で確認してください。

まとめ ── 補完層として正しく使うための 3 つの設計原則

Databricks の採用判断の問いは「使うか否か」ではなく、既存 DWH を主基盤として残した上で、本記事の 4 つの局面のどれかに該当するかを先に確認することです。

設計原則 1: DWH ファースト

4 条件 (Spark 資産の移行 / DS 組織の統合体験 / Lakeflow 固有要件 / 規制業界ガバナンス) のいずれにも該当しなければ、Databricks は不要です。BigQuery / Redshift / Snowflake の運用を継続することが、コスト効率と運用シンプルさの両面で優れた判断になります。

設計原則 2: 共存設計

Lakehouse Federation / BigLake / S3 Tables (Glue REST Catalog) / OneLake ミラーリングを介して DWH を主基盤として残します。「Databricks に移行する」ではなく「DWH と Databricks を接続する」が正しいフレームです。オープンフォーマット (Delta / Iceberg) を共通のストレージ標準にすることで、どちら側からもデータにアクセスできる構成を維持できます。

設計原則 3: コスト管理を最初から設計に入れる

All-Purpose Compute を最小化し、本番ジョブは Jobs Compute で実行する設計を導入初日から組み込みます。Lakeflow の品質チェックコストも含め、DBU のワークロードタイプ別の単価差を事前に把握した上でコスト試算を行うことが失敗を防ぐ前提条件です。

次のアクションとして、既存 Spark 資産の移行が検討事項であれば Lakebridge ドキュメント を、規制業界のガバナンス要件が起点であれば Unity Catalog ドキュメント を、コスト確認が先決であれば Databricks 公式料金ページ を参照してください。

参考文献

• What is a Data Lakehouse? (Databricks 公式ブログ)
• Databricks Lakebridge (移行ツール)
• Hadoop からの移行 (Databricks 公式)
• Photon エンジン (docs.databricks.com)
• Photon によるフィーチャーエンジニアリングの高速化
• Lakeflow Spark Declarative Pipelines 製品ページ
• Unity Catalog 製品ページ
• Managed MLflow (Databricks 公式)
• MLOps ワークフロー (docs.databricks.com)
• Serverless Compute GA 発表 (Databricks 公式ブログ)
• Lakehouse Federation 公式ドキュメント
• BigQuery の Delta Lake サポート (BigLake)
• BigQuery Object Tables (Google Cloud 公式)
• Dataform の概要 (Google Cloud 公式)
• S3 Tables + Databricks の接続 (AWS 公式ブログ)
• Databricks Runtime 15.4 LTS リリースノート
• Snowflake から Unity Catalog テーブルの読み取り
• Databricks-Snowflake Iceberg 相互接続 (DAS 2025 セッション)
• Microsoft Fabric × Azure Databricks (Microsoft 公式ブログ)
• Unity Catalog → OneLake ミラーリング GA (Microsoft 公式ブログ)
• Azure Databricks と OneLake の連携 (Microsoft Learn)
• UBS RiskLab + LSEG 事例 (DAS 2025)
• Databricks 料金ページ
• Gartner Magic Quadrant for Cloud DBMS 2025 (Databricks Leader)

Author

tgeas

大阪の SIer 勤務。Google Cloud Partner Top Engineer 2026 / 2025 JAPAN All AWS Certification Engineers。インフラ・ネットワークからデータ活用と生成 AI 活用支援まで幅広く対応。

profile