データ品質と可観測性

「データの品質が悪い」と言うだけでは、何を直せばよいか分かりません。品質はいくつかの観点に分けて、それぞれ測れる形にします。

全部を同じ厳しさで見る必要はありません。そのデータを何に使うか（請求か、傾向を見るだけか）で、どの観点をどこまで守るかを決めます。

データのテストは、コードのテストと違い「今日届いたデータが正しいか」を毎回の実行ごとに確かめるものです。ダッシュボードの数字が間違っていると利用者に言われる前に、自分たちで気づくための仕組みです。

道具：dbt を使っているなら、まず dbt test です。unique・not_null などを YAML に書くだけで使え、自分で SQL を書けば何でもテストにできます（「0行返れば合格」の SELECT を書く）。元のテーブルの鮮度は dbt source freshness で見られます。Great Expectations は Python のライブラリで、「この列は NULL でない」のような期待（expectation）を並べて、DWH に限らずファイルや DataFrame も検査できます。

-- 単独のテスト：返った行が不合格。1週間前の同じ曜日より 50% 以上減った日を見つける
SELECT d.order_date, d.cnt
FROM daily_order_count d
JOIN daily_order_count p ON p.order_date = d.order_date - 7
WHERE d.cnt < p.cnt * 0.5;

止めるか、知らせるか

どこで止めるかが設計の肝です。すべてのテストで止めると、ささいな異常で毎日パイプラインが止まり、結局テストが無視されるようになります。

• 止める（error）：主キーの重複・NULL など、下流の数字が確実に間違うもの。取り込み直後や mart の手前で止めて、壊れたデータを公開しない。
• 知らせるだけ（warn）：件数の変動、まれな値など、判断が要るもの。dbt では severity: warn にできる。
• 隔離する：おかしな行だけ別のテーブルに分けて、残りは流す。

テストは入口（取り込み直後）で早く、出口（mart）で確実にが基本です。上流に近いほど原因が分かりやすく、出口のテストは利用者が見る数字を守ります。失敗の通知には、どのテーブル・どの行が悪いかを確かめる SQL を添えると、対応が速くなります。

テストが全部通っても、元のシステムと数字が合っていないことがあります。取り込みの取りこぼしや、変換の条件の間違いは、テーブルの中だけを見ても分かりません。元のシステムと DWH で、同じ条件の件数と合計を比べます。

-- 日ごとの件数と金額を、元（レプリカから取った集計）と DWH で比べる
SELECT s.order_date,
       s.cnt AS src_cnt, d.cnt AS dwh_cnt,
       s.amount AS src_amount, d.amount AS dwh_amount
FROM src_daily s
FULL OUTER JOIN dwh_daily d USING (order_date)
WHERE s.cnt IS DISTINCT FROM d.cnt
   OR ABS(COALESCE(s.amount, 0) - COALESCE(d.amount, 0)) > 0;

会計や請求に使う数字は、経理が持っている数字とも突き合わせます。「データ基盤の売上」と「会計の売上」の差を毎月説明できる状態にしておくと、利用者の信頼が大きく上がります。

「件数が平常の半分」「NULL の割合が急に増えた」のような異常は、決まった値のテストでは書きにくいので、過去と比べる形で見張ります。

祝日・セール・月末は普段と違って当然なので、知らせが来すぎないように幅を調整し、予定されたイベントの日は除外できるようにしておきます。データの可観測性の製品は、こうした比べ方を自動で学習して知らせてくれます。

テストは「書いたルール」しか見張れません。データの可観測性は、ルールを書いていない異常にも気づけるように、データの状態をいつも計測しておく考え方です。よく見るのは次の5つです。

スキーマの変化とデータ契約

リネージ（データの系譜）があると、「この元テーブルが壊れたら、どのダッシュボードと誰に影響するか」がすぐ分かります。dbt は依存関係からリネージを作れますし、データカタログの製品や OpenLineage という共通の形式もあります。

「データは新しいほうがよい」だけでは、どこまで頑張ればよいか決まりません。利用者と何時までに・どの品質で届けるかを約束し、守れた割合を測ります。考え方は SRE の SLO と同じです。

約束があると、優先順位も決めやすくなります。約束のないテーブルの失敗は翌営業日に直し、約束のあるテーブルは朝のうちに直す、という具合です。

データの障害の対応は、SRE のインシデント対応と同じ考え方で進めます。

• 検知：テスト・監視・利用者からの報告。
• 影響の把握と連絡：リネージで下流を調べ、利用者に「このダッシュボードは今おかしい、いつ直る見込み」を先に知らせる。ダッシュボードに注意書きを出す。
• 止血：壊れたデータを下流に流さない（パイプラインの停止、前日の正しい版に戻す）。
• 原因と修正：上流へたどって原因を見つけ、直してからバックフィルで正しい値に作り直す。
• 振り返り：同じ異常を捕まえるテストを足す。上流の変更が原因ならデータ契約を結ぶ。

利用者への最初の連絡は「どの数字が・いつから・どのくらいおかしいか、次にいつ知らせるか」を短く伝えます。原因が分かるのを待ってから連絡すると、その間に間違った数字で判断されてしまいます。

過去の障害を表にしておくと、新しいテーブルを作るときに「どのテストを入れるか」のチェックリストになります。