Data quality モニタリング

備考

ベータ版

この機能は ベータ版です。

このページでは、Data Quality モニタリングとは何か、何をモニタリングするのか、どのように使用するのかについて説明します。 データ品質モニタリングは、以前は異常検出と呼ばれていました。

データ品質モニタリングに関するフィードバックを提供するために、Eメール lakehouse-monitoring-feedback@databricks.com.

データ品質モニタリングとは何ですか?

データ品質モニタリングを使用すると、スキーマ内のすべてのテーブルのデータ品質を簡単に監視できます。 Databricks はデータ インテリジェンスを活用してデータ品質を自動的に評価し、特に各テーブルの最新性と完全性を評価します。データ所有者はログテーブルにアクセスできるため、メタストア全体の異常を迅速に特定して解決できます。カタログ、スキーマ、テーブル レベルの結果は、カタログ エクスプローラーまたはガバナンス ハブ (プレビュー) で確認できます。

データ品質モニタリング は、 モニターするテーブルを変更したり、これらのテーブルに入力するジョブにオーバーヘッドを追加したりしません。

必要条件

• Unity Catalog対応ワークスペースであること。
• 既存ユーザーはサーバレスコンピュートを有効にする必要があります。 手順については、 「サーバレス コンピュートへの接続」を参照してください。
• スキーマでデータ品質モニタリングを有効にするには、カタログスキーマに対する MANAGE SCHEMA または MANAGE CATALOG 権限が必要です。

データ品質モニタリングはどのように機能しますか?

Databricks は、テーブルの 最新性 と 完全性を 監視するバックグラウンド ジョブを作成します。Databricks はスマート スキャンを使用して、テーブルをスキャンするタイミングを決定します。

鮮度と は、テーブルがどれくらい最近更新されたかを指します。データ品質モニタリングは、テーブルへのコミットの履歴を分析し、テーブルごとのモデルを構築して、次のコミットの時間を予測します。 コミットが異常に遅い場合、テーブルは古いものとしてマークされます。

注記

イベントの鮮度は、イベント時間の列と取り込みの待ち時間に基づいており、従来のデータ品質モニタリング ユーザーのみが利用できました。 現在のバージョンでは、イベントの鮮度はサポートされていません。

完全性 とは、過去 24 時間にテーブルに書き込まれると予想される行数を指します。Data Quality モニタリングは、過去の行数を分析し、このデータに基づいて、予想される行数の範囲を予測します。 過去 24 時間にコミットされたローの数がこの範囲の下限より小さい場合、テーブルは未完了としてマークされます。

スキーマでのデータ品質モニタリングの有効化

スキーマでデータ品質モニタリングを有効にするには、 Unity Catalogでスキーマに移動します。

1. スキーマページで、[ 詳細 ] タブをクリックします。

   

2. 「データ品質モニタリング 」トグルをクリックして有効にします。

   

3. スキャンが開始されます。Databricks 、各テーブルを更新の頻度と同じ頻度で自動的にスキャンし、各テーブルを手動で構成しなくても最新の情報を提供します。 2025 年 9 月 24 日より前に有効になったスキーマの初回スキャンで、 Databricksヒストリカルデータのモニター (「バックテスト」) を実行し、2 週間前にスキーマでデータ品質モニタリングが有効になっていたかのようにテーブルの品質をチェックしました。

4. スキャンが完了すると、検出された品質の問題が出力ログ テーブルに記録され、UI に「知見」が表示されます。 データ品質モニタリング トグルの横にある [結果を表示] をクリックすると、いつでも UI にアクセスできます。

データ品質モニタリング UI

important

2025 年 10 月 7 日、 Databricksデータ品質モニタリングの新バージョンをリリースしました。 その日以降にデータ品質モニタリングが有効になったスキーマには、新しい結果 UI が表示されます。

新しい UI については、 「データ品質モニタリング インシデント UI」を参照してください。

レガシー UI については、 「データ品質モニタリング ダッシュボード (レガシー)」を参照してください。

Databricks では、既存のすべてのスキーマに対して新しいバージョンを有効にすることをお勧めします。

新しいバージョンを有効にするには、 データ品質モニタリングト グルを使用して機能を無効にし、もう一度トグルして再度有効にします。

データ品質モニタリング インシデント UI

スキーマでデータ品質モニタリングを有効にすると、「結果を表示」をクリックして結果ページを開くことができます。 カタログ エクスプローラーまたはガバナンス ハブ (プレビュー) からインシデント ビューにアクセスすることもできます。

インシデント UI には、カタログとスキーマのドロップダウンが含まれています。カタログを選択すると、スキーマのドロップダウンに、データ品質モニタリングが有効になっているそのカタログ内のスキーマが表示されます。

• カタログに対する MANAGE または SELECT 権限を持っている場合は、カタログ レベルでインシデントを表示できます。
• 特定のスキーマのインシデントを表示するには、そのスキーマに対する MANAGE または SELECT 権限も必要です。スキーマを選択すると、そのスキーマのインシデントのみが表示されます。

UI には 2 つの主要なセクションがあります。

1. 概要セクション : 正常なテーブルの割合や現在監視されているスキーマ/テーブルの割合など、選択したスコープの全体的なデータ品質が表示されます。
2. インシデント セクション : 選択したスコープ内のすべての監視対象テーブルのインシデントを一覧表示します。ダウンストリーム影響分析を使用して決定された影響度の高いテーブル上のインシデントをフィルタリングできます。

各インシデント記録には次の詳細が含まれます。

• 理由 : テーブルが新鮮さや完全性に欠けているかどうか。
• 開始 : 最初のインシデントが検出されたタイムスタンプ。
• 影響 : 影響を受けるダウンストリーム テーブルとクエリの数に基づいた、ダウンストリームの影響の定性的な尺度 ( 高 、 中 、または 低 )。
• 根本原因 : 問題の原因となっている上流ジョブに関する情報 (詳細については、ログに記録された結果を確認するを参照してください)。
• レビュー : より詳細なステータスと傾向情報を確認するためのテーブル品質ページへのリンク。

データ品質モニタリング ダッシュボード (レガシー)

注記

データ品質モニタリング ダッシュボードは従来のユーザーのみが利用できました。 現在のバージョンでは、データ品質モニタリング インシデント UIを使用します。

最初のデータ品質モニターの実行により、ログ テーブルから得られた結果と傾向をまとめたダッシュボードが作成されます。ダッシュボードには、スキャンされたスキーマの知見が自動的に入力されます。 このパス: /Shared/Databricks Quality Monitoring/Data Quality Monitoringのワークスペースごとに 1 つのダッシュボードが作成されます。

品質の概要

[ Quality Overview ] タブには、最新の評価に基づいて、スキーマ内のテーブルの最新の品質ステータスの概要が表示されます。

開始するには、分析するスキーマのログテーブルを入力してダッシュボードに入力する必要があります。

ダッシュボードの上部には、スキャン結果の概要が表示されます。

概要の下には、影響別の品質インシデントをリストした表があります。特定された根本原因は、[ root_cause_analysis ] 列に表示されます。

品質インシデント テーブルの下には、長期間更新されていない識別された静的テーブルのテーブルがあります。

テーブル品質の詳細

テーブル品質の詳細 UI を使用すると、傾向を詳しく調査し、スキーマ内の特定のテーブルを分析できます。このビューにはいくつかの方法でアクセスできます。

• インシデント UI (新しいエクスペリエンス) から、インシデント リストのレビュー リンクをクリックします。
• モニタリング ダッシュボード (従来のLakeviewダッシュボード) から、[品質概要] タブのテーブル名をクリックします。
• UC テーブル ビューアー から、テーブル ページの [品質] タブにアクセスします。

どのオプションを選択しても、選択したテーブルの同じテーブル品質詳細ビューが表示されます。

テーブルがある場合、UI には、テーブルの各品質チェックの概要と、各評価タイムスタンプでの予測値と観測値のグラフが表示されます。グラフには、過去 1 週間のデータの結果がプロットされています。

テーブルが品質チェックに失敗した場合、UI には根本原因として特定されたアップストリームジョブも表示されます。

アラートを設定する

出力結果テーブルで Databricks SQL アラートを設定するには、 Databricks アラートUIで次の手順に従います。

important

もちろん、アカウント管理者だけがシステム テーブルにアクセスできますsystem.data_quality_monitoring.table_results 。 他のユーザーがアラートを設定する必要がある場合は、適切なアクセス権を付与してください。

1. アラートのクエリを構成します。

   SQL

   WITH rounded_data AS (
   SELECT
      DATE_TRUNC('HOUR', event_time) AS evaluated_at,
      CONCAT(catalog_name, '.', schema_name, '.', table_name) AS full_table_name,
      status,
      MAX(downstream_impact.num_queries_on_affected_tables) AS impacted_queries,
      MAX(freshness.commit_freshness.predicted_value) AS commit_expected,
      MAX(freshness.commit_freshness.last_value) AS commit_actual,
      MAX(completeness.daily_row_count.min_predicted_value) AS completeness_expected,
      MAX(completeness.daily_row_count.last_value) AS completeness_actual
   FROM system.data_quality_monitoring.table_results
   GROUP BY ALL
   )
   SELECT
      evaluated_at,
      full_table_name,
      status,
      commit_expected,
      commit_actual,
      completeness_expected,
      completeness_actual,
      impacted_queries
   FROM rounded_data
   WHERE
      evaluated_at >= current_timestamp() - INTERVAL 6 HOURS
      -- enter the minimum number of table violations before the alert is triggered
      AND impacted_queries > :min_tables_affected
      AND status = 'Unhealthy';

注記

従来のベータ ジョブの場合、既存のアラート構成でsystem.data_quality_monitoring.table_results <catalog>.<schema>._quality_monitoring_summaryに置き換える必要があります。

2. アラート条件を設定します。

   

3. Eメール テンプレートをカスタマイズします。

   Html

   <h4>The following tables are failing quality checks in the last hour</h4>
   
   <table>
     <tr>
       <td>
         <table>
           <tr>
             <th>Table</th>
             <th>Expected Staleness</th>
             <th>Actual Staleness</th>
             <th>Expected Row Volume</th>
             <th>Actual Row Volume</th>
             <th>Impact (queries)</th>
           </tr>
           
           {<a id='QUERY_RESULT_ROWS'/>}
           <tr>
             <td>{{full_table_name}}</td>
             <td>{{commit_expected}}</td>
             <td>{{commit_actual}}</td>
             <td>{{completeness_expected}}</td>
             <td>{{completeness_actual}}</td>
             <td>{{impacted_queries}}</td>
           </tr>
           
           {{/QUERY_RESULT_ROWS}}
         </table>
       </td>
     </tr>
   </table>

これで、品質問題の下流への影響に基づいてトリガーされるアラートが作成され、アラートをトリガーしたテーブルをデバッグできるようになります。

データ品質モニタリングの無効化

データ品質モニタリングを無効にするには、 [データ品質モニタリング] トグルをクリックして無効にします。 データ品質モニタリングを無効にすると、スキーマ内のテーブルの品質問題のスキャンが停止されます。

制約

Data Quality モニタリングでは、次のものはサポートされていません。

• ビューまたはマテリアライズドビュー。
• 完全性の判断では、ヌル、ゼロ値、NaN の割合などのアカウント メトリクスは考慮されません。

高度なトピック

ログに記録された結果を確認する

もちろん、データ品質モニタリング スキャン結果はsystem.data_quality_monitoring.table_resultsテーブルに保存されます。 このテーブルにアクセスできるのはアカウント管理者のみであり、必要に応じて他のユーザーにアクセス権を付与する必要があります。データ品質モニタリングでは、異常検出結果を保存するためにストレージを使用します。 ストレージに対して料金は請求されません。

important

結果テーブルsystem.data_quality_monitoring.table_resultsには、メタストア全体のすべての結果が含まれており、各カタログのテーブルからのサンプル値も含まれています。このテーブルへのアクセスを許可する場合は注意してください。

結果テーブルの各行は、スキャンされたスキーマ内の 1 つのテーブルに対応します。

テーブルには、次のスキーマがあります。

列名	コンテンツ ( struct データ型の場合)	データ型	説明	サンプルデータ
event_time		timestamp	行が生成された時刻。	2025-06-27T12:00:00
catalog_name		string	カタログの名前。テーブルを識別するために使用されます。	main
schema_name		string	スキーマの名前。テーブルを識別するために使用されます。	default
table_name		string	テーブルの名前。テーブルを識別するために使用されます。	events
catalog_id		string	カタログの安定した ID。	3f1a7d6e-9c59-4b76-8c32-8d4c74e289fe
schema_id		string	スキーマの安定した ID。	3f1a7d6e-9c59-4b76-8c32-8d4c74e289fe
table_id		string	テーブルの安定した ID。	3f1a7d6e-9c59-4b76-8c32-8d4c74e289fe
status		string	テーブル レベルでの統合されたヘルス ステータス。いずれかのチェックまたはグループが異常な場合は "異常" です。	Healthy、Unhealthy、 Unknown
freshness		struct	鮮度チェック。
	status	string	全体的な鮮度の状態。	Unhealthy
	commit_freshness	struct	鮮度チェック結果をコミットします。
completeness		struct	完全性チェックの結果。
	status	string	完全性チェックのステータス。	Unhealthy
	total_row_count	struct	一定期間にわたるテーブル内の行の合計数。
	daily_row_count	struct	毎日追加される行数。
downstream_impact		struct	依存関係グラフに基づくダウンストリームの影響の概要。
	impact_level	int	重大度インジケーター(0 =なし、1 =低、2 =中、3 =高、4 =非常に高い)。	2
	num_downstream_tables	int	影響を受けるダウンストリーム テーブルの数。	5
	num_queries_on_affected_tables	int	過去 30 日間に影響を受けるダウンストリーム テーブルで実行されたクエリの数。	120
root_cause_analysis		struct	問題の原因となっているアップストリームジョブに関する情報。
	upstream_jobs	array	各アップストリームジョブのメタデータ。

commit_freshness配列構造

commit_freshness構造体には次のものが含まれています。

アイテム名	データ型	説明	サンプルデータ
status	string	コミットの鮮度チェックのステータス。	Unhealthy
error_code	string	チェック中にエラーメッセージが発生しました。	FAILED_TO_FIT_MODEL
last_value	timestamp	最後のコミットタイムスタンプ。	2025-06-27T11:30:00
predicted_value	timestamp	テーブルが更新される予定の予測時間。	2025-06-27T11:45:00

total_row_countとdaily_row_count配列構造

total_row_countおよびdaily_row_count構造体には次の内容が含まれます。

アイテム名	データ型	説明	サンプルデータ
status	string	チェックのステータス。	Unhealthy
error_code	string	チェック中にエラーメッセージが発生しました。	FAILED_TO_FIT_MODEL
last_value	int	過去 24 時間に観測された行数。	500
min_predicted_value	int	過去 24 時間の最小予想行数。	10
max_predicted_value	int	過去 24 時間に予想される最大行数。	1000

upstream_jobs配列構造

upstream_jobs列に示されている配列の構造を次の表に示します。

アイテム名	データ型	説明	サンプルデータ
job_id	string	ジョブ ID。	12345
workspace_id	string	ワークスペース ID。	6051921418418893
job_name	string	ジョブの表示名。	daily_refresh
last_run_status	string	最新の実行のステータス。	SUCCESS
run_page_url	string	Databricks ジョブ実行ページの URL。	https://.../runs/123

ダウンストリーム影響情報

ログに記録された結果テーブルでは、列 downstream_impact は次のフィールドを持つ struct です。

フィールド	Type	説明
impact_level	int	データ品質の問題の重大度を示す 1 から 4 までの整数値。値が大きいほど、混乱が大きいことを示します。
num_downstream_tables	int	特定された問題の影響を受ける可能性のあるダウンストリームテーブルの数。
num_queries_on_affected_tables	int	過去 30 日間に影響を受けたテーブルとダウンストリーム テーブルを参照したクエリの合計数。

新鮮さと完全性の評価のための設定 (レガシー)

2025 年 7 月 21 日以降、ジョブ パラメーターの構成は、新しい顧客に対してサポートされなくなります。 ジョブ設定を構成する必要がある場合は、Databricks にお問い合わせください。

ジョブを制御するパラメーター (ジョブの実行頻度やログに記録された結果テーブルの名前など) を編集するには、ジョブ ページの タスク タブでジョブ パラメーターを編集する必要があります。

次のセクションでは、特定の設定について説明します。タスク パラメーターの設定方法については、「 タスク パラメーターの構成」を参照してください。

スケジュールと通知

ジョブのスケジュールをカスタマイズしたり、通知を設定したりするには、ジョブページの 「スケジュールとトリガー 」設定を使用します。 スケジュールとトリガーを使用したジョブの自動化を参照してください。

ロギングテーブルの名前

ロギング・テーブルの名前を変更したり、テーブルを別のスキーマに保存したりするには、ジョブ・タスク・パラメーター logging_table_name を編集し、目的の名前を指定します。ロギング・テーブルを別のスキーマに保存するには、完全な 3 レベルの名前を指定します。

freshnessとcompletenessの評価のカスタマイズ

このセクションのすべてのパラメーターはオプションです。デフォルトでは、データ品質モニタリングは、テーブルの履歴の分析に基づいてしきい値を決定します。

これらのパラメーターは、タスク パラメーター の metric_configs内のフィールドです。 metric_configs の形式は、次のデフォルト値を持つ JSON 文字列です。

JSON

[
  {
    "disable_check": false,
    "tables_to_skip": null,
    "tables_to_scan": null,
    "table_threshold_overrides": null,
    "table_latency_threshold_overrides": null,
    "static_table_threshold_override": null,
    "event_timestamp_col_names": null,
    "metric_type": "FreshnessConfig"
  },
  {
    "disable_check": true,
    "tables_to_skip": null,
    "tables_to_scan": null,
    "table_threshold_overrides": null,
    "metric_type": "CompletenessConfig"
  }
]

次のパラメーターは、 freshness 評価と completeness 評価の両方に使用できます。

フィールド名	説明	例
tables_to_scan	指定したテーブルのみがスキャンされます。	["table_to_scan", "another_table_to_scan"]
tables_to_skip	指定したテーブルは、スキャン中にスキップされます。	["table_to_skip"]
disable_check	スキャンは実行されません。このパラメーターは、 freshness スキャンのみ、または completeness スキャンのみを無効にする場合に使用します。	true, false

次のパラメーターは、 freshness 評価にのみ適用されます。

フィールド名	説明	例
event_timestamp_col_names	スキーマ内のテーブルが持つ可能性のあるタイムスタンプ列のリスト。テーブルにこれらのカラムのいずれかがある場合、このカラムの最大値を超えた場合は Unhealthy マークされます。このパラメーターを使用すると、評価の時間とコストが増加する可能性があります。	["timestamp", "date"]
table_threshold_overrides	テーブル名としきい値 (秒単位) で構成されるディクショナリ。これらのディクショナリは、テーブルを Unhealthyとしてマークするまでの、最後のテーブル更新からの最大間隔を指定します。	{"table_0": 86400}
table_latency_threshold_overrides	テーブル名とレイテンシーしきい値 (秒単位) で構成されるディクショナリで、テーブルを Unhealthyとしてマークするまでのテーブルの最後のタイムスタンプからの最大間隔を指定します。	{"table_1": 3600}
static_table_threshold_override	テーブルが静的テーブル (つまり、更新されなくなったテーブル) と見なされるまでの時間 (秒単位)。	2592000

次のパラメーターは、 completeness 評価にのみ適用されます。

フィールド名	説明	例
table_threshold_overrides	テーブル名とロー・ボリュームのしきい値 (整数として指定) で構成されるディクショナリ。過去 24 時間にテーブルに追加されたロー数が指定したしきい値より小さい場合、そのテーブルは Unhealthyとしてマークされます。	{"table_0": 1000}