Data quality モニタリング
ベータ版
この機能は ベータ版です。
このページでは、Data Quality モニタリングとは何か、何をモニタリングするのか、どのように使用するのかについて説明します。 データ品質モニタリングは、以前は異常検出と呼ばれていました。
データ品質モニタリングに関するフィードバックを提供するために、Eメール lakehouse-monitoring-feedback@databricks.com
.
データ品質モニタリングとは何ですか?
データ品質モニタリングを使用すると、スキーマ内のすべてのテーブルのデータ品質を簡単に監視できます。 Databricks は、データインテリジェンスを活用してデータ品質を自動的に評価し、特に各テーブルの鮮度と完全性を評価します。健康指標には質の高い知見が入力されるため、消費者は健康を一目で理解できます。 データ所有者は、ログ記録テーブルとダッシュボードにアクセスできるため、スキーマ全体の異常を迅速に特定、アラートを設定し、解決できます。
データ品質モニタリング は、 モニターするテーブルを変更したり、これらのテーブルに入力するジョブにオーバーヘッドを追加したりしません。
必要条件
- Unity Catalog対応ワークスペースであること。
- サーバレス コンピュートが有効化されていること。手順については、 サーバレス コンピュートへの接続を参照してください。
- スキーマでデータ品質モニタリングを有効にするには、カタログスキーマに対する MANAGE SCHEMA または MANAGE CATALOG 権限が必要です。
データ品質モニタリングはどのように機能しますか?
Databricks は、有効なテーブルの 鮮度 と 完全性 を監視します。
鮮度 とは、テーブルが更新された最近の日付を指します。Data Quality モニタリングは、テーブルへのコミットの履歴を分析し、テーブルごとのモデルを構築して、次のコミットの時間を予測します。 コミットが異常に遅延した場合、テーブルは古いものとしてマークされます。時系列テーブルの場合、イベント時間列を指定できます。次に、データ品質モニタリングは、データの取り込みレイテンシ (コミット時間とイベント時間の差として定義される) が異常に高いかどうかを検出します。
完全性 とは、過去 24 時間にテーブルに書き込まれると予想される行数を指します。Data Quality モニタリングは、過去の行数を分析し、このデータに基づいて、予想される行数の範囲を予測します。 過去 24 時間にコミットされたローの数がこの範囲の下限より小さい場合、テーブルは未完了としてマークされます。
データ品質モニターはどのくらいの頻度で実行されますか?
デフォルトでは、データ品質モニターは 1 時間ごとに実行されます。各テーブルをスキャンする前に、システムは、テーブルが前回の実行以降に更新されている可能性があるかどうかを確認します。テーブルがまだ更新されていないと予想される場合、スキャンはスキップされます。
スキーマでのデータ品質モニタリングの有効化
スキーマでデータ品質モニタリングを有効にするには、 Unity Catalogでスキーマに移動します。
-
スキーマページで、[ 詳細 ] タブをクリックします。
-
「データ品質モニタリング 」トグルをクリックして有効にします。
-
Databricks ジョブが開始され、スキーマがスキャンされます。Databricks は、更新されるのと同じ頻度で各テーブルを自動的にスキャンするため、各テーブルを手動で設定することなく、最新の知見を得ることができます。 最初のジョブ実行では、 Databricks ヒストリカルデータのモニターも実行して (「バックテスト」)、データ品質モニタリングが 2 週間前にスキーマで有効になっているかのようにテーブルの品質を確認します。 これらの結果は、ロギングテーブルに記録されます。
-
ジョブが完了すると、検出された品質の問題が 出力ログテーブル に記録され、 データ品質ダッシュボードに知見が入力されます。 ダッシュボードには、 Data Quality モニタリング のトグルの横にある [ 結果の表示 ] をクリックすることで、いつでもアクセスできます。
Data Quality モニタリングダッシュボード
データ品質モニターを初めて実行すると、ログ テーブルから派生した結果と傾向を要約するダッシュボードが作成されます。ジョブの実行には、ダッシュボードにアクセスするために使用できるボタンが表示されます。ダッシュボードには、スキャンされたスキーマの知見が自動的に入力されます。 ワークスペースごとに 1 つのダッシュボードが /Shared/Databricks Quality Monitoring/Data Quality Monitoring
パスに作成されます。
品質の概要
[ Quality Overview ] タブには、最新の評価に基づいて、スキーマ内のテーブルの最新の品質ステータスの概要が表示されます。
開始するには、分析するスキーマのログテーブルを入力してダッシュボードに入力する必要があります。
ダッシュボードの上部には、スキャン結果の概要が表示されます。
概要の下には、影響別の品質インシデントをリストした表があります。特定された根本原因は、[ root_cause_analysis
] 列に表示されます。
品質インシデント テーブルの下には、長期間更新されていない識別された静的テーブルのテーブルがあります。
テーブル品質の詳細
テーブル品質の詳細 UIを使用すると、トレンドを深く掘り下げ、スキーマ内の特定のテーブルを分析できます。UI にアクセスするには、品質概要ダッシュボードでテーブル名をクリックするか (前のスクリーンショットのクリック可能なリンクを参照)、UC テーブル ビューアの [品質] タブにアクセスします。
テーブルがある場合、UI には、テーブルの各品質チェックの概要と、各評価タイムスタンプでの予測値と観測値のグラフが表示されます。グラフには、過去 1 週間のデータの結果がプロットされています。
テーブルが品質チェックに失敗した場合、UI には根本原因として特定されたアップストリームジョブも表示されます。
ヘルス インジケーターの表示
Data Quality モニタリングは、データ利用者が使用するテーブルのデータ鮮度をすばやく視覚的に確認できるようにします。
スキーマページの 概要 タブで、最新の鮮度スキャンに合格したテーブルは緑色の点でマークされます。スキャンに失敗したテーブルは、オレンジ色の点で表示されます。
ドットをクリックすると、最新のスキャンの時間とステータスが表示されます。
データ所有者は、品質に基づいてテーブルを並べ替えることで、スキーマの全体的な正常性を簡単に評価できます。テーブルリストの右上にある ソート メニューを使用して、テーブルを品質でソートします。
テーブル・ページの 概要 タブにある 品質 インジケータには、テーブルのステータスが表示され、最新のスキャンで特定された異常がリストされます。
アラートを設定する
出力結果テーブルで Databricks SQL アラートを設定するには、 Databricks アラートUIで次の手順に従います。
-
アラートのクエリを構成します。
SQLWITH 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 <catalog>.<schema>._quality_monitoring_summary
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'; -
アラート条件を設定します。
-
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><a href="{{dash_link}}">{{full_table_name}}</a></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
テーブルに保存されます。 このテーブルにアクセスできるのはアカウント管理者のみであり、必要に応じて他のユーザーにアクセス権を付与する必要があります。
結果テーブルの各行は、スキャンされたスキーマ内の 1 つのテーブルに対応します。
テーブルには、次のスキーマがあります。
列名 | コンテンツ ( | データ型 | 説明 | サンプルデータ |
---|---|---|---|---|
| timestamp | 行が生成された時刻。 |
| |
| string | カタログの名前。テーブルを識別するために使用されます。 |
| |
| string | スキーマの名前。テーブルを識別するために使用されます。 |
| |
| string | テーブルの名前。テーブルを識別するために使用されます。 |
| |
| string | カタログの安定した ID。 |
| |
| string | スキーマの安定した ID。 |
| |
| string | テーブルの安定した ID。 |
| |
| string | テーブル レベルでの統合されたヘルス ステータス。いずれかのチェックまたはグループが異常な場合は "異常" です。 |
| |
| struct | 鮮度チェック。 | ||
| string | 全体的な鮮度の状態。 |
| |
| 鮮度チェック結果をコミットします。 | |||
| struct | 完全性チェックの結果。 | ||
| string | 完全性チェックのステータス。 |
| |
| 一定期間にわたるテーブル内の行の合計数。 | |||
| 毎日追加される行数。 | |||
| struct | 依存関係グラフに基づくダウンストリームの影響の概要。 | ||
| int | 重大度インジケーター(0 =なし、1 =低、2 =中、3 =高、4 =非常に高い)。 | 2 | |
| int | 影響を受けるダウンストリーム テーブルの数。 | 5 | |
| int | 過去 30 日間に影響を受けるダウンストリーム テーブルで実行されたクエリの数。 | 120 | |
| struct | 問題の原因となっているアップストリームジョブに関する情報。 | ||
| 各アップストリームジョブのメタデータ。 |
commit_freshness
配列構造
commit_freshness
構造体には次のものが含まれています。
アイテム名 | データ型 | 説明 | サンプルデータ |
---|---|---|---|
| string | コミットの鮮度チェックのステータス。 |
|
| string | チェック中にエラーメッセージが発生しました。 |
|
| timestamp | 最後のコミットタイムスタンプ。 |
|
| timestamp | テーブルが更新される予定の予測時間。 |
|
total_row_count
とdaily_row_count
配列構造
total_row_count
およびdaily_row_count
構造体には次の内容が含まれます。
アイテム名 | データ型 | 説明 | サンプルデータ |
---|---|---|---|
| string | チェックのステータス。 |
|
| string | チェック中にエラーメッセージが発生しました。 |
|
| int | 過去 24 時間に観測された行数。 |
|
| int | 過去 24 時間の最小予想行数。 |
|
| int | 過去 24 時間に予想される最大行数。 |
|
upstream_jobs
配列構造
upstream_jobs
列に示されている配列の構造を次の表に示します。
アイテム名 | データ型 | 説明 | サンプルデータ |
---|---|---|---|
| string | ジョブ ID。 |
|
| string | ワークスペース ID。 |
|
| string | ジョブの表示名。 |
|
| string | 最新の実行のステータス。 |
|
| string | Databricks ジョブ実行ページの URL。 |
|
デバッグ情報
ログに記録された結果テーブルの列 additional_debug_info
には、次の形式で情報が表示されます。
[
<metric_name>:
actual_value: <value> ,
expectation: “actual value < [predicted_value]”
is_violated: true/false,
error_code: <error_code>
from_backtesting: true/false
...
]
例えば:
{
commit_staleness:
actual_value: "31 min"
expectation: "actual_value < 1 day"
is_violated: "false"
error_code: "None"
from_backtesting: "false"
}
ダウンストリーム影響情報
ログに記録された結果テーブルでは、列 downstream_impact
は次のフィールドを持つ struct
です。
フィールド | Type | 説明 |
---|---|---|
| int | データ品質の問題の重大度を示す 1 から 4 までの整数値。値が大きいほど、混乱が大きいことを示します。 |
| int | 特定された問題の影響を受ける可能性のあるダウンストリームテーブルの数。 |
| int | 過去 30 日間に影響を受けたテーブルとダウンストリーム テーブルを参照したクエリの合計数。 |
Set パラメーター for freshness and completeness evaluation (legacy 顧客のみ)
2025 年 7 月 21 日以降、ジョブ パラメーターの構成は、新しい顧客に対してサポートされなくなります。 ジョブ設定を構成する必要がある場合は、Databricks にお問い合わせください。
ジョブを制御するパラメーター (ジョブの実行頻度やログに記録された結果テーブルの名前など) を編集するには、ジョブ ページの タスク タブでジョブ パラメーターを編集する必要があります。
次のセクションでは、特定の設定について説明します。タスク パラメーターの設定方法については、「 タスク パラメーターの構成」を参照してください。
スケジュールと通知
ジョブのスケジュールをカスタマイズしたり、通知を設定したりするには、ジョブページの 「スケジュールとトリガー 」設定を使用します。 スケジュールとトリガーを使用したジョブの自動化を参照してください。
ロギングテーブルの名前
ロギング・テーブルの名前を変更したり、テーブルを別のスキーマに保存したりするには、ジョブ・タスク・パラメーター logging_table_name
を編集し、目的の名前を指定します。ロギング・テーブルを別のスキーマに保存するには、完全な 3 レベルの名前を指定します。
freshness
とcompleteness
の評価のカスタマイズ
このセクションのすべてのパラメーターはオプションです。デフォルトでは、データ品質モニタリングは、テーブルの履歴の分析に基づいてしきい値を決定します。
これらのパラメーターは、タスク パラメーター の metric_configs
内のフィールドです。 metric_configs
の形式は、次のデフォルト値を持つ 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
評価の両方に使用できます。
フィールド名 | 説明 | 例 |
---|---|---|
| 指定したテーブルのみがスキャンされます。 |
|
| 指定したテーブルは、スキャン中にスキップされます。 |
|
| スキャンは実行されません。このパラメーターは、 |
|
次のパラメーターは、 freshness
評価にのみ適用されます。
フィールド名 | 説明 | 例 |
---|---|---|
| スキーマ内のテーブルが持つ可能性のあるタイムスタンプ列のリスト。テーブルにこれらのカラムのいずれかがある場合、このカラムの最大値を超えた場合は |
|
| テーブル名としきい値 (秒単位) で構成されるディクショナリ。これらのディクショナリは、テーブルを |
|
| テーブル名とレイテンシーしきい値 (秒単位) で構成されるディクショナリで、テーブルを |
|
| テーブルが静的テーブル (つまり、更新されなくなったテーブル) と見なされるまでの時間 (秒単位)。 |
|
次のパラメーターは、 completeness
評価にのみ適用されます。
フィールド名 | 説明 | 例 |
---|---|---|
| テーブル名とロー・ボリュームのしきい値 (整数として指定) で構成されるディクショナリ。過去 24 時間にテーブルに追加されたロー数が指定したしきい値より小さい場合、そのテーブルは |
|