上級プラットフォームエンジニアのための最高のデータ品質フレームワーク

そのため、社内の消費者であれ社外の消費者であれ、データがビジネスの機能にとって重要であると考える組織は、データ品質管理を実践し、データ品質フレームワークを実装する必要があります。つまり、システムに入力され、下流に送信されるデータが、あなたと消費者が期待するものであることを保証するため、繰り返し可能かつ理想的には自動化されたプロセスとパターンを開発しなければなりません。

上級データ・エンジニアはこの点について熟知しているとおり、こうした期待を理解することが取り組みの半分を占めます。残りの半分の多くは、それらの期待を、複雑な取り込みプロセスの問題を見つけて修正するのに役立つ追跡とアラートに変換することに費やされます。

このガイドでは、データ品質管理が既存のハードコードされたプロセスに単純に組み込まれるのではなく、すべてのDAGに組み込まれるようにするための戦略を紹介します。適切に管理するには、低品質のデータが変換レイヤーに入るずっと前に異常を検出する必要があります。

その定義からお伝えすると、データ品質フレームワークとは、組織が関連するデータ品質属性を定義し、データ品質が消費者の期待（SLA）を継続的に満たすようにするためのデータ品質管理プロセスのガイダンスを提供するために使用できるツールです。

この文は一見すると複雑なので、詳しく説明します。

1. プロセスが必要：エンジニアの作業時間が無制限でない限り、プロセスには、データ・パイプラインの各段階（特に、問題を事前に検出したい場合は取り込み時）での繰り返し可能な、理想的には自動の単体テストと、データの問題に対処するためのワークフローが含まれている必要があります。
2. 継続的な確認：データ品質はデータ速度に比例して低下します（データ・ドリフトとも呼ばれます）。現在取り扱われている多くの高速データは、頻繁にチェックする必要があります。
3. 自社の期待ではなく、消費者の期待に応える：データ品質は基本的にビジネス・プロセスを決定します。データ SLAまたは「サービス契約」は消費者と結ぶものであり、データサイエンティストがモデルを実行できない場合、顧客が不正確な配送見積もりを受け取った場合、またはダッシュボードが読み込まれなかったために地域副社長が何も持たずに取締役会に出席しなければならない場合、エンジニアリング側ですることには何も意味がありません。

上記の約束を果たすには多くの要素が必要であり、それぞれの要素には依存関係が満ち溢れています。例えば、そのようなシステムをどのように設計するかを自問するとしたら、次のような質問をすることになります。

1. データ品質に関する消費者の期待をどのように理解するのか。
2. こうした期待を、データ品質の定量化可能な尺度にどのように変換できるか。
3. 各パイプラインの品質の自動測定をどのように組み込むか。
4. データ品質の各次元のしきい値をどのように決定するか。
5. データがこれらのしきい値を超えた場合、どのようにしてチームに警告するか。
6. アラートを受け取ったとき、チームは何をするか。
7. アラートの有効性と緊急性をどのように判断するか。
8. 問題がある場合、直接的な原因をどのように特定するか。
9. 根本原因をどのように特定するか。
10. 消費者に何が期待できるかをどのように通知するか。
11. 根本的な原因にどのように対処するか。
12. 根本原因に対処したことをどのように確認するか。
13. 知識を蓄積するため、起きたことをどのように文書化するか。

自問することが多くて怖気づいてしまいましたか。恐れることはありません。この作業は専門家に委任することができます。

質問1は、ポッドまたはスクワッドのビジネス・アナリストに任せましょう。事業部に相談して、ユーザー・ストーリー、提示された嗜好、暗示的な好み、要求、およびイベントの事後分析をデータの「要求」のリストに分けるかは、彼らに判断させます。これらは消費者がデータに対して抱く定性的な期待であり、消費者は自分が何を望んでいるのかを正確に表現する言葉を持っていない可能性があるため、双方向の会話になります。（データ消費者がデータサイエンティストでない限り、これを大幅にスピードアップできます。）

質問2は、データサイエンティストが一緒に回答するものです（特に、データサイエンティストが消費者でもある場合）。各パイプラインのデータ特性を考慮すると、定性的な期待のリストを定量的な測定値のリストにさらに分解するために実際に測定できる属性は何ですか。

従うデータ品質モデルに応じて、注目すべき品質の次元は4つまたは5つあります。IBM® Databandでは、次の4つの特性を持つモデルを推奨しています。

• 適合性
  • 精度 - データが現実を反映していること
  • 完全性 - 品質／時間
• リネージュ
  • 情報源 - 情報提供者が貴社の期待に応えていること
  • 起源 - 情報の抽出元
• ガバナンス
  • データ・コントロール
  • データ・プライバシー
  • 規制
  • セキュリティー
• 安定性
  • 一貫性
  • 信頼性
  • 適時性
  • バイアス

これらのメトリクスに基づき、データ・エンジニアは質問3から13に取り組み、データ品質管理戦略の構築を開始することができます。その方法を具体的に説明する前に、なぜこのような作業が必要なのかを考えてみましょう。

数年前、大手小売業者のMicrosoft Dynamics CRM社の無害な構成変更により、オンラインの各商品に表示される在庫の数が現実を反映しなくなり、カウンターが更新されなくなりました。

つまり、顧客が購入しても、在庫数は一定に保たれました。データ・エンジニアリング・チームが警告を受ける頃には、事態は最悪なものになっていました。

ほとんどの商品はオンラインで購入可能でしたが、店頭での受け取りも可能であったため、多くの人が店舗受け取りを選択しました。存在しない商品にもかかわらず、注文が処理され、販売手続きが完了しました。結果、購入者が店を訪れた時点で店員は代替品を探したり、割引を約束したりして、何とか顧客をなだめようとしました。ここで、商品の購入行列ができ、来店者は購入するために待たなければならないだけではなく、多くの人が携帯電話に向かって怒鳴っている様子に、うんざりしていました。また、問題を発見し、パイプラインが修正されるまでに数日かかり、問題が解決するまでにはさらに数日かかりました。

ブランドの評判の低下を考慮に入れると、このミスには数千万ドルの損害が発生しました。

言うまでもなく、データの問題は複雑です。それらを発見して対処するのは困難である上、見えないところで問題は大きくなっている場合があります。水面下でデータの問題が悪化しているにもかかわらず、まだ何らかの洞察が得られているという理由だけで、すべてがうまくいっていると思い込むパターンに陥りがちです。

さらに、データ品質の問題の最も真の兆候は、遅行指標である傾向もあります。例えば、消費者からの苦情などです。あるいは、上述の小売業向けCRMの例のように、何千人もの小売経営者や地域副社長から問題が指摘される場合です。これはうれしくない状況と言えるでしょう。これは、データが一定期間システム内に存在し、修正から結果が出るまでに数日かかることを意味します。これでは、消費者の期待には応えられないでしょう。

これは、配送スタートアップのShipper社が実際に直面した状況で、このような事態の再発を防ぐために多額の投資を行った理由です。同社のデータ・エンジニアリング・チームは、eコマース・ベンダーが在庫を出荷港に配送するのに役立つアプリケーションに、可能な限りリアルタイムに近いデータを提供します。心配しなければならないのは、顧客の期待だけではありません。その顧客の期待も考慮しなければなりません。同社のシステムは2日ほど更新されないことがあり、顧客の期待に応えられない状況を作り出していました。このため、同社はデータ品質管理と、自動チェックによる早期警告アラートを提供できるツールに多額の投資を行いました。

データ品質管理は、データ品質チェックを自動化し、広範囲に実施する方法であり、データセットとパイプラインに対するエントロピーの力に、同等かつ反対の力で対抗することになります。

前の例と質問のリストに戻りましょう。アナリストが企業と話をして要件を収集すると、データサイエンティストから消費者の期待の定量的なリストを受け取ります。では、どのように進めてシステムを構築するのでしょうか。

データ品質のフレームワークを活用します。フレームワークは、何よりもまず、システムが一貫したプロセスで稼働し、進化し続ける消費者の期待についての洞察すべてがシステムに影響を与える必要があります。

それぞれの段階について詳しく見ていきましょう。

1. 適格性評価：ビジネス・アナリストは消費者のニーズを要件リストで分類します。
2. 定量化：データサイエンティストは、要件をデータ品質の定量化可能な尺度に基づき分類しますが、この時点ではまだ理論上のものにすぎません。
3. 計画：データ・エンジニアは、データ品質の定量的な測定値を、データ・パイプラインの観測性プラットフォームで実行できるチェック事項に変換します。このようなプラットフォームは重要です。AirflowやSparkなどのワークフローおよびパイプライン・スケジューリング・システムは、パイプライン自体の問題を検出できますが、ほとんどの問題が発生するデータ内の問題は検出できません。エンジニアは、システム内で追跡できるものと追跡できないものを理解する必要があります。
4. 実行：データ・エンジニアが追跡を実行し、テストします。非常に単純な例として、データがすべて存在し、フィールドや列が欠落していない必要がある場合は、データの完全性パラメーターに関するアラートを設定できます。Databandのような可観測性プラットフォームはこれを可能にし、異常値の検出を設定できるため、すべての値を手動で設定する必要がなくなります。
5. 管理：データ・エンジニアは、これらのアラートを過去のパイプライン・データに照らしてバックテストし、実際に意図したとおりに機能したかどうかを確認します。意図したとおりに機能していた場合、アラートが発生したときの責任者や、アラートを受け取ったときの対処を定めたインシデント管理計画とともに、それらを本番環境に導入します。
6. 検証：データ・エンジニアとデータサイエンティストは、データ管理フレームワークを導入することで、望ましい指標に沿ってパフォーマンスが測定可能に向上したことを確認します。ビジネス・アナリストは、これが事実であることを消費者に確認します。

フレームワークを活用しましょう。

多くの例で検討したように、データ品質の問題を示す最悪の指標は、遅延指標です。例えば、消費者から何かが壊れていると苦情がある場合などです。データ・エンジニアリングでは、パイプラインの構築とともに信頼を得られるように取り組みます。

チームが問題を自動的に特定できるようにするデータ品質管理フレームワークに投資することで、信頼できるデータを作成できます。そうすれば仕事はずっと楽になります。

IBM Databandのデータ品質の監視機能は、予期せぬ列の変更とNullレコードを検出して、データ品質の監視を強化し、データのSLAの達成を促進する方法をご覧ください。さらなる詳細については、今すぐデモを予約してください。