DatabricksにおけるData Quality Monitorsの実務設計: 4層品質戦略

データ品質の管理は単一の仕組みでは完結しません。Databricksでは「パイプライン内の品質制御（DLT Expectations）」「テーブルレベルの制約（Delta Constraints）」「統計的な品質監視（Lakehouse Monitor）」「閾値ベースの通知（SQL Alerts）」の4層を組み合わせることで、検出から通知・改善まで一気通貫の品質戦略を構築できます。

4層品質戦略の全体像

各層は対象フェーズと検出タイミングが異なります。パイプラインの上流から下流へ、予防→検出→監視→通知の順で防御線を張る設計です。

第1層: DLT Expectations（パイプライン内品質制御）

Delta Live Tables（DLT）のExpectationsは、パイプライン定義内に品質ルールを宣言的に埋め込む仕組みです。 各Expectationに対して、違反時の動作（warn / drop / fail）を指定します。

import dlt
from pyspark.sql.functions import col

@dlt.expect_or_drop("valid_amount", "amount > 0")
@dlt.expect_or_fail("not_null_user_id", "user_id IS NOT NULL")
@dlt.expect("valid_email", "email LIKE '%@%'")
@dlt.table(comment="品質検証済みの注文データ")
def orders_clean():
    return dlt.read("orders_raw").filter(col("order_date") >= "2025-01-01")

• expect: 違反行を含めたまま処理を続行し、メトリクスに記録（warn相当）
• expect_or_drop: 違反行を除外して処理を続行（隔離パターン）
• expect_or_fail: 違反行があればパイプライン全体を停止（致命的品質違反向け）

Expectationsの結果はDLTパイプラインのイベントログに記録され、UIのDAGビューで合格率を確認できます。 Bronze→Silver変換での null除去やフォーマット検証に適しており、Medallionアーキテクチャの品質ゲートとして機能します。

第2層: Delta Constraints（テーブルレベル制約）

Delta ConstraintsはDeltaテーブルに対して NOT NULL 制約とCHECK制約を設定する仕組みです。 DLTを使わないバッチ処理やSQLベースのETLでも、テーブル側で最終防衛線を張れます。

-- NOT NULL制約の追加
ALTER TABLE gold.orders
ALTER COLUMN order_id SET NOT NULL;

ALTER TABLE gold.orders
ALTER COLUMN customer_id SET NOT NULL;

-- CHECK制約の追加
ALTER TABLE gold.orders
ADD CONSTRAINT valid_amount CHECK (amount > 0);

ALTER TABLE gold.orders
ADD CONSTRAINT valid_status CHECK (status IN ('pending', 'shipped', 'delivered', 'cancelled'));

-- 制約の確認
DESCRIBE DETAIL gold.orders;

制約違反時はINSERT/UPDATE/MERGEトランザクション全体がロールバックされます。 DLT Expectationsとの違いは、DLTがパイプライン定義に紐づくのに対し、Delta Constraintsはテーブル定義に永続化される点です。 どのETLツール・ジョブから書き込んでも制約が適用されるため、マルチパイプライン環境で特に有効です。

第3層: Lakehouse Monitor（統計的品質監視）

Lakehouse MonitorはUnity Catalogのマネージドテーブルに対して、カラム統計（null率、平均、分布）やデータドリフトを定期的に計測する機能です。 スナップショット分析またはタイムシリーズ分析の2モードがあります。

-- Lakehouse Monitorの作成（SQL）
CREATE MONITOR gold.orders
WITH (
  PROFILE_TYPE = 'SNAPSHOT',
  SCHEDULE = CRON '0 8 * * *',    -- 毎朝8時に実行
  OUTPUT_SCHEMA = gold
);

-- タイムシリーズモードの場合
CREATE MONITOR gold.daily_metrics
WITH (
  PROFILE_TYPE = 'TIME_SERIES',
  TIMESTAMP_COL = 'event_date',
  GRANULARITIES = ('1 day'),
  SCHEDULE = CRON '0 9 * * *',
  OUTPUT_SCHEMA = gold
);

Monitorは自動的に2つのテーブルを生成します。

• profile_metrics: 各カラムのnull率、distinct数、平均値、最小/最大値、分布ヒストグラム等
• drift_metrics: ベースラインとの比較によるドリフトスコア（KLダイバージェンス、JSダイバージェンス等）

MLモデルの入力テーブルに対して適用すると、特徴量の分布変化（データドリフト）を早期検出でき、モデル再学習の判断材料になります。

第4層: SQL Alerts（閾値ベース通知）

SQL Alertsは、SQLクエリの結果が閾値を超えた場合に通知を送る仕組みです。 Lakehouse Monitorのメトリクステーブルや、独自の品質チェッククエリに対して設定します。

-- アラート用クエリ例: null率が5%を超えたカラムを検出
SELECT
  column_name,
  ROUND(percent_nulls * 100, 2) AS null_pct
FROM gold.profile_metrics
WHERE log_date = CURRENT_DATE()
  AND percent_nulls > 0.05
ORDER BY null_pct DESC

このクエリをDatabricks SQL Alertに登録し、「結果行が1行以上存在する場合」にSlackチャンネルへ通知する設定にします。 評価間隔は最短1分から設定可能です。

アラート連携フロー

4層が連携する典型的なフローを整理します。

[Raw Data]
  │
  v
[DLT Pipeline]
  ├─ Expectation: expect_or_drop("valid_amount", "amount > 0")
  ├─ Expectation: expect_or_fail("not_null_id", "id IS NOT NULL")
  │   → 違反行は隔離/停止、メトリクスはイベントログに記録
  v
[Silver/Gold Table]
  ├─ Delta Constraint: CHECK (amount > 0), NOT NULL (id)
  │   → 制約違反時はトランザクション拒否
  v
[Lakehouse Monitor] (毎朝8時)
  ├─ profile_metrics: null率、分布、統計量
  ├─ drift_metrics: ベースラインからのドリフト
  v
[SQL Alert] (結果行 > 0 で発火)
  └─ Slack / Email / Webhook → 運用チームが調査

各層の使い分け判断基準

実務設計のベストプラクティス

• Bronze→Silver変換ではDLT Expectations（expect_or_drop）でnull除去・フォーマット検証を行う
• Goldテーブルには必ずDelta Constraints（NOT NULL + CHECK）を設定し、多経路書き込みでも品質を保証する
• MLモデルの入力テーブルにはLakehouse Monitor（TIME_SERIES）を設定し、特徴量ドリフトを毎日検出する
• profile_metricsの異常値検出クエリをSQL Alertに登録し、Slackで運用チームに即時通知する
• Expectationsのfail設定は本番に影響が大きいため、最初はwarnで運用し、安定後にfailに移行する

問題で確認

よくある質問