7.8 データ品質とオブザーバビリティ

概要と動機

データ品質とは、利用への適合性です。データが、それに依存する決定、プロダクト、レポートにどれだけ仕えるかの度合い。データセットは、抽象的に良いか悪いかではありません。ある目的に十分に良いか、そうでないかです。マーケティングの集計には問題ない顧客の住所が、法的な通知には不適当かもしれません。その枠づけが重要なのは、会話を「データは完璧か」(決して完璧ではない)から「これから行うことにデータは適しているか」(答えられ、テストできる)へと動かすからです。古典的な次元は、正確性、完全性、一貫性、適時性、妥当性、一意性で、実際の問題のほとんどは、そのうちの一つに帰着します。

大きなチームにとって居心地の悪い真実はこうです。悪いデータは、データがないよりも悪い。データがないときは、それを知っていて、適切な注意を払って進みます。正しく見える間違ったデータがあるとき、偽りの自信をもってそれに基づいて行動します。悪いデータは静かに破損します。経営者が信頼するダッシュボードに流れ込み、それで訓練してその誤りを符号化する機械学習のモデルに流れ込み、数字が画面にそこにあったので誰も疑うことを考えない決定に流れ込みます。被害は拡散し遅れて現れ、だからこそ高価です。誰かが気づく頃には、間違った数字は、取締役会の資料、規制上の提出書類、公的な統計で引用されています。

データオブザーバビリティは、消費者より先にこれを捉える規律です。ソフトウェアのオブザーバビリティとテレメトリ(9.2章)の直接の対応物です。リクエストのレイテンシとエラー率を監視するよう教える同じ本能が、データの鮮度、量、スキーマ、分布を監視するよう教えます。本章は、データ戦略とガバナンス(7.1章)とデータエンジニアリング(7.2章)の上に築かれ、データモデリングとセマンティックレイヤー(7.7章)と責任あるAIと信頼できるAI(6.5章)に供給します。多くの源のシステムを突き合わせる企業と、法定の統計を公表する政府にとって、データの信頼性を、所有者とサービスレベルを伴うエンジニアリングの問題として扱うことは、信頼と、非常に公的な訂正との違いです。

主要原則

データ品質は完璧ではなく利用への適合性です。目的に照らして定義します。
悪いデータは、データがないよりも悪い。決定を静かに破損するからです。
コードをテストするようにデータをテストします。パイプラインにアサーション、期待値、スキーマのチェック。
生産者と消費者の間のコントラクトが、期待を明示的で徹底可能にします。
サービスを観察するのと同じように、鮮度、量、スキーマ、分布を観察します。
系統は、「何かがおかしい」を「これが壊れ、これに影響する」に変えます。
データのインシデントを、所有者、重大度、サービスレベルを伴う本番のインシデントのように扱います。
ダッシュボードの三層下流ではなく、問題が入る所で検知します。

推奨事項

次元で品質を定義し、測定する

漠然とした品質の目標は、漠然とした結果を生みます。品質を測定可能な次元に分け、それぞれに具体的なチェックを付けます。正確性は、値が現実を反映するかを問います(この記録された収益は源の台帳と合うか)。完全性は、期待されるレコードと項目が存在するかを問います(欠けた日はないか、必須の列がヌルでないか)。一貫性は、同じ事実がシステム間で一致するかを問います(財務の顧客数はウェアハウスの数と合うか)。適時性は、データが役立つのに間に合って届くかを問います(昨日のデータは朝のレポートの前に準備できているか)。妥当性は、値がルールと形式に適合するかを問います(すべての通貨コードは実在するか、日付は範囲内か)。一意性は、エンティティが一度だけ現れるかを問います(合計を膨らませる重複した注文はないか)。各データセットに重要な次元を選び、閾値を設定し、時間とともに追跡します。測定しない品質は、当て推量の品質です。

アサーションと期待値でパイプラインをテストする

データは、アプリケーションのコードと同じテストの厳密さに値します。あらゆる段階でデータ検証を使います。不変条件が破られたときにパイプラインを失敗させるアサーションベースのテストと、テーブルの「普通」がどう見えるかを宣言して逸脱に旗を立てる期待値ベースのテスト。主キーが一意でヌルでないこと、外部キーが解決すること、カテゴリーの列が許容される値だけを含むこと、数値の列がもっともらしい範囲に収まること、行数が期待される帯に着地することをアサートします。上流で列が追加、削除、改名、型変更されたときに大きく失敗するスキーマのチェックを加えます。悪い変換がマージ前に捉えられるよう、これらのチェックを継続的インテグレーションで実行し、悪い源が消費者に届く前に捉えられるよう、本番のライブデータに対して再び実行します。目標は早く大きく失敗することです。壊れたパイプラインは、静かに間違ったものより安全だからです。

生産者と消費者の間にデータコントラクトを確立する

データ品質のインシデントのほとんどは、生産するチームが、誰が依存しているか知らずに、スキーマ、意味的な意味、値の慣習を変えるときに、上流で始まります。データコントラクトは、インターフェースを明示的にすることでこれを直します。スキーマ、各項目の意味、許容される値、鮮度の保証、変更のプロセス。生産者はコントラクトにコミットし、消費者はそれに対して築き、破壊的な変更は、月曜の静かな驚きではなく、バージョニングと通知を要します。可能な所では、境界で入ってくるデータをコントラクトに対して検証し、違反を拒否あるいは隔離することで、機械的にコントラクトを徹底します。コントラクトは、暗黙で脆い依存関係を、明示的で交渉された依存関係に変えます。また、所有を可視にし、それは規模では戦いの半分です。

データオブザーバビリティの四つのシグナルを監視する

データオブザーバビリティは、動いているサービスを見る方法(9.2章)に直接対応して、四つのシグナルを見ます。鮮度:データは本来あるべきほど新しいか、パイプラインが止まったか。量:行数は期待される範囲か、テーブルが半分空で届いたか二重に読み込まれたか。スキーマ:構造が予期せず変わったか。分布:値そのものがずれたか、2パーセントがヌルだった列が突然40パーセントがヌルになった、あるいは平均が上流のバグを示す形でずれた。重要なテーブルでこれらのシグナルを計装し、その通常のパターンを学び、違反にアラートを出します。これが、「経営者がダッシュボードが間違って見えると気づいた」を「所有するチームが故障の時点で呼び出された」に置き換える方法です。データの問題の考えうる最悪の検知器は、数字を信頼する下流の人間です。

異常検知を加えるが、アラート疲れに対して調整する

静的な閾値は、明白な失敗を捉えます。より微妙なずれには、各指標の通常の季節パターンを学び、統計的に異常な逸脱に旗を立てる異常検知を重ね、ゆっくりした漏れが洪水になる前に捉えます。これについて規律を持ってください。ノイズの多い異常のアラートは、人々にアラートを無視するよう訓練し、それはアラートがないよりも悪い。最も価値の高いテーブルから始め、人間が行動すべきことにだけアラートを出し、各アラートを名前のある所有者にルーティングし、容赦なく調整します。誰も行動しないアラートは、機能ではなく、監視のバグです。

影響分析と根本原因のために系統を追跡する

何かが壊れたとき、すぐに二つの問いが重要になります。何が原因で、何に影響するか。データ系統は、データが源からすべての変換を経てすべての下流のテーブル、ダッシュボード、モデルにどう流れるかを対応づけることで、両方に答えます。根本原因には、悪い数字を上流にたどり、それを持ち込んだ変換あるいは源まで行きます。影響分析には、前方にたどり、悪い読み込みに触れられたすべての消費者を見て、被害が広がる前に彼らに通知し隔離します。手で描いた図は描いた翌日には間違っているので、手作業で図を保守するのではなく、変換とオーケストレーションのツールから系統を自動的に捉えます。多くの源を持つ企業では、系統をデータカタログに公開し、どの消費者も項目がどこから来たかを見て、それに応じて信頼できるようにします。

データのインシデントを本番のインシデントのように扱う

サービスを信頼できる状態に保つ実践は、データにも直接当てはまります。すべての重要なデータセットに所有者を与えます。「データのダウンタイム」、つまりデータが欠けている、間違っている、遅れている期間に、重大度のレベルを定義します。サービスレベルを設定します。鮮度の目標、許容されるエラーバジェット、検知と解決の目標時間。最も重要なパイプラインの背後にデータのオンコールのローテーションを置き、ランブックを書き、同じ失敗が再発しないよう、インシデントの後に非難しないポストモーテムを実施します。支払いのテーブルが遅れたり、公的な指標が間違ったりしたとき、それはインシデントであり、障害と同じ真剣さに値します。これが、ツールのすべてを元取らせる文化的な転換です。

継続的にプロファイルし、突き合わせる

プロファイリングとは、データの形を日常的に調べることです。値の分布、ヌル率、カーディナリティ、最小と最大、形式のパターン。それは、アサートしようと思わなかった問題を表面化させ、良い期待値を設定できるよう、「普通」がどう見えるかを教えます。突き合わせとは、独立した源が一致することを確認することです。ウェアハウスの合計は記録のシステムの源と合うか、部分の合計は全体と等しいか。重要なシステム間の突き合わせを自動化し、乖離にアラートを出します。突き合わせの破綻は、上流で何かが間違ったという、しばしば最も早く最も明確なシグナルだからです。

トレードオフ: 長所と短所

アプローチ	長所	短所	最適な場合
アサーションテスト(ハードな失敗)	悪いデータを冷たく止める。明確な不変条件	軽微な問題でパイプラインをブロックしうる	重要なキー、参照の整合性
期待値テスト(ソフトな旗)	ずれを捉える。脆くない	調整が必要。無視されうる	分布、量の帯
データコントラクト	上流の驚きを防ぐ。明確な所有	調整とガバナンスのオーバーヘッド	チームをまたぐ生産者/消費者の境界
異常検知	微妙で予期しないずれを捉える	アラート疲れ。偽陽性	価値の高いテーブル、季節的な指標
手作業の抜き打ち確認	始めるのが安い。ツール不要	スケールしない。静かなエラーを見逃す	ごく初期の段階のみ
完全なオブザーバビリティのプラットフォーム	広いカバレッジ、系統、アラート	コスト、セットアップ、動かすもう一つのシステム	多くの源、規制対象のレポーティング

中心的な緊張は、カバレッジ対ノイズです。何も計装しなければ、問題が最初に消費者に届き、それは信頼を破壊します。すべてを敏感なアラートで計装すれば、チームが偽陽性に溺れてチャンネルをミュートするまで続き、それも問題が消費者に届くのを許します。データを影響範囲で順位づけして解決してください。取締役会の指標、顧客向けのプロダクト、規制上のレポート、機械学習のモデルに供給するテーブルは、完全な扱いを受けます。コントラクト、ハードなアサーション、オブザーバビリティ、オンコールの所有。探索的なテーブルの長い尾は、軽いプロファイリングを受けます。信頼性の予算を、間違ったデータが最も傷つける所に使い、他では意図して控えめにします。

チームで議論すべき問い

悪いデータが本番に届いたとき、誰がどうやって最初に気づきますか。 これは、データの信頼性についての最も明らかにする問いです。誠実な答えは、通常、「消費者が、偶然に」だからです。アナリスト、経営者、顧客があなたの検知システムなら、検知までの平均時間は日数で測られ、そのたびに信頼性が打撃を受けます。代替は、悪い数字が広がる前に、故障の時点で所有するチームを呼び出す計装です。本物の数字を持ち込んでください。直近十件のデータのインシデントのうち、監視で捉えられたものと下流の人間が報告したものはいくつで、それぞれが検知されないまま座っていた時間はどれだけか。答えは、オブザーバビリティを持っているのか、希望だけかを教え、鮮度、量、スキーマ、分布のチェックにどこから最初に投資するかを直接駆動すべきです。
どのデータセットが所有者、コントラクト、サービスレベルを持ち、どれが孤児ですか。 規模では、データ品質の失敗のほとんどは、所有されないインターフェースにさかのぼります。生産するチームが、誰が依存しているか知らずに何かを変えた。それは、コントラクトがそう言わなかったからです。所有は、コントラクト、アラートの経路、インシデント対応を可能にする基盤で、孤児のデータセットは静かな破損が住む所です。最も重要なテーブルをたどり、それぞれについて、誰が責任を負い、生産者が何にコミットし、消費者がどんな鮮度と正確性を約束されているかを問ってください。系統を持ち込んでください。下流の影響範囲が最大のテーブルは、これを最も必要とし、しばしばそれを欠いているものです。「重要」と「所有されている」の間のギャップが、次の四半期の優先順位の一覧です。
データ品質のインシデントの私たちにとっての実際のコストは何で、それに応じて扱っていますか。 チームはデータ品質に投資不足になります。悪いデータのコストは拡散し遅れて現れるので項目として決して現れず、品質のツールを築くコストは具体的で即座だからです。本物のインシデントを端から端まで値付けして枠づけ直してください。間違った決定、手戻り、系統なしに根本原因をたどることに費やされたエンジニアの時間、人々が静かに自分のシャドーのデータセットを再構築するほど信頼を侵食すること、そして規制対象あるいは公衆に面する設定では、訂正の通知とその評判上の損害。昨年の具体的な例を持ち込み、誠実に合計してください。支払いや公的な統計のパイプラインの一つの静かな失敗が、オブザーバビリティのツールの一年分より多くかかりうるなら、ビジネスケースは自ずと成り立ち、会話は投資するかどうかから、どこにかへと移ります。
データセットを影響範囲で順位づけしましたか。そして監視への投資は、その順位づけに実際に従っていますか。 規模での中核の失敗のモードは、信頼性の労力を均等に使うことです。誰も信頼しない探索的なテーブルが、取締役会の指標に供給するものと同じ注意を受け、一方、価値の低いテーブルの敏感なアラートが、重要な呼び出しも運ぶチャンネルを、人々がミュートするよう訓練します。すべてを計装すればノイズに溺れ、何も計装しなければ問題が最初に消費者に届くので、本当の決定は、完全な扱い(コントラクト、ハードなアサーション、オブザーバビリティ、オンコールの所有)をどこに置き、軽いプロファイリングで足りるのがどこかです。何がそれらに依存するかでタグ付けされたテーブルの目録を持ち込み(取締役会の指標、顧客向けのプロダクト、規制上のレポート、機械学習のモデル)、その順位づけを、チェックとアラートが今日実際にある場所と比べてください。多くの源を突き合わせる企業や、法定の数字を公表する政府では、法的あるいは公的な露出を持つテーブルが一覧の最上位に属し、「間違っていれば最も傷つく」と「最も監視されている」の間のギャップは、今正すべき優先順位づけの誤りです。
どの機械学習のモデルと分析が、検証しないデータに基づいて決定していて、どんな誤りを静かに符号化しているかもしれませんか。 ダッシュボードは、疑うかもしれない一人の人間に間違った数字を示しますが、モデルは間違った特徴量で訓練し、それらの誤りを、気づいたり元に戻したりするのがはるかに難しい規模と不透明さで、あらゆる予測に符号化します。相反する圧力は速度です。データサイエンスのチームは新しい特徴量で速く動きたく、すべてのフィードに検証、コントラクト、鮮度の保証を加えることは、上流の列がずれたためにモデルが静かに劣化するまで、摩擦に感じられます。本番のモデルと分析、それぞれが消費するデータセット、それらのフィードのうちどれがテスト、コントラクト、オブザーバビリティを持ち、どれが無防備かの誠実な印の目録を持ち込んでください。モデルが与信、給付、執行の決定に影響する企業や政府の設定では、検証されない訓練データは、品質のリスクの上に、監査と公平性の負債になるので、どのフィードがモデルのリリースをゲートするかという問いには、所有者と文書化された答えがあるべきです(6.5章)。
品質のバグが数週間後に表面化したとき、実際に再処理して突き合わせられますか。それとも、必要なものをすでに捨てていますか。 多くの品質の失敗は、読み込み時には見えず、突き合わせの破綻や疑わしい傾向が誰かに調べさせたときに後で明らかになり、その時点では、きれいに直せるかは、ずっと前になした選択に依存します。不変の生のレコードを保ったか、独立した源を突き合わせられるか、系統が悪い数字を起源までたどれるか。緊張は、コストと単純さ対再現性です。生のデータを保持し、システム間の継続的な突き合わせを実行することは無料ではなく、変換されたテーブルが正しく見えたら生の入力を削除したくなるからです。生のデータの保持と不変性の方針、自動的に突き合わせる重要なシステムの組の一覧、再処理で解決できた、あるいはできなかったバグの本物の例を持ち込んでください。公表されたあらゆる数字を源のレコードまでたどる法定の義務を負う政府機関や、規制上の再表明に直面する企業にとって、不変の生のデータと自動化された突き合わせは、任意の衛生ではなく、訂正を擁護できるようにする仕組みです。

セクター別の視点

スタートアップ。 網羅性より速度と信頼が重要です。変換ツールに少数の軽量なテストを置き(キーの一意性とヌルでないこと、意味を運ぶ列の許容される値、源ごとの行数の帯)、会社の指標に供給する少数のテーブルにだけ鮮度と量の監視を加えてください。すべてのアラートを、一人のエンジニアが所有する一つのチャンネルにルーティングし、正当化するテーブルもチームもできる前にオブザーバビリティのプラットフォームを買うことには抵抗します。目標は、すべてを計装することではなく、創業者が引用する数字を膨らませる前に、誤ってラベル付けされた項目に気づくことです。

小規模事業者。 データエンジニアがおらず予算も厳しいので、別個のスタックを立ち上げるのではなく、すでに払っているウェアハウス、BIツール、SaaSプラットフォームに組み込まれた品質の機能に頼ってください。意思決定を実際に駆動する少数の数字(収益、パイプライン、在庫)に労力を集中させ、独立した源に対して定期的な周期で抜き打ち確認し、ベンダーの鮮度とスキーマのアラートがあるなら十分だと扱います。すでに動かしているツールに埋め込まれた品質を買うことは、保守する人のいないパイプラインを築くことに勝ります。

大企業。 問題は、多くのチームと数千のテーブルにわたる信頼性なので、インターフェースを標準化してください。すべての生産者の境界でのデータコントラクト、鮮度、量、スキーマ、分布を観察するオブザーバビリティのプラットフォーム、影響分析のためにカタログに公開された系統。データを影響範囲で順位づけし、価値の高いものに異常検知とオンコールの所有を置き、データのインシデントを、サービスの障害と同じ重大度とポストモーテムのプロセスで運営します。規制上のレポートと経営者のダッシュボードに供給するパイプラインのサービスレベルは、データの信頼性を願望から、測定され統治されたコミットメントに変えます。

政府。 法定の正確性と公的な説明責任が基準を設定します。不変の生の調査と行政のレコードを着地させ、層をなすテストされた段階で変換し、各ステップで源の合計に対して突き合わせます。公表されたあらゆる数字を監査のために源のレコードまでたどれるよう完全な系統を保ち、妥当性、完全性、前の期間との一貫性の検証の背後で、あらゆるリリースをゲートしてください。ツールの調達は、透明性とデータの可搬性を求めるべきで、間違った公的な統計は、公的な信頼が求める重みで、深刻なインシデントとして扱われなければなりません。

事例

スタートアップ。 20人の会社は、プロダクトのイベントと決済プロバイダーから供給されるウェアハウスで市場投入を運営しています。初期に、誤ってラベル付けされた通貨の項目が、誰かが気づく前の二週間、報告される収益を静かに膨らませ、すべてのダッシュボードへのチームの信頼を揺るがしました。彼らは変換ツールの軽量なテストの集合で応えました。キーの一意性とヌルでないこと、通貨とステータスの列の許容される値のチェック、源ごとの行数の帯。会社の指標に供給する少数のテーブルに、基本的な鮮度と量の監視を加え、一人のエンジニアが所有する一つのSlackチャンネルにルーティングしました。控えめですが、重要な失敗を捉え、創業者たちは再び数字を信頼しています。

大企業。 多国籍の銀行は、規制上のレポート、リスクモデル、経営者のダッシュボードに供給する統治されたウェアハウスへ、数十の源のシステムにわたる顧客と取引のデータを突き合わせます。すべての生産者の境界でデータコントラクトを運用するので、上流のスキーマの変更は、消費者に突然浴びせられるのではなく、バージョン管理され交渉されます。オブザーバビリティのプラットフォームが数千のテーブルにわたって鮮度、量、スキーマ、分布を監視し、価値の高いものには異常検知を、影響分析のためにデータカタログに公開された系統とともに備えます。データのインシデントは、規制上の提出書類に供給するパイプラインのサービスレベルを伴う、サービスの障害と同じ重大度とオンコールのプロセスに従います。源のシステムがずれたとき、所有するチームが呼び出され、影響を受ける下流のレポートは、規制当局に発見されるのではなく、数分以内にわかります。

政府。 国の統計機関は、市場、政策立案者、公衆が権威あるものと見なす経済指標を公表しており、正確性は法定の義務で、公表されるすべての数字は監査可能でなければなりません。そのパイプラインは、不変の生の調査と行政のレコードを着地させ、それから層をなすテストされた段階で、各ステップで源の合計に対する突き合わせとともに変換します。完全な系統により、アナリストは公表されたどの数字も源のレコードまでたどれ、それは品質のツールであり、法的要件でもあります。リリース前に、数字は妥当性、完全性、前の期間との一貫性の検証のゲートを通り、どんな異常も、公表されるのではなく、調査され文書化されます。間違った公的な統計は深刻なインシデントなので、機関は、データのダウンタイムを、公的な信頼が求める重みで扱います。

ビジネスケース: 動機、ROI、TCO

データ品質とオブザーバビリティの見返りは、保たれた信頼、短縮されたインシデント、避けられた悪い決定から来ます。信頼できるデータは、下流の分析、ビジネスインテリジェンス、AIへのあらゆる投資を実際に元取らせる基盤です。モデルやダッシュボードは、その下のデータの分だけ良いからです。品質のチェックが境界で悪い読み込みを捉えるとき、間違った数字が決定、顧客、提出書類に届くはるかに大きなコストを避けます。系統は、根本原因の調査を数日の手作業のたどりから数分に縮め、それは純粋な取り戻されたエンジニアリングの時間です。オブザーバビリティは、検知までの平均時間を「消費者が不満を言うとき」から「パイプラインが失敗するとき」に縮め、そこが信頼の損害の大半が避けられる所です。

総所有コストには、テスト、オブザーバビリティ、カタログ化のツール、パイプラインを計装するエンジニアリングの時間、所有者を割り当てコントラクトを書く組織的な仕事が含まれます。これは本物ですが、しないコストと量ってください。経営者に発見される静かな破損、誤りを規模で符号化する悪い特徴量で訓練された機械学習のモデル、もう公式のものを信頼しないので静かにシャドーのデータセットを再構築するアナリスト、そして規制対象あるいは公的な設定では、何年も信頼性を損なう訂正の通知。リーダーシップには、データ品質を、組織が下すあらゆるデータ駆動の決定への保険として枠づけてください。保険料は控えめで予測可能です。保険のない損失、一つの目立つ間違った数字は、そうではありません。

アンチパターンと落とし穴

データ品質を、継続的なエンジニアリングの実践ではなく、一度きりの掃除プロジェクトとして扱うこと。
故障の時点での監視ではなく、下流の消費者から失敗を発見すること。
データセットの所有がなく、何かが壊れたとき誰も責任を負わず、誰も呼び出されないこと。
コントラクトなしに生産者がスキーマや意味を変え、すべての消費者を静かに壊すこと。
チームがチャンネルをミュートして本物のインシデントを見逃すほどノイズの多い異常のアラート。
検証されないデータを機械学習のモデルに直接供給し、誤りを規模で符号化すること(6.5章)。
描いた翌日には間違っている手描きの図として系統を保守すること。
重要なテーブルの利用への適合した品質ではなく、あらゆる所で完璧なデータを追うこと。
生のデータを削除し、品質のバグが後で表面化したときに再処理も突き合わせもできなくすること。

成熟度モデル

レベル1、開始: 品質は誰の仕事でもありません。問題は消費者に、通常は間違った数字がレポートに届いた後に発見されます。テストも、監視も、所有もありません。修正は手作業の火消しで、同じ失敗が再発します。
レベル2、発展: 重要なテーブルに基本的なテスト(キー、ヌル、許容される値)を加え、最も気にかけるデータセットに少しの鮮度と量の監視を加えるチームもあります。その実践は存在する所で機能しますが、カバレッジと厳密さはチームごとに異なり、何も標準化されず、インシデントは依然として反応的に扱われます。
レベル3、標準化: 品質の次元が閾値とともに定義され、パイプラインを誰が築いたかに依存するのではなく、同じ期待がチーム間で適用されます。データコントラクトが主要な生産者の境界を統治し、オブザーバビリティが重要なテーブルの鮮度、量、スキーマ、分布をカバーし、系統が影響分析をサポートします。すべての重要なデータセットに名前のある所有者がおり、データのインシデントは組織全体で文書化された重大度と対応のプロセスに従います。
レベル4、管理: 品質と信頼性が、ベースラインに対して測定され、制御されます。データのダウンタイムが、本物の指標で追跡されます。検知までの平均時間、解決までの平均時間、合意されたサービスレベルに対する鮮度と正確性、行動を引き起こす前にデータセットが使えるエラーバジェット。突き合わせの破綻率、テストの合格率、異常の偽陽性率が時間にわたって傾向を追われ、アラートは勘ではなくそれらの数字に対して調整され、データのリリースの実施/不実施の判断は、希望ではなくベースラインに対する測定された品質に基づいてなされます。
レベル5、オーケストレーション: 品質とオブザーバビリティは、浸透し、自動化され、適応的です。異常検知が微妙なずれを捉え、コントラクトが機械的に徹底され、系統が自動的に捉えられてカタログに公開されます。データは本番のサービスのようにサービスレベルとオンコールの所有を持ち、突き合わせは継続的に走り、非難しないポストモーテムがデータのダウンタイムの着実な削減に供給します。品質はデータガバナンス、機械学習、ビジネスの計画と統合され、組織はデータの状況が移るにつれて、閾値、カバレッジ、所有を継続的に再スコープします。

議論のためのアイデア

どのテーブルが一週間静かに間違っていたら最も被害をもたらすか。そしてそれらは最も監視しているものですか。
データコントラクトは、最後の上流起因のインシデントをどこで防いだはずか。そしてなぜなかったのですか。
典型的な根本原因の調査に現在どれだけのエンジニアリングの時間がかかり、自動化された系統はどれだけ節約しますか。
機械学習のモデルのうち、検証しないデータで訓練しているものはありますか。そしてどんな誤りを符号化しているかもしれませんか。
アラートは、人々がすべてのアラートに行動するほど調整されていますか。それとも誰かがチャンネルをミュートしましたか。
最も重要な消費者は、実際にどんな鮮度と正確性のサービスレベルに同意するか。そして今日それを満たせますか。

要点

データ品質は、正確性、完全性、一貫性、適時性、妥当性、一意性にわたる利用への適合性です。
悪いデータは、データがないよりも悪い。決定とモデルを静かに破損するからです。
コードのようにデータをテストします。CIと本番で、アサーションと期待値のテストにスキーマのチェックを加えて。
データコントラクトで、生産者と消費者の期待を明示的で徹底可能にします。
ソフトウェアのオブザーバビリティ(9.2章)に対応して、鮮度、量、スキーマ、分布を観察します。
速い根本原因と影響分析のために系統を捉え、消費者のために公開します。
データのインシデントを、所有者、重大度、サービスレベルを伴う本番のインシデントのように扱います。
間違ったデータが最も傷つく所を計装します。あらゆる所の完璧ではなく、利用に適合した品質を目指します。

参考文献とさらなる読み物

Barr Moses, Lior Gavish, and Molly Vorwerck, “Data Quality Fundamentals.”
Jacek Majchrzak, Sven Balnojan, and Marian Siwiak, “Data Contracts.”
Danette McGilvray, “Executing Data Quality Projects.”
Thomas C. Redman, “Data Driven: Profiting from Your Most Important Business Asset.”
Laura Sebastian-Coleman, “Measuring Data Quality for Ongoing Improvement.”
Joe Reis and Matt Housley, “Fundamentals of Data Engineering.”
DAMA International, “DAMA-DMBOK: Data Management Body of Knowledge.”
ISO/IEC 25012, “Data quality model.”