【総集編】Microsoft Fabric と Databricksをつなぐデータ総合運用術 -hubストレージにDelta Lake形式で保管する-

概要

2025/5/28 開催Microsoft Data Analytics Day(Online) 勉強会にて
「Microsoft Fabric と Databricksをつなぐデータ総合運用術 -ハブストレージにDelta Lake形式で保管する-」
というタイトルで発表しました。
本記事ではその発表内容を整理し
「全体像の再整理」「ハブストレージ戦略の核心」「実装と運用でつまずくポイント」などについて
ご説明します。

▽毎月開催！Microsoft Fabricの勉強会（Microsoft Data Analytics Day(Online) 勉強会）
ぜひご参加ください！

発表資料とアーカイブ

▽発表資料

▽アーカイブ

はじめに

Microsoft FabricとDatabricksは、ともにエンドツーエンドのデータ分析を実現するレイクハウスプラットフォームとして注目されています。
両者はデータ統合から分析・機械学習まで幅広い機能を備えており、一見すると「ほぼ同じことができるのではないか」と感じるほどです。
実際、ETL処理から高度なAIモデルの作成・推論まで対応しており、データ主導の企業に多く導入されています。

一方で両者には設計思想やユーザビリティに違いがあります。

Microsoft FabricはビジュアルなGUIが充実していて直感的に操作しやすく、データエンジニアリングの専門知識が浅いユーザーにも扱いやすいのが特長です。
Power BIとのシームレスな連携やワンクリックでのデプロイなど低コード志向のサービスであり、構築や管理の容易さに優れています。

一方、Databricksはノートブック上でのコードベースの作業が中心となるため高度なプログラミングスキルが求められますが、その分クラスタ設定やチューニングの柔軟性が高く、大規模データ処理や機械学習ワークロードで定評があります。
またクラスターの起動・停止を細かく制御することでコスト最適化もしやすい点はDatabricksの強みと言えるでしょう。

総じて使いやすさ（Fabric）と柔軟性（Databricks）のトレードオフがあり、企業のニーズに応じて使い分けが検討されています。

こうした背景から、組織によってはビジネス部門は使いやすいFabricを採用し、エンジニア部門は慣れ親しんだDatabricksを使い続けるケースも出てきています。

では、Microsoft FabricとDatabricksを相互運用し、両者の利点を活かしながら同じデータを共有・活用することは可能なのでしょうか？

本記事ではこの問いに答えるため、
FabricとDatabricksの相互運用を実現する具体的な方法として
「hubストレージ」とDelta Lakeを活用したアプローチを紹介します。

▽Microsoft FabricとDatabricksの比較についてはこちらもご参照ください。

1章：Microsoft FabricとDatabricks の相互運用の As-IsとTo-Be

Microsoft FabricとDatabricks の相互運用の As-Is

前提

まず大前提として、Fabric 側・Databricks 側ともに「Bronze ➜ Silver ➜ Gold」の三層メダリオンが個別に成立しているものとします。

また「Fabric で加工した Silver が途中で Databricks の Silver に混在している」といったクロス汚染は、
すでに整理済みとします。
（同じデータソース由来のsilverがFabricにもDatabricksにもあり、よくわからない状況になっているなどはない前提）

Microsoft FabricとDatabricks の相互運用の As-Isパターン

一つ目のパターンは、
後からもう一つのプラットフォームを足す というパターンです。
イメージは次の二通り。

• 先に Databricks が動いているところへ、BI 用に Fabric をあとから導入する
• 先に Fabric が定着しているところへ、機械学習や大規模バッチ用に Databricks をあとから導入する

どちらの場合も、もともと動いていた仕組みをすぐには捨てられません。

結果として、

• 片方のデータをもう片方にコピーする作業が日常化
• コピーが失敗すると、ダッシュボードの数字が合わない
• 「データを動かすチーム」と「画面をつくるチーム」の責任範囲があいまい
• コピーで増えたストレージ代をどの部署が払うかで揉める

といった問題が起こりえます。

または以下のパターンも考えられます。
営業部が Fabric で管理するテーブルを、データサイエンス部門の Databricks で AI 学習に使いたい
あるいはその逆というシチュエーションがあるかと思います。

ところが現状では、

• 実体データをどちらかに複製（= ETL）
• 二重ストレージ・二重運用コストを負担

という“旧 DWH 時代”の運用に逆戻りしがちです。（レイクハウス本来のメリットが目減りしてしまう）

たとえコピーを自動化しても、コピーが存在する限り「どちらが真実か？」という監査論争 は避けられません。

加えて、FabricとDatabricksの相互運用に対して以下のような要望もあるかと思います。

• 他部署が Databricks で管理している Delta テーブルを、わが部署の Fabric から直接読めないの？
• 今は Databricks が主軸だけど、将来 Fabric に寄せる可能性もある。常にベンダーフリー でいたい。
• ビジネスユーザーは Fabric、エンジニアは Databricks――同じテーブルを別 UI から触れるようにしたい。

メダリオンが二本立てでは、どこかで必ず “データ移送コスト” が発生し、それが増え続ける点が As-Is 最大の課題です。

【キーワード】メダリオンアーキテクチャとは

メダリオンアーキテクチャは、データの品質と構造を段階的に向上させるためのデータ設計パターンです。

データはBronze（生データ）、Silver（クレンジング済みデータ）、Gold（ビジネス対応データ）の3層に分類され、各層でデータが精緻化されていきます。

これにより、データの品質管理とアクセス性が向上し、分析や機械学習の基盤として活用しやすくなります。

Bronze 層 では、センサーログやアプリケーションイベントなどの Raw データを欠損も重複も含めて丸ごと格納します。
“事実の一次ソース”を損ねないことがここでの品質指標です。

Silver 層 になると、ジョインによる参照整備や型変換、レコードの重複排除といったクレンジングが行われます。
この時点で初めて BI ツールや ML フレームワークが安全に読み込める整合性が確保されます。

Gold 層 ではビジネス部門が意思決定に即利用できる形にデータが凝縮されます。データマートとも呼ばれます。
多くの場合、スター・スキーマのファクト／ディメンションがここに位置し、Power BI のモデルが直接参照します。

▽参考
メダリオンアーキテクチャ (Medallion Architecture)

Microsoft FabricとDatabricks の相互運用の To-Be

Fabric と Databricks を共存させる鍵は、Gold 層の実体を 1 か所に集約することです。具体的には、

• 保存場所を データレイク（今回はADLS Gen2）に一本化
  • Gold レイヤーは Delta Lake 形式のファイルだけを置き、そこが「データの本体」になります。
• Delta Lake というオープンフォーマットで置く
• Fabric からは スキーマショートカット で参照
• Databricks からは 外部テーブルで参照

こうして 「実体は 1つ、入り口は 2つ」 の状態を作ると、次のような効果が得られます。

効果	なぜ嬉しいか
データをコピーしなくて済む	ETL や同期バッチがなくなるので遅延ゼロ、運用コストも小さくなる。
同じテーブルを両方から更新できる	Delta Lake が ACID を担保するため、Fabric で INSERT した行を Databricks が即読めるし、その逆も可能。
ストレージ料金が一目瞭然	ファイルは ADLSにあるので料金は明確
ベンダーロックを避けられる	将来別エンジン（Snowflake・BigQuery など）が必要になっても、DeltaLakeに対応できればすぐ同じデータを読める。

これによって「コピーが要らない」「どちらが元データか迷わない」という、As-Is で一番痛かった問題を丸ごと解消できます。

詳しい構成については３章をご覧ください。

【キーワード】 Delta Lakeとは

• Parquet を拡張したオープンなテーブル形式で、_delta_log フォルダーにトランザクション履歴を保持し ACID 特性 を実現します。
• INSERT／UPDATE／DELETE／MERGE をネイティブにサポートし、履歴を指定して過去状態を再現できる Time Travel 機能も備えます。
• スキーマの追加・変更を安全に反映できる Schema Evolution、ファイル再配置による OPTIMIZE（Z-Order / V-Order） などパフォーマンス管理も容易です。
• Spark だけでなく Fabric Lakehouse、Snowflake、Flink、Presto など主要エンジンが読み書き可能で、レイクハウスの共通言語 として採用が拡大しています。
• 公式サイトにはアーキテクチャ図や導入ガイドがあるので詳細はこちらを参照してください → https://delta.io/

2章：なぜハブストレージにDelta Lake形式保管が相互運用力を上げるか

2024 Data + AI Summit Keynote Day 1 より「コンピュートとストレージのコストを分けろ！」

ベンダーにデータを渡すな！（Databricks にさえも）

Stop giving your data to vendors(even databricks don’t give it to us either)

コンピュートとストレージのコストを分けろ！

Pay for it independently and make sure it has sprated compute and storage completely from the compute

Databricks CEO Ghodsi氏の素晴らしいお言葉をお借りします。（YouTube 10分あたり参照）

ポイントはただ一つ

データは自社が握り、計算エンジンは後から好きに取り替えられる設計にせよ

この言葉が意味するところは何か？
そして 今回の Fabric × Databricks のハブストレージ案が、どのようなメリットがあるのか？

続く 「ウェアハウスではなくレイクハウスだから」 と 「データメッシュの視点」 の２節で詳しく掘り下げます。

ウェアハウスではなくレイクハウスだからこそ実現できるhubストレージによる相互運用性

まずは データウェアハウス（DWH）と レイクハウス（LH）の立ち位置を整理してみます。

観点	データウェアハウス (DWH)	レイクハウス (LH)
誕生	1980 年代	2020 年ごろ
主な用途・得意領域	構造化データの高速分析 (OLAP)	構造化＋非構造化データを一元管理
ストレージの特徴	専用フォーマット／エンジンと密結合	ADLS・S3・GCS など安価なオブジェクトストレージ
ACID・トランザクション	ネイティブに対応	Delta／Iceberg 等で同レベル機能を実装
非構造化データへの対応	非対応	画像・ログもそのまま取り込み可能
製品例	Snowflake、Fabric Warehouse	Databricks、Fabric Lakehouse

そして本稿でいう ハブストレージ とは、

「クラウドの汎用ストレージ（今回は ADLS Gen2）に Delta Lake 形式で置いた 外部ストレージ」を指します。

レイクハウスはコンピュートとストレージを切り離せるため、マネージド領域の外 にあっても同じ仕組みがそのまま効きます。

主な利点を絞って挙げると

• コンピュートとストレージの完全分離
  • Delta Lake の _delta_log が ACID を担保するので、Spark・Fabric SQL・Photon など複数エンジンが 同じファイルを読み書き できる。
• オープンフォーマットだからコピー不要
  • 「ADLS に Delta を置けば誰でも読める」――将来エンジンを入れ替えても、データ移行や再取り込みがいらない。
• 構造化／非構造化を同じ場所で管理
  • 画像やログを ML で加工し、その結果を即座に BI で可視化。DWH では分断していた流れが 1 本化する。

Ghodsi CEO の「データは自社が握れ」というメッセージは、このモデルを指しています。

データを安価なストレージ＋オープンフォーマットに保管し、計算エンジンだけを後から最適化――この順番さえ守れば、新しいベンダーを試しても 移行コストはほぼゼロ。

この設計思想こそが、Fabric と Databricks(その他の製品を加えても) をhubストレージ上で共存させても “新しいサイロを作らない” 最大の理由になります。

DMBOKより　３つ以上のシステムでデータを交換するときのhubストレージの効率性

DMBOK（Data Management Body of Knowledge）は、
データマネジメントの国際的な標準ガイドラインであり、その中で
「データ統合と相互運用性」（第8章）で相互運用性に関する考え方が整理されています。

ここでは特に、複数のシステムが連携する際のアーキテクチャ設計として、疎結合を実現しているハブ＆スポークモデルの有効性が紹介されています。

この考え方を、データ分析基盤以外にもアプリケーションやその他のシステムに共通する話ですが、
今回はデータ分析基盤の構成にあてはめて整理すると以下のようになります。

■ 1システム構成（例：Fabric のみ）

最もシンプルかつ安定した構成です。
すべてのデータ処理・可視化・管理が 1 つの製品内で完結するため、

• ETL なしで即時にデータが使えることがある
• セキュリティ設定・ガバナンスが一元管理可能
• 運用設計がシンプル

といったメリットがあります。

特に中小規模の組織や、統一された要件で動くチームにとっては理想的な構成です。

一方で、将来的に機械学習基盤やリアルタイム分析などの新しいニーズが出てきたとき、その機能が今の製品にないと、
「別のベンダー製品を追加したいけど、すでに大量のデータを囲い込んでしまっている」
という ベンダーロックの罠 に陥る可能性もあります。

■ 2システム構成（例：Fabric＋Databricks）

2システム構成ではシステム間のデータコピーや定期 ETL パイプラインで連携を実現できます。

ただしこの構成は、“蜜結合”の状態になりやすいという落とし穴もあります。

• どちらかの仕様変更や障害がもう一方に影響する
• 更新タイミングのズレがデータ不整合を招く
• 「どちらのテーブルが正か？」という監査上の混乱が起きやすい

など、片方に依存する構造が負債になっていく可能性があります。

■ 3システム以上の構成（例：Fabric＋Databricks＋Snowflake＋BigQuery など）

この段階になると、システム構成の複雑さが一気に増します。

それぞれのシステムが他のすべてと直接つながろうとすると、
接続の本数は「n(n-1)/2」のペースで急増し、データのやり取りや変換処理がどんどん複雑になっていきます。

その結果として、

• 「あのデータはどこから来て、どこに渡されているのか」とリネージが見えにくくなる
• システムの追加・変更が全体に影響してしまいがち
• 運用コストや開発の手間も大幅に増える

といった問題が発生しやすくなります。

こうした状況を整理する方法として、DMBOKでは、中央に“共通のデータ形式の標準”を作るというアーキテクチャが紹介されています。これがハブ＆スポークです。

• 各システムはその“中央（hub）”とだけやり取りする
• それぞれが独自の形式で連携するのではなく、あらかじめ決めた共通ルールに従ってデータをやり取りする

これにより、やり取りの本数を最小限に抑えられ、運用もずっとシンプルになります

3つ以上のデータ基盤が存在する環境では、こうしたhub型の設計が非常に効果的です。
データの流れが整理され、責任範囲も明確になるため、トラブル対応やシステム追加も柔軟に行えるようになります。

そして本記事で提案している構成に当てはめると、
この“中央の通り道”は ADLS（Azure Data Lake Storage）であり、共通ルールとなるデータ形式が Delta Lake というわけです。

この考え方は、今や当たり前になりつつある マルチエンジン構成（Fabric、Databricks、Snowflake、BigQuery など） にも非常に相性がよく、
「hubストレージ」（＝中心に置く共通の Delta Lake データ基盤）という形で実装することで、コピー・変換・分散管理の負担を大幅に減らす ことができます。

複数の製品が並立する時代において、hubを持たない構成は「拡張性の壁」と「運用コストの爆発」を招く可能性があります
。
DMBOK の知見は、まさに今この時代に再注目されるべき設計指針といえるでしょう。

▽DAMAとDMBOKについてはこちら

データマネジメント知識体系ガイド／DAMAInternational／DAMA日本支部／Metafindコンサルティング株式会社【1000円以上送料無料】 価格：13,200円（税込、送料無料) (2025/5/27時点) 楽天で購入

3章：具体的なFabricとDatabricksの相互運用方法を考える

Microsoft Fabric と Databricks を連携させる方法には、大きく分けて次の3つのパターンが考えられます。

① Databricks にテーブル実体があり、Fabric から参照・更新するパターン

Databricks 側に格納された Delta テーブルを、Fabric から接続して利用する形です。

② Fabric にテーブル実体があり、Databricks から参照・更新するパターン
Fabric の OneLake 上に保存された Delta テーブルを、Databricks 側から接続して利用する形です。

①②の構成は、前章で紹介した蜜結合に近い形になります。

③ ハブストレージ（ADLS）にテーブル実体を置き、両方から参照・更新するパターン

本記事のメインで扱うのがこの構成です。

Databricks・Fabric 双方が同じ ADLS 上の Delta テーブルを、

• Fabric はスキーマショートカットで
• Databricks は外部テーブルで

接続することで、両者が対等に同じデータを直接参照・編集できる仕組みです。

この方法は、前章で紹介した DMBOK の“疎結合＋ハブ構成”の考え方にもっとも近く、拡張性・保守性・コストの観点からも実務的な選択肢といえます。

次のセクションでは、それぞれのパターンについて具体的にどのような設定・運用が必要になるのかを詳しく紹介していきます。

それぞれの相互運用パターンのポイントと課題

① Databricks にテーブル実体があり、Fabric から接続するパターン

Databricks 側で管理されているテーブルを、Microsoft Fabric 側から Unity Catalog ミラーリング機能を用いて参照する構成です。
Fabric に “ミラー化されたカタログ” として表示され、SQL エディタやノートブックからクエリが可能になります。
※この機能は現在 プレビュー の段階です。

ポイント

• ストレージコストやミラーリング自体に追加料金は発生しない
• 対象のストレージアカウントはファイアウォールの外部に公開されている必要がある（内部ネットワーク専用設定では利用不可）

詳しくはMSドキュメントを参照ください。
Azure Databricks Unity カタログのミラーリング (プレビュー)

② Fabric の OneLakeにテーブル実体があり、Databricks から接続するパターン

このパターンでは、Microsoft Fabric 側の OneLake に保存された Delta テーブルを、Azure Databricks 側から直接アクセスして利用する構成です。

Spark 構成設定による Azure Storage アクセスが現状最善だが、Unity catalog で管理できない点が難点です。

このパターンについては、以下の記事に非常にわかりやすく整理されています：

Azure Databricks から OneLake 上のデータにアクセスする方法 2024/12 版

③ Hubストレージ（Databricks ↔ Fabric）

ADLS 上に共通の Delta テーブルを置き、Fabric は「スキーマショートカット」、
Databricks は「外部テーブル」として同じデータを参照・編集するパターンです。

本記事の主軸となる構成です。

ポイント

• 双方向アクセスを実現する構成で、Fabric・Databricks どちらからも参照・編集が可能
• ベンダーフリー：Delta Lake のオープンフォーマットを利用するため、将来的に他のエンジン（Snowflake, BigQuery など）との拡張性も高い
• スキーマショートカット（プレビュー）は、Fabric 側からフォルダ単位でまとめて外部テーブルをショートカットできるのでFabric側からの運用が楽
• 一方Databiricks からの外部テーブルの指定はテーブルごとに個別に指定する必要がある

hubストレージの具体的なアーキテクチャ図と設定方法

こちらは、前章で紹介した「ハブストレージ方式」

すなわち、ADLS（Azure Data Lake Storage）を中核に据えて、
Databricks と Fabric の両方から同じ Delta テーブルを参照・更新可能にする構成の
具体的なアーキテクチャ図です。

この構成を実現するための具体的な設定方法や構成手順については、以下の記事で詳しく解説しています。

FabricとDatabricksをハブストレージ（Delta Lake）で接続する設定手順 – Qiita

記事では以下のような内容を丁寧にステップごとに紹介しています：

• ADLS の設定（コンテナ・権限・パス構造の整理）
• Databricks での外部テーブル作成（CREATE EXTERNAL TABLE の書き方）
• Fabric 側でのスキーマショートカット登録手順

4章：Demo1 Databricksで作成したテーブルをFabricで使用する

Databricks 上の Delta テーブルを、
Microsoft Fabric 側からスキーマショートカット機能を使って参照・編集する方法を紹介します。

Databricks にある既存データを、Fabric の可視化や分析機能でそのまま活用したい場面で使える構成です。

概要

• テーブル実体は ADLS にあり、Databricks から日常的に利用されているもの
• Fabric 側で「スキーマショートカット（プレビュー）」を設定することで、コピーせずにそのまま接続
• Power BI や SQL エンドポイントから、追加加工なしで直接参照可能
• Fabric 側から更新可能 かつその内容が Databricks にも即反映

詳しい設定方法は以下の記事で紹介しています：

5章：Demo2 Fabricで作成したテーブルをDatabricksで使用する

Microsoft Fabric 側で作成されたテーブル（実体は ADLS 上の Delta Lake 形式）を、
Azure Databricks から外部テーブルとして参照・編集する方法を紹介します。

Fabric に蓄積したデータを、Databricks の Spark 処理やノートブックでそのまま分析したいときに使える構成です。

概要

• データの実体は Fabricから作成された ADLS Gen2 上の Delta テーブル
• Databricksのノートブックや SQL クエリで直接参照・集計・分析が可能
• Databricks 側から更新可能 かつその内容が Fabric にも即反映

詳しい手順や注意点は以下の記事で紹介しています：

6章：hubストレージによるFabricとDatabricksの相互運用の課題

hubストレージ方式は、Fabric と Databricks をベンダーフリーで柔軟につなぐ有力な選択肢ですが、
まだ発展途上の部分も多く、適用には計画的な設計とガバナンス体制の整備が不可欠です。

以下に、現在見えている代表的な課題をまとめます。

■ Fabric 側の課題

• ゴールドレイヤーをウェアハウスで使いたい場合は ETL が必要
  　→ スキーマショートカットはレイクハウスにしか適用できないため、SQL Warehouse で使うには一度データを取り込む必要があります。

• ショートカット参照時は V-Order が効かない
  　→ 読み込みパフォーマンスが最適化されないが、後から OPTIMIZE を手動実行すれば補える。

■ Databricks 側の課題

• 外部テーブルの再指定が面倒
  　→毎回 テーブルごとにSQL で CREATE TABLE ... USING DELTA LOCATION ... を書く必要があります。（Fabricは一度ショートカットするだけ）

• 予測最適化が機能しない
  　→ Databricks の高速化機能は主にマネージドテーブル（managed table）向けで、外部テーブルには適用されない。
  参考：
  Unity Catalog マネージドテーブル向け予測最適化

共通の課題

■ メンテナンス・運用上の注意点

• メンテナンス処理の競合（OPTIMIZE / VACUUM など）
  　→ Databricks と Fabric がそれぞれのスケジューラで OPTIMIZE や VACUUM を実行すると、タイムトラベルが壊れたり、ファイル欠損が発生するリスクあり。
  　→ どちらが管理主体になるか、明確な役割分担が必要です。

■ ガバナンスとメタデータ管理の分散
Unity Catalog（Databricks）と OneLake/Fabric（Microsoft）で メタデータの管理系統が分かれている
　→ アクセス制御・変更履歴・データリネージの追跡が一元管理の方法について検討する必要がある。

■ メダリオンレイヤーの「どこまで共有するか」問題

• Bronze から共有すると： 権限管理が非常に煩雑
• Gold だけ共有すると： ETL 回数が増え、レイテンシやコストが上がる

■ 権限モデルの二重管理
ADLS 側では RBAC / ACL、Databricks 側では Unity Catalog の GRANT 構文、Fabric 側では Workload ロールと OneLake アクセス権
　→ 複数層での管理が必要となり、運用ルールの明文化などが求められます

最後に

Fabric と Databricks を本気でつなぐには、技術の話だけでは足りません。

「なぜ今ハブストレージなのか？」という問いに立ち返ると、その背景には DWH からレイクハウスへの構造転換があります。

そして、Ghodsi CEO の「ストレージを自社で持て」というメッセージが、それを強く後押ししています。

複数システムが当たり前になった今、DMBOKの示す“疎結合のハブ”という知恵もますます現実的です。

コピーせず、同期せず、1つのデータを複数のエンジンが安全に扱える世界――。

それを実現する具体解が、「ADLS＋Delta Lake」のhub構成です。

もちろん、最適化競合や機能差、ガバナンスの二重管理など課題もあります。

でもそれらは“限界”ではなく、“設計ポイント”として捉え直すべきでしょう。

Fabric と Databricks、どちらかを選ぶのではなく、どちらも活かす道を考える。

この記事が、そのための一歩になれば幸いです。

参考文献