Microsoft Fabric におけるモダンなデータ ウェアハウスのメダリオン アーキテクチャ

Microsoft Fabric
Power BI

このワークロード例では、SQL ファーストのモダン データ ウェアハウス (MDW) medallion アーキテクチャについて説明します。 最新のデータ ウェアハウスでは、SQL ベースのデータ ストアを使用して、分析とレポートのために構造化データを整理します。 このアーキテクチャでは、Fabric Data Warehouseにブロンズ、シルバー、ゴールドのレイヤーを実装し、Fabric Data Factory を使用してデータインジェストと変換を調整します。

Fabric Data Warehouseは、リレーショナル データを OneLake の Delta 形式で格納し、テーブル、ビュー、トランザクション、ストアド プロシージャを使用した T-SQL 開発をサポートします。 Power BI、SQL クライアント、およびその他のアプリケーションは、ゴールド レイヤーからキュレーションされたデータを使用します。

Important

推奨されるFabric medallion パターンでは、すべてのレイヤーにレイクハウスを使用するか、ブロンズレイヤーとシルバーレイヤーにはレイクハウスを使用し、ゴールドレイヤーには倉庫を使用します。 このアーキテクチャでは、データは構造化されたままであり、プロセス全体で SQL を使用して変換されるため、3 つのレイヤーすべてにウェアハウスが使用されます。 Lakehouses は、Spark ベースの処理、データ サイエンス ワークロード、大量の非構造化データまたは半構造化データに適しています。 Spark と非構造化データをサポートする lakehouse ファーストの実装については、Microsoft Fabricの Greenfield lakehouse を参照してください。

Architecture

Microsoft Fabric におけるモダンなデータ ウェアハウスのメダリオン アーキテクチャの図。

このアーキテクチャの PowerPoint ファイルをダウンロードする。

この図では、ミラーリングが運用データベースのレプリケーションを処理し、Fabric Data Factory パイプラインがミラーリングされていないソースをブロンズ パスに取り込みます。

データ フロー

次のデータ フローは、前の図に対応しています。

  1. 運用データベース、SaaS アプリケーション、ファイル、およびその他のソース システムによってデータが生成されます。

  2. インジェストでは、ソース データが 2 つのパスを介してFabricに取り込まれます。 サポートされている運用データベースの場合、Fabricのミラーリングでは、OneLake のミラー化されたデータベース項目にデータが継続的にレプリケートされます。 その後、倉庫 CTAS または INSERT ... SELECT ステップでは、そのデータがブロンズ 倉庫に保持されます。 ファイル、SaaS アプリケーション、およびその他のミラー化されていないソースの場合は、Fabric Data Factory パイプラインまたはウェアハウス T-SQL (COPY INTO など) を使用して、ブロンズ テーブルを読み込みます。

  3. ブロンズ レイヤーは、生の最小限の処理済みデータをウェアハウス テーブルに格納します。 読み込みタイムスタンプやソース識別子などのインジェスト メタデータでは、監査と再処理がサポートされます。

  4. 最初の変換ステージ (Bronze to silver) は、ブロンズ データを検証し、シルバー レイヤーに変換します。

  5. シルバー レイヤーには、クレンジングされたデータ、重複除去されたデータ、および準拠したデータが含まれています。 履歴分析が必要な場合、シルバー テーブルでは、有効な日付と現在の行インジケーターを使用してソースの変更が保持されます。

  6. ストアド プロシージャまたは dbt ジョブは、通常、CREATE TABLE AS SELECT (CTAS)、INSERT ... SELECT、MERGEなどの SQL パターンを使用して、Bronze to silver ステージを実装します。

  7. ゴールドレイヤーは、そのまま利用可能なスター スキーマ、データ マート、および事前集計済みテーブルを提供します。

  8. 2 番目の変換ステージ (Silver to gold) は、シルバー データをゴールド レイヤーのビジネス エンティティ、ディメンション、ファクト、集計に変換します。

  9. Power BIは、セマンティック モデルを通じてゴールド データを使用します。 SQL クライアント、ノートブック、アプリケーションなどの他のコンシューマーは、ウェアハウス SQL エンドポイントに対してクエリを実行できます。

Components

  • Fabric Data Warehouseでは、ブロンズ、シルバー、ゴールドの各レイヤーの T-SQL コンピューティング テーブルとリレーショナル テーブルが提供されます。
  • OneLake は、デルタ形式でウェアハウス データを格納し、Fabric ミラーリングによってレプリケートされたデータを格納します。
  • Fabricのミラーリングでは、サポートされている運用データベースが OneLake に継続的にレプリケートされます。
  • Fabric Data Factory は、データを取り込み、ストアド プロシージャ、パイプライン、およびその他の変換アクティビティを調整します。
  • Power BIでは、キュレーションされたゴールド データに対するセマンティック モデル、レポート、ダッシュボードが提供されます。

設計ガイダンス

次のガイダンスでは、ブロンズ、シルバー、ゴールドの各レイヤーを実装し、サポートワークスペースを整理する方法について説明します。 これらの推奨事項を、ワークロードのデータ ソースとガバナンスの要件とチームのスキルに合わせて調整します。

ブロンズ レイヤー: 生データの取り込み

ブロンズ レイヤーは、生データを取り込み、ビジネス ロジックを適用せずに元の形式ですべてのソース データをキャプチャします。 これはレコードのシステムとして機能し、完全な追跡と再処理を可能にします。 このレイヤー内のテーブルはソース スキーマを厳密にミラーリングし、フィルター処理、重複除去、エンリッチメントを意図的に回避します。 インジェスト タイムスタンプやソース ファイル名などのオプションのメタデータ列では、多くの場合、監査がサポートされます。

サポートされている運用データベースの場合は、Fabricでミラーリングを使用して、ソース テーブルを OneLake に継続的にレプリケートします。 ファイル、SaaS、またはサポートされていないソースの場合は、Fabric Data Factory パイプライン、一括インジェスト向けの COPY INTO、または INSERT ... SELECT もしくは OPENROWSET と組み合わせた CTAS を使用して、外部ファイル データをブロンズ ウェアハウスに保存します。

この段階では、インジェストは最小限に変更され続け、ブロンズ層は再生可能な記録システムのままです。 ミラー化されていないソースに必要な場合は、ブロンズ読み込みストアド プロシージャ (または同等の dbt モデル) で受信レコードを標準化し、読み込みメタデータを追加できます。

ブロンズ レイヤーのベスト プラクティスでは、無効なレコードを含むすべての生データの保持、小さなファイルの問題を回避するためのバッチ インジェストの使用、ソース システムとのスキーマの密接な連携、Fabric パイプラインを使用したインジェスト ワークフローの自動化を重視して、一貫性と信頼性を大規模に確保します。

シルバー レイヤー: データ クレンジングと準拠

シルバー レイヤーは、データ品質ルールの適用、標準化、重複除去、複数のソース間の統合を通じてブロンズ データを絞り込むことで、データ クレンジングと準拠に重点を置いています。 最終的には、クレンジングされた信頼性の高いデータの単一の信頼できるソースが生成されます。

通常は、T-SQL を使用し、バッチ処理と増分処理の両方をサポートする CREATE TABLE AS SELECT (CTAS)、 INSERT … SELECT、 MERGE ステートメントなどのパターンを使用して、この段階で変換を実装します。 Fabric Data Warehouseは具体化されたビューをサポートしていませんが、Spark を使用して実装された具体化されたレイク ビューを使用して、Delta テーブルを生成できます。 SQL 分析エンドポイントは、これらの Delta テーブルを、ウェアハウスが読み取ることができるテーブルとして公開します。

シルバー レイヤーのベスト プラクティスには、変換がべき等になるように設計すること、データ品質ルールを一貫して適用すること、増分更新には MERGE を使用することなどがあります。 ワークロードでヒストライゼーションが必要な場合は、有効な開始日と終了日と現在の行インジケーターを使用して行バージョンを保持します。 Gold ディメンションでは、この履歴を使用して、型 1 または型 2 の緩やかに変化するディメンション (SCD) の動作を実装できます。

ゴールド レイヤー: 分析用にキュレーションされたデータ

ゴールド レイヤーは、Power BIなどの BI ツールによる分析、レポート、および使用に最適化された、キュレーションされたビジネス対応のデータを提供します。 このレイヤーは、分析モデリング パターンを中心に設計されています。一般的には、ファクト テーブルとディメンション テーブルを含むスター スキーマ、ドメイン固有のデータ マート、事前集計されたサマリー テーブルを使用して、パフォーマンスの高いクエリと直感的な分析をサポートします。

通常は、シルバー データからのみゴールド テーブルを派生させ、エンド ユーザーとレポート ツールに公開します。

ファクトが変更可能なソース システム キーに依存しないように、ディメンションには安定したサロゲート キーを使用します。 Fabric Data Warehouseでは、サロゲート キー生成のBIGINT IDENTITY列がサポートされています。 ID 値は一意ですが、シーケンシャルまたは順序付けされる保証はなく、ギャップが発生する可能性があります。 これらの制限がワークロードに適さない場合は、変換ロジックで代理キーを生成して永続化し、各自然キーへの永続的なマッピングを維持します。 完全な更新中に代理キーを再生成しないでください。

ゴールド レイヤーのベスト プラクティスには、分析とビジネスのユース ケースと密接に連携するモデリング データ、パフォーマンスを向上させるために可能な限りデータを事前に集計する、行レベルのセキュリティ (RLS)、列レベルのセキュリティ (CLS)、データ マスクなどのセキュリティコントロールを適用する、データ系列と変換を徹底的に文書化することが含まれます。

ワークスペース戦略

ワークスペース戦略では、ガバナンス、セキュリティ、運用のシンプルさのバランスを取るために、ブロンズ、シルバー、ゴールドの各レイヤーを論理的および物理的に分離する方法を定義します。 レイヤーを実装するには、レイヤーごとに個別のワークスペースを使用します。これは、強力なセキュリティ境界、明確な所有権、または責任の厳密な分離が必要な場合にお勧めします。 たとえば、キュレーションされたビジネス データから生データ インジェストを分離する必要があります。

または、ブロンズ、シルバー、ゴールドのデータ用に個別のウェアハウスを使用して、1 つのワークスペース内にレイヤーを実装することもできます。 このアプローチにより、管理オーバーヘッドを削減し、medallion レイヤー間の倉庫レベルの分離を維持しながら、クロスレイヤーの開発とテストを簡素化できます。

通常、これらのアプローチの選択は、組織の規模、セキュリティ要件、チーム構造、ガバナンスの成熟度などの要因によって異なります。 多くの企業では、Fabric実装の進化に合わせたハイブリッド モデルを採用しています。 分離、ガバナンス、所有権の境界が必要な場合は、個別のワークスペースを使用することをお勧めします。

実装ガイダンス

Fabric Data Warehouseは、ブロンズ、シルバー、ゴールドの各レイヤーでトランザクションの一貫性と信頼性の高いデータ処理を提供します。 バッチ指向の書き込みを使用して、小さなファイルの問題を最小限に抑え、ストレージとクエリの効率を向上させます。 MERGE ステートメントを使用して、増分処理シナリオで到着遅延または変更されたデータを処理します。

トランザクションの有効期間を短くして競合を減らし、コンカレンシーを最適化します (特にインジェストが多い環境では)。 Fabricクエリ分析情報と動的管理ビュー (DMV) を使用して、パフォーマンスと運用の正常性を積極的に監視します。 Fabricでの読み取りと書き込みのワークロードのアーキテクチャの分離により、インジェストジョブと変換ジョブを同時に実行し、分析クエリをブロックすることなく、ダウンストリームの分析とレポートの予測可能なパフォーマンスを確保できます。

ネイティブ SQL 変換とオーケストレーションには、T-SQL ストアド プロシージャと Fabric Data Factory パイプラインを使用します。 モジュール式 SQL モデルとテストを優先するチームは、Fabric Data WarehouseにMicrosoft保守された dbt アダプターを使用できます。 データをダウンストリーム レイヤーに公開する前に、デプロイゲートまたはパイプライン ゲートとして一意性、参照整合性、および受け入れ値テストを実行します。

オルタナティブ

このアーキテクチャには、ワークロードの機能要件と非機能要件に応じて、他のAzure サービスまたはアプローチに置き換えることができる複数のコンポーネントが含まれています。 次の代替手段とそのトレードオフを検討してください。

大規模なデータ エンジニアリング、高度な分析、機械学習、または非構造化データを重視するシナリオでは、Microsoft Fabric上の lakehouse ファースト アーキテクチャの方が適している可能性があります。 このアプローチでは、Fabric lakehouse は OneLake のプライマリ データ ストアとして機能し、変換は主にノートブックや Dataflow Gen2 などの Spark ベースのツールを使用して実装されます。 このパターンでは、この SQL 優先のウェアハウス アーキテクチャの焦点ではない分散計算、ノートブック、機械学習ツールが提供されます。

データ サイエンス、AI、または複雑な分散処理に重点を置いている組織では、Azure Databricksも別の方法です。 Azure Databricksは、通常、ワークロードがオープンソースの機械学習フレームワークとの詳細な統合、Spark の実行に対するきめ細かな制御、またはマルチクラウドの移植性を必要とする場合に選択されます。

ほぼリアルタイムまたはイベントドリブンの分析では、Fabric Real-Timeインテリジェンス、Azure Event Hubs、またはAzure Stream Analyticsは、Fabric Data Warehouseを中心とするバッチ指向の medallion 設計よりも適している場合があります。

シナリオの詳細

Fabric Data Warehouseは、使い慣れた SQL パターンを使用して、管理された分析に対応したデータを大規模に提供することを主な目的とする場合に、この medallion アーキテクチャに適しています。

シナリオ 1: 分析に対応した精選されたデータセットのリレーショナル セマンティクスと SQL パフォーマンス

Fabric Data Warehouse は、Delta データに対するリレーショナル テーブルとビュー、ACID トランザクション、および T-SQL での操作を提供するため、非常に適しています。 この機能セットは、データが既にクレンジングされ、準拠しており、SQL を通じて一貫してクエリを実行する必要があるワークロードをサポートします。

例: 航空会社は、フライトの運用と収益分析のためにキュレーションされたゴールド データセットを構築します。 アナリストは、安定した SQL クエリ パフォーマンスを利用して、オンタイム パフォーマンスの傾向、ルートの収益性、および乗組員の使用率を評価します。 ウェアハウス テーブルとビューを使用すると、トランザクションの一貫性と信頼性の高いクエリ動作が保証されます。これは、アドホック ファイル ベースのアクセスでは保証が困難です。

シナリオ 2: SQL 優先エクスペリエンスを使用した一元化されたガバナンス

Fabric Data Warehouseを使用すると、ワークスペースのアクセス許可、オブジェクト レベルのセキュリティ、組み込みの系列を使用して一元的なガバナンスを実現しながら、分析エンジニアリング チームになじみのある SQL インターフェイスを介してデータを公開できます。 このアプローチにより、運用上の摩擦が軽減され、アクセス制御が簡素化され、新しいアクセス パラダイムを導入することなく、チーム間での導入が促進されます。

例: グローバル企業は、厳密な職務の分離を強制します。プラットフォーム チームはインジェストと変換を管理し、分析チームはキュレーションされたデータのみを使用します。 ウェアハウスを介してゴールド レイヤー テーブルのみを公開し、アクセスを一元的に管理することで、組織は、使い慣れた SQL ベースのワークフローを維持しながら、未加工または中間データへの制御されないアクセスを回避します。

シナリオ 3: レポートとダッシュボードに対する BI 最適化の消費量

このウェアハウスは、コンカレンシーが高く、読み取り負荷の高いワークロード用に最適化されているため、多数のビジネス ユーザーが一貫したセマンティック モデルに基づいて構築されたダッシュボードとレポートを使用する場合に適しています。 この最適化は、ピーク使用時にパフォーマンス、安定性、予測可能なクエリ動作が必要な場合に特に重要です。

例:財務チームと運用チームは、業務時間中Power BIダッシュボードにアクセスして、収益、運用効率、SLA コンプライアンスなどの KPI を監視します。 Fabric Data Warehouseでは、SELECTワークロードと非SELECT ワークロードを別々のコンピューティング プールに分離し、ダッシュボード クエリとウェアハウス インジェスト間の直接の競合を減らします。

シナリオ 4: 再利用可能なゴールド レイヤーのディメンション モデリングのサポート

Fabric Data Warehouseは、ビジネスに優しく再利用可能なデータセットを公開するためにゴールド レイヤーでよく使用するファクト テーブルやディメンション テーブルなど、ディメンション モデリング パターンに自然に合わせて調整されます。 これらのモデルは、分析を簡素化し、ロジックの重複を減らし、チーム間で一貫したメトリック定義を促進します。

例: 小売組織は、顧客、製品、店舗の共有ディメンション テーブルと、売上と在庫のファクト テーブルを作成します。 これらのゴールド データセットは、複数のPower BI レポートと事業単位で再利用されるため、売上高や在庫回転率などの KPI が 1 回定義され、一貫して適用されます。

Considerations

これらの考慮事項では、Azure Well-Architected Framework の柱を実装します。これは、ワークロードの品質を向上させるために使用できる一連の基本原則です。

[信頼性]

信頼性は、アプリケーションが顧客に対して行ったコミットメントを確実に満たすことができるのに役立ちます。 詳細については、 信頼性の設計レビュー チェックリストを参照してください。

ゾーンダウン動作や地域の考慮事項など、文書化された回復性モデルのMicrosoft Fabricの信頼性を確認します。 リージョンとワークロードの要件に対するこのガイダンスに対する復旧の期待を検証します。

リージョン間のディザスター リカバリー シナリオでは、組織の要件と共有責任モデルに合わせた復旧戦略を設計して文書化します。

  • Fabric Data Warehouseでは、NOT ENFORCEDとしてのみ、PRIMARY KEY、FOREIGN KEY、およびUNIQUEテーブルの制約がサポートされます。 ウェアハウスは、一意性または参照整合性を検証しません。 インジェストと変換ロジックでは、重複または孤立したレコードを検出し、ダウンストリーム レイヤーに到達できないようにする必要があります。

セキュリティ

セキュリティは、意図的な攻撃や貴重なデータとシステムの誤用に対する保証を提供します。 詳細については、 セキュリティの設計レビュー チェックリストを参照してください。

Microsoft Fabricには、組織の要件に基づいてセキュリティ設定を管理、制御、監査する機能が用意されています。 次のセキュリティプラクティスを検討してください。

  • Microsoft Entra ID シングル サインオン (SSO) を使用してユーザーを認証し、デバイスと場所間で一貫した ID 管理を提供します。

  • ワークスペースベースのアクセス許可を適用して、誰が Fabric 成果物を作成、変更、または利用できるかを制御します。

  • ネットワークFabric内部または外部のデータまたはサービスにアクセスする場合は、受信と送信のネットワーク セキュリティ制御を使用します。 これらの制御には、 条件付きアクセス、 プライベート リンク、 信頼されたワークスペース アクセス、 およびマネージド プライベート エンドポイントが含まれます。

  • Fabric監査ログを使用して、プラットフォーム全体のユーザー アクティビティ、構成の変更、データ アクセスを追跡します。

詳細については、「Fabric のセキュリティ」を参照してください。

コストの最適化

コストの最適化では、不要な経費を削減し、運用効率を向上させる方法に重点を置いています。 詳細については、 コスト最適化の設計レビュー チェックリストを参照してください。

Microsoft Fabricでは、定義された数の容量ユニット (CU) の容量予約が提供されます。 1 年間の予約は、予測可能で安定した状態のワークロードのコストを削減するのに役立ちます。

Fabric の容量使用率を最大化するには、次のベスト プラクティスを検討してください。

  • 試用容量または従量課金制の F SKU から始めて、ワークロードの動作を理解します。 代表的なデータ取り込み、変換、およびレポート作成のワークロードを使用して、範囲を限定した概念実証を実施します。 CU 消費量を監視し、結果を推定して、運用環境のニーズを見積もります。 需要の増加に応じてFabric容量をスケーリングできます。

  • 過去の使用状況を分析して、ピーク時とピーク時以外の期間を特定します。 需要の低い時間帯にクリティカルではないワークロードまたはバックグラウンド ワークロードをスケジュールして、持続的な CU 負荷を軽減します。

  • SQL クエリ、データ分析式 (DAX)、およびバックグラウンド ジョブを最適化することで、不要なコンピューティング消費量を削減します。

  • Fabric は、バースト処理と平準化をサポートしており、コンピューティング需要の短期的な急増を吸収し、バックグラウンド ワークロードによる消費を時間の経過とともに分散できます。 これらの機能は、ピーク時の需要ではなく、平均使用量の容量を大きくするのに役立ちます。 詳細については、「Microsoft Fabric 容量を評価して最適化する」を参照してください。

  • 実行時間の長い変換と更新操作を調整して、同じ容量で高コンピューティング ワークロードが重複しないようにします。 詳細については、「Fabric Data Warehouseでのワークロード管理」を参照してください。

次の価格に関する考慮事項に注意してください。

  • OneLake ストレージ ボリューム、保有期間、およびデータ アクセス パターンは、合計コストに直接影響します。 各メダリオン レイヤーの想定データ増加量を見積もり、保持期間をビジネス要件およびコンプライアンス要件に整合させます。

  • Microsoft Fabric価格は、割り当てられた F 容量 (CU 単位) に基づきます。 ユーザーごとのライセンスPower BIは個別であり、Fabric容量はプロビジョニングされません。

Azure料金計算ツール で構成済みの見積もりを使用して、このアーキテクチャの開始コストを取得します。 予想されるワークロードに合わせて値を調整します。

オペレーショナル エクセレンス

オペレーショナル エクセレンスは、運用環境でワークロードをデプロイ、監視、保守する運用プロセスを対象としています。 詳細については、 オペレーショナル エクセレンスの設計レビュー チェックリストを参照してください。

Microsoft Fabricでは、データ エンジニアリング、ウェアハウス、分析の各ワークロードにわたって、運用上の可視性が組み込まれています。 Fabric容量メトリック アプリを使用して、容量消費量を監視し、リソースを集中的に消費する成果物を特定し、対話型ワークロードとバックグラウンド ワークロードが全体的な使用率にどのように影響するかを理解します。 これらの分析情報は、チームがスケーリング、スケジュール設定、最適化に関する情報に基づいた運用上の意思決定を行うのに役立ちます。

容量管理者が高使用率または調整状態を早期に特定し、ユーザーへの影響が発生する前に対応できるように、プロアクティブ アラートを設定します。

パフォーマンス効率

パフォーマンス効率とは、ユーザーの需要を効率的にスケーリングして満たすワークロードの能力を指します。 詳細については、 パフォーマンス効率の設計レビュー チェックリストを参照してください。

Microsoft Fabricには、パフォーマンスと容量の使用率を管理するのに役立ついくつかのメカニズムが含まれています。

  • バースト処理とスムージングを使用すると、短期的に急増したコンピュート需要への対応をより迅速に完了できる一方で、使用量を時間の経過とともに分散させることができます。 対話型操作は通常、数分程度の時間幅で平滑化され、バックグラウンド操作はより長い時間幅で平滑化されます。

  • スロットリングは、容量に割り当てられた SKU の制限を超える持続的なコンピューティング使用量が発生した場合に適用されます。 スロットリングは、プラットフォームの安定性を維持するために、新しい操作を遅延させるか拒否します。

  • Fabric容量メトリック アプリでは、容量の消費量を詳細に把握でき、対話型操作 (レポート クエリなど) とバックグラウンド操作 (インジェストやモデルの更新など) を区別できます。 この区別により、さまざまなワークロードの種類に対して、対象となるパフォーマンスの最適化が可能になります。

貢献者達

Microsoft では、この記事を保持しています。 この記事を書いたのは、以下の寄稿者です。

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。

次のステップ