目次 › 第3章 › 3-6

第3章 データ変換とモデリング / 想定学習時間:30〜40分 / 最終確認:2026年8月

3-6. ゴールド層オブジェクト(マテリアライズドビュー・ビュー・ストリーミングテーブル)とデータ品質チェック

1. ゴールド層に置く4つのオブジェクト

メダリオンアーキテクチャの最終層であるゴールド層(3-1)は、BI・分析・ML が「そのまま使える」形でデータを提供する層です。Unity Catalog 上でその受け皿になるオブジェクトは主に4種類あり、「結果を物理的に保存するか」「更新を誰がどう行うか」で区別します。

1-1. ビュー vs マテリアライズドビュー:計算をいつ払うか

両者の違いは「計算コストをいつ払うか」です。ビューは参照のたびに計算するため、定義が重い集計だとダッシュボードを開くたびに全計算が走ります。MV は事前に計算して保存しておくため、参照時は保存済みの結果を読むだけで高速・低コストです。しかも更新は Databricks が管理し、ソースの変化に対して可能な場合は増分更新(全再計算せず差分だけ反映)されます。

1-2. マテリアライズドビュー vs ストリーミングテーブル

どちらも「Databricks が更新を管理する」仲間ですが、役割が違います。ST は入口側(ソースからの増分取り込み。各入力行を一度だけ処理する追記中心の処理)、MV は出口側(集計・結合の結果を最新に保つ。ソースの更新・削除にも定義どおり追従)に向きます。ST は集計の作り直しをしないため、ソース側の過去データ修正を反映したい集計には MV を選びます。

-- ビュー:保存なし。参照のたびに元テーブルを計算
CREATE OR REPLACE VIEW gold.v_orders_recent AS
SELECT order_id, customer_id, total_amount, order_date
FROM silver.orders
WHERE order_date >= current_date() - INTERVAL 90 DAYS;

-- マテリアライズドビュー:事前計算・増分更新。BI向けの重い集計に
CREATE OR REPLACE MATERIALIZED VIEW gold.mv_daily_sales AS
SELECT
  order_date,
  region,
  SUM(total_amount)              AS revenue,
  COUNT(*)                       AS order_cnt,
  COUNT(DISTINCT customer_id)    AS customers
FROM silver.orders
GROUP BY order_date, region;

-- ストリーミングテーブル:ファイルの継続的な増分取り込み
CREATE OR REFRESH STREAMING TABLE bronze.events_st AS
SELECT * FROM STREAM read_files(
  '/Volumes/main/raw/events/',
  format => 'json'
);

2. BI/分析チーム向けゴールド層の設計

ゴールド層の設計で決めるべきことは、技術よりもまず「誰が・何の質問に答えるためのデータか」です。

• 集計粒度を明示する:1行が何を表すか(日次×地域×商品カテゴリ、月次×顧客など)をテーブルごとに1つに固定します。粒度の混在(日次と月次が同じテーブルに同居)は集計ミスの温床です。ダッシュボードの表示要件に対して細かすぎる粒度は計算コストを、粗すぎる粒度は分析の自由度を犠牲にします。
• 命名で内容がわかるようにする:カタログ.スキーマ.テーブルの3階層(Unity Catalog)を活かし、たとえば gold.sales.daily_revenue_by_region のように「層・領域・粒度・内容」が名前から読めるようにします。tmp_final_v2 のような名前を BI に公開しない、ビューには v_、MV には mv_ のような接頭辞を付ける、といったチーム規約を決めて統一します。
• ビジネスロジックはゴールド層に集約する:「売上の定義(税込/税抜、キャンセル除外)」のような計算を BI ツール側に散らばらせず、ゴールド層で一度だけ定義して全ダッシュボードに共通化します。

3. データ品質チェック

ゴールド層は利用者から最も見られる層であり、ここに不正データが混ざると信頼を直接損ないます。品質を守る仕組みは「テーブル自体に制約を付ける」「パイプラインで検査する」「クエリで監視する」の3段構えです。

3-1. テーブル制約:NOT NULL と CHECK

Delta テーブルには強制力のある制約を付けられます。制約違反の書き込みはエラーで拒否されるため、不正データがテーブルに入ること自体を防げます。

-- NOT NULL 制約:キー列の null を拒否
ALTER TABLE gold.daily_sales
  ALTER COLUMN order_date SET NOT NULL;

-- CHECK 制約:条件を満たさない行の書き込みを拒否
ALTER TABLE gold.daily_sales
  ADD CONSTRAINT valid_revenue CHECK (revenue >= 0);

ALTER TABLE silver.orders
  ADD CONSTRAINT valid_date
  CHECK (order_date >= '2020-01-01');

3-2. パイプラインの expectations(Lakeflow Spark Declarative Pipelines)

Lakeflow Spark Declarative Pipelines(旧 Delta Live Tables)では、expectations(期待値)という宣言的な品質ルールを定義できます。テーブル制約と違い、違反時の動作を3種類から選べるのが特徴です。

-- SQL での expectations の例(違反行を除外する場合)
CREATE OR REFRESH MATERIALIZED VIEW gold.mv_daily_sales (
  CONSTRAINT valid_date    EXPECT (order_date IS NOT NULL) ON VIOLATION DROP ROW,
  CONSTRAINT valid_revenue EXPECT (revenue >= 0)           ON VIOLATION FAIL UPDATE
) AS
SELECT ...;

3-3. 検証クエリのパターン

制約や expectations に加えて、更新後のテーブルをクエリで検証するのも実務の定番です。ジョブの最終タスクとして流し、期待に反したら通知・失敗させます。

-- パターン1:キーの一意性(重複があれば行が返る)
SELECT order_id, COUNT(*) AS cnt
FROM gold.daily_sales
GROUP BY order_id
HAVING COUNT(*) > 1;

-- パターン2:null 率の監視
SELECT
  COUNT(*)                                          AS total,
  SUM(CASE WHEN region IS NULL THEN 1 ELSE 0 END)   AS null_region
FROM gold.daily_sales;

-- パターン3:値域・鮮度のチェック
SELECT COUNT(*) FROM gold.daily_sales WHERE revenue < 0;
SELECT MAX(order_date) FROM gold.daily_sales;  -- 直近日付が来ているか

練習問題