データの壊れ方

Posted at 2025-12-14

はじめに

社内の勉強会で『改訂新版［エンジニアのための］データ分析基盤入門＜基本編＞』を読んでいます。先日、7章で扱われるデータ品質管理について議論したところ、この内容はレビュー観点にまとめるのが良いのでは？という話になりました。

レビュー時に参照することで、品質観点のポイントに気付けることを目的としつつ、本記事を執筆します（ゆくゆくは AI に任せたい）。

書籍では、データの品質を6つの要素に分解しています。これらの項目を可視化し、改善することが、データの品質向上につながります。

逆に、これらを満たしていないということは、データの品質になんらかの問題が存在している可能性があるということになります。つまり、6つの要素はそれぞれ、問題のあり方 = データの壊れ方を表現しているともいえます（例えば、このデータは正確性の観点から壊れており、品質に問題がある、のように）。

また、データが劣化する原因については、以下を挙げています。

これは、データが壊れる理由 / 場所を表していると言えます。

データの壊れ方と壊れる理由 / 場所を理解すると、それぞれの組み合わせで、具体的に壊れるケースを想像することがきます。ここでは、壊れ方（データ品質の要素）ごとに、実際にあり得そうな例と、どういうケースの時に気をつければいいか？を考えてみます。

データが実態を表しているかどうかを示す指標。結局のところ、どんなに基本的な用語だとしても、確実に定義を確認することが重要そうです（テスト、メタデータ、I/O時の変換は方法にすぎない）。

観点	典型的な例	気をつけるケース
データの往来	送信側と受信側で単位・スケール・タイムゾーンの解釈がズレる	外部連携、複数サービスを跨ぐ場合
データの変換	集計・丸め・欠損補完（0埋め等）の前後で値が異なる	複雑なSQL（多段CTE）、変換ルールが口頭で共有されている場合
時間の経過	マスタ更新によって過去データの意味が変化する	組織・制度・料金体系など「変わる前提」のドメイン
人的要因	その場しのぎの手修正・例外対応で根拠が追跡できない	運用者が多い、臨時オペレーションが存在する場合

レコードの全カラムに必要な値が存在しているかを示す指標。欠落や欠損が多いと、がんばって作ったテーブルも利用価値がなくなってしまう🥲。

観点	典型的な例	気をつけるケース
データの往来	遅延到着、レート制限によるデータ欠落	バッチ取り込み、外部API、メッセージキュー
データの変換	SQLミス（INNER JOINでレコードが消える、フィルタで削りすぎる）	結合が多いクエリ
時間の経過	保持期間・TTL・アーカイブ方針により古いデータが欠ける	ログ保持、プライバシー対応
人的要因	運用ミスによる投入漏れ、バッチ実行手順の抜け	手動ジョブ、作業手順書が弱い場合

テーブル内、テーブル間で、データのフォーマットや値が一貫しているかを示す指標。Single Source of Truth の徹底が、対策の中心となるでしょうか。

観点	典型的な例	気をつけるケース
データの往来	複数系統に同じデータが配布され、更新タイミングの差で不整合が生じる	同一データを複数DWH・複数マートに配る構成
データの変換	同じ指標を別々のSQLで計算し、仕様の差分によってズレが生じる	指標の再利用・共通化がされていない場合
時間の経過	定義変更後も古い計算と新しい計算が混在している	定義変更が日常的に発生する領域
人的要因	ドメイン知識が共有されず、担当者ごとに解釈が異なり「同じ言葉が違う意味」になる	組織のサイロ化

データが指定のフォーマットに沿っているか否かを示す指標。外部システムとの連動をうまいことしておかないと、急な対応になりかねない。

観点	典型的な例	気をつけるケース
データの往来	型が崩れる（数値→文字列、日付フォーマットの違いなど）	多言語・多通貨・複数地域を扱う場合
データの変換	変換時に enum 外の値が混入、コード変換表の漏れ、桁あふれ、NULL 混入	文字列加工・正規化・マッピング処理が多い場合
時間の経過	外部仕様の変更	基盤データ（マスタ）と連動する箇所
人的要因	手入力による表記ゆれ・禁則値・範囲外データの混入	入力自由度が高いUI、運用現場が広い場合

データが必要なタイミングで、適切な値が適切な場所にあることを示す指標。最新の ID なのかといった基本的な内容はもちろん、性能や SLA の検討といった非機能的な項目についても検討する必要がある。

観点	典型的な例	気をつけるケース
データの往来	外部API遅延、キュー詰まり、ネットワーク問題によりデータ到達が遅れる	ストリーミング連携、締め時間がある業務では特に重要
データの変換	重い変換処理（巨大JOIN、全表スキャン）により処理時間が増大する	データ量増加を前提とするパイプライン
時間の経過	データ量成長・テーブル肥大化により処理が徐々に遅くなる（性能劣化の典型）	スケール見積もりが無い場合に発生しやすい
人的要因	手動承認・手動実行がボトルネックになり、担当者不在で復旧が遅れる	運用フローに人が挟まるとSLAが崩れやすい

データが重複していないかを示す指標。パーティションが絡むと一層注意。

観点	典型的な例	気をつけるケース
データの往来	再送・リトライにより同一イベントが複数回届く（at-least-once 配信の宿命）	イベントログ、キュー、バッチ再実行がある構成では最重点
データの変換	重複排除ロジックが曖昧（DISTINCT の乱用、キー設計が弱い）	粒度が曖昧な設計ほど事故が起きやすい
時間の経過	ID体系変更やキー再採番による衝突、過去分バックフィルでの二重計上	長期運用・再計算・バックフィルがあると増えやすい
人的要因	同じジョブを二度実行、手動補正を二重投入	手動運用が残っていると最終的に事故りやすい

もしパイプラインを設計しているなら、上記に記載した「気をつけるケース」に該当しないかを見て、データが壊れる箇所はないだろうか？と考えるのが良いと思いました。