APC 技術ブログ

株式会社エーピーコミュニケーションズの技術ブログです。

株式会社 エーピーコミュニケーションズの技術ブログです。

トップ > DatabricksとMicrosoft Fabricの連携 メリットと方法について

DatabricksとMicrosoft Fabricの連携 メリットと方法について

目次

1.はじめに

iTOC事業部GDAI部の合田と申します。
近年、データ活用の現場では膨大なデータを高速に処理する「エンジニアリング」と、その結果を素早くビジネスの意思決定に繋げる「可視化」の両立が求められています。こうしたニーズに対し、有力な選択肢となるのが Azure Databricks と Microsoft Fabric です。
しかし、どちらも強力なレイクハウス機能を持つがゆえに、「どちらを導入すべきか」「どう使い分けるべきか」という点に悩む機会も多いと思います。
本記事では、両者の特徴を整理した上で、なぜこれらを組み合わせることで真価を発揮するのか、その連携メリットを詳しく解説します。
それぞれの強みを活かした「Databricksをデータの加工に利用し、Microsoft Fabricを可視化に利用するために連携させる」という使い方が連携時に効果的です。

引用：Microsoft Fabric と Azure Databricks を使用して SMB の最新のデータ プラットフォーム アーキテクチャを構築する

2.Databricks と Microsoft Fabric の強みと連携時の担当領域

どちらも似たような機能を備えておりますが、それぞれ異なることを得意としているサービスです。 連携する際は、それぞれの得意なことが生きるように担当領域を分けると効果的です。

サービス 得意なこと 主要なユーザー層
Databricks 高度なETL、機械学習(AI)、Unity Catalogによるデータ管理 エンジニア・サイエンティスト
Microsoft Fabric Power BIによる高速可視化、Office 365統合、ノーコード加工 アナリスト・ビジネスユーザー

Databricks の担当領域（データ加工・高度な分析）

Databricksは、大量のデータを高度に処理し、クレンジングや構造化を行う「データの工場」としての役割を担います。

  • 高度なETL / データエンジニアリング
    Sparkエンジンを活用し、大規模で複雑なデータセットのクレンジング、変換、統合処理を高速に実行します。
  • データサイエンスと機械学習
    MLflowを用いたモデルの学習、ライフサイクル管理、および大規模な推論処理（バッチ・リアルタイム）を強力に支援します。
  • Unity Catalogによる統制
    カタログ、スキーマ、テーブルの階層で、組織横断的なデータ資産に対するきめ細かなアクセス制御とデータリネージ（履歴管理）を実現します。

Microsoft Fabric の担当領域（データの可視化・共有）

Fabricは、加工済みのデータをビジネスユーザーへ届け、迅速な意思決定を支援する「データの店舗（配信拠点）」としての役割を担います。

  • セルフサービスBI（Power BI）
    Direct Lakeモードを活用することで、データを複製することなく、Databricks上のDeltaテーブルをインメモリ並みの速度で可視化します。
  • ビジネスユーザーへの公開と共有
    Power BIレポートやダッシュボードを通じて、加工済みのデータを組織全体へ安全かつ直感的に共有します。
  • Office 365 エコシステムとの統合
    TeamsやExcelなど、日常的なビジネスツールとシームレスに連携したデータ活用を提供します。

3.【メリット】あえて連携させる３つのメリット

「DatabricksからPower BIへ直接接続する」構成と比較して、Microsoft Fabricをハブとして介在させることで得られる技術的・運用的メリットをさらに深掘りして解説します。

Direct Lake モードによるレスポンス性能の向上

  • コピーレスなインメモリ実行
    従来、高速な分析にはデータをPower BI側にコピー（インポート）する必要がありましたが、Direct LakeはOneLake上のDeltaファイルを直接インメモリにロードします。これにより、数億行のデータでも移動させることなく、インポートモードと同等のレスポンス性能を発揮します。

  • 「V-Order」による最適化
    Fabric（OneLake）上のデータは「V-Order」という書き込み最適化が施されており、Direct Lakeはこの構造を最大限に活かして高速な読み取りを実現します。

コストの最適化による計算リソースの分離による予測可能性の向上

Databricksに直接つなぐ構成では、レポートの閲覧が増えるほどDatabricks側のコストが跳ね上がるリスクがあります。

  • DBU消費の抑制
    DirectQuery接続では、レポートのフィルター操作一つひとつがDatabricksのSQL Warehouseを稼働させ、DBU（Databricksの課金単位）を消費し続けます。Fabricを挟むと、閲覧時の負荷はFabric側のリソース（F SKU等の固定容量）で処理されるため、Databricks側のコストをエンジニアリング業務のみに集中させることができます。

  • 定額リソースの活用
    レポート閲覧者が数十名、数百名と増えても、あらかじめ確保したFabric容量の範囲内で処理を完結できるため、月額コストの予測が容易になります。

分業とガバナンスの共存

各ユーザー層が「最も使い慣れた、得意なツール」に専念できる環境を提供します。

  • エンジニアやサイエンティスト
    Databricksの強力なノートブック環境やUnity Catalogによる厳格なガバナンス、MLflowによるモデル管理を駆使して、PythonやSQLで高度なデータパイプラインを構築することに専念できます。

  • ビジネスユーザー
    「親しみのあるSaaS環境」をアナリストやビジネスユーザーは、ExcelやTeamsと親和性の高いMicrosoft FabricのUI上で、安全に、かつノーコード・ローコードでデータを探索できます。これにより、全社的なデータ利活用（データ民主化）が加速します。

4.【デメリット】権限管理の二重持ち問題

連携時に必ず直面するのが「どちらのサービスで権限を管理するか？」という問題です。

  • 課題： Databricks (Unity Catalog) と Microsoft Fabric (Workspace Role) の両方で設定が必要になり、管理が複雑化しやすい。
  • 運用Tips：
    • Entra ID（旧Azure AD）グループの共通化： 権限付与の単位をグループに統一し、両方のサービスで同じグループを参照するようにします。
    • サービスプリンシパルの活用： Microsoft FabricからDatabricksへの接続を特定の共通アカウントに集約する。

5.コストからみた検討開始の目安

DatabricksとMicrosoft Fabricを連携させ、PowerBIで可視化を行う構成は非常に強力ですが、両方の基盤にコストが発生します。そのため、単体運用から連携構成へシフトすべき「損益分岐点」を正しく把握することが重要です。データ量（パフォーマンス限界）とユーザー数（コスト予測可能性）の2軸から、具体的な目安を解説します。

① データ量の分岐点：1億行（または 100GB）

  • Databricks単体（DirectQuery）
    データが1億行を超えると、レポートを表示するたびにDatabricksの計算リソース（SQL Warehouse）がフル稼働し、応答に数秒〜数十秒の待ちが発生し始めます。この「クエリの重さ」がDBU消費（コスト）を跳ね上げる要因です。
  • Microsoft Fabric連携（Direct Lake）
    1億行を超える巨大なテーブルであっても、Microsoft FabricがDeltaファイルをV-Order形式でメモリに最適化ロードするため、ユーザーは待ち時間ゼロで分析できます。

    目安： 1テーブルが1億行、あるいはデータサイズが100GBを超え、BIの応答速度に不満が出始めたらMicrosoft Fabric連携の検討時期です。

② ユーザー数の分岐点：30〜50名

  • Databricks単体 DatabricksをPower BIから直接参照（DirectQuery）する場合、ユーザーのすべての「アクション」がSQL Warehouseの稼働（DBU消費）に直結します。

    • SQL Warehouseの処理が走るタイミング

      • レポートを開いたとき
      • スライサー・フィルターの操作
      • グラフのドリルダウン

    • 同時実行性能の限界とオートスケール
      SQL Warehouseには同時実行できるクエリ数に上限があるため、閲覧者が増えてクエリが滞留し始めると、Databricksは応答速度を維持するために自動でクラスターを並列化（スケールアウト）します。

    • 課金の加速: クラスターが2倍、3倍と増えるごとに、消費されるDBUも倍増します。全社的にレポートを公開した場合、特定のごく短い時間帯にアクセスが集中し、1ヶ月の予算を一気に消化してしまうような「コストの予測不可能性」が最大の懸念点となります。

  • Microsoft Fabric連携
    Fabricをハブとして介在させると、レポート閲覧時のコンピューティング負荷の所在がDatabricksからFabricへと移ります。

    • ユーザーの「アクション」でSQL Warehouseが稼働不要 Fabricのショートカット経由で「Direct Lakeモード」を利用する場合、Power BIはOneLake上のDeltaファイルを直接メモリにロードして処理します。レポート閲覧時にDatabricksのSQL Warehouseを起動しておく必要はなく、Fabricの計算リソース（F SKU）を利用します。
      • 予約済みキャパシティ
        Fabricの計算リソース（F SKU）は、あらかじめ確保した「F2」や「F64」といったサイズ（容量）の範囲で動作します。
      • コストの固定化
        Fabricの料金は「稼働時間 × 容量単価」の固定レートで推移するため、ユーザーが30名から100名に増えたとしても、確保した容量の範囲内であれば追加コストは発生しません。これにより、大規模な組織展開においてもコストの予測がしやすくなります。

6.Databricksとの連携方法

Databricksとの連携方法は３つあります。

  • OneLakeショートカット
    Databricks側でデータをAzure Data Lake Strage（ADLS） Gen2に保存し、それをMicrosoft Fabricから直接参照する方法です。

  • Data bricksカタログのミラーリング
    DatabricksのUnity CatalogにあるテーブルをMicrosoft Fabricへミラーリングし、Microsoft Fabric上で直接クエリ可能にする方法です。

  • Hubストレージを利用する ADLS Gen2上にDeltaテーブルを置き、Microsoft Fabricは「スキーマショートカット」、Databricksは「外部テーブル」として同じデータを参照・編集する方法です。

・比較表

連携手法 特徴 向いているケース
OneLakeショートカット ADLS上のデータを直接参照 最も一般的。既存のデータ資産をそのまま活かしたい場合
Unity Catalogミラーリング メタデータを含め自動同期 Unity Catalogの環境をMicrosoft Fabric側でも維持したい場合
Hubストレージ(外部Table) 共通のストレージを読み書き DatabricksとMicrosoft Fabricの双方から頻繁に書き込みが発生する場合

7.OneLakeショートカットでデータを実体なしで接続してみる

「OneLakeショートカット」を利用してMicrosoft FabricからADLSGen2のデータを参照するまでの設定をハンズオンで行ってみたいと思います。

作業ステップ

  • Azureポータル上での準備
    • Azureポータルにログインし「アプリの登録」を行う
    • 「アプリの登録」時に以下３つの情報を用意
      • アプリケーション (クライアント) ID
      • ディレクトリ (テナント) ID
      • クライアント シークレットの「値」（※IDではなく「値」です）
    • 対象のADLS Gen2のURL

  • 作成したアプリへIAM権限付与

  • Microsoft FabricにLakehouseを作成し、FilesにOnelakeショートカットを作成する

STEP 1：Azureポータル上で「アプリの登録」を行う

  1. Azureポータルの上部検索ボックスで「アプリの登録」を検索し、新規登録をクリック。

  1. 任意の名前（例：Fabric-Databricks-Link）を入力し、登録します。

    • サポートされているアカウントの種類
      該当のものを選択、デモは同一組織間の連携を行っている為「この組織ディレクトリのみに含まれるアカウント」を選択しています。
    • リダイレクト URI (省略可能)
      今回は省略

  2. 登録完了後、画面に表示される以下の情報をメモしてください。

    • アプリケーション (クライアント) ID
    • ディレクトリ (テナント) ID

  3. 左メニューの [証明書とシークレット] > [新しいクライアント シークレット] を作成。

    • 重要： 追加後に表示される 「値」 を必ずコピーしてください（一度画面を離れると再表示できません）。

STEP 2：作成したアプリへIAM権限の付与

作成したアプリ（サービスプリンシパル）に、データへアクセスする許可を与えます。 なお、こちらの権限付与はテナントの設定によっては管理者しか付与できない可能性もあります。

  1. 対象のADLS Gen2（ストレージアカウント）のリソース画面を開きます。

  2. [アクセス制御 (IAM)] > [追加] > [ロールの割り当ての追加] を選択。 ※私は権限がないのでグレーアウトしています。同様の方は管理者に権限付与を依頼することとなります。

  3. 「ストレージ BLOB データ閲覧者」を選択します。

    • ※データの書き込みも行う場合は「ストレージ BLOB データ共同作成者」を選択。
  4. [メンバー] タブで、STEP 1 で作成したアプリ名を選択して [レビューと割り当て] をクリック。

STEP 3：ADLS Gen2 のエンドポイント URL を確認

Microsoft Fabric側の設定画面で入力する接続先アドレスを確認します。

  1. ストレージアカウントのメニューから [エンドポイント] を開きます。
  2. 「Data Lake Strage」 の項目にあるURL（https://<アカウント名>.dfs.core.windows.net/）をコピーします。

STEP 4：Microsoft FabricにLakehouseを作成し、TablesにOnelakeショートカットを作成する

最後に、Microsoft Fabric側で「データの実体を動かさない」接続設定を行います。

  1. Microsoft Fabricのワークスペースから [＋新規] > [Lakehouse] を作成。

  2. エクスプローラー画面の [Tables]（Delta形式として認識させたい場合）を右クリックし、[新しいショートカット] を選択。

  1. [Azure Data Lake Storage Gen2] を選択し、設定を入力します。
    • URL: STEP 3 でコピーした URL
    • 接続: 「新しい接続を作成」を選択
    • 認証種類: 「サービス プリンシパル」を選択
    • 各ID/シークレット: STEP 1 でメモした値をそれぞれ入力
      • テナントID：テナントID
      • サービスプリンシパルのクライアントID：アプリケーションID
      • サービスプリンシパルキー：クライアントシークレットの値

  1. 接続が確立されるとエクスプローラーにADLS内のコンテナが表示されるので、対象を選択して [作成] をクリックすれば完了です！
    以下画像のようにTables内にテーブルデータが追加されています。

8.参考文献

Azure Databricks 関連

Microsoft Fabric 連携・可視化関連

データパイプライン・ストリーミング関連

9. おわりに

  • スモールスタートの場合
    まずはDatabricks単体とPower BIの直結構成で、ミニマムに運用を開始するのが適しています。
  • 全社展開・大規模データへの対応が必要な場合
    Microsoft FabricのDirect Lake連携を活用することで、コストの予測可能性を高めつつ、ユーザーがストレスを感じにくいデータ参照環境の構築が可能になります。

まずは両方の試用版を使って、ショートカットによる「データ移動のない連携」を試してみてください。
また、一緒に働いていただける仲間も募集中です！ エーピーコミュニケーションズやGDAI部にご興味がある方は問い合わせいただければ幸いです。 hrmos.co