メダリオンレイクハウスアーキテクチャとは

メダリオンアーキテクチャは、レイクハウスに格納されているデータの品質を示す一連のデータレイヤーを表します。 Databricksでは、エンタープライズデータ製品の信頼できる唯一の情報源を構築するために、多層アプローチを採用することをお勧めします。

このアーキテクチャでは、データを効率的なアナリティクス用に最適化されたレイアウトに格納される前に、検証と変換の複数のレイヤーを通過させることで、原子性、独立性、分離性、および耐久性を保証します。ブロンズ (生)、シルバー (検証済み)、およびゴールド (補強) という用語は、これらの各レイヤーのデータの品質を表します。

データ設計パターンとしてのメダリオンアーキテクチャ

メダリオンアーキテクチャは、データを論理的に整理するために使用されるデータ設計パターンです。その目標は、アーキテクチャの各レイヤー (ブロンズテーブル⇒、シルバーテーブル、ゴールドレイヤーテーブル) を流れるデータの構造と品質を段階的かつ段階的に向上させることです (ブロンズテーブル、シルバーテーブル⇒)。メダリオンアーキテクチャは、 マルチホップアーキテクチャと呼ばれることもあります。

これらのレイヤーを通じてデータを進めることで、組織はデータの品質と信頼性を段階的に向上させ、ビジネスインテリジェンスや機械学習アプリケーションにより適したものにすることができます。

メダリオンアーキテクチャに従うことは推奨されるベストプラクティスですが、必須ではありません。

質問	青銅	銀	ゴールド
このレイヤーでは何が起こるのでしょうか?	Raw データ取り込み	データのクリーニングと検証	ディメンション・モデリングとアグリゲーション
対象ユーザーは誰ですか?	データエンジニアデータ操作コンプライアンスチームと監査チーム	データエンジニアデータアナリスト (シルバーレイヤーを使用して、より詳細な分析に必要な詳細な情報を保持しながら、より洗練されたデータセットを作成します) data scientists (モデルの構築と高度なアナリティクスの実行)	ビジネスアナリストとBI開発者 data scientists ・機械学習(ML)エンジニア経営幹部と意思決定者運用チーム

例メダリオンアーキテクチャ

このメダリオンアーキテクチャの例は、ビジネス運用チームが使用するブロンズ、シルバー、およびゴールドレイヤーを示しています。各レイヤーは、ops カタログの異なるスキーマに格納されます。

メダリオンアーキテクチャ Bronze, Silver, and ゴールドレイヤー

ブロンズレイヤー (ops.bronze):クラウドストレージ、Kafka、Salesforceから生データを取り込みます。ここでは、データのクリーンアップや検証は実行されません。
シルバーレイヤー (ops.silver):データのクリーンアップと検証は、このレイヤーで実行されます。
- 顧客とトランザクションに関するデータは、null を削除し、無効なレコードを検疫することでクリーンアップされます。これらのデータセットは、 customer_transactionsという新しいデータセットに結合されます。 data scientists このデータセットを予測分析に使用できます。
- 同様に、Salesforce のアカウントデータセットと opportunity データセットを結合して account_opportunitiesを作成し、これはアカウント情報で強化されています。
- leads_rawデータは、 leads_cleanedというデータセットでクリーニングされます。
ゴールドレイヤー (ops.gold):このレイヤーはビジネスユーザー向けに設計されています。銀や金よりもデータセットが少なくて済みます。
- customer_spending: 各顧客の平均支出額と合計支出額。
- account_performance: 各アカウントの日次パフォーマンス。
- sales_pipeline_summary: エンドツーエンドの販売パイプラインに関する情報。
- business_summary: エグゼクティブスタッフ向けの高度に集約された情報。

生データをブロンズレイヤーに取り込む

ブロンズレイヤーには、未検証の生データが含まれています。ブロンズレイヤーに取り込まれるデータには、通常、次の特性があります。

データソースの生の状態を元の形式で保存し、維持します。
増分的に追加され、時間の経過と共に大きくなります。
は、シルバーテーブル用のエンリッチデータワークロードによる消費を目的としており、アナリストや data scientistsによるアクセスを目的としていません。
真実の 1 つのソースとして機能し、データの忠実性を維持します。
すべてのヒストリカルデータを保持することで、再処理と監査を可能にします。
クラウドオブジェクトストレージ ( S3、 GCS、 ADLSなど)、メッセージバス ( Kafka、 Kinesisなど)、フェデレーテッドシステム (レイクハウスフェデレーションなど) など、ソースからのストリーミングトランザクションとバッチトランザクションの任意の組み合わせにすることができます。

データのクリーンアップまたは検証を制限する

ブロンズレイヤーでは、最小限のデータ検証が実行されます。データの削除を防ぐために、Databricks では、予期しないスキーマ変更から保護するために、ほとんどのフィールドを文字列、VARIANT、またはバイナリとして格納することをお勧めします。データの出所やソースなどのメタデータ列が追加される場合があります (例: _metadata.file_name )。

シルバーレイヤーのデータを検証して重複排除する

データのクリーンアップと検証は、シルバーレイヤーで実行されます。

ブロンズレイヤーからシルバーテーブルを組み立てる

シルバーレイヤーを構築するには、1 つ以上のブロンズテーブルまたはシルバーテーブルからデータを読み取り、シルバーテーブルにデータを書き込みます。

Databricks では、インジェストから直接シルバーテーブルに書き込むことはお勧めしません。インジェストから直接書き込むと、スキーマの変更やデータソースのレコードの破損によるエラーが発生します。すべてのソースが追加専用であると仮定して、ブロンズからのほとんどの読み取りをストリーミング読み取りとして構成します。バッチ読み取りは、小さなデータセット (小さなディメンションテーブルなど) 用に予約する必要があります。

シルバーレイヤーは、検証、クリーニング、およびエンリッチされたバージョンのデータを表します。シルバーレイヤー:

各レコードの少なくとも 1 つの検証済みの非集計表現を常に含める必要があります。集約表現が多くのダウンストリームワークロードを駆動する場合、それらの表現はシルバーレイヤーにある可能性がありますが、通常はゴールドレイヤーにあります。
ここでは、データクレンジング、重複除去、正規化を実行します。
エラーや不整合を修正することでデータ品質を向上させます。
データをより消費しやすい形式に構造化し、ダウンストリーム処理に利用できるようにします。

データ品質の向上

シルバーテーブルでは、次の操作が実行されます。

スキーマ強制
null 値と欠損値の処理
データ重複排除
順不同および遅延到着のデータ問題の解決
データ品質のチェックと適用
スキーマの展開
タイプキャスティング
テーブル結合（join）

データのモデリングを開始

シルバーレイヤーでデータモデリングの実行を開始するのが一般的です。これには、ネストの多いデータや半構造化データの表現方法の選択も含まれます。

VARIANTデータ型を使用します。
JSON文字列を使用します。
構造体、マップ、および配列を作成します。
スキーマをフラット化するか、データを複数のテーブルに正規化します。

ゴールドレイヤーを使用して高度な分析を行う

ゴールドレイヤーは、ダウンストリーム分析、ダッシュボード、 ML、およびアプリケーションを推進するデータの高度に洗練されたビューを表します。ゴールドレイヤーデータは、多くの場合、特定の期間または地理的地域に対して高度に集約され、フィルタリングされます。これには、ビジネス機能とニーズに対応する意味的に意味のあるデータセットが含まれています。

ゴールドレイヤー:

アナリティクスとレポート用に調整された集計データで構成されます。
ビジネスロジックと要件に合わせます。
クエリとダッシュボードのパフォーマンスに最適化されています。

ビジネスロジックと要件に合わせる

ゴールドレイヤーでは、ディメンションモデルを使用して、関係を確立し、メジャーを定義することで、レポート作成と分析のためのデータをモデル化します。ゴールドのデータにアクセスできるアナリストは、ドメイン固有のデータを見つけて質問に答えることができるはずです。

ゴールドレイヤーはビジネスドメインをモデル化するため、一部の顧客は、人事、財務、 ITなど、さまざまなビジネスニーズを満たすために複数のゴールドレイヤーを作成します。

アナリティクスとレポート用に調整された集計を作成する

多くの場合、組織は、平均、カウント、最大値、最小値などのメジャーの集計関数を作成する必要があります。たとえば、ビジネスで週次売上の合計に関する質問に答える必要がある場合は、このデータを事前に集計する weekly_sales という具体化されたビューを作成して、アナリストや他のユーザーが頻繁に使用する具体化されたビューを再作成する必要がないようにすることができます。

CREATE OR REPLACE MATERIALIZED VIEW weekly_sales AS
SELECT week,
       prod_id,
       region,
       SUM(units) AS total_units,
       SUM(units * rate) AS total_sales
FROM orders
GROUP BY week, prod_id, region

クエリとダッシュボードのパフォーマンスの最適化

ゴールドレイヤーテーブルのパフォーマンスを最適化することは、これらのデータセットが頻繁にクエリされるため、ベストプラクティスです。通常、大量のヒストリカルデータはスライバーレイヤーでアクセスされ、ゴールドレイヤーでは具体化されません。

データ取り込みの頻度を調整することでコストを制御

データを取り込む頻度を決定することで、コストを制御します。

データ取り込み頻度	コスト	レイテンシー	宣言型の例
継続的なインクリメンタルインジェスト	高い	下げる	`spark.readStream`を使用してクラウドストレージまたはメッセージバスから取り込むストリーミングテーブル。このストリーミングテーブルを更新する Delta Live Tables パイプラインは、継続的に実行されます。ノートブック内の `spark.readStream` を使用して、クラウドストレージまたはメッセージバスから Delta テーブルに取り込む構造化ストリーミングコード。ノートブックは、Databricks ジョブと連続ジョブトリガーを使用して調整されます。
トリガーされた増分インジェスト	下げる	高い	`spark.readStream`を使用してクラウドストレージまたはメッセージバスから取り込むストリーミングテーブル。このストリーミングテーブルを更新するパイプラインは、ジョブのスケジュールされたトリガーまたはファイル到着トリガーによってトリガーされます。 `Trigger.Available`トリガーを備えたノートブック内の構造化ストリーミングコード。このノートブックは、ジョブのスケジュールされたトリガーまたはファイル到着トリガーによってトリガーされます。
手動インクリメンタルインジェストによるバッチインジェスト	下げる	最も高かったのは、実行頻度が低いためです。	ストリーミングテーブルは、 `spark.read`を使用してクラウドストレージから取り込みます。構造化ストリーミングは使用しません。代わりに、パーティション上書きなどのプリミティブを使用して、パーティション全体を一度に更新します。インクリメンタル処理を設定するには広範なアップストリームアーキテクチャが必要であり、構造化ストリーミングの読み取り/書き込みと同様のコストがかかります。また、 `datetime` フィールドによってソースデータをパーティション分割し、そのパーティションのすべてのレコードをターゲットに処理する必要があります。