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 ヒストリカルデータのモニターも実行して (「バックテスト」)、データ品質モニタリングが 2 週間前にスキーマで有効になっているかのようにテーブルの品質を確認します。これらの結果は、ロギングテーブルに記録されます。
デフォルトでは、ジョブは 1 時間ごとに実行されます。この設定を変更するには、「鮮度と完全性の評価のパラメーターの設定」を参照してください。
ジョブの進行状況を表示したり、ジョブを設定したりするには、トグルの横にある歯車アイコンをクリックします。表示されるダイアログで、[ 詳細の表示 ] をクリックします。
ジョブが完了すると、検出された品質の問題が出力ログテーブルに記録され、データ品質ダッシュボードに知見が入力されます。ダッシュボードには、 Data Quality モニタリング のトグルの横にある [ 結果の表示 ] をクリックすることで、いつでもアクセスできます。

Data Quality モニタリングダッシュボード

データ品質モニターを初めて実行すると、ログテーブルから派生した結果と傾向を要約するダッシュボードが作成されます。ジョブの実行には、ダッシュボードにアクセスするために使用できるボタンが表示されます。ダッシュボードには、スキャンされたスキーマの知見が自動的に入力されます。ワークスペースごとに 1 つのダッシュボードが /Shared/Databricks Quality Monitoring/Data Quality Monitoringパスに作成されます。

品質の概要

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

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

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

ダッシュボードの「品質概要」タブにあるデータ品質モニタースキーマの概要。

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

ダッシュボードの [品質の概要] タブにある影響別の品質インシデント。

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

テーブル品質の詳細

テーブル品質の詳細 UIを使用すると、トレンドを深く掘り下げ、スキーマ内の特定のテーブルを分析できます。UI にアクセスするには、品質概要ダッシュボードでテーブル名をクリックするか (前のスクリーンショットのクリック可能なリンクを参照)、UC テーブルビューアの [品質] タブにアクセスします。

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

データ品質モニターのテーブル品質詳細 UI。

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

テーブル品質の詳細 UI の根本原因テーブル。

ヘルスインジケーターの表示

Data Quality モニタリングは、データ利用者が使用するテーブルのデータ鮮度をすばやく視覚的に確認できるようにします。

スキーマページの概要タブで、最新の鮮度スキャンに合格したテーブルは緑色の点でマークされます。スキャンに失敗したテーブルは、オレンジ色の点で表示されます。

カタログエクスプローラのスキーマ概要ページには、品質合格マークのテーブルが表示されます。

ドットをクリックすると、最新のスキャンの時間とステータスが表示されます。

健康状態の詳細を示すポップアップ。

データ所有者は、品質に基づいてテーブルを並べ替えることで、スキーマの全体的な正常性を簡単に評価できます。テーブルリストの右上にある ソート メニューを使用して、テーブルを品質でソートします。

テーブル・ページの概要タブにある品質インジケータには、テーブルのステータスが表示され、最新のスキャンで特定された異常がリストされます。

カタログエクスプローラーのテーブルページにある健康品質インジケーター。

アラートを設定する

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

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

SQL
WITH rounded_data AS (
  SELECT
    DATE_TRUNC('HOUR', evaluated_at) AS evaluated_at,
    CONCAT(catalog, ".", schema, ".", table_name) as full_table_name,
    table_name,
    status,
    MAX(downstream_impact.num_queries_on_affected_tables) AS impacted_queries,
    MAX(CASE WHEN quality_check_type = 'Freshness' AND additional_debug_info.commit_staleness.expectation IS NOT NULL
        THEN additional_debug_info.commit_staleness.expectation END) AS commit_expected,
    MAX(CASE WHEN quality_check_type = 'Freshness' AND additional_debug_info.commit_staleness.actual_value IS NOT NULL
        THEN additional_debug_info.commit_staleness.actual_value END) AS commit_actual,
    MAX(CASE WHEN quality_check_type = 'Freshness' AND additional_debug_info.event_staleness.expectation IS NOT NULL
        THEN additional_debug_info.event_staleness.expectation END) AS event_expected,
    MAX(CASE WHEN quality_check_type = 'Freshness' AND additional_debug_info.event_staleness.actual_value IS NOT NULL
        THEN additional_debug_info.event_staleness.actual_value END) AS event_actual,
    MAX(CASE WHEN quality_check_type = 'Completeness' AND additional_debug_info.daily_row_count.expectation IS NOT NULL
        THEN additional_debug_info.daily_row_count.expectation END) AS completeness_expected,
    MAX(CASE WHEN quality_check_type = 'Completeness' AND additional_debug_info.daily_row_count.actual_value IS NOT NULL
        THEN additional_debug_info.daily_row_count.actual_value END) AS completeness_actual
  FROM <catalog>.<schema>._quality_monitoring_summary
  GROUP BY ALL
)
SELECT
  evaluated_at,
  full_table_name,
  status,
  commit_expected,
  commit_actual,
  event_expected,
  event_actual,
  completeness_expected,
  completeness_actual,
  impacted_queries,
  CONCAT("<link-to-dashboard>&f_table-quality-details~table-quality-details-logging-table-name=<catalog>.<schema>._quality_monitoring_summary&f_table-quality-details~9d146eba=", table_name) AS dash_link
FROM rounded_data
WHERE
  evaluated_at >= current_timestamp() - INTERVAL 6 HOUR AND
  -- enter the minimum number of table violations before the alert is triggered
  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 の割合などのアカウントメトリクスは考慮されません。
完全性のヘルス指標
イベントベースの鮮度または完全性のための「バックテスト」

高度なトピック

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

デフォルトでは、データ品質モニタリング・スキャンの結果は、データ品質モニタリングを有効にしたユーザーのみがアクセスできる _quality_monitoring_summary という名前のテーブルのスキーマに保存されます。ログテーブルの名前または場所を構成するには、「鮮度と完全性の評価のためのパラメーターの設定」を参照してください。

このテーブルには、次の情報が含まれています。

列名	Type	説明
`evaluated_at`	timestamp	スキャン実行の開始時刻。
`catalog`	string	スキャンが実行されたスキーマを含むカタログ。
`schema`	string	スキャンが実行されたスキーマ。
`table_name`	string	スキャンされたテーブルの名前。
`quality_check_type`	string	`Freshness` または `Completeness`
`status`	string	品質チェックの結果。`Healthy`、 `Unhealthy`、 `Unknown`のいずれか。結果が `Unknown`の場合は、 `error_message` で詳細を参照してください。
`additional_debug_info`	map	このフィールドには、テーブルのステータスを決定するために使用された値が表示されます。詳細については、デバッグ情報を参照してください。
`error_message`	string	`status` が `Unknown`の場合は、デバッグに役立つ追加情報がここに表示されます。
`table_lineage_link`	string	カタログエクスプローラのテーブルリネージタブへのリンクは、 `Unhealthy` テーブルの根本原因の調査に役立ちます。
`downstream_impact`	struct	特定されたデータ品質の問題が下流の資産に与える影響。詳細については、「ダウンストリーム影響情報」を参照してください。

デバッグ情報

ログに記録された結果テーブルの列 additional_debug_info には、次の形式で情報が表示されます。

Bash
[
  <metric_name>:
    actual_value: <value> ,
    expectation: “actual value < [predicted_value]”
    is_violated: true/false,
    error_code: <error_code>
    from_backtesting: true/false
    ...
]

例えば：

JSON
{
  commit_staleness:
    actual_value: "31 min"
    expectation: "actual_value < 1 day"
    is_violated: "false"
    error_code: "None"
    from_backtesting: "false"
}

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

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

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

鮮度と完全性の評価のためのパラメーターを設定する

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

データ品質モニタリングジョブを表示するジョブページ。

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

スケジュールと通知

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

ロギングテーブルの名前

ロギング・テーブルの名前を変更したり、テーブルを別のスキーマに保存したりするには、ジョブ・タスク・パラメーター 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}`

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

必要条件​

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

データ品質モニターはどのくらいの頻度で実行されますか?​

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

Data Quality モニタリングダッシュボード​

品質の概要​

テーブル品質の詳細​

ヘルス インジケーターの表示​

アラートを設定する​

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

制約​

高度なトピック​

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

デバッグ情報​

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

鮮度と完全性の評価のためのパラメーターを設定する​

スケジュールと通知​

ロギングテーブルの名前​

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