メダリオンアーキテクチャとは？Bronze/Silver/Goldの設計パターン徹底解説

メダリオンアーキテクチャとは、Databricksが提唱するデータレイクハウスの設計パターンで、Bronze(生データ)・Silver(クレンジング済み)・Gold(ビジネス用)の3層でデータ品質を段階的に向上させる考え方です。本記事では各層の設計指針とコード例、3層構造（Raw / Staging / Mart）との対応関係、そしてアンチパターンまでを解説します。

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

メダリオンアーキテクチャは、Databricksが自社のレイクハウス設計で広めた概念で、メダル（金銀銅）になぞらえた3層構造を特徴とします。Bronze層にソースの原形を格納し、Silver層でクレンジングと整形を行い、Gold層でビジネスロジックを適用する――この段階的な品質向上が基本思想です。

発祥はDatabricksですが、概念自体はクラウドDWH(BigQuery、Snowflake)でも適用可能です。dbtコミュニティの「3層構造(Raw / Staging / Mart)」と本質的に同じ思想であり、呼び方が違うだけと考えて差し支えありません。

Bronze層の設計

Bronze層の役割は「生データを忠実に保存すること」です。ソースシステムから受け取ったデータをそのままの形で保持し、将来の再処理や監査に備えます。変換・集計・結合は行いません。ここで気を付けるべきはスキーマ進化への対応で、Delta Lakeの場合はschema evolutionを有効化して後方互換性を確保します。

以下はDelta LakeでBronzeテーブルを作成する例です。

CREATE TABLE bronze.orders (
    id STRING,
    amount STRING,
    created_at STRING,
    _ingested_at TIMESTAMP,
    _source_file STRING
) USING DELTA
PARTITIONED BY (DATE(_ingested_at))
TBLPROPERTIES ('delta.autoOptimize.autoCompact' = 'true');

Silver層の設計

Silver層はBronzeを受けて、クレンジング・正規化・ビジネスキーの付与を行います。型変換、NULLハンドリング、重複除去、軽いJOINによるエンリッチメントといった処理を施し、「整った元テーブル」を準備します。ここまで到達したデータは、分析利用者が安心して触れるベースラインとなります。

BronzeからSilverへの変換例をSQLで示します。

CREATE OR REPLACE TABLE silver.orders AS
SELECT
    id AS order_id,
    CAST(amount AS DOUBLE) AS amount,
    CAST(created_at AS TIMESTAMP) AS created_at,
    _ingested_at
FROM bronze.orders
WHERE id IS NOT NULL
  AND amount IS NOT NULL;

Gold層の設計

Gold層は分析・BI・業務還流で利用する最終形です。ビジネスロジックの適用、KPI計算、ファクト/ディメンション構築、集計マートの作成など、ビジネス文脈に即したテーブルを用意します。ドメイン別にフォルダを分け、テーブル数が爆発しないよう統治することが重要です。

CREATE OR REPLACE TABLE gold.daily_sales AS
SELECT
    DATE(created_at) AS sale_date,
    COUNT(*) AS order_count,
    SUM(amount) AS total_amount,
    AVG(amount) AS avg_amount
FROM silver.orders
GROUP BY DATE(created_at);

3層の設計ルール

メダリオンアーキテクチャ全体を一枚の図で俯瞰すると次のようになります。

【メダリオンアーキテクチャ全体図】

  [Source Systems]
         |
         v
  [Bronze層]
    - 原形保存、スキーマ進化対応
    - パーティショニング
         |
         v
  [Silver層]
    - 型変換、NULL処理、重複除去
    - ビジネスキー付与
    - 軽いJOINでエンリッチメント
         |
         v
  [Gold層]
    - KPI計算、集計
    - ファクト / ディメンション
    - 分析 / BI / 業務還流
         |
         v
  [BI / Dashboard / Business SaaS]

各層の設計ルールを表にまとめました。

観点	Bronze	Silver	Gold
データ品質	保証なし	型とNULLを整備	ビジネス品質
変換内容	なし	クレンジング・軽JOIN	集計・KPI・ロジック
アクセス制御	限定的	データチーム	分析者・全社員
保持期間	長期（再処理用）	中期	短〜中期(再計算可能)
テスト密度	取り込み完了確認	型・NULL・ユニーク	ビジネスルール検証
更新頻度	取り込みごと	日次〜時次	日次
ストレージ形式	Delta Lake	Delta Lake	Delta Lake / 集計テーブル

dbtの3層構造との対応は次の通りです。

メダリオン	dbt 3層構造	役割
Bronze	Raw	原形保存
Silver	Staging / Intermediate	クレンジング・共通ロジック
Gold	Mart	分析用・ビジネス

メダリオンアーキテクチャの注意点

メダリオンは万能ではなく、採用時に気をつけるべき落とし穴があります。第一に「層の増やしすぎ」です。Silver1→Silver2→Silver3と枝分かれが進むと、どこを参照すべきか誰も分からなくなります。必要に応じてIntermediate的な中間層を設ける程度に留めましょう。

第二に「Silverスキップ問題」で、Bronzeから直接Goldを作ろうとするアンチパターンです。確かに手早く結果は出ますが、後からSilver層を挿入するのは非常に困難で、結局全部書き直すはめになります。

第三に「メンテナンスコスト」で、層が増えるほど実行時間とストレージ費用が積み重なります。Bronze層の保持期間を長くしすぎない、Goldは必要に応じてマテリアライズする、といった運用ルールで費用をコントロールしてください。

まとめ

メダリオンアーキテクチャは、データの品質段階を明確に意識させる優れた設計パターンです。Databricks環境だけでなく、SnowflakeやBigQueryでも同じ思想を取り入れられます。dbtの3層構造と併せて理解することで、チーム内での共通言語を確立し、保守性の高いデータ基盤を構築できるでしょう。

よくある質問

メダリオンアーキテクチャはDatabricks専用ですか?

いいえ。Databricksが提唱しましたが、概念自体はクラウドDWH(BigQuery、Snowflake)でも適用可能です。dbtの3層構造と本質的に同じ考え方です。ツール選定と設計思想は切り離して考えましょう。

Bronze/Silver/Goldの3層は必須ですか?

規模に応じて2層（Raw / Mart）にすることも可能です。ただし中規模以上ではSilver層が品質ゲートとして重要な役割を果たします。最初は3層で設計し、必要に応じて簡略化するのが安全です。

各層にどのようなテストを設定すべきですか?

Bronze層は取り込み完了の確認、Silver層は型チェック・NULL制約・ユニーク制約、Gold層はビジネスルール検証が基本です。層が進むほどテストを厳密にします。dbt testsやElementaryで自動化するのが定石です。