データサイエンスとデータベース

データ品質プロセスを実装する方法

データウェアハウスシステムのデータ品質（DQ）はますます重要になっています。規制要件の増加だけでなく、データウェアハウスソリューション、企業にデータ品質イニシアチブを強化（または開始）するように強制します。

この記事の主な焦点は「従来の」データウェアハウジングですが、データレイクなどのより「現代的な」概念ではデータ品質も問題になります。データ品質戦略を実装する際に考慮すべきいくつかの主要なポイントと、回避すべきいくつかの一般的な落とし穴を示します。 DQフレームワークを構築するための適切なテクノロジー/ツールの選択に関する部分については説明していません。

DQプロジェクトの最も厄介な問題の1つは、一見したところ、追加の機能を提供せずにビジネスユニットに多くの作業を作成するという事実です。データ品質イニシアチブには通常、次の場合にのみ強力な支持者がいます。

ビジネスに深刻な影響を与えるデータ品質の問題があります。
規制機関は、データ品質基準を実施します（例： BCBS 239 金融業界で）。

DQの扱いは、ソフトウェア開発でのテストの扱いと似ています。プロジェクトの時間や予算が不足すると、この部分が最初に削減される傾向があります。

もちろん、これは完全な真実ではありません。優れたデータ品質システムは、エラーを早期に検出するのに役立ち、「十分に優れた」品質のデータをユーザーに配信するプロセスをスピードアップします。

用語の定義

トピックについて説明する前に、使用される用語の一般的な理解が重要です。

データウェアハウス（DWH）

にデータウェアハウス（DWH）は、主に意思決定支援に使用される非運用システムです。運用システムのデータ（それらすべてまたはより小さなサブセット）を統合し、DWHシステムのユーザーにクエリ最適化データを提供します。データウェアハウスは、企業内で「真実の単一バージョン」を提供する必要があります。データウェアハウスは通常、ステージ/レイヤーで構成されています。

共通のデータウェアハウスレイヤー

図1：一般的なデータウェアハウスレイヤー。

運用データはほとんど変更されずに ステージングレイヤー 。ザ・ コア層 統合および統合されたデータが含まれています。次のオプションの段階は 派生エリア 、派生データ（たとえば、売上の顧客スコア）と集計を提供します。ザ・ データマートレイヤー 特定のユーザーグループ向けに最適化されたデータが含まれています。データマートには、多くの場合、集計と多くの派生メトリックが含まれています。データウェアハウスのユーザーは、多くの場合、データマートレイヤーでのみ作業します。

各段階の間に、ある種のデータ変換起こる。通常、データウェアハウスには、運用データのデルタ抽出が定期的に読み込まれ、履歴データを保持するためのアルゴリズムが含まれています。

データ品質

データ品質は通常、製品がユーザーの要件をどの程度満たしているかに関する指標として定義されます。ユーザーごとに製品の要件が異なる可能性があるため、実装はユーザーの視点によって異なり、これらのニーズを特定することが重要です。

データ品質は、データに完全またはほぼエラーがないことを意味するのではなく、ユーザーの要件によって異なります。「十分に良い」アプローチから始めるのが良い選択です。今日、大企業には「データ（または情報）政府の方針」があり、データ品質はその一部です。 A データ政府の方針 あなたの会社がデータをどのように扱っているか、そしてデータが適切な品質を持っていることをどのように確認しているかを説明する必要があります データプライバシールール 違反していません。

データ品質は継続的なトピックです。 DQ回路ループを実装する必要があります（次の章を参照）。規制要件とコンプライアンスルールも、次のような必要なデータ品質に影響を与えます。 TCPA （米国の電話消費者保護法）または GDPR ヨーロッパではプライバシーの問題だけでなく、次のような業界固有のルールもありますソルベンシーII EUの保険、銀行向けのBCBS239など。

データ品質回路ループ

すべての品質トピックと同様に、DQは満足のいく品質を維持するために設計された継続的な活動です。 DQプロジェクトの結果として、 回路ループ 以下のようなものを実装する必要があります。

データ品質回路ループ

図2：データ品質回路ループ。

このループ内の手順については、次の章で説明します。

データ品質の役割

DQイニシアチブを成功させるには、次の役割が必要です。

データ所有者。 データ所有者は、データ品質だけでなく、データプライバシー保護にも責任があります。データ所有者は、データドメインを「所有」し、アクセスを制御し、データ品質を保証し、調査結果を修正するためのアクションを実行する責任があります。大規模な組織では、複数のデータ所有者を見つけるのが一般的です。データドメインには、たとえば、マーケティングデータ、管理データなどがあります。会社に複数のデータ所有者が存在する場合は、データ品質プロセス全体の責任者が1人（データ所有者または他の誰か）である必要があります。データ所有者は、データ品質を強化し、DQプロセスをサポートする強力な権限を持っている必要があります。したがって、データ所有者は多くの場合、上級の利害関係者です。優れたコミュニケーションスキルとともにビジネスドメインをよく理解することが重要です。
データスチュワード。 データスチュワードは、企業内でのデータ品質の実装を支援し、データ/データモデルの解釈方法、データ品質の問題などに関する質問についてデータユーザーをサポートします。データスチュワードは、多くの場合、データ所有者のスタッフであるか、データ品質コンピテンスセンターで編成できます。またはDQチーム。データスチュワードはITまたはビジネスのバックグラウンドを持つことができますが、両方の側面を知っている必要があります。分析スキルと、サポートするビジネスドメインの十分な理解、および強力なコミュニケーションスキルは、データスチュワードを成功させるための主要な前提条件です。
データユーザー。 これらは、データを操作するデータウェアハウスユーザーです。データユーザーは通常、データマートレイヤーで作業し、データでの作業結果に責任があります。データユーザーは、必要な品質レベルに対して適切なデータ品質チェックがあることを確認します。データユーザーは、データ、ビジネスドメイン、およびデータを解釈するために必要な分析スキルを十分に理解している必要があります。すべてのビジネスユニットのデータユーザーの中から、データ品質の問題を担当する人を数人見つけるのは合理的です。

成功を確実にするために、これらの役割を明確に定義し、広く持つことが重要です 受け入れられました DQプロジェクトの初期段階で組織内に。見つけることも同様に重要です有能なデータスペシャリストプロジェクトをサポートするこれらの役割のために。

ルールを定義する

検索して実装する有用 DQチェック/ルール。 DQルールを定義するには、データウェアハウスとその使用法を十分に理解する必要があります。

DQルールを見つける方法は？

前に説明したように、 データユーザー （およびデータ所有者）は、データの使用に責任があり、したがって、必要なレベルのデータ品質にも責任があります。データユーザーは、有用なデータ品質ルールに最適な入力を提供できるように、データを十分に理解している必要があります。

彼らはデータ品質ルールの結果を分析する人でもあるので、彼らに独自のルールを定義させることは常に良い考えです。これにより、データユーザーユニットに割り当てられたDQルールの結果をチェックおよび評価するための受け入れがさらに強化されます（「分析」の章を参照）。

このアプローチの欠点は、データユーザーは通常、データウェアハウスの以前のレイヤーではなく、データマートレイヤーのみを知っていることです。「下位」段階でデータが破損した場合、データウェアハウスの「最上位」層だけをチェックしても、これは検出されません。

エラーへの取り組み

データウェアハウスでどのような既知のエラーが発生する可能性がありますか？

データウェアハウスの間違った変換ロジック
- ITランドスケープが複雑になるほど、変換ロジックは複雑になる傾向があります。これらは最も一般的なDQの問題であり、このようなエラーの影響は、データの「損失」、重複、誤った値などである可能性があります。
不安定なロードプロセスまたはロードの誤った処理
- データウェアハウスのロードは複雑なプロセスである可能性があり、ジョブオーケストレーションの定義にエラーが含まれる可能性があります（ジョブの開始が早すぎたり遅すぎたり、ジョブが実行されなかったりなど）。手動による介入によるエラー（たとえば、一部のジョブがスキップされたり、一部のジョブが間違った期日で開始されたり、昨日のデータファイルで開始されたりする）は、何らかの中断のためにロードプロセスが帯域外で実行されると頻繁に発生します。
データソースの間違ったデータ転送
- 多くの場合、データ転送はソースシステムのタスクとして実装されます。ジョブフローの異常または中断により、空のデータまたは不完全なデータが配信される可能性があります。
間違った運用データ
- 運用システムのデータには、これまで認識されていなかったエラーが含まれています。奇妙に聞こえるかもしれませんが、データウェアハウスプロジェクトでは、データがDWHに含まれるまで運用データの品質が見られないことがよくあります。
データの誤解
- データは正しいですが、ユーザーはそれを正しく解釈する方法を知りません。これは非常に一般的な「エラー」であり、厳密にはデータ品質の問題ではありませんが、データガバナンスに関係し、データスチュワードのタスクです。

これらの問題は、多くの場合、データウェアハウスソリューションを定義、実装、実行、および操作するための適切なノウハウとスキルが不足している人々によって引き起こされます。

データ品質の次元

DQ寸法 DQチェックを識別してクラスター化する一般的な方法です。多くの定義があり、次元の数はかなり異なります。16、またはそれ以上の次元が見つかる場合があります。実用的な観点から、いくつかの次元から始めて、ユーザーの間でそれらの一般的な理解を見つけることはそれほど混乱しません。

完全： 必要なすべてのデータが利用可能でアクセス可能ですか？必要なすべてのソースが利用可能でロードされていますか？ステージ間でデータが失われましたか？
一貫性： 誤った/矛盾した/一貫性のないデータはありますか？たとえば、「終了」状態の契約の終了日には、契約の開始日以上の有効な日付が含まれている必要があります。
独自性： 重複はありますか？
整合性： すべてのデータが正しくリンクされていますか？たとえば、存在しない顧客IDにリンクする注文はありますか（従来の参照整合性の問題）？
適時性： データは最新ですか？たとえば、毎日更新されるデータウェアハウスでは、昨日のデータが今日利用可能になると思います。

データウェアハウスによって生成されたデータ ロードプロセス 同様に役立つことができます。

データが破棄されたテーブル。 データウェアハウスには、技術的な問題（フォーマット変換、必須値の欠落など）が原因でロードできないデータをスキップ/遅延するプロセスがある場合があります。
ロギング情報。 顕著な問題がログテーブルまたはログファイルに書き込まれる可能性があります。
配達の請求書。 一部のシステムでは、運用システムによって提供されるデータ（レコード数、個別のキーの数、値の合計など）に「納品書」を使用します。これらは、データウェアハウスと運用システム間の調整チェック（以下を参照）に使用できます。

エラーが見つかった場合は、少なくとも1人のデータユーザーが各データ品質チェックを分析する必要があることに注意してください（「分析」の章を参照）。エラーが見つかった場合は、実装されたすべてのチェックの世話をする責任者が必要です。

複雑なデータウェアハウス内では、多くの（場合によっては数千の）DQルールが作成される可能性があります。データ品質ルールを実行するプロセスは、これを処理するのに十分な堅牢性と速度を備えている必要があります。

技術的な実装によって保証されている事実を確認しないでください。たとえば、データがリレーショナルDBMSに格納されている場合、次のことを確認する必要はありません。

必須として定義された列には、NULL値が含まれています。
主キーフィールドの値は、テーブル内で一意です。
リレーショナル整合性チェックが有効になっているテーブルには、既存の外部キーはありません。

ただし、データウェアハウスは常に変化しており、フィールドとテーブルのデータ定義は時間の経過とともに変化する可能性があることに常に注意してください。

ハウスキーピングは非常に重要です。異なるデータユーザーユニットによって定義されたルールは重複する可能性があるため、統合する必要があります。組織が複雑になるほど、より多くのハウスキーピングが必要になります。データ所有者は、一種の「データ品質ルールのデータ品質」としてルール統合のプロセスを実装する必要があります。また、データが使用されなくなった場合、またはデータの定義が変更された場合、データ品質チェックが役に立たなくなる可能性があります。

データ品質ルールのクラス

データ品質ルールは、テストのタイプに基づいて分類できます。

データ品質チェック。 1つのテーブルまたはテーブルのセット内の1つのデータウェアハウスレイヤー（図1を参照）内のデータをチェックする「通常の」ケース。
和解。 データがデータウェアハウスレイヤー間で正しく転送されたかどうかをチェックするルール（図1を参照）。これらのルールは主に、「完全性」のDQディメンションをチェックするために使用されます。調整では、単一の行または要約されたアプローチを使用できます。単一の行のチェックははるかに詳細ですが、比較されたレイヤー間で変換手順（データのフィルタリング、フィールド値の変更、非正規化、結合など）を再現する必要があります。スキップするレイヤーが多いほど、より複雑な変換ロジックを実装する必要があります。したがって、ステージングをデータマートレイヤーと比較するのではなく、各レイヤーとその前のレイヤーの間で調整を行うことをお勧めします。調整ルールで変換を実装する必要がある場合は、データウェアハウスコードではなく仕様を使用してください。要約された調整については、意味のあるフィールド（要約、個別の値の数など）を見つけます。
モニタリング。 データウェアハウスには通常、履歴データが含まれており、運用データのデルタ抽出がロードされます。データウェアハウスと運用データの間のギャップが徐々に大きくなる危険性があります。要約された時系列データを作成すると、このような問題を特定するのに役立ちます（たとえば、先月のデータと今月のデータを比較するなど）。データに精通しているデータユーザーは、ルールを監視するための有用な測定値としきい値を提供できます。

データ品質の問題を定量化する方法

何をチェックするかを定義したら、特定された問題を定量化する方法を指定する必要があります。「5つのデータ行がID15のDQルールに違反している」などの情報は、データ品質にはほとんど意味がありません。

次の部分が欠落しています。

検出されたエラーを定量化/カウントする方法。 「行数」を数えることもできますが、金銭的尺度（露出など）を使用することもできます。金銭的価値にはさまざまな兆候がある可能性があるため、それらを有意義に要約する方法を調査する必要があることに注意してください。データ品質ルールには、両方の数量化単位（行数と要約）を使用することを検討してください。
人口。 データ品質ルールによってチェックされるユニットの数はいくつですか？「5つのうち5つのデータ行」は、「500万のうち5つ」とは品質が異なります。母集団は、エラーの場合と同じ定量化を使用して測定する必要があります。データ品質ルールの結果をパーセンテージで表示するのが一般的です。母集団は、テーブルの行数と同じであってはなりません。 DQルールがデータのサブセットのみをチェックする場合（たとえば、契約テーブル内の終了した契約のみ）、同じフィルターを適用して母集団を測定する必要があります。
結果の定義。 データ品質チェックで問題が見つかった場合でも、必ずしもエラーが発生するわけではありません。データ品質については、しきい値を使用して調査結果を評価する信号システム（赤、黄、緑）が非常に役立ちます。たとえば、緑：0〜2％、黄色：2〜5％、赤：5％以上。データユーザーユニットが同じルールを共有している場合、特定のルールに対して非常に異なるしきい値を持つ可能性があることに注意してください。マーケティングビジネスユニットは数件の注文の損失を気にしないかもしれませんが、会計ユニットはセントさえ気にするかもしれません。パーセンテージまたは絶対値でしきい値を定義できるはずです。
サンプルエラー行を収集します。 データ品質ルールが検出されたエラーのサンプルを提供する場合に役立ちます。通常、（ビジネス！）キーとチェックされたデータ値は、エラーの調査に十分です。データ品質ルールの書き込みエラー行の数を制限することをお勧めします。
場合によっては、修正されないが有用なデータ品質チェックによって検出される「既知のエラー」がデータに見つかることがあります。これらの場合、 ホワイトリスト （データ品質チェックでスキップする必要があるレコードのキー）をお勧めします。

その他のメタデータ

メタデータ「分析」をルーティングし、データ品質制御ループのフェーズを監視することが重要です。

チェック項目。 チェックされたテーブルとフィールドをデータ品質ルールに割り当てるのに役立ちます。拡張メタデータシステムを使用している場合、これはデータユーザーとデータ所有者をこのルールに自動的に割り当てるのに役立つ場合があります。規制上の理由（BCBS 239など）のために、データがDQによってどのようにチェックされるかを証明することも必要です。ただし、データリネージ（*）を介してデータユーザー/データ所有者にルールを自動的に割り当てることは、両刃の剣である可能性があります（以下を参照）。
データユーザー。 すべてのDQルールには、「分析」フェーズで結果を確認し、結果がデータの処理に影響を与えるかどうか、およびどのように影響するかを決定するために、少なくとも1つのデータユーザー/データユーザーユニットを割り当てる必要があります。
データ所有者。 すべてのDQルールには、データ所有者を割り当てる必要があります。

（*）データ系統は、2点間のデータの流れを示します。データリネージを使用すると、ウェアハウス内の特定のターゲットフィールドに影響を与えるすべてのデータ要素を見つけることができます。

データリネージを使用してユーザーをルールに割り当てると、問題が発生する可能性があります。前述のように、ビジネスユーザーは通常、データマートレイヤー（およびオペレーティングシステム）のみを知っており、データウェアハウスの下位レベルは知りません。データ系統を介してマッピングすることにより、データユーザーには慣れていないルールが割り当てられます。下位レベルでは、データ品質の結果を評価するためにITスタッフが必要になる場合があります。多くの場合、手動マッピングまたは混合アプローチ（データマート内でのみデータリネージを介したマッピング）が役立ちます。

データ品質の測定

データ品質の測定とは、利用可能なデータ品質ルールを実行することを意味します。 自動的に 、データウェアハウスのロードプロセスによってトリガーされます。これまで見てきたように、データ品質ルールの数が非常に多い可能性があるため、チェックには時間がかかります。

完璧な世界では、すべてのデータにエラーがない場合にのみ、データウェアハウスがロードされます。現実の世界では、これはめったにありません（現実的には、ほとんどありません）。データウェアハウスの全体的なロード戦略に応じて、データ品質プロセスがロードプロセスを支配するかどうか（後者の方がはるかに可能性が高い）です。データ品質プロセス（ジョブネットワーク）を並列にして、「通常の」データウェアハウスのロードプロセスにリンクさせることは、優れた設計です。

定義されたサービスレベルアグリーメントがある場合は、データ品質チェックでデータウェアハウスのロードを妨げないようにしてください。データ品質プロセスのエラー/異常終了は、通常のロードプロセスを停止するべきではありません。データ品質プロセス内の予期しないエラーを報告し、「分析」フェーズで表示する必要があります（次の章を参照）。

予期しないエラーが原因でデータ品質ルールがクラッシュする可能性があることに注意してください（ルール自体が誤って実装されたか、基になるデータ構造が時間の経過とともに変更された可能性があります）。あなたのデータ品質システムがメカニズムを提供するならそれは助けになるでしょう 非アクティブ化 このようなルールは、特に会社のリリースが1年に少ない場合に顕著です。

DQプロセスは できるだけ早く実行され、報告されます -理想的には、チェックされたデータがロードされた直後。これにより、データウェアハウスのロード中にエラーをできるだけ早く検出できます（複雑なウェアハウスシステムのロードには数日かかるものがあります）。

分析する

このコンテキストでは、「分析」とは、データ品質の結果に対応することを意味します。これは、割り当てられたデータユーザーとデータ所有者のタスクです。

tddとbddの面接の質問

反応する方法は、データ品質プロジェクトによって明確に定義する必要があります。データユーザーは、調査結果のあるルール（少なくとも赤信号のあるルール）にコメントし、調査結果を処理するためにどのような対策が取られているかを説明する義務があります。データ所有者に通知する必要があり、データユーザーと一緒に決定する必要があります。

次のアクションが可能です。

深刻な問題： 問題を修正し、データのロードを繰り返す必要があります。
問題は許容できます： 将来のデータロードに備えて修正し、データウェアハウスまたはレポート内の問題を処理してみてください。
欠陥のあるDQルール： 問題のあるDQルールを修正します。

完璧な世界では、すべてのデータ品質の問題が修正されます。ただし、リソースや時間の不足は、多くの場合、回避策になります。

時間内に対応できるようにするには、DQシステムはデータユーザーに「彼らの」ルールについて調査結果を通知する必要があります。データ品質ダッシュボードを使用すること（おそらく何かが起こったというメッセージを送信することで）は良い考えです。調査結果についてユーザーに通知するのは早いほどよいでしょう。

ザ・ データ品質ダッシュボード 含める必要があります：

特定の役割に割り当てられたすべてのルール
結果とデータドメインでルールをフィルタリングする機能を備えたルールの結果（信号機、メジャー、および行例）
データユーザーが調査結果のために入力しなければならない必須のコメント
オプションで結果を「無効にする」機能（たとえば、データ品質ルールが実装の欠陥によるエラーを報告した場合）。複数のビジネスユニットに同じデータ品質ルールが割り当てられている場合、「オーバールール」はデータユーザーのビジネスユニットにのみ有効です（会社全体ではありません）。
実行されなかった、または異常終了したルールを表示する

ダッシュボードには、最近のデータウェアハウスのロードプロセスの現在のステータスも表示され、ユーザーはデータウェアハウスのロードプロセスを360度表示できます。

データ所有者は、すべての調査結果にコメントが付けられ、すべてのデータユーザーのデータ品質のステータス（元の状態または却下された状態）が少なくとも黄色であることを確認する責任があります。

概要を簡単に説明すると、データユーザー/データ所有者向けの一種の単純なKPI（主要業績評価指標）を作成すると便利です。各ルールに同じ重みが与えられている場合、関連するすべてのルールの結果に対して全体的な信号機を用意するのは非常に簡単です。

個人的には、特定のデータドメインのデータ品質の全体的な値の計算はかなり複雑で、陰謀的な傾向があると思いますが、少なくともデータドメインの結果ごとにグループ化された全体的なルールの数を示すことができます（例：「100DQルール」 90％が緑、5％が黄色、5％が赤の結果になります」）。

調査結果を修正し、データ品質を向上させることは、データ所有者の仕事です。

プロセスの改善

データウェアハウスのプロセスは頻繁に変更されるため、データ品質メカニズムもメンテナンスが必要です。

データ所有者は、常に次の点に注意する必要があります。

最新の状態に保ちます。 データウェアハウスの変更は、データ品質システムでキャッチする必要があります。
強化します。 データ品質ルールでまだカバーされていないエラーの新しいルールを実装します。
合理化。 不要になったデータ品質ルールを無効にします。重複するルールを統合します。

データ品質プロセスの監視

データ品質プロセス全体を監視することは、時間の経過とともにそれを改善するのに役立ちます。

見る価値のあるものは次のとおりです。

データ品質ルールによるデータのカバレッジ
時間の経過に伴うアクティブなルール内のデータ品質の結果の割合
アクティブなデータ品質ルールの数（注意してください。データユーザーがデータ品質ルールを無効にするだけで調査結果を解決しているのを見てきました。）
すべての調査結果を評価および修正するためにデータロード内で必要な時間

結論

以下の点の多くは、あらゆる種類のプロジェクトで重要です。

抵抗を予測します。 これまで見てきたように、緊急の品質問題がない場合、データ品質は新しい機能を提供せずに追加の負担と見なされることがよくあります。データユーザーに追加のワークロードが発生する可能性があることに注意してください。多くの場合、コンプライアンスと規制の要求は、それを避けられない要件と見なすようにユーザーを説得するのに役立ちます。

スポンサーを探す。 上記のように、DQは売れ行きの良いアイテムではないため、強力なスポンサー/利害関係者が必要です。管理のレベルが高いほど、優れています。

味方を探す。 スポンサーと同様に、強力なデータ品質のアイデアを共有する人は誰でも最も役に立ちます。 DQ回路ループは進行中のプロセスであり、回路ループを存続させるために人々を必要とします。

小さく始めます。 これまでDQ戦略がなかった場合は、より優れたデータ品質を必要とするビジネスユニットを探してください。より良いデータの利点を示すためにプロトタイプを作成します。特定のデータ品質戦略を改善または置き換えることがタスクである場合は、組織でうまく機能している/受け入れられているものを確認し、それらを維持します。

全体像を見失わないでください。 小さなことから始めますが、いくつかのポイント、特に役割は、DQ戦略を成功させるための前提条件であることに注意してください。

実装したら、手放さないでください。 データ品質プロセスは、データウェアハウスの使用の一部である必要があります。時間の経過とともに、データ品質への焦点は少し失われる傾向があり、それを維持するのはあなた次第です。