---

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

概要

• BigQuery上のテーブルをbronzeやsilverやgoldやplatinumなどの層に分けて管理する設計パターン
• 目的はデータ品質の段階的な向上とユースケースごとの責務分離
• GCSやPubSubなどから取り込んだデータをBigQuery上で段階的に整形する前提で考える

各層の役割

bronze層

• 生データをlosslessに格納するBigQueryテーブル群
• スキーマ変更や取り込みミスが起きても元データに戻れるようにする
• 取り込みはstreaming insertやbatch loadなど複数パターンが混在してもよく変換ロジックは極力持たない

silver層

• bronzeからクレンジングや正規化を行った分析用の共通基盤となるBigQueryテーブル群
• テーブル単位で主キーや整合性制約を意識したスキーマにする
• 複数システムのデータをjoinして横断的に使える形にする
• パーティションやクラスタリングを意識して一般的な分析クエリのコストを最適化する

gold層

• BIやプロダクト機能など具体的なユースケース向けに最適化されたBigQueryデータマート層
• 指標定義を固定しダッシュボードやレポートから直接参照される
• ログ系とマスタ系をjoin済みのテーブルや集計済みのsnapshotテーブルを配置する

platinum層 (Looker向け特殊化レイヤー)

• Lookerなど特定のBIツールで利用することを前提にさらに用途特化させた層
• gold層のテーブルを元にダッシュボード単位で最適化されたビューやマートを作る
• Lookerのモデルやexploreから参照されることを前提とし列名や粒度や計算ロジックを安定させる
• 変更時は対象ダッシュボードとオーナーを明確にし影響範囲を限定する

メリット

• データ品質の議論を層ごとに分離でき責任範囲が明確になる
• 障害時にbronzeへロールバックして再処理する運用が取りやすくなる
• goldの変更が入ってもbronzeやsilverを安定した契約として扱えるため利用者への影響を限定しやすい

データレイク全体設計との関係

• メダリオンアーキテクチャはBigQueryを中核としたデータレイクの論理レイヤを表現するためのパターンの一つという位置づけ
• ストレージ基盤としてはGCSなどを利用しつつ分析やBIの入口はBigQueryに集約しメダリオンはその上に被せる設計ルールとして扱う
• streaming ingestionやバッチ処理のどちらでも取り込み先をbronzeに固定することで全体設計をシンプルに保てる