概要

Data Observability のモニターは、季節性、傾向、ユーザーのフィードバックから学習する異常検知を使用して、データの遅延、不完全なロード、予期しない値の変化を、それらがダウンストリームのダッシュボード、AI アプリケーション、またはビジネス上の意思決定に影響を与える前の段階で捕捉します。エンドツーエンドのデータおよびコードリネージとこれらのモニターを組み合わせて利用すると、チームが問題を早期に検出し、ダウンストリームへの影響を評価し、適切な所有者にルーティングする上で役立ちます。

Data Observability のモニターでは以下のメトリクスタイプがサポートされています。

テーブルレベルのメトリクスタイプ:

列レベルのメトリクスタイプ:

Datadog は、利用可能な場合にはウェアハウスシステムのメタデータ (例: INFORMATION_SCHEMA) から行数や鮮度などのメトリクスを収集します。これにより、ウェアハウスに対するクエリの実行が回避され、コンピューティングコストが削減されます。すべてのウェアハウスがシステムメタデータを公開しているわけではありません。システムメタデータから収集できないメトリクスについては、モニターがウェアハウスに対して直接クエリを実行し、値を計算します。

Data Observability のモニターを使用するには、少なくとも 1 つのサポートされているデータウェアハウス (例: Snowflake、Databricks、BigQuery など) で Quality Monitoring を設定する必要があります。

Data Observability は、モニター作成フロー の最初のステップで選択される 4 つのモニタータイプを提供します。

特に記載がない限り、以下のセクションではデータ品質モニタータイプについて説明します。

モニターの作成

Datadog で Data Observability モニターを作成するには、[Data Observability] > [Monitors] (モニター) > [New Monitor] (モニターの新規作成) または [Monitors] (モニター) > [New Monitor] (モニターの新規作成) > [Data Observability] に移動します。既存のすべての Data Observability モニターを表示するには、[Data Observability Monitors] ページ を参照してください。

監視するデータの選択

まず、Table レベルと Column レベルのどちらを監視するかを選択します。

次に [Edit] (編集) タブを使用して、検索フィールドに key:value フィルターを入力し、テーブル、ビュー、または列を検索します。

名前または場所でのフィルタリング:

タグでのフィルタリング:

タグキーをフィルターキーとして使用して、データアセットに適用されているタグでフィルタリングします。たとえば、アセットに owner、platform、または environment というタグが付いている場合、それらのタグを直接検索します。

タグフィルターでは、名前フィルターと同様に * ワイルドカードと引用符がサポートされています (例: owner:data-* または platform:"Snowflake Prod")。

計算属性でのフィルタリング:

各自専用のタグの他に、Datadog はデータアセットの属性を計算し、その属性に基づいてフィルタリングできます。利用可能な計算属性は次のとおりです。

lineage_score は連続的な値をとるのではなく、上記にリストされた個別の階層に分類されるため、いずれかの正確な値でフィルタリングします。単一の階層と一致するか、または OR を使用して階層を組み合わせます。たとえば、lineage_score:1.00 は最も依存されているアセットを返し、lineage_score:(0.90 OR 1.00) は上位 2 つの階層を返します。

これらのフィルターを AND またはOR と組み合わせるか、括弧を使用して条件をグループ化するか、または - を先頭に付けて除外します。

例:

リネージ関係でのフィルタリング:

選択範囲を、リネージグラフ内で別のアセットに接続されているアセットに絞り込むには、[Add Relation Filter] (関係フィルターを追加) をクリックします。[Upstream of] (次のアセットのアップストリーム:) または [Downstream of] (次のアセットのダウンストリーム:) を選択して、特定のアセットを選択するか、または同じ key:value フィルターを使用して一連のアセットを一致させます。たとえば、重要なダッシュボードのアップストリームにあるすべてのテーブルや、特定のソーステーブルのダウンストリームにあるすべての列を監視します。

階層関係でのフィルタリング:

選択範囲を、リネージグラフ内の別のアセットの親アセットまたは子アセットに絞り込むには、[Add Relation Filter] (関係フィルターを追加) をクリックします。[Parent of] (次のアセットの親:) または [Child of] (次のアセットの子:) を選択して、特定のアセットを選択するか、または同じ key:value フィルターを使用して一連のアセットを一致させます。たとえば、revenue 列を含んでいるすべてのテーブルや、重要なスキーマ内にあるすべてのテーブルを監視します。

1 つのモニターで最大 5,000 個のテーブル、ビュー、または列を追跡できます。この制限を増やすことはできません。クエリとの一致の数がこれを上回る場合は、複数のモニターに分割してください。

メトリクスタイプの選択

メトリクスタイプは、追跡するデータ品質シグナルに基づいて選択します。各モニターは 1 つのメトリクスタイプを追跡します。

[Freshness] (鮮度) メトリクスタイプは、データが期待される時間枠内に更新されなかった状況を検出します。これを使用して、古いデータがダウンストリームのレポートやモデルに影響を与える前の段階でそのデータを捕捉します。

• Table freshness (テーブルの鮮度は、最後に更新された時点からの経過時間を追跡します。テーブルの鮮度は、ビューでは使用できません。また、システムメタデータ内のテーブルの更新タイムスタンプを提供しないデータウェアハウスでも使用できません。代わりに列レベルの鮮度を使用してください。
• Column freshness (列の鮮度) は、日時列に表示される最新の日付を追跡します。

[Row Count] (行数) メトリクスタイプは、テーブル内の行数を追跡します。これを使用して、予期しないデータの減少や急増を検出します。このような減少や急増は、パイプラインの障害やアップストリームの問題を示している可能性があります。

[Column] (列) メトリクスタイプは、列レベルのメトリクスを追跡して、データのドリフトや品質低下を検出します。以下のいずれかを選択します。

メトリクス	説明
Uniqueness (一意性)	列内の値のうち、一意の値の割合。
Nullness (null 値)	列内の値のうち、null である値の割合。
Cardinality (カーディナリティ)	列内の個別の値の数。
[Percent Zero] (ゼロの割合)	列内の値のうち、ゼロと等しい値の割合。
Percent Negative (負の値の割合)	列内の値のうち、負の値の割合。
Min (最小値)	列内のすべての値の最小値。
Max (最大値)	列内のすべての値の最大値。
Mean (平均値)	列内のすべての値の平均値。
Standard Deviation (標準偏差)	列内の値のばらつきの尺度。
Sum (合計)	列内のすべての値の合計。

一部の列メトリクスは、特定の列タイプでのみ利用可能です。数値メトリクス ([Percent Zero] (ゼロの割合)、[Percent Negative] (負の値の割合)、[Min] (最小値)、[Max] (最大値)、[Mean] (平均値)、[Standard Deviation] (標準偏差)、[Sum] (合計値)) には、数値列が必要です。

[Custom SQL] (カスタム SQL) メトリクスタイプは、ユーザーが定義した SQL クエリから返されるカスタムメトリクス値を追跡します。組み込みのメトリクスタイプでは対応できないユースケース (ビジネス固有のデータ品質ルールの監視など) に使用します。

1. クエリから返される値を表すモデルタイプを選択します。
   • Default (デフォルト): クエリはスカラー値を返します。ほとんどの場合はこれを使用します。
   • Freshness (鮮度): クエリは、現在時刻とイベントの最終発生時刻の差 (秒単位) を返します。
   • Percentage (パーセンテージ): クエリは 0 から 100 の間のパーセンテージ値を返します。
2. エイリアスが設定された単一値を dd_value として返す SQL クエリを作成します (例: SELECT COUNT(*) as dd_value FROM ANALYTICS_DB.PROD.ORDERS WHERE STATUS = 'FAILED')。
3. [Validate] (検証) をクリックしてクエリ構文を検証します。

SQL クエリに GROUP BY 句が含まれている場合は、グループ化する列をカンマ区切りのリストとして [Group by] (グループ化) フィールドに指定します (例: column_a, column_b)。各グループは個別に評価されます。

注: 請求のため、各カスタム SQL モニターは個別の監視対象テーブルとしてカウントされます。

モニターの構成

検出方法

検出方法を選択します。

• Anomalies (異常): メトリクスが期待されるパターンから逸脱したときにアラートを送信します。しきい値は不要です。異常モデルのトレーニングには、基になるデータの更新頻度に応じて 3 〜 7 日間 (週末を含む) かかります。トレーニング期間中は、モニターはアラートをトリガーせず、青色で表示されます。トレーニング完了後、モニターは正常な状態では緑色で、外れ値の状態では赤色で表示されます。
• Thresholds (しきい値): メトリクスが一定の値を超えたときにアラートをトリガーします。比較演算子 (above、above or equal to、below、below or equal to、equal to、または not equal to) を設定し、[Critical] (重大) しきい値 (必須) を指定します。また、必要に応じて [Warning] (警告) しきい値を定義します。詳細については、モニターを構成 を参照してください。

WHERE 句

WHERE 句を追加して、モニターが評価するデータをフィルタリングします。これは、特定のデータセグメントや最近のレコードのみを監視する場合に便利です。たとえば、次のようにします。

• created_at >= DATEADD(day, -7, CURRENT_TIMESTAMP()) — 過去 1 週間の行のみを監視します。
• region = 'US' — 特定のリージョンのデータのみを監視します。

グループ化

Group by 句を追加して、単一モニターを複数のグループに分割し、それぞれを個別に評価できます。たとえば、行数モニターを REGION 列でグループ化すると、地域別に個別のアラートが生成されます。

モニターあたりのデフォルトの上限は 500 グループです。この制限を増やすには、サポートにお問い合わせください。

データがない

[If data is missing to evaluate] (評価対象データがない場合) ドロップダウンメニューで、評価対象のデータがない場合にモニターが報告する内容を選択します。

モデル構成

[Anomalies] (異常) 検出方法を使用するモニターの場合、[Model configuration] (モデル構成) を展開してモデルの動作を調整します。

モニターのスケジュール

モニターがデータを評価する頻度を設定します。

• Scheduled (スケジュール済み): モニターは一定の間隔で実行されます。[Run this monitor] (このモニターの実行間隔) で、[Hourly] (1 時間)、[Every 3 hours] (3 時間)、[Every 6 hours] (6 時間)、[Every 12 hours] (12 時間)、[Daily] (1 日)、または [Custom schedule] (カスタムスケジュール) を選択します。
• [Manual] (手動)(プレビュー): モニターは、プログラムによってトリガーされた場合にのみ実行されます。Data Observability API を使用して、スケジュールに沿ってこれらのモニターをトリガーし、モデリングに役立つ十分な履歴データを蓄積します。UI では行数や鮮度などのデフォルトメトリクスがサポートされていないため、このワークフローはカスタムメトリクスまたはカラムレベルのメトリクスに適用されます。

独自のスケジュールを定義するには、[Custom schedule] (カスタムスケジュール) を選択して cron 式を入力します。カスタムスケジュールは、最短で 15 分間隔で実行できます。[Preview times] (時間のプレビュー) には次回以降のいくつかの実行がローカルタイムゾーンで表示されるため、この式を保存前に確認できます。

アラート条件の設定

集計タイプを選択します。

• Simple Alert (シンプルなアラート): 監視対象のテーブルまたは列が条件に一致したときに、通知を 1 回送信します。
• Multi Alert (複数のアラート): 条件に一致するグループごとにアラートを送信します。アラートの粒度を制御するには、グループ化の基準となるディメンション (例: table、schema、database) をカスタマイズします。たとえば、schema でグループ化すると、スキーマごとに 1 つのアラートのみが送信され、影響を受けるすべてのテーブルがまとめられるため、ノイズが軽減されます。

通知の例

{{#is_alert}}
Data quality issue detected on {{database.name}}.{{schema.name}}.{{table.name}}:
current value {{value}} has breached the threshold of {{threshold}}.
{{/is_alert}}

{{#is_recovery}}
Data quality issue on {{database.name}}.{{schema.name}}.{{table.name}} has recovered.
Current value {{value}} is within the threshold of {{threshold}}.
{{/is_recovery}}

{{#is_alert}}
Anomaly detected on {{database.name}}.{{schema.name}}.{{table.name}}:
observed value {{observed}} is outside the expected range of {{lower_bound}} to {{upper_bound}}
(predicted: {{predicted}}).
{{/is_alert}}

{{#is_recovery}}
{{database.name}}.{{schema.name}}.{{table.name}} has recovered.
Observed value {{observed}} is within the expected range.
{{/is_recovery}}

ソース/ターゲットモニター

ソース/ターゲットモニターは、2 つのデータアセットで同じメトリクスを比較し、この 2 つの値が乖離したときにアラートを送信します。その他の Data Observability モニターは、単一アセットが最新であるか、または完了しているかを追跡します。ソース/ターゲットモニターは、宛先に到達したコピーがソースから移動されたコピーと一致しているかどうかを追跡します。

パイプラインでデータがシステム間を移動する場合、部分的な失敗が失敗として認識されることはほとんどありません。100,000 行がソーステーブルから移動され、宛先に到達した行が 99,850 行の場合、行数モニターは宛先の行数のみを妥当な値として認識します。2 つのアセットを比較することで、その差異が明らかになります。

ソース/ターゲットモニターは次の目的に使用できます。

• Postgres から Databricks へのレプリケーションを検証する。
• 同じ Snowflake アカウント内の 2 つのデータベース (例: 品質データベースと本番データベース) を照合する。
• カットオーバー前に Redshift から BigQuery への移行を検証する。この場合、両方のシステムを並行して実行し、それらが一致することを確認する。
• 変換によって、入力と出力の間で行が削除されていないことを確認する。

ソース/ターゲットモニターは、GovCloud を除くすべてのリージョンで利用可能です。

ソース/ターゲットモニターの作成

1. [Monitors] (モニター) > [New Monitor] (モニターの新規作成) に移動し、[Source to Target] (ソース/ターゲット) を選択します。
2. [Choose source] (ソースを選択) で、ソースデータを保持するデータウェアハウスを選択し、比較するデータを選択します。
3. [Choose target] (ターゲットを選択) で、宛先について同様の操作を行います。ソースとターゲットは、異なるデータウェアハウスにあっても、同じデータウェアハウスにあっても構いません。
4. [Select your metric type] (メトリクスタイプを選択) で、比較するメトリクスを選択します。ソース/ターゲットモニターでは、他の Data Observability モニターと同じメトリクスタイプ (行数、鮮度、null 値、、一意性、カーディナリティ、Custom SQL (カスタム SQL) など) がサポートされています。
5. 比較の表現方法を制御するため、[Format] (形式) を設定します。
   • Difference (差分): ターゲットの値からソースの値を引いた値。負の値は、ターゲットがソースより少ないことを意味します。
   • % Difference (差分 %): 同じ差分をソースの値に対する割合として示します。
6. モニターを構成の説明に従って、検出方法、スケジュール、および通知を構成します。

[Preview Monitor Evaluation] (モニターのプレビュー) パネルには、指定したソースとターゲット、および選択したメトリクスのプレビューが表示されます。

監視対象のアセットはターゲットであるため、モニターはターゲットのステータスページに表示されます。

カスタムメトリクスの比較

メトリクスタイプが [Custom SQL] (カスタム SQL) の場合、ソースとターゲットそれぞれにクエリを 1 つずつ提供します。このメトリクスタイプでは、WHERE 句は受け入れられません。各クエリにフィルタリングを含めます。

評価

ソースとターゲットの差分は固有のメトリクスとして記録されるため、ソース/ターゲットモニターは、異常検知などの他の Data Observability モニターと同じ検出方法で評価されます。両側が同期されたスケジュールで測定されるため、各ウェアハウスのデフォルトの収集頻度に従うのではなく、2 つの値が同時にキャプチャされます。

スキーマ変更モニター

スキーマ変更モニターは、データの内容が変更されたときではなく、データの構造が変更されたときにアラートを送信します。これを使用して、列の削除、名前変更、または別のデータ型への切り替えなどのアップストリームの変更を、この変更によってダウンストリームのパイプラインやダッシュボードが破損する前の段階で捕捉します。

スキーマ変更モニターは、データベース、スキーマ、テーブル、および列で 4 種類の変更を検出します。

スキーマ変更は、Snowflake、BigQuery、Databricks、および Redshift で検出されます。

スキーマ変更モニターの作成

1. [Monitors] (モニター) > [New Monitor] (モニターの新規作成) > [Schema Change] (スキーマ変更) に移動します。
2. [Choose data to monitor] (監視対象データを選択) で、監視するウェアハウスを選択します。
3. モニターを構成の説明に従って通知を構成します。

スキーマ変更モニターは、測定値が境界を超えたことではなく、構造的な変更についてアラートを送信するため、メトリクスタイプや検出方法を使用しません。

検出されたスキーマ変更の確認

モニターを作成せずに Datadog が検出した変更を確認するには、[Data Observability] > [Schema Changes] (スキーマ変更) に移動します。プラットフォーム、アカウント、データベース、スキーマ、または変更タイプでフィルタリングし、エントリを展開して影響を受ける列とそのデータ型を確認します。

変更が検出されるのは、Datadog が次にウェアハウスからスキーマメタデータを収集し、現在の構造を以前に収集した構造と比較する時点です。

モニターの例

境界にアノテーションを付ける

異常検出方法を使用するモニターの場合、境界範囲にアノテーションを付けてフィードバックを提供し、時間の経過とともにモデルを改善できます。インフラストラクチャーメトリクスとは異なり、データ品質メトリクスは多くの場合ビジネス固有であるため、アノテーションを使用して、データにとってどのような動作が正常であるかをモデルに学習させます。

モニターのステータスページで [Annotate Bounds] (境界にアノテーションを付ける) をクリックし、チャート上で時間範囲を選択して、次のいずれかのアノテーションを選択します。

参考資料

役立つドキュメント、リンク、記事:

Data Observability の概要ドキュメント Quality Monitoringドキュメント モニター通知の設定ドキュメント モニターをミュートするダウンタイムのスケジュールドキュメント モニターステータスの参照ドキュメント