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

公開: 2022-03-11

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

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

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

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

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

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

用語の定義

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

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

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

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

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

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

データ品質

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

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

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

データ品質回路ループ

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

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

データ品質の役割

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プロセスは、できるだけ早く実行して報告する必要があります。理想的には、チェックしたデータがロードされた直後です。これは、データウェアハウスのロード中にエラーをできるだけ早く検出するのに役立ちます（一部の複雑なウェアハウスシステムのロードには数日間の期間があります）。

分析する

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

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

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

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

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

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

データ品質ダッシュボードには、次のものが含まれている必要があります。

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

ダッシュボードには、最近のデータウェアハウスのロードプロセスの現在のステータスも表示され、ユーザーはデータウェアハウスのロードプロセスを360度見渡せるようになります。

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

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

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

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

プロセスの改善

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

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

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

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

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

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

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

結論

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

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

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

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

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

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

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