Microsoft OneLakeのパターンと基礎機能

この記事では、一般的なOneLakeパターンと、それらを実装するために使用できるプラットフォーム機能について紹介します。 この記事の情報を活用して、データ環境をどのように整理したいかを考え、ビジネス、技術的、ガバナンスのニーズに合ったパターンを選んでください。

各パターンは、特定のアーキテクチャ目標を達成するためにデータと所有権をどのように整理するかを記述しています。 パターンを実装するには、 OneLakeの基礎的な機能 の一つまたは複数を組み合わせます。データ仮想化、オープンデータの相互運用性、中央集権的ガバナンス、統合分析とAIです。 各機能はショートカット、ミラーリング、OneLakeのセキュリティ、Direct Lakeモードなど、特定の 製品機能 に依存しています。 同じ機能や特徴が複数のパターンで現れることがよくあります。

Note

この記事は 、OneLakeのアーキテクチャガイダンス白書で特定されたパターンに基づいています。

これら5つのパターンをOneLakeデザインの構成要素と考えてください。 ほとんどの環境は複数の環境を組み合わせています。 目標に合ったパターンを選びましょう:

最小限のレプリケーションで統一データアクセス

もしデータが複数のクラウド、オンプレミスシステム、外部のレイクに分散している場合、すべてを一箇所にコピーするのは現実的でない、あるいは不可能かもしれません。 最小限の 複製パターンによる統一データアクセス により、OneLakeはこれらのソース全体で単一の論理データレイヤーとして扱われます。 すべてのソースに対してインジェストパイプラインを作る代わりに、ショートカットを使ってデータをその場で参照し、同期されたクエリ最適化コピーが必要なときにミラーリングします。

このパターンは次の状況で使用します。

  • あなたのデータは複数のクラウド、オンプレミスシステム、または外部のレイクに分散しています。
  • 中央ストレージにデータを複製すると、過剰なストレージ、遅延、コンプライアンスのオーバーヘッドが生じます。
  • 新しいソースを迅速にオンボーディングし、完全な抽出・変換・ロード(ETL)パイプラインを書く必要はありません。
  • 既存のデータレイク、倉庫、運用ストアへの投資を維持したいのです。

統合データアクセスの適用

このパターンを実践するためには、まずデータ移動プロセスを構築・運用する必要のない2つの主要なデータアクセスアプローチから始めましょう。仮想 化 はソースデータをコピーせずにOneLake経由で利用可能にし、 ゼロETLミラーリング はプラットフォーム管理の同期コピーを分析対応のデルタテーブルとしてOneLakeに持ち込みます。 Fabricのデータ移動ツールは、これらの方法がソースをサポートしていない、または要件に合わない場合にのみ使用してください。 これらのアプローチの選択と組み合わせに関する追加のガイダンスについては、 UnifyデータとOneLakeショートカットおよびミラーリングをご覧ください。

  1. OneLakeが仮想化やゼロETLミラーリングでアクセス可能なデータソースをインベントリ作成し、クラウドオブジェクトストレージ、外部カタログ、運用データベース、Dataverseなどを特定しましょう。 残っている情報源はデータ移動の方法が必要だとフラグを立ててください。

  2. サポートされる各ソースに合った適切なデータアクセス技術を選択してください。 ソースがノーコピーアクセスをサポートする場合は仮想化を好みます。 ソースが同期しクエリ最適化されたコピーを必要とする場合、ゼロETLミラーリングを使用してください:

ソース データ アクセス方法 データの処理
クラウドオブジェクトストレージ(Azure Data Lake Storage Gen2、Amazon S3、Google Cloud Storage)およびS3互換オンプレミスストレージ ショートカット 仮想化:ソースデータをコピーせずに利用可能にする
コピーせずに利用可能にしたい外部カタログで管理されるデータ(例:Azure Databricks Unity Catalog)など メタデータミラーリング - カタログメタデータ(スキーマ、テーブル)のみを同期し、ショートカットを通じてソースデータにアクセスする 仮想化:ソースデータをコピーせずに利用可能にする
クエリ最適化コピーが必要な運用データベース(Azure SQL Database、Azure Cosmos DB、Snowflake、PostgreSQL、SQL Server 2025、Oracle Database、Google BigQuery) データベースミラーリング、またはサポートされるカスタムおよびパートナーソリューション向けのオープンミラーリング Zero-ETL ミラーリング:同期されたデルタコピーを作成する
Dataverse(Dynamics 365およびPower Platformデータ) Microsoft Fabricへのショートカットまたはリンクによるゼロコピーアクセス 仮想化:ソースデータをコピーせずに利用可能にする

  1. 必要に応じてソースデータを変換します。 ショートカット変換は、外部に保存されているかOneLakeに既に保存されているかに関わらず、ショートカットを通じて公開されたサポートファイルを処理できます。 ショートカットファイル変換を使って構造化ファイルをデルタテーブルに変換したり、ショートカットAI変換で非構造化テキストを処理したりできます。 ショートカット変換は変換されたデルタ出力を作成し、ショートカットで参照されるデータと同期させます。

  2. 仮想化やミラーリングがソースをサポートしていない場合や、複雑な変換、オーケストレーション、スケジュールされた移動のリズム、ストリーミングの取り込みが必要な場合は、Fabricのデータ移動ツールを活用してください。 パイプライン、データフロー、コピージョブ、イベントストリームの中から選択するための助けは、「 データ移動戦略の選択」をご覧ください。

データ移動を選択した場合は、 Delta Parquet や Icebergのようなオープンテーブル形式でコピーデータを格納してください。 ミラーリングやショートカット変換はすでにデルタ出力を生み出します。 オープンフォーマットを使用することで、仮想化されたデータ、同期されたコピー、変換されたDelta出力がFabricエンジンや外部プラットフォームで読み取れるように保ちます。

  1. 同期コピー、変換されたDelta出力、またはFabricのデータ移動ツールでコピーを作成する際には、その理由を必ず記録してください。 この記録により、決定は監査可能な状態に保たれます。 ソースが物理的なクエリ最適化レイアウトを必要としているか、フレッシュネス、変換コスト、コンプライアンス、処理要件をバーチャルで満たせない場合のみコピーを作成しましょう。

  2. OneLakeを通じて提供されるデータに OneLakeのセキュリティ を適用し、仮想化されたデータ、同期コピー、変換されたDelta出力を同じポリシーでカバーします。

  3. OneLakeカタログで得られるデータ項目を推奨し説明し、消費者が見つけて信頼できるようにします。

統合データアクセス機能

  • データ仮想化 と ゼロETLミラーリング - 他のシステムやクラウドに存在するデータをノーコピー参照や同期済みの分析対応コピーで公開します。 機能：
  • 中央集権的ガバナン ス - 仮想化されたソースに対して、ネイティブのOneLakeデータと同様に一貫したセキュリティとディスカバリーを適用します。 機能：
  • オープンデータの相互運用性 - 仮想化されたデータやプラットフォーム管理のコピーをFabricエンジンおよび外部プラットフォームの両方で読み取れるように保つこと。 機能：

メダリオン建築(ブロンズ、シルバー、ゴールド)

OneLakeでデータを公開することは、あくまで第一歩に過ぎません。 ソースシステムからの生データは、分析やAIに直接使うのは通常安全ではありません。 重複、誤り、一貫性のないフォーマット、または機密性の高いフィールドが含まれていることが多いです。 複数のチームが同じソースデータに基づいて構築する場合、各データの段階が何に信頼されるかの共通定義が必要です。

メダリオン アーキテクチャ パターンでは、OneLake 内のデータを 3 つの品質レイヤーに整理します。つまり、ブロンズ層は生の不変なソース データ、シルバー層はクレンジングされ整合性の取れたデータ、ゴールド層は認定済みのビジネス対応テーブルとセマンティック モデルのためのレイヤーです。 各層は、下流の消費者が信頼できる明確な段階です。 シルバーテーブルとゴールドテーブルはBI、分析、AIのワークロードで再利用可能なので、チームは同じクレンジングやモデリングロジックを別々のツールで再構築する必要がありません。

このパターンは次の状況で使用します。

  • 複数のチームは同じソースデータに基づいて構築し、一貫した品質が求められます。
  • 生の入力から認証された出力までの追跡可能な系譜が必要です。
  • データエンジニアリングと分析、あるいはAI消費者との間に明確な契約が必要です。

このパターンの詳細については、「OneLakeでFabricのメダリオンアーキテクチャを理解する」をご覧ください。 その記事では、レイヤー設計、デプロイメントモデル、ストレージフォーマット、マテリアルライズレイクビュー、そしてDeltaテーブル最適化についてカバーしています。

使い方

ワーキングメダリオンは一つの考え方にかかっています。各層は下流の消費者との契約であり、データはその層の品質基準を満たして初めて次の層へ進むということです。

  1. 生の情報源と認証データに依存する消費者を特定しましょう。

  2. 各レイヤーに属するものを定義し、ドメイン間で一貫してこれらの定義を適用してください:

    レイヤー 内容 典型的な消費者
    銅 スキーマの強制なしにソースから直接取得された生の、変わらないデータ データエンジニア(アクセス制限付き)
    シルバー クレンジングされ、重複が排除され、共通のビジネス定義に準拠した データエンジニアと訓練を受けたアナリスト
    金 厳選されたビジネス対応のテーブルとセマンティックモデル BI、分析、AIのすべての利用者

  3. 各レイヤーを適切なFabricワークロードで作成してください。通常はData Engineering(Spark)やData Factoryでブロンズやシルバー、Data WarehouseやPower BIのセマンティックモデルでゴールドを獲得します。 ブロンズでソースの忠実度を保つには、元のフォーマット、ソースデータへのショートカット、必要に応じてParquet、またはDeltaを使いましょう。 銀と金にはDeltaテーブルを使い、Fabricワークロードが精錬されたデータを確実に読み書きできるようにします。

  4. レイヤー認識アクセスポリシーを適用してください。 対応アイテムにはOneLakeのセキュリティを使用し、ウェアハウスには該当するFabricおよびSQL権限を適用してください。 ブロンズへのアクセスを制限し、銀をアナリストに提供し、消費者のニーズや最小特権基準に基づいて金へのアクセスを認めます。

  5. 下流分析にはキュレーションされたゴールド出力を使いましょう。 Direct Lakeモードでゴールドレイヤーのセマンティックモデルを構築し、Power BIがインポートコピーを作成したりスケジュール更新を必要とせずにOneLakeデータを読み取れるようにしましょう。

  6. すべての金の産出物が銀を通じて青銅の産地に至る系譜を持っていることを確認してください。 次に、 OneLakeカタログで認証されたゴールドレイヤーテーブルやセマンティックモデルを推奨してください。 この検証により、消費者はどのデータが本番環境で利用可能かを特定できます。

  7. ゴールドセマンティックモデルを再利用してFabric IQのオントロジーを活性化させましょう。 このステップは、AIエージェントに認証データに基づく管理されたビジネスコンテキストを提供します。

基本的な機能

  • 統合分析とAI - ブロンズ、シルバー、ゴールドのレイヤーが、OneLakeのすべての分析およびAIワークロードにエンジン固有のコピーを使わずに供給します。 機能：
  • 中央集権的ガバナン ス - 各レイヤーで異なるアクセスポリシーと品質ゲートを適用し、消費者が自分の役割に適したデータだけを見るようにします。 機能：
  • オープンデータの相互運用性 - レイヤーをオープンフォーマットで保存し、外部エンジンがFabricと併用して読み取れるようにします。 機能：

共有プラットフォーム上のドメイン指向データメッシュ

複数のビジネスチームがデータを生成・消費している場合、すべてのリクエストを単一の中央データチームにルーティングすると、配信が遅くなる可能性があります。 ビジネスチームは自分たちのデータや要件を最もよく理解していることが多いですが、共有ガバナンスなしの分散化は、セキュリティ、品質、系譜の不整合を招く可能性があります。

ドメイン指向のデータメッシュパターンにより、各ビジネスドメインは独自のデータ製品の所有権を持ち、すべてのドメインはOneLake基盤の上で共有標準に従っています。 各ドメインは独自のデータ製品を公開し、他のドメインはショートカットを通じてそれらにアクセスし、Fabric分析やAIワークロードで利用しています。 中央集権型のアイデンティティ、セキュリティ、ガバナンスポリシーはすべてのドメインで一様に適用されます。

このパターンは次の状況で使用します。

  • 単一の中央データチームが配信のボトルネックとなります。
  • 異なるビジネスドメインは、異なるデータ、要件、リリースの頻度を持っています。
  • 企業全体のガバナンスを維持したまま、ドメインレベルのデータ品質に関する明確な説明責任を確保する必要があります。

ドメイン指向のデータメッシュを適用します

分散化と一貫性の適切なバランスを見つけてください。 所有権をデータを最もよく知るドメインに押し付け、アイデンティティ、セキュリティ、系譜を中央集権化して、すべてのドメインのデータ製品が同じ基準を満たすようにしましょう。

  1. ビジネスドメインを特定しましょう。 各ドメインは、エンドツーエンドでデータ製品を所有・運用できるチームを持つ、ビジネスの一貫した領域を代表すべきです。

  2. 各ビジネスエリアごとに ドメイン を作成し、ワークスペースを割り当てます。 共有インフラと再利用可能なエンタープライズデータ用に別個の中央ドメインを設定しましょう。

  3. すべてのドメインが満たすべきデータ製品標準を定義します。例えば、承認や認証要件、文書化されたスキーマ、所有権メタデータ、バージョン管理、サービスレベル契約(SLA)などです。 これらの標準により、各製品は単なるワークスペースフォルダーではなく、再利用可能で発見可能な契約書となっています。

  4. OneLakeのセキュリティを活用して、フォルダ、テーブル、行、列レベルでロールベースのデータアクセス制御を適用し、プロデューサーがワークスペース内のすべてを公開せずにデータ製品を公開できるようにします。

  5. OneLakeカタログによるテナント全体のガバナンスをクロスドメインの発見と系譜管理に適用し、Microsoft Purviewを活用してセンシティブラベルや監査を行うことができます。 同じアイデンティティとポリシーモデルをドメインデータ製品を利用するAIエージェントにも拡張し、エージェントのアクセスは他の消費者と同様に管理されます。

  6. 消費者向けドメインは、コピーするのではなく、生産者のデータ製品を参照する ショートカット を使うようにしましょう。 消費者は、自分のニーズに合った参照データ製品をFabricワークロードで利用できます。 Power BIのセマンティックモデルでは、Direct Lakeモードを使ってOneLakeから直接データを読み取ってください。 Fabric Data AgentsやFabric IQを使って、ガバナンスされたドメインデータ製品に基づくAI体験を作成しましょう。

  7. ドメインがFabric外のカタログに公開する場合は、アクセス制御の同期を計画し、OneLakeと外部カタログ間の権限が一貫性を保つようにしましょう。

    Tip

    MicrosoftのオープンソースアクセラレーターであるPolicy Weaverは、Azure Databricks(Unity Catalog)、Snowflake、Dataverseソースの同期を自動化できます。 これはデータアクセスポリシーをOneLakeのセキュリティロールにミラーリングし、ミラーリング(データを移動させるが権限は移動しない)を補完します。

データメッシュ機能

  • 中央集権的ガバナン ス - 所有権をドメインに分散させつつ、アイデンティティ、セキュリティ、系譜を中央集権化します。 機能：
    • ドメインは ビジネスエリアごとにワークスペースをグループ化します。
    • OneLakeのセキュリティ は、ロールベースのフォルダー、テーブル、行、列のアクセス制御を提供します。
    • OneLakeカタログ は、ドメイン横断的な発見と系譜を可能にします。
    • Microsoft Purviewはセンシティブラベルと監査を適用します。
  • データ仮想化 - 消費者ドメインがコピーではなく参照を通じてプロデューサー所有のデータ製品を利用できるようにします。 機能：
  • 統合分析とAI - すべてのドメインのデータ製品をFabricワークロード全体で消費可能にします。 機能：

分析とAIのためのプラットフォーム統合

複数の分析プラットフォームを並行して運用すると、データウェアハウジング、ビジネスインテリジェンス、データサイエンス、リアルタイム分析、AIのそれぞれのツールがそれぞれ独自のデータコピー、パイプライン、ガバナンスモデルを備えています。 その断片化はコストを押し上げ、一貫したセキュリティを適用したり、ビジネス上の質問に対して単一の答えを得るのを難しくします。

プラットフォーム統合パターンにより、これらのワークロードはFabricに移され、OneLakeは共有されガバナンスされたデータ基盤を提供します。 Fabricワークロードは、各ツールごとに個別のデータやガバナンスモデルに頼るのではなく、この基盤を通じてデータへのアクセス、変換、同期、分析を行います。

このパターンは次の状況で使用します。

  • 複数の分析プラットフォームを使い、機能が重複しています。
  • エンジン固有のデータコピーやパイプラインはコストと保守のオーバーヘッドを増加させます。
  • すべての分析およびAIワークロードに共通する単一のガバナンスとセキュリティモデルが必要です。

プラットフォーム統合の適用

より多くの統合ではなく、プラットフォーム数を減らすことを目指しましょう。 ツールをブリッジするのではなく、Fabricでワークロードを統合し、外部エンジンをまだ廃止できない時だけブリッジしてください。

  1. 現在使っている分析、データウェアハウジング、データサイエンス、ビジネスインテリジェンス(BI)、AIツールやパイプラインをリストアップしましょう。 各ツールがどのワークロードを担当し、どのデータをコピーするかを確認しましょう。

  2. 既存の各ワークロードを置き換え可能なFabricワークロードにマッピングします:

    レガシーワークロード Fabric 作業負荷
    データ オーケストレーションと ETL データファクトリー
    Sparkノートブックとレイクハウス処理 データ エンジニアリング
    SQLデータウェアハウジング Data Warehouse
    ストリーミングとKQL分析 リアルタイム インテリジェンス
    MLモデルのトレーニングと実験トラッキング データ サイエンス
    運用データベース データベース(FabricのSQLデータベースおよびFabricのCosmos DB)
    BIの可視化とセマンティックモデル Power BI と Direct Lake モード
    エンタープライズデータに基づく対話型AI Fabric Data Agents、Copilot for Fabric、Fabric IQ

  3. OneLakeのセキュリティ、Microsoft Purview、OneLakeカタログを用いて、すべてのワークロードに一つのガバナンスとセキュリティモデルを確立します。 サポートされるFabricアイテムが追加の暗号化層を必要とする場合は、顧客管理キーを設定しましょう。

  4. DeltaまたはIceberg形式を用いてOneLakeで分析データを統合し、ワークロードがガバナンスされたデータ基盤を共有できるようにします。 運用ワークロードをFabricデータベースに統合することで組み込み、同期された分析データをOneLakeで利用可能にします。

  5. 統合されたデータにAIを置く。 キュレーションしたデータレイヤーの上にオントロジー(プレビュー)を構築し、Ontology MCPサーバーを通じてエージェントに公開します。そうすればFabric Data Agents、Microsoft 365 Copilot、外部ツールは同じガバナンスコンテキストで計算できます。 Power BIのセマンティックモデルから、インポート、Direct Lake、またはDirectQueryモードでオントロジー定義を生成できます。 サポートされるOneLakeデータに生成されたバインディングが必要な場合は Direct Lakeモード を使用し、現在のオントロジーの制限を確認してください。

  6. 外部エンジンでまだ引退できない場合は、Azure Databricks連携、SnowflakeとのIceberg相互運用性、OneLakeアクセスやAPIを通じてOneLakeデータを公開しましょう。

  7. Fabricの同等品を検証した後、置き換えたツール、データコピー、パイプラインは廃止してください。 そうすることで、統合によってコストやライセンス、引き継ぎを省き、新たなプラットフォームを追加することがなくなります。

プラットフォーム統合機能

組織間の外部データ共有

パートナー、サプライヤー、顧客、その他の部門と継続的にデータを交換する場合、バッチエクスポート、ファイル転送、重複した下流システムの生成は遅延、コスト、ガバナンスのギャップを生み出します。 外部データ共有パターンにより、組織や事業部門外の消費者が、繰り返しエクスポートされることなくキュレーションされたOneLakeデータに直接アクセスできます。 消費者はFabricのテナント間共有や、OneLakeの相互運用機能を利用してSnowflakeやAzure Databricksなどの外部分析プラットフォームからデータにアクセスできます。

消費者はあなたが更新を公開することでそれを目にします。 消費者のプラットフォームをサポートする共有や相互運用性のメカニズムを通じて、ソースデータへのアクセスを制御します。

このパターンは次の状況で使用します。

  • 外部組織と継続的にデータを交換しています。
  • バッチエクスポートやファイル転送は遅延、複雑さ、ガバナンスのギャップを生み出します。
  • 外部アクセスを中央で追跡・取り消す必要があります。

外部データ共有の適用

外部共有は、データをエクスポートするよりも仮想化を使うときに最も効果的に機能します。 アクセス方法を各消費者が読み取れる内容にマッチさせ、その共有や相互運用性メカニズムでサポートされるアクセス制御を適用します。

  1. 外部に共有したいデータ製品と、それを必要とする消費者(パートナー、サプライヤー、顧客)を特定しましょう。 通常、厳選されたテーブルやファイルは明確に定義されドキュメント化されています。

  2. 各消費者に最適なシェアリング方法を選ぶ:

    消費者タイプ 推奨される方法
    別のテナントの Fabric のユーザー 読み取り専用の仮想化されたテナント間アクセスのための外部データ共有
    Snowflake on Azure のユーザー IcebergとSnowflakeの相互運用性:Iceberg形式で公開されたFabricテーブルを読み取るための
    Azure Databricks ユーザー Azure DatabricksでOneLake Catalog Federationを用いて、データをコピーせずにUnCatalog経由でOneLakeテーブルをクエリする方法
    ADLS Gen2 または Blob API をサポートするアプリケーションやツール OneLakeへのアクセスおよび 対応APIを通じてOneLakeデータにアクセスするAPI

    Dataverse のデータを共有する前に OneLake に取り込むには、統合データ アクセス パターンを使用します。

  3. 選択した共有メカニズムでサポートされる権限で外部アクセスの範囲を設定できます。 Fabricの外部データ共有では、共有により招待されたユーザーのホームテナント内の任意のユーザーに読み取り専用アクセスが付与されます。 OneLakeのセキュリティ、センシティブラベル、データ損失防止ポリシーなどのプロバイダー側のセキュリティおよびガバナンスポリシーは、消費者のテナントでは強制されていません。 消費者は自らの環境における下流アクセスを管理しなければなりません。

  4. 共有関係の条件を事前に合意しましょう。何を共有するか、誰と、どのくらいの期間を共有するかを。 Fabricの外部データ共有については、「権限管理」ページの「外部データ共有」タブからのアクセスを取り消してください。 他の方法については、選択した共有メカニズムを通じてアクセスを取り消します。 消費者が視界を失うことを確認しましょう。

  5. プロバイダーのFabric環境でMicrosoft Purviewを使って、センシティブラベル、監査、データ損失防止を適用します。

  6. OneLakeカタログ内のソースデータ製品を承認・文書化し、プロバイダーが共有前に見つけて管理できるようにします。 OneLakeのカタログは、データ製品を外部のテナントや分析プラットフォームに公開しません。

外部データ共有機能

  • データ仮想化 - エクスポートパイプラインを管理せずにノーコピー参照を通じてデータを共有する。 機能：
  • オープンデータの相互運用性 - Fabricを使わない消費者とオープンフォーマットで共有。 機能：
  • 中央集権的ガバナンス - Fabric内のソースデータを管理し、各共有メカニズムを通じて外部アクセスを制御します。 機能：
    • OneLakeのセキュリティはFabric内のソースデータへのアクセス範囲をカバーします。
    • Microsoft Purviewは、プロバイダーのFabric環境でセンシティブラベル、監査、データ損失防止を適用します。
    • OneLakeカタログ は、共有前のプロバイダー側の発見と承認をサポートします。
  • Last updated on