Microsoft Fabric と Databricksをつなぐデータ総合運用術 -hub ストレージにDelta Lake形式で保管する-“Unified Data Operations with Microsoft Fabric and Databricks – Building a Shared Delta Lake Hub on ADLS Gen2 –”

Microsoft Data Analytics Day(Online) 勉強会にて発表しました
▽勉強会URL
https://sqlserver.connpass.com/event/354041/
▽アーカイブ
https://youtu.be/A9aIcowJn1I

# 概要
Microsoft Fabric と Databricks という 2 大レイクハウス・プラットフォームを 「ハブストレージ（ADLS Gen2 + Delta Lake）」 経由で疎結合に連携し、
・As-Is / To-Be の整理 – 二重メダリオンが生むコピー問題をどう解消する？
・ハブストレージ戦略の核心 – Delta Lake で実現する「実体 1 つ・入口 2 つ」構成
・3 パターンの相互運用
　・Databricks 主体 → Fabric 参照
　・Fabric 主体 → Databricks 参照
　・ADLS ハブ → 双方対等アクセス（今回のメイン）
・デモ – 同じテーブルに対して双方向で参照・編集 が即時反映される様子を実演
・課題と設計ポイント – OPTIMIZE 競合、権限モデル二重管理、Warehouse 連携時の ETL など

を具体的なアーキテクチャ図・SQL 例・運用ガイドラインとともに解説しています。
レイクハウス時代の“データサイロ撲滅”を目指す方のヒントになれば幸いです。

👉 Qiita元記事はこちら：https://qiita.com/ReijiOtake/items/f134ae040a63576732ad

(English Description)

In this talk, we explored how two major lakehouse platforms—Microsoft Fabric and Databricks—can be loosely coupled via a hub storage architecture using ADLS Gen2 and Delta Lake.
The session covers:
・As-Is / To-Be analysis: How can we solve the duplication problem caused by dual medallion pipelines?
・Core strategy of hub storage: Achieving a “one physical copy, two logical entry points” model with Delta Lake
・Three interoperability patterns:
　・Databricks-centric → Referenced by Fabric
　・Fabric-centric → Referenced by Databricks
　・Hub on ADLS → Equal access by both platforms (main focus)
・Live demo: Bi-directional read/write to the same Delta table with immediate reflection
・Challenges and design considerations:
　・OPTIMIZE command contention
　・Dual governance models (Unity Catalog vs OneLake)
　・ETL needs when working with Fabric Warehouses
The presentation includes architectural diagrams, SQL code samples, and practical design guidance.
We hope this will be a useful reference for anyone aiming to eliminate data silos in the era of the lakehouse.
👉 Full article on Qiita: https://qiita.com/ReijiOtake/items/f134ae040a63576732ad

Transcript

1. Microsoft Fabric と Databricksをつなぐデータ総合運用術 -hub ストレージにDelta Lake形式で保管する- Microsoft Data Analytics Day (Online) 勉強会 2025.5.28 大竹 礼二
2. 自己紹介 ⚫大竹礼二 ⚫所属：株式会社ジール ⚫経歴：2024年4月 新卒入社（2年目） ⚫仕事 ⚫ Microsoft Fabricでのデータ分析基盤開発 ⚫ Power BI でのレポート開発 ⚫ Azureでのクラウド基盤開発 ⚫ Etc ⚫My Qitta・X ⚫ ReijiOtake – Qiita ⚫ Reiji Otake（大竹 礼二）（@reireireijinjin）さん / X ⚫保有資格 ⚫データベーススペシャリスト ⚫基本情報技術者試験 ⚫Databricks Certified Data Engineer Associate ⚫AZ-900、DP-900、PL-900 ⚫Etc..
3. ビジネスサイド、エンジニアサイド どっちの意見も見えてきたぞ！ ・GUIでわかりやすいFabricは裏を返せば “ブラックボックス” ・コードベースで柔軟なDatabricksは “敷居が高い” ス テ ッ プ ア ッ プ （ 男 性 ・ ビ ジ ネ ス ） パ ソ コ ン を 打 つ ビ ジ ネ ス ウ ー マ ン Fabric と Databricks -強みは弱みの裏返し- 先月のアーカイブ：（Microsoft Fabric vs Databricks vs (Snowflake) -若手エンジニアがそれぞれの強みと違いを比較してみた）
4. Microsoft FabricとDatabricks の相互運用の As-IsとTo-Be
5. Microsoft FabricとDatabricks の相互運用の As-Is silver データソース4 データソース5 データソース6 Gold データ データマートとも呼ばれる状態。 個別のユースケースに即したデータモデルを表 現する。特定のシナリオに適合した変換を 加えた調整済みデータ Bronze データレイクとも呼ばれる状態。根本的な ロジック変更やデータ破損への対処として 後続を再生成可能にする生データ Silver データ DWHとも呼ばれる状態。特定用途には加工 されていない、汎用的なデータモデル。 ここではデータ定義と品質チェックが適用され ているのみの、公開すべき状態の利用可能 データ gold 可視化 AI / MLモデル bronze
6. データソース1 bronze silver gold パ ソ コ ン を 打 つ ビ ジ ネ ス ウ ー マ ン データソース2 データソース3 データソース4 データソース5 データソース6 Microsoft FabricとDatabricks の相互運用の As-Is Gold データ データマートとも呼ばれる状態。 個別のユースケースに即したデータモデルを表 現する。特定のシナリオに適合した変換を 加えた調整済みデータ Bronze データレイクとも呼ばれる状態。根本的な ロジック変更やデータ破損への対処として 後続を再生成可能にする生データ Silver データ DWHとも呼ばれる状態。特定用途には加工 されていない、汎用的なデータモデル。 ここではデータ定義と品質チェックが適用され ているのみの、公開すべき状態の利用可能 データ gold 可視化 AI / MLモデル 可視化 AI / MLモデル silver bronze ・ETL ・二重ストレージ ・どっちのデータが正しいのか？
7. Microsoft FabricとDatabricks の相互運用の To-Be ショートカット Data Lake 外部テーブル ・ETL や同期バッチががなくなり、運用コストも小 / ストレージコスト減 ・Fabric、Databricksどちらからもテーブルの参照・編集が可能 ・オープンテーブルフォーマットにより、ベンダーフリー Delta Lake （オープンテーブルフォーマット） データソース1 bronze silver gold パ ソ コ ン を 打 つ ビ ジ ネ ス ウ ー マ ン データソース2 データソース3 データソース4 データソース5 データソース6 gold 可視化 AI / MLモデル 可視化 AI / MLモデル silver bronze
8. SQL Spark BI レイクハウスを作成（スキーマ有効化） SQL Spark BI 設 定 フ ェ ー ズ 作 成 ・ 使 用 （ 可 視 化 ・ 編 集 ） フ ェ ー ズ Databricksからカタログ、スキーマを新規作成 （カタログの場所をhubストレージに指定する） 常に実態は データレイクに Delta Lakeとして保管 外部ロケーションを追加する CREATE TABLE CREATE TABLE hubストレージの具体的なアーキテクチャ図と設定方法 Ext（ディレクトリ） Create from Fabric スキーマショートカットでhub ストレージを指定 _delta_log Parquet Create from Databricks _delta_log Parquet AzureポータルからAzure Databricks用のアクセスコネ クタを作成する Azureポータルからコネクタにhubストレージへのアク セスを許可する Databricksから資格情報を作成する CREATE TABLE ~ LOCATION FabricとDatabricksの相互運用性 2：FabricとDatabricksをハブストレージ（Delta Lake）で接続する設定手順 #Azure - Qiita
9. 【参考】FabricとDatabricks相互運用 その他の方法 パターン 方法 ポイント ① Databricks にテーブル実体があ り、Fabric から接続するパターン Unity Catalogミラーリング （プレビュー） • 簡単にできる（メタデータ同期） • 基本的にストレージコストミラーリングコストは無料 • Unity Catalog データを含むストレージ アカウントを ファイアウォールの内側に置けない • レイクハウスショートカットによってAzure Databricks ワークスペースから追加したこれらのカタログ テーブ ルのデータに対してデータ処理を実行 ② FabricのOneLakeにテーブル実体 があり、Databricks から接続するパ ターン 〇Spark 構成設定による Azure Storage アクセス △資格情報パススルークラス ターを使用したアクセス ×外部ロケーション • Spark 構成設定による Azure Storage アクセスが現状最 善だが、Unity catalog で管理できない点だけが難点 • Azure Databricks から OneLake 上のデータにアクセス する方法 2024/12 版 #Microsoft – Qiita ③ Hubストレージ（Databricks Fabric） hubストレージにDelta Lake形 式で保管 Fabric スキーマショートカット Databricks 外部テーブルの指定 • ベンダーフリー＆双方向アクセスを実現する構成で、 Fabric・Databricks どちらからも参照・編集が可能 • Delta Lake のオープンフォーマットを利用するため、 将来的に他のエンジンとの拡張性も高い • スキーマショートカット（プレビュー）を使う • Databiricks からの外部テーブルの指定はテーブルごと に個別に指定する必要
10. Demo1：Databricksで作成したテーブルをFabricで使用する 作る 使う
11. SQL Spark BI レイクハウスを作成（スキーマ有効化） SQL Spark BI 設 定 フ ェ ー ズ 作 成 ・ 使 用 （ 可 視 化 ・ 編 集 フ ェ ー ズ ） FabricとDatabricksの相互運用性②：hubストレージ設定方法 -Databricks で作成したテーブルをFabric で利用する、Fabric で作成したテーブルを Databricksで利用する- #Azure - Qiita Databricksからカタログ、スキーマを新規作成 （カタログの場所をhubストレージに指定する） 常に実態は データレイクに Delta Lakeとして保管 外部ロケーションを追加する CREATE TABLE CREATE TABLE hubストレージの具体的なアーキテクチャ図と設定方法 Ext（ディレクトリ） Create from Fabric スキーマショートカットでhubス トレージを指定 _delta_log Parquet Create from Databricks _delta_log Parquet AzureポータルからAzure Databricks用のアクセスコネ クタを作成する Azureポータルからコネクタにhubストレージへのアク セスを許可する Databricksから資格情報を作成する CREATE TABLE ~ LOCATION
12. ・Databricksから空の新規外部テーブルを作成 ⇒Locationにはhubストレージのフォルダパスを指定 Databricksで作成したテーブルをFabricで使用する
13. Databricksで作成したテーブルをFabricで使用する ・デルタテーブルにデータを挿入
14. Databricksで作成したテーブルをFabricで使用する ・作成したテーブルの確認 ⇒カタログエクスプローラーからデルタテーブルにデータが入っていることを確認
15. Databricksで作成したテーブルをFabricで使用する ・新規作成した外部テーブルはhubストレージ上に実態が存在する
16. Databricksで作成したテーブルをFabricで使用する ・Fabricから閲覧・分析可能
17. Databricksで作成したテーブルをFabricで使用する ・Fabricから閲覧・分析可能
18. Databricksで作成したテーブルをFabricで使用する ・Fabricから編集 ⇒NotebookからSparkが可能 もちろんDatabricks側にも反映 FabricとDatabricksの相互運用性④：Databrick で作成したテーブルをFabricで利用する（Fabricで閲覧・分析・編集可能） #SQL - Qiita
19. Demo2：Fabricで作成したテーブルをDatabricksで使用する 使う 作る
20. SQL Spark BI レイクハウスを作成（スキーマ有効化） SQL Spark BI 設 定 フ ェ ー ズ 作 成 ・ 使 用 （ 可 視 化 ・ 編 集 フ ェ ー ズ ） FabricとDatabricksの相互運用性②：hubストレージ設定方法 -Databricks で作成したテーブルをFabric で利用する、Fabric で作成したテーブルを Databricksで利用する- #Azure - Qiita Databricksからカタログ、スキーマを新規作成 （カタログの場所をhubストレージに指定する） 常に実態は データレイクに Delta Lakeとして保管 外部ロケーションを追加する CREATE TABLE CREATE TABLE hubストレージの具体的なアーキテクチャ図と設定方法 Ext（ディレクトリ） Create from Fabric スキーマショートカットでhubス トレージを指定 _delta_log Parquet Create from Databricks _delta_log Parquet AzureポータルからAzure Databricks用のアクセスコネ クタを作成する Azureポータルからコネクタにhubストレージへのアク セスを許可する Databricksから資格情報を作成する CREATE TABLE ~ LOCATION
21. Fabricで作成したテーブルをDatabricksで使用する ・Fabricにテーブルを作成（この時点で実態はハブストレージにある） ⇒スキーマ（ストレージ上のファイル）にテーブルを作成
22. Fabricで作成したテーブルをDatabricksで使用する ・作成したテーブルの確認 ⇒レイクハウスのプレビューからテーブルにデータが入っていることを確認
23. Fabricで作成したテーブルをDatabricksで使用する ・新規作成した外部テーブルはhubストレージ上に実態が存在する
24. Fabricで作成したテーブルをDatabricksで使用する ・DatabricksからFabricで作成したテーブルを操作できるようにする ⇒Locationにhubストレージフォルダパス（Fabricで作成したテーブルのフォルダ）を指定する まだFabricで作成したテーブルはDatabricks上で見えない
25. Fabricで作成したテーブルをDatabricksで使用する ・DatabricksからFabricで作成したテーブルを操作できるようにする ⇒Locationにhubストレージフォルダパス（Fabricで作成したテーブルのフォルダ）を指定する まだFabricで作成したテーブルはDatabricks上で見えない CREATE TABLE <table_name> USING DELTA LOCATION hubストレージのパス
26. Fabricで作成したテーブルをDatabricksで使用する ・DatabricksからFabricで作成したテーブルを操作できるようにする ⇒Locationにhubストレージフォルダパス（Fabricで作成したテーブルのフォルダ）を指定する まだFabricで作成したテーブルはDatabricks上で見えない CREATE TABLE <table_name> USING DELTA LOCATION hubストレージのパス
27. Fabricで作成したテーブルをDatabricksで使用する ・Databricksから閲覧・分析可能
28. Fabricで作成したテーブルをDatabricksで使用する ・Databricksから編集 ⇒NotebookからSparkが可能 もちろんBIにも反映
29. Fabricで作成したテーブルをDatabricksで使用する ・Databricksから編集 ⇒NotebookからSparkが可能 もちろんFabric側にも反映 FabricとDatabricksの相互運用性③：Fabric で作成したテーブルをDatabricksで利用する（Databrickで閲覧・分析・編集可能） #BI - Qiita
30. なぜhubストレージにDelta Lake形式保管が 相互運用力を上げるか
31. ベンダーにデータを渡すな！（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 Data + AI Summit Keynote Day 1 - Ali Ghodsi, Co-founder and CEO of Databricks CEO Ali Ghodsi さん 2024 Data + AI Summit Keynote Day 1 より Databricks Leadership Team | Databricks
32. WHではなくLHだからこそ実現できるhubストレージによる相互運用性 ウェアハウス レイクハウス 誕生 1980年代 2020年ころ ストレージ 専用フォーマット／エンジンと密結合 ADLS・S3・GCS など安価なオブジェクトストレージ ACID・トランザクショ ン ネイティブに対応 Delta／Iceberg 等で同レベル機能を実装 非構造化データへの対 応 非対応 対応：画像・ログもそのまま取り込み可能 製品例 Snowflake、Fabric Warehouse Databricks、Fabric Lakehouse オープンフォーマット （Delta Lake、Iceberg） で保管可能 ウェアハウス レイクハウス どこの クラウドストレージ でもOK どのベンダー でもOK 参考： Microsoft Fabric OneLake を通じた Delta Lake & Iceberg の相互運用性 - Speaker Deck
33. • 疎結合 • 各システムはその“中央（hub）”とだけやり取り する • それぞれが独自の形式で連携するのではなく、あ らかじめ決めた共通ルールに従ってデータをやり 取りする • ベンダーフリー • オープンテーブルフォーマットを利用すれば将来 的に他のエンジンとの拡張性も高い • 企業におけるデータ相互運用性の複雑さと サポートコストが大幅に削減される システムが１つ • 理想的な面も多い • ETL なしで即時に データが使える • セキュリティ設定・ガバ ナンスが一元管理可能 • 運用設計がシンプル • ベンダーロックが起きる • 別のベンダー製品を追加 したいけど、既に大量の データを囲い込んでし まっている etc Hub Storage ３つ以上のシステムでデータを交換するときのhubストレージの効率性 システムが2つ のどれかに固定 etc のうち２つ使う システムが3つ以上 etc のうち3つ以上使う 今後も減ったり増えたり • 蜜結合 • どちらかの仕様変更や 障害がもう一方に 影響する • 更新タイミングのズレ がデータ不整合を招く • 「どちらのテーブルが 正しいか？」の混乱が 起きやすい unknown 参考：一般社団法人 データマネジメント協会 日本支部(DAMA Japan)
34. 課題
35. 課題 ▪ Fabric 側の課題 • ゴールドレイヤーをウェアハウスで使いたい場合は ETL が必要 • ショートカットはレイクハウスにしか適用できないため、ウェアハウスで使うに は一度データを取り込む必要がある • ショートカット参照時は V-Order が効かない • 読み込みパフォーマンスが最適化されないが、後から OPTIMIZE を手動実行すれ ば補える ▪ Databricks 側の課題 • Fabricから作成されたテーブルに対して個別で外部テーブルの再指定が必要 • →毎回 テーブルごとにSQL で CREATE TABLE ... USING DELTA LOCATION ... を書く 必要がある（Fabricは一度ショートカットするだけ） • 予測最適化が機能しない • Databricks の予測最適化機能は主にマネージドテーブル（managed table）向け で、外部テーブルには適用されない
36. 課題 共通の課題 ▪ メンテナンス・運用上の注意点 • メンテナンス処理の競合（OPTIMIZE / VACUUM など） • Databricks と Fabric がそれぞれのスケジューラで OPTIMIZE や VACUUM を実行すると、 タイムトラベルが壊れたり、ファイル欠損が発生するリスクあり • どちらが管理主体になるか、明確な役割分担が必要 ▪ ガバナンスとメタデータ管理の分散 • Unity Catalog（Databricks）とOneLake（ Fabric ）で メタデータの管理系統が分かれている • アクセス制御・変更履歴・データリネージの追跡が一元管理の方法について検討する必要 ▪ メダリオンレイヤーの「どこまで共有するか」問題 • Bronze から共有すると： 権限管理が非常に煩雑 • Gold だけ共有すると： ETL 回数が増え、レイテンシやコストが上がる ▪ 権限モデルの二重管理 • ADLS 側では RBAC / ACL、Databricks 側では Unity Catalog の GRANT 構文、Fabric 側では Workload ロールと OneLake アクセス権 • 複数層での管理が必要となり、運用ルールの明文化などが求めらる
37. まとめ hub ストレージとDelta Lakeを用いた Fabric と Databricksをつなぐデータ総合運用術 • Fabric、Databricksどちらからもシームレスにテーブルの 作成・使用が可能 • Delta Lake （オープンテーブルフォーマット）を利用するため、 将来的に他のエンジンとの拡張性も高い • どんなベンダーにも対応できる • 自社のデータを自分たちで管理
38. 参考文献 Azure Databricks から OneLake 上のデータにアクセスする方法 2024/12 版 #Microsoft - Qiita ミラーリング - Microsoft Fabric | Microsoft Learn Azure Databricks からの Microsoft Fabric ミラー化カタログ (プレビュー) - Microsoft Fabric | Microsoft Learn Azure Databricks からの Microsoft Fabric ミラー化データベース (プレビュー) チュートリアル - Microsoft Fabric | Microsoft Learn OneLake と Azure Databricks の統合 - Microsoft Fabric | Microsoft Learn Lakehouse フェデレーションとは - Azure Databricks | Microsoft Learn 具体化されたビュー - Azure Databricks | Microsoft Learn Microsoft Fabric での Delta テーブルのメンテナンス - Microsoft Fabric | Microsoft Learn Solved: V-Order & Z-Order - Microsoft Fabric Community Delta Lake テーブル形式の相互運用性 - Microsoft Fabric | Microsoft Learn Databricks ユーザーが Fabric を使う際にひっかかりがちな Delta Lake テーブル機能の互換性について #Microsoft – Qiita 削除ベクトルとは - Azure Databricks | Microsoft Learn