データ品質を確保する基本的な方法

データはビジネスの意思決定に欠かすことはできません。
データエンジニアリングチームとしてデータ品質を確保する方法を見ていきましょう。

データ異常とは何か

まずはデータ品質を脅かすデータ異常がどんなものかを見てみます。
具体的には以下の現象が起きていれば異常と言えるでしょう。

1. データの行数が昨日と比べて70%しかない

2. 日付列など重要な列の値がnullになっている

3. `usere_id`列などのカテゴリ型の列のカーティナリティが昨日より大幅に大きくなっている など
   まずはデータ異常の発生を検知することから始まります。

いつ検知するのか

データ異常の状態は分かりましたが、いつこれを検知すればよいのでしょうか？
考えられるのは本番テーブルにデータを挿入する前か後のどちらかですが、おすすめは挿入前です。
本番テーブルにデータを入れてしまった後では後続のユーザーやシステムに影響が出る恐れがあるからです。
早く失敗して早く対処するのがエンジニアリングの基本です。（いわゆるfail fast）

どのように検知するか

WAPという考え方があります。

• W（Write）: 本番と同等のステージングテーブルに一旦書き込む

• A（Audit）: 書き込まれたステージングテーブルでデータ品質を確認する

• P（Publish）: データ品質に問題がなければ公開する
  このようにデータ品質を確認することで安全かつ事前に異常を発見することができます。

データの流れのどこで検知するか

「いつ検知するのか」のところで本番テーブルにデータを挿入する前と書きましたが、DWHやDMという構成を取っていると本番テーブルがいくつも連なっていることが多いでしょう。
その場合データの流れのどこで検知すればよいのかという話です。
連なった全てのテーブルにデータを挿入する前に品質を確認する、というのが一つ。
もう一つは最上流で最低限1回というものです。
品質が怪しいデータを後続のテーブルにまで伝播させてしまう前に直しておきましょう。

異常検知したらどうするか

データ品質に何らかの異常を検知したとします。
その場合データ処理のパイプラインを止めてしまうこともあれば、ちょっとした対処をして処理を継続させることもあります。
データ異常が致命的で何かトラブルが起きているときは前者、トラブルとまではいかないがいつもと違うことが起きていれば後者の対応となります。
具体的には、前者はシステムダウンによってそもそもデータが取れていない例が挙げられます。
後者だと大雨が降った影響でログ数がいつもより多くなった、などがあります。

どんな指標を確認するか

現実ではビジネスモデルなどに合わせて確認事項が異なるものの、一般的には以下のとおりです。

• nullチェック: 主キーなどの列にnullが入っていないことを確認する

• カーディナリティチェック: 特定の列のカーディナリティが一定の範囲に収まっていることを確認する

• 0値チェック: 0値やnull値が一定の範囲に収まっていることを確認する

• 重複チェック: 主キー列や行単位で見て重複がないことを確認する

• ソース・ターゲットチェック: ソーステーブルのデータが過不足なるターゲットテーブルに読み込まれていることを確認する

まとめ

データ品質の問題は素早く検知して素早く対処することでビジネスへの影響を最小限に抑えることができます。
この記事の内容を基本として抑えつつ各組織に合った品質確保の方法を探ってください。

参考

https://medium.com/@sudha.dhriti/data-quality-guidelines-6b45107ca842