← データエンジニアリング 一覧

🎓 レベル：標準　|　重要度：A（必須）

📎 前提：べき等性と再実行　|　関連：SQL変換とdbt・データガバナンスとカタログ

要点（BLUF）

• データ品質は「正しさ・完全さ・一意性・整合性・鮮度」など複数の次元で測る。コードと同じく自動テストで守る。
• テストの基本形は「違反行を数える検査クエリ」。COUNTが0なら合格、1以上なら失敗としてパイプラインを止める（または隔離する）。
• 上流と下流の間で「この列はNULLなし・一意・この値域」を取り決めるのがデータ契約（data contract）。契約をテストにして、壊れたデータの下流流出を未然に防ぐ。

概念 ── 品質の次元

仕組み ── 検査クエリは0を返せば合格

「違反を数える」クエリを並べ、0でなければFAILにします。

-- not_null: emailの欠損
SELECT COUNT(*) FROM customers WHERE email IS NULL;
-- unique: cust_idの重複（総数 - 異なり数）
SELECT COUNT(*) - COUNT(DISTINCT cust_id) FROM customers;
-- accepted_values: 想定外のstatus
SELECT COUNT(*) FROM customers WHERE status NOT IN ('active','churned');

実行結果（実機・SQLite／わざと汚したデータ）:

not_null(email)   : 違反 1 件 -> FAIL
unique(cust_id)   : 違反 1 件 -> FAIL
accepted(status)  : 違反 1 件 -> FAIL

3つとも違反を検出。「違反行を数える」だけで、ほとんどの品質次元はテストにできます。これがdbtテストやGreat Expectationsの中身でもあります（→ SQL変換とdbt）。

設計の勘所 ── どこで・何を・どうするか

flowchart LR
    SRC["取り込み"] --> T1["入口テスト（契約：型・必須・一意）"]
    T1 --> TR["変換"] --> T2["出口テスト（整合・値域・鮮度）"]
    T2 --> SRV["提供"]
    T1 -.失敗.-> STOP["停止 or 隔離（quarantine）"]
    T2 -.失敗.-> STOP

• 入口で契約を検査：取り込み直後に「型・必須・一意」を確認し、契約違反は止める。源の仕様変更を早期に検知できる。
• 失敗時の振る舞い：パイプラインを止める（下流に汚染を流さない）か、違反行だけ隔離テーブルに退避して残りを通すか、要件で選ぶ。
• 観測（observability）：行数・NULL率・鮮度を時系列で監視し、異常を検知する。テスト（既知の規則）＋観測（未知の異常）の両輪。

なぜそうするか ── 下流の信頼を守る

なぜ品質をテストで自動化するのか。壊れたデータは下流（ダッシュボード・ML）に静かに流れ、間違った意思決定を生むからです。しかもデータの破損は、コードのバグより気づきにくい（エラーを出さず“それらしい数字”になる）。だから「契約をテストにして、違反したらパイプラインを止める」ことで、間違った数字が世に出る前に堰き止める。テストが無いパイプラインは、型のないコードと同じで、壊れて初めて気づきます。

⚠️ よくある落とし穴

• 「だいたい合ってる」を目視で確認 → 規模が増えると破綻。検査クエリで自動化。
• 失敗を握りつぶして処理続行 → 汚染が下流へ。止めるか隔離するかを明示的に設計。
• テストを出口だけに置く → 源の異常を取り込んでから気づく。**入口（契約）**にも置く。
• 鮮度テストを忘れる → 「壊れてはいないが更新が止まっている」（パイプライン停止）を見逃す。

対応ラボ

data-engineering-study/labs/04_etl_pipeline.py（PYTHONIOENCODING=utf-8 で実行・not_null/unique/accepted_valuesの検出を確認済み）。

関連

• テストを変換とセットで管理するのが SQL変換とdbt
• 安全な再実行の前提は べき等性と再実行
• 組織的なメタデータ・契約・リネージは データガバナンスとカタログ

← 第4章 ETLとデータパイプライン 目次