異常検出

備考

ベータ版

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

このページでは、異常検出とは何か、監視対象、およびその使用方法について説明します。

異常検出とは?

レイクハウスモニタリング anomaly detection を使用すると、スキーマ内のすべてのテーブルのデータ品質を簡単に監視できます。 Databricks は、データインテリジェンスを活用してデータ品質を自動的に評価し、特に各テーブルの鮮度と完全性を評価します。健康指標には質の高い知見が入力されるため、消費者は健康を一目で理解できます。 データ所有者は、ログ記録テーブルとダッシュボードにアクセスできるため、スキーマ全体の異常を迅速に特定、アラートを設定し、解決できます。

必要条件

• Unity Catalog対応ワークスペースであること。
• サーバレス コンピュート enabled. 手順については、 サーバレス コンピュートへの接続を参照してください。
• スキーマで異常検出を有効にするには、カタログスキーマに対する MANAGE SCHEMA または MANAGE CATALOG 権限が必要です。

異常検出はどのように機能しますか?

Databricks は、有効なテーブルの 鮮度 と 完全性 を監視します。

鮮度 とは、テーブルが更新された最近の日付を指します。異常検出は、テーブルへのコミットの履歴を分析し、テーブルごとのモデルを構築して、次のコミットの時間を予測します。 コミットが異常に遅延した場合、テーブルは古いものとしてマークされます。時系列テーブルの場合、イベント時間列を指定できます。次に、異常検出は、データの取り込みレイテンシ (コミット時間とイベント時間の差として定義される) が異常に長いかどうかを検出します。

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

スキーマで異常検出を有効にする

スキーマで異常検出を有効にするには、Unity Catalog でスキーマに移動します。

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

   

2. [異常検出 ] トグルをクリックして有効にします。

   

3. Databricks のスケジュールされたジョブが開始されてスキーマがスキャンされ、ダイアログが表示されます。ジョブの進行状況を表示するには、ダイアログで [ 結果の表示 ] をクリックします。ジョブが完了すると、検出された異常が 出力ログ テーブルに記録されます。また、異常検出トグルの横にある [設定 ] をクリックして、いつでもダイアログにアクセスできます。

   

4. デフォルトでは、ジョブは 6 時間ごとに実行されます。この設定を変更するには、「 鮮度と完全性の評価のパラメーターの設定」を参照してください。

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

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

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

列名	タイプ	説明
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	マップ	このフィールドには、テーブルのステータスを決定するために使用された値が表示されます。詳細については、 デバッグ情報を参照してください。
error_message	string	status が Unknownの場合は、デバッグに役立つ追加情報がここに表示されます。
table_lineage_link	string	カタログエクスプローラのテーブルリネージタブへのリンクは、 Unhealthy テーブルの根本原因の調査に役立ちます。
downstream_impact	構造体	異常がダウンストリーム資産に与える影響。詳細については、「 ダウンストリーム影響情報」を参照してください。

デバッグ情報

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

Bash

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

例えば：

JSON

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

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

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

フィールド	タイプ	説明
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_logging	true に設定すると、ジョブ実行の結果はロギングテーブルに保存されません。	true, false
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}

異常検出を無効にする

異常検出を無効にするには、[ 異常検出 ] トグルをクリックして無効にします。異常検出ジョブは削除され、すべての異常検出テーブルと情報が削除されます。

異常検出に関するフィードバックを提供するために、Eメール lakehouse-monitoring-feedback@databricks.com.

制約

異常検出では、次のものはサポートされていません。

• Views, マテリアライズドビュー, またはストリーミングテーブル.
• 外部テーブル or フォーリンテーブル.
• 過去 30 日間にコミットが 2 つ未満のテーブル。
• 完全性の判断では、ヌル、ゼロ値、NaN の割合などのアカウント メトリクスは考慮されません。