Data Quality データ品質
ぺい(pei0804)
データの品質は、強固に管理していても、100％の正確さや完全さはないし、それがが重要でもない。
むしろ重要なのは、戦いの場を選び、許容範囲まで品質を向上させること。
1 不完全なデータ
列の情報が欠落したり、ETLジョブの失敗などで、下流の分析に影響が出る。
これに対しては、レコード数のチェックや、レコード欠落をしている場合に警告を出す。
デフォルト値
ある取引が1891年のような大昔が指定されていることがある。これはデフォルト値が使われている可能性が高い。これらはメタデータが整備されていれば何が起きているかはある程度把握できる。
なぜ、このようなデータになったのか？を可視化できると良い。
データフォーマットの不整合
文字列カラムが様々なフォーマットで保存されている。
顧客の姓名や、電子メールのフォーマットなどなど。データウェアハウスに入れるまでには、標準化しておきた。
重複したデータ
発見するのは簡単だけど、直すのはかなり骨が折れる。下流のプロセスが全て壊れる。これに伝播して様々な箇所でデータの品質が損なわれる可能性がある。
これに対しては、マスターデータ制御の実装。レコードの正確な重複チェック、1つのレコードをパージ。
システム間の不整合
複数のシステムで様々な方法で保存されていて、一貫性がない。
これに対してはマスターデータ姓おぎょが必要。また、全ての異なる情報を一つのレコードに一致させる必要がある。称号に正確性は必要なく、一致率のしきい値などを使っても良い。
データの大幅変更
毎日顧客アドレスがいっぱい届くとする。通常は毎日5000レコードのところ。今日は30件だった。
このファイルは、一意性や有効性、正確性などのチェックには合格しますが、恐らくデータの欠落が発生しています。
この問題には、分析レイヤーで気づくことも出来るし、送られてきたファイルまたはレコードをチェックする仕組みで対応することもできる。
ファイルとデータ転送後のレコード照合など。
孤児データ
データが一方のシステムでは存在するけど、もう一方では存在しない。
ある顧客がAテーブルに存在するのに、その顧客の講座がBテーブルに存在しない場合、これは孤児と分類される。
テーブルAとBに取り込まれるたびに、どちらにも存在するかをチェックするデータ品質のルールがあれば、この問題を発見することが出来る。
機能不全の履歴管理
データウェアハウスを導入する場合、履歴のメンテナンスは大事。SCD type2など。
履歴が正しく動かなければ、下流工程が壊れてしまう。
無関係なデータ
利用可能な全ての情報を収集することほど、もどかしいことはない。
なぜ、そのデータが必要かは言語化する。取得する意味がないデータであれば、取得するべきではない。
不明確なデータ定義
例えば、コンバージョンというイベントがあったとする。チームによって実は解釈が異なっているということはよくある。
データの定義が揃ってないということは明確姓に反しているため、データが作成されるたびに、データの定義を揃えよう。
重複データ
組織内の複数のチームが、同じデータを繰り返し取得していると、様々なシステムでそのデータを利用できるようになり、データの冗長性が発生する。これは、企業の収益悪化だけではなく、顧客体験も悪くなる。
全ての組織の代理店が受け取ることのできる単一のデータシステムが必要。
古いデータ、陳腐化したデータ
一定期間以上保存されたデータは、データスタックに何の価値も与えない。コストをかけたり、エンジニアを混乱させたり、分析にも影響が出る。
必要以上に保存しないようにする。
キーの非整合性
コアデータモデルにプライマリキーとサロゲートキーを使用することを想像してください。ナチュラルキーが一意ではないケースがある。これが起きるとデータの整合性が損なわれる。サロゲートキーが常に一意であることは確認する必要がある。
データへのアクセス性の悪さ
データが使いにくければ、アクセスできるとは言えない。
データの受信が遅すぎる
データは、その瞬間に重要な判断を下すのに必要なタイミングに用意されている必要がある。
例えば、週次MTGの時に、先週のデータが揃ってないと、何を話す？となってしまう。
どのデータがいつまでに必要かを合意する必要がある。そして、SLAを守れるようにソースシステムを逆算する。