メダリオンアーキテクチャは、レイクハウスに置いたテーブルを品質段階でBronze・Silver・Goldの3つに分け、層をまたぐたびに構造と品質を上げていく設計パターンです。図としては分かりやすい一方、実装で詰まるのは「どの型でBronzeに落とすか」「どこまで遡って再処理できるか」「層をいくつに割るか」という値の決定です。この記事では各層のテーブル設計とファイルサイズの目安、VACUUMの保持制約から逆算する再処理の起点、Databricks・Microsoft Fabric・OSS構成でのデプロイ単位の違いを整理し、3層を敷かないほうがよい要件まで条件付きで示します。数値と仕様は公式ドキュメントを2026-09-11に読み直して裏を取り、取り込み・MERGE・VACUUM・クラスタリングはそのまま実行できるSQLとPySparkのコードとして載せました。
まとめ：メダリオンアーキテクチャの層分割で先に決める3つの設計値
層の名前を決めても実装は進みません。着手前に確定させる値は3つです。第一にBronzeの履歴保持期間、第二に再処理の起点となる層、第三に層の分離単位（スキーマ・カタログ・ワークスペースのどれで割るか）。この3点が決まれば、テーブル定義とジョブ設計は機械的に埋まります。
3層は義務ではありません。Azure Databricksのメダリオンレイクハウスアーキテクチャの公式ドキュメントは「medallion アーキテクチャに従うことをお勧めするが、必須条件ではありません」と明記しています（2026-08-10更新時点）。一方でMicrosoft FabricはOneLakeでのメダリオン実装ガイドで「Fabric に推奨される設計アプローチ」と位置づけており（2026-02-12更新時点）、製品によって前提が違う点は押さえておく必要があります。
判断の目安はソース数です。データソースが1〜2系統、更新が日次バッチ、用途がBIレポートだけなら、Silverを省いた2層で足ります。名寄せや遅延データの調停が発生した時点が、はじめてSilverを置く価値の出るタイミングです。以下では層ごとの設計値を決めたあと、そのまま流せるコードへ落とすところまでを順に扱います。
メダリオンアーキテクチャの定義とマルチホップ構成が示す品質段階の違い
層の呼び名はデータの品質ラベルであって、ストレージ製品の種類ではありません。ここを取り違えると、層ごとに別サービスを買う設計に流れます。
品質段階でテーブルを分けるマルチホップ設計のデータ管理上の位置づけ
メダリオンアーキテクチャは、データを論理的に整理するための設計パターンで、マルチホップアーキテクチャとも呼ばれる方式です。Bronzeは到着したままの未加工データ、Silverは検証と重複除去を通した状態、Goldは分析に向けて集計・整形した状態を指します。ホップ（層の移動）ごとにテーブルを作り直すため、どの段階でデータが壊れたかを切り分けやすい構造です。土台となるレイクハウス側の構造はデータレイクハウスの定義とアーキテクチャを解説した記事に整理しており、本記事はその上に置くテーブル層の設計だけを扱います。層はメタルの色に由来する呼称で、金額的な価値ではなく精製度を表す言葉です。
ブロンズ・シルバー・ゴールドの各層が担う利用者と処理内容の分担
層の責務は、処理内容と読み手の両方で分かれます。Azure Databricksのドキュメントが示す分担を整理すると次の通りです。
| 層 | この層で行う処理 | 主な読み手 | テーブル例 |
|---|---|---|---|
| Bronze | 生データ取り込み（検証なし） | データエンジニア・監査 | orders_raw |
| Silver | クレンジングと検証・結合 | データエンジニア・データサイエンティスト | customer_transactions |
| Gold | ディメンションモデリングと集計 | BI開発者・業務部門 | customer_spending |
読み手の欄がそのままアクセス権限の設計図になります。Bronzeはシルバーテーブルを作るワークロードのためのもので、アナリストが直接触る前提では設計しません。監査とコンプライアンスの参照だけは例外的にBronzeへ向きます。
Delta LakeとIcebergのどちらでも層設計が成立する理由
層を分ける行為そのものはフォーマット非依存です。成立の前提は、テーブル単位でACIDトランザクションとスキーマ管理が効くこと。Delta LakeでもApache Icebergでも、この条件は満たされます。Microsoft FabricはDelta Lakeを既定のストレージ形式に据え、すべてのワークロードエンジンが新規テーブルをDeltaで書き込む設計です。テーブルログがどう版を管理するかはDelta Lakeのトランザクションログの仕組みを解説した記事で確認できます。逆に、素のParquetをディレクトリに並べただけの状態では、Silverでの更新処理が書き込み途中の読み取りと衝突します。フォーマット選定を先に済ませてから層を切る順序が安全です。
Bronze・Silver・Goldの層別テーブル設計とスキーマ・ファイルサイズの基準
ここからは各層で具体的に何をどう格納するかに入ります。設計値の根拠は各社の公式ドキュメントに揃っています。
Bronze層で型を文字列やVARIANTへ寄せる取り込み設計とメタデータ列
Bronzeでの型付けは緩めが基本です。Azure Databricksは、破棄されるデータを確実に防ぎ想定外のスキーマ変更から守るため、ほとんどのフィールドを文字列・VARIANT・バイナリで格納する構成を推奨しています。型を厳しく当てると、ソース側の仕様変更でジョブが落ち、その日の生データを失う原因になります。加えて、どのファイルから来たかを示す _metadata.file_name のようなメタデータ列を足しておけば、後から取り込み元を追跡可能です。Bronzeは追記中心で時間とともに増え、全履歴を持つことで再処理と監査を成立させる層です。ソースがAmazon S3やADLS Gen2、Google Cloud Storageに既にあるなら、FabricではコピーせずショートカットでBronzeに参照を作る方法も選べます。生データを二重に持たずに済むため、保管費が下がる構成です。
Silver層で重複除去とスキーマ適用を行い非集計表現を残す設計
Silverで行う処理は、スキーマの適用、null・欠損値の処理、重複除去、順序が乱れて到着したデータの調停、型キャスト、結合です。設計上の要点はひとつ。各レコードについて検証済みかつ非集計の表現を最低1つ残すこと。ここで集計まで済ませてしまうと、後から粒度の違う分析要件が来たときにBronzeまで戻る羽目になります。取り込み処理から直接Silverへ書き込む構成も避けます。ソース側のスキーマ変更や壊れたレコードがそのままエラーになるためで、Bronzeからの読み取りを挟むのが定石です。読み取りは追記前提のストリーミング読み取りを基本とし、小さなディメンションテーブルだけバッチ読み取りに回します。検証ルールをコード側に持たせるなら、Great Expectationsによるデータ品質検証の実装を層の境界に挟む構成が扱いやすいところです。
Gold層のディメンションモデル化と部門別に複数持たせる基準
Goldはビジネス部門が読む層で、ファクトとディメンションの関係を定義し、メジャーを持たせたモデルにします。週次売上のような定型の集計は、マテリアライズドビューとして事前計算しておくと、閲覧のたびに再集計が走りません。Goldはビジネスドメインをそのままモデル化するため、人事・財務・ITのように部門ごとに複数のGoldを作る構成も採れます。判断基準は「同じ集計を3つ以上のチームが別々に書いているか」。重複が見えてから分けるほうが、使われないテーブルが増えません。大量の履歴データはSilverで参照させ、Goldには実体化しないのが基本形です。Goldのテーブル数がSilverより多くなっている基盤は、粒度設計に失敗しています。
層ごとに変えるファイルサイズとパーティション設計の切り替え判断基準
小さなファイルが増えるとメタデータ操作が膨らみ、クエリのプランニングが遅くなります。Microsoft Fabricのガイダンスは、テーブルサイズと利用パターンに応じて128MBから1GBのファイルサイズを目標に置く方針です（2026-02-12更新時点）。層ごとの当て方は次のように分かれます。
- Bronze：生データの性質上、小さめのファイルを許容してよい（変換はSparkに寄せる）
- Silver：書き込みと読み取りの釣り合いを取る中間サイズにする
- Gold：利用エンジンのクエリ性能を優先し、大きめのファイルと行グループにする
分割方式も層で変わります。Bronzeのパーティション分割は許容されるものの、新規実装では推奨されていません。SilverとGoldではパーティションの代わりにリキッドクラスタリングを使う指針が示されています。パーティション済みのテーブルへMERGEをかける場合は、パーティションフィルタを併用して更新対象外を除外する方式です。層ごとのメンテナンス方針はFabricのレイクハウステーブルメンテナンス文書にまとまっており、Vオーダーの有効化条件もそちらで確認できます。
取り込みからSilver生成までをSQLとPySparkで組み立てる手順
ここからは机上の層図をコードへ落とします。以下はDatabricks・Fabricのどちらでも動く形で書いており、テーブル名だけ自分の環境に置き換えれば流せます。
Bronzeテーブルをストリーミング読み取りで作る取り込みコード
Bronzeへの取り込みは、クラウドストレージへ届いたファイルを増分で拾う構成にします。Auto Loaderの cloudFiles ソースを使うと、処理済みファイルの管理をチェックポイントに任せることが可能です。取り込み元ファイル名と取り込み時刻を列として残しておくのが要点で、この2列が後の再処理範囲の指定に効きます。
(spark.readStream
.format("cloudFiles")
.option("cloudFiles.format", "json")
.option("cloudFiles.schemaLocation", f"{checkpoint_path}/_schema")
.option("cloudFiles.schemaEvolutionMode", "rescue")
.load(source_path)
.selectExpr(
"*",
"_metadata.file_name AS _source_file",
"current_timestamp() AS _ingested_at")
.writeStream
.option("checkpointLocation", checkpoint_path)
.trigger(availableNow=True)
.toTable("ops.bronze.orders_raw"))
schemaEvolutionMode を rescue にすると、想定外の列が来ても救済列へ退避され、ジョブは落ちません。Bronzeで型を緩く受ける方針をコードで担保する箇所がここです。trigger(availableNow=True) は溜まったファイルを一度で処理して終了する指定で、常時起動のクラスタを抱えずに済みます。秒単位の鮮度が要る場合だけ、この行を外して継続実行に切り替えます。
MERGEで冪等なSilver更新を書き再実行しても増えない状態にする
Silverへの書き込みは追記ではなくアップサートにします。Delta Lake公式のテーブル更新ドキュメントは、MERGEのソース側について「新しいログのデータセットは、それ自体で重複排除される必要があります」と述べています。つまりソース側での重複除去とMERGEは、セットで記述する処理です。
MERGE INTO ops.silver.customer_transactions AS t
USING (
SELECT * FROM (
SELECT *,
row_number() OVER (
PARTITION BY order_id ORDER BY updated_at DESC) AS rn
FROM ops.bronze.orders_raw
WHERE _ingested_at >= current_date() - INTERVAL 3 DAYS
) WHERE rn = 1
) AS s
ON t.order_id = s.order_id
WHEN MATCHED AND s.updated_at > t.updated_at THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *
内側の row_number() がソース側の重複を1行に畳み、WHEN MATCHED AND s.updated_at > t.updated_at が古い版での上書きを止めます。この2つが揃うと、同じジョブを何度流しても結果は変わりません。_ingested_at の絞り込み幅がバックフィルの範囲指定になるので、障害時は日数を広げて流し直します。冪等性の考え方そのものはデータパイプラインの構成要素と冪等性から考える設計判断に整理しており、層をまたぐ設計にもそのまま当てはまります。
Gold層の集計をマテリアライズドビューとして宣言する記述例
Goldの定型集計は、パイプラインを組まずにビュー定義で宣言する方法が扱いやすいところです。Azure Databricksのドキュメントは週次予約数の例を示しており、次の形がそのまま雛形になります。更新順序と増分判定はサービス側が持つため、層間の依存を自分でスケジュールする作業が減ります。
CREATE OR REPLACE MATERIALIZED VIEW ops.gold.weekly_bookings AS
SELECT date_trunc('week', check_in) AS week,
property_id,
status,
count(*) AS total_bookings,
sum(total_amount) AS total_revenue
FROM ops.silver.bookings
GROUP BY week, property_id, status
Fabricでも同じ発想で、マテリアライズドレイクビューをSQLで宣言すれば依存解決と更新順序をサービスに任せられます。ここで注意したいのは、宣言型に寄せるほど「どのビューがどれだけ再計算されたか」が見えにくくなる点。コスト監視は層単位ではなくビュー単位で取る運用にしておきます。
層をまたぐ再処理とバックフィルを成立させる保持期間と冪等性の設計
メダリオンの実務価値は、壊れたときにどこから流し直せるかで決まります。設計の起点は保持期間です。
Bronzeの履歴保持とVACUUM既定7日制約から決める再処理の起点
Bronzeが全履歴を持つ限り、Silver以降はいつでも作り直せます。ところがDelta Lakeは既定で変更履歴を残し続けるため、履歴メタデータは時間とともに膨らみます。古い版の削除には VACUUM を使いますが、Delta Lake公式のユーティリティコマンド文書が示す既定の保持しきい値は7日で、それより新しい履歴データは消せません。一貫性を守るための制約で、テーブルプロパティ delta.deletedFileRetentionDuration で日数を変更できます。ここで決めた保持期間が、そのまま遡って再処理できる最大期間になります。監査要件で3年分の再現が要るなら、Bronzeのファイル本体は消さずに残し、履歴メタデータの保持だけを1か月程度に絞る組み合わせが現実的です。保持期間を決めないまま運用に入ると、ストレージ費用が積み上がる一方で、いざ障害時に「どこまで戻せるか」の答えが誰にも出せません。
冪等な変換とMERGEで再実行時の重複を防ぐパイプライン実装
再処理は同じジョブを二度走らせる操作です。追記だけで組んだ変換では、二度目の実行時に行が倍になる結果を招きます。自然キーと更新時刻を決めてMERGEによるアップサートに寄せれば、何度流しても結果が変わらない状態を作れます。ストリーミング読み取りで組む場合は、チェックポイントの保存先を層ごとに分け、テーブルを作り直したらチェックポイントも捨てる運用が必要です。バックフィルの範囲指定は日付パーティションで切るのが扱いやすく、対象期間のSilverを削除してから流し直す手順を運用に組み込む設計です。前章のMERGE文はこの手順をそのまま実装した形になっています。
継続・トリガー・バッチという取り込み頻度3方式のコストと遅延
取り込み頻度は、そのまま計算資源の費用になります。Azure Databricksのドキュメントが整理する3方式の関係は次の通りです。
| 取り込み方式 | コスト | 遅延 | 実装の型 |
|---|---|---|---|
| 継続的な増分取り込み | 高い | 小さい | ストリーミングを継続実行 |
| トリガー実行の増分取り込み | 低い | 中程度 | スケジュールやファイル到着で起動 |
| 手動増分を伴うバッチ | 低い | 大きい | パーティション単位の上書き |
実務でまず試すのはトリガー実行です。ファイル到着トリガーなら、常時起動のクラスタを抱えずに数分単位の鮮度を作れます。継続実行が要るのは、秒単位の鮮度が業務要件になっている場合に限られます。
VACUUMとOPTIMIZEで保持期間とファイル統合を運用に組み込む
層を切って終わりにすると、半年後にファイル数とストレージ費用の両方が膨らみます。保持期間の変更とファイル統合は、テーブル作成と同じタイミングでコードに固定しておく作業です。
保持期間のテーブルプロパティを変更してVACUUMを流す手順
保持日数はテーブルプロパティで宣言し、実行前に必ずドライランで消える対象を確認します。delta.logRetentionDuration の既定は30日で、履歴メタデータの保持期間を指します。削除対象ファイルの猶予を決めるのが delta.deletedFileRetentionDuration です。
ALTER TABLE ops.bronze.orders_raw
SET TBLPROPERTIES (
'delta.deletedFileRetentionDuration' = 'interval 30 days',
'delta.logRetentionDuration' = 'interval 30 days'
);
DESCRIBE HISTORY ops.bronze.orders_raw;
VACUUM ops.bronze.orders_raw DRY RUN;
VACUUM ops.bronze.orders_raw RETAIN 720 HOURS;
DESCRIBE HISTORY で残っている版を先に見ておくと、タイムトラベルで戻せる下限が把握できます。RETAIN 720 HOURS は30日を時間で指定した書き方です。既定より短い時間を指定すると安全チェックに引っかかるため、短縮したいときはプロパティ側を先に変更します。なおDelta 3.3系以降では対象を絞って軽く走らせる VACUUM ... LITE も使えます（2026-09-11時点の公式ドキュメント記載）。
Silver層とGold層にリキッドクラスタリングを設定する記述
SilverとGoldではパーティションを切らず、リキッドクラスタリングでレイアウトを管理します。Databricksのリキッドクラスタリング文書によれば、Delta LakeテーブルではDatabricks Runtime 15.4 LTS以降で一般提供、マネージドApache IcebergテーブルではRuntime 16.4 LTS以降のパブリックプレビューという扱いです（2026-09-03更新時点）。指定できるクラスタリングキーは最大4つで、それを超える設計にはしません。
CREATE TABLE ops.gold.customer_spending (
customer_id BIGINT,
event_date DATE,
total_amount DECIMAL(18,2)
)
CLUSTER BY (event_date, customer_id);
ALTER TABLE ops.silver.customer_transactions
CLUSTER BY (event_date, customer_id);
OPTIMIZE ops.silver.customer_transactions FULL;
キーを後から変えても既存データは書き換わりません。レイアウトへ反映させるには OPTIMIZE ... FULL を明示的に走らせます。書き込み時のクラスタリングが自動で走る条件はトランザクションのサイズで決まり、Unity Catalogのマネージドテーブルではキー1本で64MB、4本で1GBがしきい値です。この値を下回る小口の書き込みが続く基盤では、OPTIMIZE を1〜2時間おきに回す設計にします。
既存のパーティション済みテーブルをクラスタリングへ移す変換手順
すでにHiveスタイルのパーティションで運用しているテーブルは、書き換えなしで移行できます。Databricks Runtime 18.1以降では専用の変換文が用意されており、読み書きの停止時間を抑えたまま切り替えられます。
ALTER TABLE ops.silver.customer_transactions
REPLACE PARTITIONED BY WITH CLUSTER BY (event_date, customer_id);
OPTIMIZE ops.silver.customer_transactions;
DESCRIBE EXTENDED ops.silver.customer_transactions;
キーを明示しなければ、現在のパーティション列がそのままクラスタリングキーへ引き継がれます。DESCRIBE EXTENDED でクラスタリング列が入れ替わったことを確認するまでが1セットです。ここで元のパーティション列と大きく離れた列を選ぶと、初回の OPTIMIZE でテーブル全体の再配置が走り、数時間かかる場合があります。移行時のキーは元のパーティション列に寄せておくのが無難です。
Databricks・Fabric・OSS構成で分かれるデプロイ単位と権限境界
層をどの単位で物理分離するかは製品で変わります。同じ3層でも、置き場所と権限の切り方が違います。
Databricksでカタログとスキーマを使い層を分離する権限設計
Databricksの標準形は、1つのカタログの下に層ごとのスキーマを並べる構成です。運用チーム向けの基盤なら ops.bronze、ops.silver、ops.gold のように、カタログ名で用途を、スキーマ名で品質段階を表します。公式ドキュメントの例もこの命名で、Bronzeにクラウドストレージ・Kafka・Salesforceからの生データを受け、Silverで customer_transactions や leads_cleaned を作り、Goldに customer_spending や sales_pipeline_summary を置く形です。権限はスキーマ単位で付与し、BIツールにはGoldスキーマだけを見せます。テーブル作成と削除の権限を分析者全員に配ると、破損時の原因追跡ができなくなるため、書き込みはパイプライン用のサービスプリンシパルに限定する設計が定石です。層をまたぐ系統（リネージ）はカタログ側で自動記録されるため、Gold のテーブルがどの Bronze から来たかを後から追えます。
Fabricで層ごとにレイクハウスとワークスペースを分ける構成
Fabricでは各層をOneLake上の別のレイクハウスとして作ります。よく採られる型は2つで、全層をレイクハウスにしてSQL分析エンドポイントから読ませる構成か、BronzeとSilverをレイクハウス・Goldをデータウェアハウスにしてウェアハウスのエンドポイントから読ませる構成です。すべてを1つのワークスペースに置くこともできますが、ドキュメントは層ごとに別ワークスペースへ分ける方針を推奨しています（2026-02-12更新時点）。層の単位で統制と権限を効かせやすくなるためです。層間の変換をパイプラインで組む代わりに、マテリアライズドレイクビューをSQLで宣言し、依存関係の解決と更新順序をサービス側に任せる選択肢も用意されています。SilverとGoldにはVオーダー書き込み時の処理が効くため、Power BIやSQLエンドポイントからの読み取りが速くなります。
IcebergとTrinoで組む自前構成の名前空間とジョブ配置
OSSだけで組む場合は、カタログの名前空間を層に対応させます。Apache Icebergの公式ドキュメントが示すカタログ仕様に沿って、bronze・silver・goldの名前空間を切り、書き込み権限を名前空間単位で分けるのが最小構成です。Trinoから作る場合の記述は次の形になります。
CREATE SCHEMA iceberg.bronze
WITH (location = 's3://lake/bronze');
CREATE SCHEMA iceberg.silver
WITH (location = 's3://lake/silver');
CREATE TABLE iceberg.silver.customer_transactions (
order_id BIGINT,
customer_id BIGINT,
event_date DATE,
amount DECIMAL(18,2)
)
WITH (partitioning = ARRAY['month(event_date)']);
ジョブはSparkやTrinoで実装し、層ごとに実行スケジュールを変えます。小ファイル統合と旧スナップショット削除は自分で組み込む前提になるため、マネージド構成より運用の重さが増します。ストレージからクエリエンジンまでの組み上げ手順はデータレイクハウス実装の手順6ステップを解説した記事に分けて整理しました。自前構成を選ぶ条件は、SparkやTrinoの運用経験者が複数名いること。この条件を満たさないなら、層設計だけ持ち込んでマネージド基盤に載せる判断を勧めます。
3層固定を見送る判断基準とメダリオンが不向きな要件の切り分け
ここからは立場を明確にします。メダリオンは万能の型ではなく、噛み合わない要件がはっきりあります。
単一ソースとBI限定の要件で3層が過剰になる境界と2層への集約
データソースが1〜2系統、更新が日次バッチ、用途が定型BIだけ、規模が数十GB程度。この4条件が揃うなら、3層は敷きません。生データを受けるBronzeと、BIが読むGoldの2層で足ります。Silverの存在価値は、複数ソースの名寄せ・遅延データの調停・重複除去といった調停処理にあり、ソースが1本ならその処理自体が発生しないためです。層を1つ減らせば、テーブル定義もジョブも監視対象も減ります。判断を先送りして3層で始めると、実体としてSilverがBronzeの単なるコピーになり、保管費と実行時間だけが二重に乗ります。切り替えの目安は、2つ目の基幹データを取り込む段階です。
不正検知などリアルタイム性が最優先の用途で多段構成を避ける判断
層をまたぐたびにコミットが挟まるため、遅延は積み上がります。決済の不正検知のように、秒単位で判定を返す用途では、メダリオンの多段構成を判定経路に置くべきではありません。この場合はストリーム処理側で直接判定し、メダリオンは事後の分析・学習データ整備用として並置します。判定経路と分析経路を分ける設計です。両方を1本の層構成でまかなおうとすると、鮮度を上げるために継続実行のコストを払い、それでも層数ぶんの遅延は消えないという中途半端な結果に落ちます。リアルタイム判定と履歴分析は、要件が違う以上、経路も分けるのが結論です。
Platinum層を足す前に見直すGoldの粒度とSilverの責務
Goldの上にPlatinum層を置く構成が語られることがありますが、層の追加はデータのコピーと運用対象を1段増やす判断です。着手前に見るべきは2点。Goldのテーブルが増えすぎている原因が粒度設計の失敗ではないか、そしてSilverに集計処理が混入していないか。Silverで集計してしまうとGoldとの責務が重なり、どちらを直せばよいか分からないテーブル群ができます。層の追加を認めてよいのは、部門をまたいだ同一のKPI定義が3チーム以上で重複実装されている場合に限ります。それ以外は、Goldの粒度を切り直すほうが早く、費用も増えません。
内製で層設計を保守できるデータ基盤チームの条件と受託開発への線引き
層設計は作って終わりではなく、保持期間の見直しとファイル統合を回し続ける運用です。内製が成立する条件は、SparkまたはクラウドDWHの運用経験者が複数名いて、基盤整備に半年単位の工数を確保できること。分析要件は決まっているのに基盤の担当者がいない状況で3層を敷くと、Silverのジョブが止まったまま誰も気づかない状態になります。当社ではデータ分析基盤構築・MLOps構築支援として、層設計とテーブル定義から再処理の運用設計までを受託しています。層数の判断だけを相談し、構築範囲を後から広げる進め方も可能です。内製か外注かを決めないまま着手する進め方だけは避けてください。
よくある質問
メダリオンアーキテクチャの設計段階でよく挙がる質問に、実装の観点から答えます。
メダリオンアーキテクチャは必ず3層にする必要がありますか？
必須ではありません。Azure Databricksのドキュメントも、メダリオンに従うことを推奨しつつ必須条件ではないと明記しています（2026-08-10更新時点）。ソースが1〜2系統で名寄せや重複除去が発生しないなら、BronzeとGoldの2層で足ります。逆にMicrosoft Fabricでは3層が推奨設計として案内されており、採用製品によって前提が変わります。層数は要件から決め、図に合わせて増やさないでください。
Bronze層のデータは分析者が直接参照してよいですか？
設計としては想定しません。Bronzeは検証前の未加工データを保持する層で、読み手はSilverテーブルを作るワークロードです。分析者が直接参照すると、型が文字列のまま解釈され、部門ごとに違う集計結果が出ます。例外は監査・コンプライアンス目的の参照で、この場合も読み取り専用の権限に絞ります。分析者へはSilverかGoldを見せる構成が基本です。
Silver層とGold層の違いはどこで判断しますか？
集計しているかどうかで分けます。Silverは各レコードの検証済みかつ非集計の表現を最低1つ持つ層で、クレンジング・重複除去・結合までを担当します。Goldはビジネス要件に沿ってディメンションモデル化し、集計値やマテリアライズドビューを置く層です。Silverに集計が混ざり始めたら責務が崩れているサインで、集計処理をGold側へ寄せ直します。
メダリオンアーキテクチャはDatabricks以外でも実装できますか？
Databricks以外でも実装可能です。層分割はテーブルフォーマットに依存しない設計パターンで、ACIDトランザクションとスキーマ管理が効けば成立します。Microsoft FabricはOneLake上のレイクハウスで3層を組み、AWSではS3とIcebergにGlueカタログの名前空間を層として割り当てる構成が採れます。製品で変わるのは層の物理的な分離単位（スキーマ・レイクハウス・名前空間）と権限の切り方です。前章のTrinoの記述例はそのまま自前構成の雛形になります。
既存のデータレイクからメダリオン構成へ移行できますか？
移行できます。手順は、既存のParquet群をテーブル化してBronzeに位置づけ、そこから読み取るSilverの変換を新規に組む流れです。データ本体を書き直さずにテーブル化できる場合が多く、移行費用を抑えられます。パーティション運用のまま移すなら、変換文でリキッドクラスタリングへ切り替える手順も併せて検討してください。着手前に、Bronzeの保持期間・再処理の起点・層の分離単位の3点を決めておくと、移行後の作り直しを避けられます。
関連記事
- データレイクとは？データウェアハウス・レイクハウスとの違いを実装視点で解説：層設計の土台となるデータレイクの構造と使い分けを整理しています。
- ETLとは？仕組み・ELTとの違い・ツール選定から導入判断まで解説：層をまたぐ変換処理そのものの設計原則を、ツール選定の観点から補完します。
- Dagsterとは？アセット指向の仕組み・実装手順とAirflowとの使い分けを実装者目線で解説【2026年版】：層間のジョブ依存と再実行をどう管理するか、オーケストレータ側から扱っています。
