analyze-data-quality

関連スキル

KPI フレームワーク、指標の定義、ガードレール、または目標を定義・再設計する場合は、既存データの信頼性を確認するのではなく、$design-kpis を使用してください。

データそのものを調査するのではなく、分析、グラフ、レポート、または提案を品質保証する場合は、$validate-data を使用してください。

データ品質を分析する

データセットが、分析、モデリング、ダッシュボード、実験、または下流のパイプラインに利用できるほど信頼できるかを評価します。想定される用途と粒度を確認し、データの形状に応じて最も価値の高いチェックを実施します。具体的な証拠、分析上のリスク、考えられる原因、および最小限で有効な修正や自動テストを報告します。

ワークフロー

1. 品質に関する質問と運用上の背景を明確にします。

   データセットが何を表すのか、分析の単位、下流での用途、ユーザーが生データ取り込みの品質、変換済みモデルの品質、またはその両方を重視しているのかを確認します。また、比較の基準となるデータ（過去の週、以前のスキーマ、信頼できる参照テーブルなど）も確認します。想定される粒度、主キーまたは候補キー、重要な日付列、タイムゾーンの前提、ドメインルール、許容値、ビジネス上のしきい値を特定します。情報が不足している場合は、慎重に推測し、前提を明記します。

2. 調査可能な分析方法を選びます。

   チェックに SQL または Python が必要な場合は、調査結果の根拠となるコードをユーザーが確認できるよう、コンパニオンノートブックを標準で使用します。専用のノートブックスキャフォールドやリファクタリングのワークフローが役立つ場合は、$jupyter-notebooks を使用します。クエリ可能なテーブルについては、より詳細なチェックを行う前に ~~structured_data を使い、該当するソースコネクターを通じてスキーマ、粒度、サンプル行、クエリルールを確認します。鮮度やリネージのチェックが重要な場合は、~~operations_logs を使用します。

3. 簡潔なプロファイルを作成します。

   行数、列数、列名と型、候補キー、識別子として有力な列の重複率、関連する日付列の最小・最大タイムスタンプ、NULL 率、カテゴリ列として有力な列の個別値の数、測定列の基本的な数値サマリーから始めます。異常を解釈する前に粒度を確認します。品質上の問題に見えるものの多くは、異なる粒度のデータの混在、一部のみのバックフィル、到着の遅いデータ、または重複した結合が原因です。

4. 基本的な品質チェックを実行します。

   データセットとタスクに合ったチェックを選びます。完全性、一意性、妥当性、一貫性、整合性、適時性、データ量、形状について、最も関連性の高いチェックを標準で実行します。件数だけでなく比率を比較し、実際の問題と想定内の変動を区別するうえで役立つ場合は、時間、ソース、国、プラットフォーム、モデルバージョン、またはその他の主要なディメンションごとに分割します。

5. データの形状に特化したチェックを実行します。

   データの形状に合わせてチェックを調整します。

   • イベントデータ：イベント ID の重複、未来のイベントタイムスタンプ、セッションまたはユーザーのカバレッジの欠落、リリース後のイベント構成の急変を確認します。
   • ディメンションテーブル：一意でないビジネスキー、参照先のないサロゲートキー、対応するタイムスタンプを伴わないステータス変更、参照値の予期しない変動を確認します。
   • ファクトテーブル：異なる粒度の混在、負の売上や数量などのあり得ない測定値、ディメンションとの結合による行数の急増、到着の遅いパーティションや一部しか読み込まれていないパーティションを確認します。
   • ML の特徴量テーブルまたはスコアリングテーブル：結果発生後のフィールドによるデータリーク、特徴量のスパース性の急増、モデルや特徴量ストアの変更後の値域の変化、クラスラベルのドリフトを確認します。
   • 実験データ：割り当ての重複、想定を超えたバリアントの不均衡、割り当てのない露出、割り当てタイムスタンプより前のイベントを確認します。

6. 履歴がある場合は、時系列と分布をチェックします。

   ユーザーが「X 日以降」「突然」「最近」「現れ始めたばかり」などと言及した場合は、時系列の診断を優先します。初回確認日、最終確認日、日次または週次の NULL 率の推移、重複率の推移、行数の推移、カテゴリ構成比の変化、分布のドリフト、リリース、移行、インシデント、モデル変更、バックフィル前後の変化点を確認します。

7. 分析上のリスクと考えられる原因を調査します。

   各問題を、下流で生じるリスクと結び付けます。信頼性の高い分析の破綻、意思決定の偏り、結合の破損、ダッシュボードの古さ、実験の誤り、データリーク、信頼性の低いモデル特徴量、誤解を招くセグメントなどが該当します。可能であれば、問題が特定のデータソース、セグメント、パーティション、期間、リリース、移行、バックフィル、または上流パイプラインの変更に限定されるかを特定します。

8. 修正または自動テストを提案します。

   リスクを大幅に低減できる、必要最小限の追加修正、監視、または自動テストを提案します。ルールが安定しており、保守する価値がある場合に限り、自動化を提案します。調査結果の生成にコードを使用した場合は、ノートブックまたはクエリのパスを記載するか保存します。

基準

基本チェック

• 完全性：列ごとの NULL 率、パーティション・セグメント・時間バケットごとの NULL 率、予期しない空文字列やセンチネル値、必須列の入力率。
• 一意性：完全重複行、主キーの重複、複合キーの重複、およびメールアドレスやデバイス ID など、準一意フィールドの一意率。
• 妥当性：型変換後の型への準拠、ID、メールアドレス、URL、列挙値、国コード、タイムスタンプの形式チェック、測定値・割合・件数・日付の範囲チェック、管理された語彙で定められた許可値のチェック。
• 一貫性：フィールド間ルールのチェック、単位や通貨の一貫性、ステータスとタイムスタンプの整合性、異なるデータソースから取得した重複フィールド間の一致。
• 整合性：親子キーのカバレッジ、孤立レコード、予期しない多対多結合、変更履歴付きディメンション結合の破損。
• 適時性：ソースイベント時刻からロード時刻までの鮮度遅延、ロード時刻からレポート時刻までの鮮度遅延、直近のパーティションの欠落、説明のない過去データの書き換えやバックフィル。
• ボリュームと形状：行数の変動、個別値数の変動、分布の変動、主要カテゴリにおける全体に占める割合の変動、新しいカテゴリや消失したカテゴリ。

個別チェックのガイダンス

• 重複とキー：完全重複、主キーの重複、意図した粒度における複合キーの重複、および空白、大文字・小文字、書式、遅延更新に起因する準重複をチェックします。件数、影響を受けた行の割合、重複したキー、および重複が特定の期間、データソース、セグメントに限定されるかを報告します。
• 欠損：許容できるスパース性と完全性の破損を区別します。NULL 率の経時変化、スキーマやパイプラインの変更後に新たに NULL になった列、''、'unknown'、'n/a'、0、-1 などのセンチネル値をチェックします。
• ドメイン妥当性：形式不正な識別子、国コード、タイムスタンプ、不可能な値、許可された値の集合から外れた値、is_cancelled = false なのに cancelled_at が NULL でない場合などのフィールド間の矛盾をチェックします。
• 結合カバレッジ：複数のデータセットが関係する場合、親テーブルに一致しない外部キー、予期しない一対多の件数増加、ディメンションや実験との結合時のカバレッジ低下、および結合前後の行数をチェックします。
• 鮮度とスキーマのドリフト：最近の履歴と比較した行数の変化、重要な日付列の遅延、列の追加・削除・型変更、および上流の変更を示唆するスパース性やカーディナリティの変化をチェックします。
• 外れ値と分布のシフト：Z スコアを使う前に、分位点、MAD、IQR などのロバストな手法を使用します。平均値、中央値、分散、ゼロ率、カテゴリの割合、ロングテールの挙動の急な変化をチェックします。
• データリーク、バックフィル、タイムトラベル：本来存在する前に値が設定された特徴量、未来の日付を持つレコード、遅延到着データによる直近のパーティションの不安定化、注記なしに過去の件数を変えるバックフィルをチェックします。

重大度

• Critical: 信頼された分析、中核となる結合、本番ダッシュボード、または重要な意思決定を破壊するもの。たとえば、粒度の重複、主キーの欠落、本番データの陳腐化などです。
• High: 下流の意思決定に重大なバイアスを与えるもの。たとえば、大規模な NULL の急増、 中核ディメンションにおけるカテゴリのドリフト、ビジネスルール上無効な値、リーク、または結合カバレッジの深刻な損失などです。
• Medium: 局所的または説明可能な問題であっても、ドキュメント化、 監視、または担当者によるフォローアップが必要なもの。
• Low: 見た目の不整合、想定内の疎性、または現在の利用に重大な影響を与えない既知のエッジケース。

解釈を伴わずに生のプロファイリング出力をそのまま出すのはやめてください。各所見を分析上のリスクと想定される影響に結び付けてください。

自動テストのガイダンス

• 自動化の候補として適切なもの: 主キーの一意性、必須カラムの NOT NULL チェック、安定した enum の許容値、参照整合性、 鮮度のしきい値、季節性を考慮した行数またはボリュームの範囲。
• 注意が必要なもの: 変動の大きいプロダクト指標に対するハードコードされた分布しきい値、乱雑なエンティティ解決ユースケースにおける厳密な一意性、遅延到着データが通常である場合の直近パーティション。
• 自動テストは、期待されるルールが安定しており、重要で、保守可能な場合にのみ提案してください。

出力基準

ステークホルダー向けのデータ品質作業では、完了した所見を既定で $build-report に渡し、ランタイムが MCP アプリまたは HTML レポートを生成するようにしてください。ユーザーが明示的に簡潔なインライン回答または別の主要な成果物を求めていない限り、プロファイリング出力、ノートブック、またはチャットのみの所見で止めないでください。以下の構成がレポート内容を定義します。

回答は次の構成でまとめてください:

1. データセットと粒度の概要
2. 実施したチェック
3. 所見
4. 時間的またはトレンドの異常
5. 想定される原因と影響を受けるユースケース
6. 推奨される修正または自動テスト
7. 前提と未解決の質問

各所見には次を含めてください:

• 何が失敗したか
• 証拠: 件数、率、セグメント、日付
• なぜ重要か
• 重大度と信頼度
• 判明している場合の想定原因
• 推奨される修正または自動テスト

コードを使用した場合は、主要な SQL および Python のチェックを含むノートブックを同梱または保存し、ノートブックのパスを簡単に見つけられるようにしてください。

デフォルト

• 網羅的なダンプよりも、小さくシグナルの強いテーブルを優先してください。
• 件数だけでなく率を比較してください。
• 可能な限り、時間および主要セグメントごとにチェックを分割してください。
• 重複または distinct カウントの急増を判断する前に、文字列を正規化してください。
• データが遅れて到着する場合、直近のパーティションは慎重に扱ってください。
• 異常が正当な製品ローンチ、 実験、移行、インシデント、モデル変更、またはバックフィルによって引き起こされた可能性がある場合は、その旨を指摘してください。
• 検査可能な証拠を保持してください: SQL、クエリリンク、ノートブックのパス、ソースパス、 サンプル行、チャート出力、計算メモ。