この記事では、medallion Lake のアーキテクチャについて説明し、Microsoft Fabric で設計パターンを実装する方法について説明します。 これは複数のユーザーを対象としています。
- データ エンジニア: 組織が大量のデータを収集、保存、処理、分析できるようにするインフラストラクチャとシステムを設計、構築、および管理する技術スタッフ。
- センター オブ エクセレンス、IT、BI チーム: 組織全体の分析の監視を担当するチーム。
- Fabric 管理者: 組織の Fabric 監視を担当する管理者。
medallion レイクハウス アーキテクチャ (一般に メダリオン アーキテクチャと呼ばれます) は、組織がレイクハウス内のデータを論理的に整理するために使用する設計パターンです。 これは Fabric に推奨される設計アプローチです。 OneLake は Fabric のデータ レイクであるため、medallion アーキテクチャは OneLake に lakehouse を作成することによって実装されます。
Medallion アーキテクチャは、ゾーンとも呼ばれる 3 つの異なるレイヤーで構成されています。 3 つのメダリオン レイヤーは、ブロンズ (生データ)、シルバー (検証済みデータ)、ゴールド (エンリッチされたデータ) です。 各レイヤーは、レイクハウスに保存されているデータの品質を示し、高いレベルは高い品質を表します。 この多層アプローチは、エンタープライズ データ製品にとっての信頼できる唯一のソースを構築するのに役立ちます。
重要なのは、medallion アーキテクチャは、データがレイヤーを通過するにつれて、原子性、一貫性、分離性、持続性 (ACID) を保証することです。 データは生の形式で始まり、一連の検証と変換によってデータが準備され、効率的な分析のために最適化され、元のコピーも信頼できるソースとして維持されます。
詳細については、「メダリオン レイクハウス アーキテクチャとは」を参照してください。
Fabric のメダリオン アーキテクチャ
メダリオン アーキテクチャの目標は、各段階を進むにつれて、データの構造と品質を段階的に向上させることです。
メダリオン アーキテクチャは、3 つの異なるレイヤー (またはゾーン) で構成されています。
- 青銅：生ゾーンとも呼ばれるこの最初のレイヤーは、非構造化、半構造化、または構造化データ型を含む元の形式でソース データを格納します。 このレイヤーのデータは通常、追加専用で変更不可です。 ブロンズ層に生データを保持することで、真実の源を維持し、将来の再処理と監査を可能にします。
- 銀：エンリッチされたゾーンとも呼ばれるこのレイヤーには、ブロンズ レイヤーからソースされたデータが格納されます。 データはクレンジングおよび標準化され、テーブル (行と列) として構造化されます。 また、他のデータと統合して、顧客、製品などのすべてのビジネス エンティティのエンタープライズ ビューを提供することもできます。
- 金：キュレーション ゾーンとも呼ばれるこの最終レイヤーには、シルバー レイヤーからソースされたデータが格納されます。 データは、特定のダウンストリーム ビジネスと分析の要件を満たすように調整されます。 テーブルは通常、パフォーマンスと使いやすさのために最適化されたデータ モデルの開発をサポートするスター スキーマ設計に準拠します。
各ゾーンは OneLake 内の個別のレイクハウスまたはデータウェアハウスに分ける必要があります。データは、変換および洗練される過程でゾーン間を移動します。
Fabric の一般的なメダリオン アーキテクチャの実装では、ブロンズ ゾーンはデータ ソースと同じ形式でデータを保存します。 データ ソースがリレーショナル データベースの場合は、Delta テーブルが適しています。 シルバー ゾーンとゴールド ゾーンには Delta テーブルが含まれている必要があります。
ヒント
レイクハウスを作成する方法については、「レイクハウス のエンドツーエンド シナリオ」チュートリアルを参照してください。
Fabric の OneLake とレイクハウス
最新のデータ ウェアハウスの基礎は、データ レイクです。 Microsoft OneLake は、組織全体の単一の統合された論理データ レイクです。 すべての Fabric テナントで自動的にプロビジョニングされ、すべての分析データの 1 つの場所になります。
OneLake を使用すると、次のことができます。
- サイロを削除し、管理作業を減らします。 すべての組織データは、単一のデータ レイク リソース内で保存、管理、およびセキュリティ保護されます。
- データの移動と重複を減らします。 OneLake の目的は、データのコピーを 1 個だけ保存することです。 データのコピーが少ないほどデータ移動プロセスが少なくなり、効率の向上と複雑さの削減につながります。 ショートカットを使用して、OneLake にコピーするのではなく、他の場所に格納されているデータを参照します。
- 複数の分析エンジンを使用します。 OneLake のデータは、オープン形式で保存されます。 こうすることで、Analysis Services (Power BI で使用)、T-SQL、Apache Spark など、さまざまな分析エンジンでデータを照会できます。 Fabric 以外の他のアプリケーションも、API と SDK を使用して OneLake にアクセスできます。
OneLake にデータを保存するには、Fabric に"レイクハウス" を作成します。 Lakehouse は、構造化データと非構造化データを 1 つの場所に格納、管理、分析するためのデータ アーキテクチャ プラットフォームです。 すべてのファイルの種類とサイズの大きなデータ ボリュームにスケーリングできます。また、データは 1 つの場所に格納されるため、組織全体で共有および再利用できます。
各レイクハウス には、データを移動することなくデータ ウェアハウス機能が利用できる SQL 分析エンドポイントが組み込まれています。 つまり、特別なセットアップを行わなくても、SQL クエリを使用して、レイクハウス内のデータに対してクエリを実行できます。
詳細については、「Microsoft Fabric のレイクハウスとは」を参照してください。
テーブルとファイル
OneLake でレイクハウスを作成すると、次の 2 つの物理ストレージの場所が自動的にプロビジョニングされます。
- テーブル は、すべての形式のテーブルを Apache Spark (CSV、Parquet、Delta) に格納するための管理領域です。 自動的に作成されたか明示的に作成されたかに関係なく、すべてのテーブルはレイクハウス内のテーブルとして認識されます。 ファイル ベースのトランザクション ログを含む Parquet データ ファイルであるデルタ テーブルもテーブルとして認識されます。
- ファイル は、任意のファイル形式でデータを保存するためのアンマネージド領域です。 この領域に保存されているデルタ ファイルは、テーブルとして自動的に認識されません。 アンマネージド領域の Delta Lake フォルダーに対してテーブルを作成する場合は、Apache Spark の Delta Lake ファイルを含むアンマネージド フォルダーを指す場所を持つ ショートカット または外部テーブルを作成します。
マネージド領域 (テーブル) とアンマネージド領域 (ファイル) の主な違いは、テーブルの自動検出と登録プロセスです。 このプロセスは、マネージド領域で作成されたフォルダーに対してのみ実行されますが、アンマネージド領域では実行されません。
ブロンズ ゾーンでは、元の形式 (テーブルまたはファイル) でデータを格納します。 ソース データが OneLake、Azure Data Lake Store Gen2 (ADLS Gen2)、Amazon S3、または Google からのデータである場合は、データをコピーするのではなく、ブロンズ ゾーンにショートカットを作成します。
シルバー ゾーンとゴールド ゾーンでは、通常、Delta テーブルにデータを格納します。 ただし、Parquet または CSV ファイルにデータを格納することもできます。 その場合は、Apache Spark の Delta Lake ファイルを含むアンマネージド フォルダーを指す場所を持つショートカットまたは外部テーブルを明示的に作成する必要があります。
Microsoft Fabric のレイクハウス エクスプローラーでは、ユーザーがデータのナビゲーション、アクセス、更新を行うための、レイクハウス全体で統一されたグラフィカル表現が提供されます。
テーブルの自動検出の詳細については、「テーブルの自動検出と登録」を参照してください。
Delta Lake ストレージ
Delta Lake は、データとテーブルを保存するための基盤を提供する最適化されたストレージ レイヤーです。 ビッグ データ ワークロードに対する ACID トランザクションがサポートされており、このため Fabric レイクハウスの既定のストレージ形式となっています。
Delta Lake は、ストリーミング操作とバッチ操作の両方に対して、Lakehouse の信頼性、セキュリティ、パフォーマンスを提供します。 内部的には Parquet ファイル形式でデータを保存しますが、トランザクション ログと統計も保持することで標準の Parquet 形式に勝る機能とパフォーマンス向上を提供します。
Delta Lake 形式には、汎用ファイル形式と比較して次の利点があります。
- ACID プロパティ、特にデータ破損を防ぐための持続性のサポート。
- 読み取りクエリの高速化。
- データ鮮度の向上。
- バッチ ワークロードとストリーミング ワークロードの両方に対するサポート。
- Delta Lake タイム トラベルを使用したデータロールバックのサポート。
- Delta Lake テーブル履歴を使用して規制コンプライアンスと監査を強化しました。
Fabric は、Delta Lake を使用してストレージ ファイル形式を標準化します。 既定では、新しいテーブルにデータを書き込むときに、Fabric のすべてのワークロード エンジンによって Delta テーブルが作成されます。 詳細については、「レイクハウスと Delta Lake テーブル」を参照してください。
デプロイメント モデル
Fabric でメダリオン アーキテクチャを実装するには、レイクハウス (ゾーンごとに 1 個)、データ ウェアハウス、またはその両方の組み合わせを使用できます。 自分の好みとチームの専門知識に基づいて判断する必要があります。 Fabric では、OneLake 内のデータの 1 つのコピーで動作するさまざまな分析エンジンを使用できます。
考慮すべき 2 つのパターンを次に示します。
- パターン 1: 各ゾーンをレイクハウスとして作成します。 この場合、ビジネス ユーザーは SQL 分析エンドポイントを使用してデータにアクセスします。
- パターン 2: ブロンズ ゾーンとシルバー ゾーンをレイクハウスとして作成し、ゴールド ゾーンをデータ ウェアハウスとして作成します。 この場合、ビジネス ユーザーはデータ ウェアハウス エンドポイントを使用してデータにアクセスします。
1 つの Fabric ワークスペースにすべての lakehouse を作成できますが、各 Lakehouse を独自の個別のワークスペースに作成することをお勧めします。 このアプローチにより、ゾーン レベルで制御が強化され、ガバナンスが向上します。
ブロンズ ゾーンでは、元の形式でデータを保存するか、Parquet または Delta Lake を使用することをお勧めします。 可能な限り、データを元の形式に保つようにします。 ソース データが OneLake、Azure Data Lake Store Gen2 (ADLS Gen2)、Amazon S3、または Google からのデータである場合は、データをコピーするのではなく、ブロンズ ゾーンにショートカットを作成します。
シルバー ゾーンとゴールド ゾーンでは、追加の機能とパフォーマンス強化が提供されているため、Delta テーブルを使用することをお勧めします。 Fabric は Delta Lake 形式で標準化されており、既定では Fabric のすべてのエンジンがこの形式でデータを書き込みます。 さらに、これらのエンジンでは、Parquet ファイル形式に対する V オーダー書き込み時間の最適化が使用されます。 この最適化により、Power BI、SQL、Apache Spark などの Fabric コンピューティング エンジンによる高速読み取りが可能になります。 詳細については、「Delta Lake テーブルの最適化と V オーダー」を参照してください。
最後に、今日、多くの組織は、データ量の大幅な増加に直面しており、また、そのデータを論理的な方法で整理および管理する必要性が高まっています。一方で、よりターゲットを絞った効率的な使用とガバナンスが促進されています。 このため、ガバナンスによる分散型またはフェデレーションデータ組織を確立して管理することが求められる場合があります。 この目的を達成するには、"データ メッシュ アーキテクチャ" の実装を検討してください。 "データ メッシュ" は、製品としてデータを提供するデータ ドメインの作成に重点を置くアーキテクチャ パターンです。
データ ドメインを作成することで、Fabric でデータ資産のデータ メッシュ アーキテクチャを作成できます。 マーケティング、販売、在庫、人事などのビジネス ドメインにマップするドメインを作成できます。 その後、各ドメイン内にデータ ゾーンを設定することで、メダリオン アーキテクチャを実装できます。 ドメインの詳細については、「ドメイン」を参照してください。
Delta テーブル データ ストレージについて
このセクションでは、Fabric での medallion lakehouse アーキテクチャの実装に関連するその他のガイダンスについて説明します。
ファイル サイズ
一般に、ビッグ データ プラットフォームは、多数の小さなファイルではなく、いくつかの大きなファイルがある場合にパフォーマンスが向上します。 パフォーマンスの低下は、コンピューティング エンジンに管理するメタデータとファイル操作が多数ある場合に発生します。 クエリのパフォーマンス向上のために、サイズが約 1 GB のデータ ファイルを目指することをお勧めします。
Delta Lake には、"予測最適化"と呼ばれる機能があります。 予測最適化により、デルタ テーブルのメンテナンス操作が自動化されます。 この機能を有効にすると、Delta Lake はメンテナンス操作の恩恵を受けるテーブルを識別し、そのストレージを最適化します。 この機能はオペレーショナル エクセレンスとデータ準備作業の一部であるはずですが、Fabric ではデータ書き込み時にもデータ ファイルを最適化できます。 詳細については、「Delta Lake の予測最適化」を参照してください。
履歴の保持期間
既定では、Delta Lake は加えられたすべての変更の履歴を保持するため、履歴メタデータのサイズは時間の経過とともに大きくなります。 ビジネス要件に基づいて、履歴データを一定期間のみ保持して、ストレージ コストを削減します。 過去 1 か月のみ、またはその他の適切な期間のみ履歴データを保持することを検討してください。
VACUUM コマンドを使用して、Delta テーブルから古い履歴データを削除できます。 ただし、既定では、過去 7 日以内に履歴データを削除することはできません。 この制限により、データの一貫性が維持されます。 table プロパティの delta.deletedFileRetentionDuration = "interval <interval>"を使用して、既定の日数を構成します。 このプロパティは、バキューム操作の候補と見なされる前にファイルを削除する必要がある期間を決定します。
テーブルのパーティション
各ゾーンにデータを保存する際には、必要に応じてパーティション分割されたフォルダー構造を使用することをお勧めします。 この手法により、データ管理の容易性とクエリのパフォーマンスが向上します。 一般に、フォルダー構造内のパーティション分割されたデータは、パーティションの排除/削除により、特定のデータ エントリの検索が高速になります。
通常は、新しいデータが生じると、その都度ターゲット テーブルにデータを追加します。 ただし、場合によっては、既存のデータを同時に更新するために、データをマージすることがあります。 その場合は、MERGE コマンドを使用して "アップサート" 操作を実行できます。 ターゲット テーブルがパーティション分割されている場合は、パーティション フィルターを使用して操作を高速化するようにしてください。 これにより、エンジンは更新を必要としないパーティションを排除できます。
データ アクセス
レイクハウス内の特定のデータにアクセスする必要があるユーザーを計画し、制御する必要があります。 また、このデータへのアクセス中に使用されるさまざまなトランザクション パターンについても理解する必要があります。 その上で、Delta Lake の Z オーダー インデックスを使用して、適切なテーブル パーティション分割スキームとデータ コロケーションを定義できます。
関連するコンテンツ
Fabric レイクハウスの実装の詳細については、次のリソースを参照してください。