Lakehouse Monitoring完全解説｜データ品質監視

本番テーブルのデータ品質は時間とともに劣化します。スキーマは変わらなくても、NULL率の上昇、値分布の偏り、上流システムの仕様変更による静かなデータ破損は日常的に発生します。Lakehouse Monitoringは、Unity Catalogに登録されたDeltaテーブルに対して統計プロファイルを定期計算し、品質変化やドリフトを自動検知するDatabricksのネイティブ機能です。

この記事では、3つのプロファイルタイプの使い分け、モニター作成の具体的なSQL/API、メトリクステーブルの構造、ダッシュボード自動生成、アラート設定、そしてDatabricks認定試験（MLA/MLP）で問われるポイントを整理します。

Lakehouse Monitoringの仕組み

Lakehouse Monitoringは、Unity Catalogのマネージドテーブルまたは外部テーブルに対してモニターを作成すると、指定スケジュールで統計量を計算し、結果を2つのメトリクステーブル（profile_metrics、drift_metrics）にDeltaテーブルとして書き出します。計算はServerless Computeで実行されるため、ユーザーがクラスタを用意する必要はありません。

モニター作成時に「プロファイルタイプ」を1つ指定します。プロファイルタイプによって計算される統計量とドリフト検知の方法が異なります。テーブルの性質（静的マスタ／時系列データ／推論ログ）に応じて適切なタイプを選択します。

3つのプロファイルタイプ比較

Lakehouse Monitoringには3つのプロファイルタイプがあり、対象テーブルのデータ特性に応じて選択します。

Snapshotは最もシンプルで、テーブルの「今の状態」を定期記録します。TimeSeriesはtimestamp_colを指定し、granularities（日次、週次等）ごとに集計ウィンドウを切って統計量を計算します。InferenceLogはTimeSeriesの拡張で、prediction_col、model_id_col、label_col（任意）を追加指定することで、MLモデル固有のメトリクス（予測ドリフト、入力ドリフト、モデル間比較）を自動計算します。

モニター作成のSQL/API

モニターの作成はSQL（CREATE MONITOR）またはDatabricks SDK（Python API）で行います。以下はTimeSeriesプロファイルでモニターを作成するSQLの例です。

-- TimeSeriesプロファイルでモニターを作成
CREATE MONITOR catalog.schema.sales_daily
USING TIMESERIES (
  TIMESTAMP_COL order_date,
  GRANULARITIES ('1 day', '1 week')
)
WITH (
  LINKED_ENTITIES (catalog.schema.sales_daily),
  SCHEDULE CRON '0 8 * * *',
  BASELINE_TABLE catalog.schema.sales_daily_baseline
);

Python APIでの同等の操作は以下の通りです。

from databricks.sdk import WorkspaceClient
from databricks.sdk.service.catalog import (
    MonitorTimeSeries, MonitorCronSchedule
)

w = WorkspaceClient()

w.quality_monitors.create(
    table_name="catalog.schema.sales_daily",
    assets_dir="/Shared/monitors/sales_daily",
    output_schema_name="catalog.schema",
    time_series=MonitorTimeSeries(
        timestamp_col="order_date",
        granularities=["1 day", "1 week"]
    ),
    schedule=MonitorCronSchedule(
        quartz_cron_expression="0 0 8 * * ?",
        timezone_id="Asia/Tokyo"
    ),
    baseline_table_name="catalog.schema.sales_daily_baseline"
)

InferenceLogの場合はtime_seriesの代わりにinference_logパラメータを指定し、prediction_col、model_id_col、problem_type（classification / regression）を設定します。Snapshotの場合はtime_series / inference_logのいずれも指定しなければSnapshot扱いになります。

メトリクステーブルの構造

モニターが実行されると、指定したoutput_schema内に2つのDeltaテーブルが自動生成されます。

profile_metricsはモニター実行のたびにレコードが追加され、時系列で統計量の推移を追跡できます。drift_metricsにはカテゴリカル変数に対するカイ二乗検定、数値変数に対するKS検定・JS距離・Wasserstein距離などの統計的検定結果が記録されます。これらのテーブルは通常のDeltaテーブルなので、Databricks SQLやNotebookから直接クエリして独自の分析やカスタムアラートを構築できます。

ダッシュボード自動生成

モニター作成時にassets_dirを指定すると、Databricks SQLダッシュボードが自動生成されます。このダッシュボードには以下の可視化が含まれます。

• カラムごとの統計量推移（NULL率、平均値、カーディナリティの時系列グラフ）
• ドリフトスコアのヒートマップ（どのカラムがどの時点で変化したかを一覧表示）
• 数値カラムの分布ヒストグラム（ベースラインと現在の比較）
• InferenceLogの場合は予測分布の変化、モデルバージョン間比較

ダッシュボードはDatabricks SQLのLakeview Dashboard形式で生成され、assets_dirに格納されます。生成後はダッシュボードを手動でカスタマイズすることも可能です。ただし、モニターを再作成するとダッシュボードも再生成されるため、大幅なカスタマイズを行う場合は別途ダッシュボードをコピーして利用することを推奨します。

アラート設定

Lakehouse Monitoring単体にはアラート通知機能はありません。異常検知時の通知には、drift_metricsテーブルに対するDatabricks SQLアラートを組み合わせます。

-- ドリフトスコアが閾値を超えたカラムを検出するアラートクエリ
SELECT
  column_name,
  js_distance,
  window.start AS window_start,
  window.end AS window_end
FROM catalog.schema.sales_daily_drift_metrics
WHERE js_distance > 0.3
  AND window.end = (
    SELECT MAX(window.end)
    FROM catalog.schema.sales_daily_drift_metrics
  );

このクエリをDatabricks SQLアラートとして登録し、スケジュール実行で結果が1行以上返された場合にメール・Slack・Webhook経由で通知を送信します。閾値の設定は対象データの特性に依存しますが、JS距離で0.1〜0.3が一般的な初期値です。本番運用では閾値を段階的に調整し、誤検知率を下げていきます。

DLT Expectations / Delta Constraints / Lakehouse Monitor 使い分け

Databricksにはデータ品質を担保する仕組みが複数あります。それぞれの適用タイミングと用途が異なるため、混同しないことが重要です。

典型的な実務構成は、DLT Expectationsで「明らかに不正なレコード」をパイプライン段階で除外し、Delta Constraintsで「テーブルレベルの不変条件」（主キーNOT NULL等）を強制し、Lakehouse Monitoringで「書き込み済みデータの品質が時間経過で劣化していないか」を監視する3層構成です。

試験で問われるポイント（MLA/MLP）

Lakehouse MonitoringはDatabricks Certified ML Associate（MLA）およびML Professional（MLP）で「モデル監視」「データドリフト」の文脈で出題されます。主な出題パターンは以下の通りです。

• 「本番MLモデルの入力データの分布が変化していないか監視したい」→ InferenceLogプロファイル。Model Servingのペイロードログテーブルにモニターを設定し、入力特徴量のドリフトを検知する。
• 「データドリフト検知に使われる統計的手法は何か」→ 数値変数にはKS検定（Kolmogorov-Smirnov test）、カテゴリカル変数にはカイ二乗検定。Jensen-Shannon距離も合わせて覚える。
• 「モニターの結果はどこに保存されるか」→ profile_metricsとdrift_metricsの2つのDeltaテーブル。出力先はモニター作成時に指定するoutput_schema。
• 「Lakehouse MonitoringとMLflowの関係」→ Lakehouse Monitoringはデータ/予測の品質監視、MLflowはモデルのライフサイクル管理（実験追跡・レジストリ・デプロイ）。両者は補完関係。
• 「DLT Expectations / Delta Constraints / Lakehouse Monitorの違い」→ 適用タイミングと目的の違いを正確に整理する。

試験では「ドリフト検知＝Lakehouse Monitoring」「レコード単位のバリデーション＝DLT Expectations」「スキーマ制約＝Delta Constraints」という対応を即答できるようにしておくことが重要です。

問題で確認

よくある質問