Slide 1

Slide 1 text

© 2023 NTT DATA Japan Corporation © 2023 NTT DATA Japan Corporation データ品質評価の お悩みと 解決方法を考えてみた 2023年9月1日 株式会社NTTデータ 佐川 未紗

Slide 2

Slide 2 text

© 2023 NTT DATA Japan Corporation 2 自己紹介 株式会社NTTデータ 名前:佐川未紗 仕事:システムインテグレータの立場で 某社様データ分析基盤開発プロジェクトを担当 # 内容 キーワード 1 データ分析基盤グランドデザイン提案&構築 #DWH #snowflake #MLOps #AWS 2 旧オンプレデータ基盤からSnowflakeへのデータ移行 &新規取込データの仕様調整 #ETL #処理性能 #データ運用 #データアクセス制御 #取込要件調整 3 開発品質・データ品質改善のためのプロセス・ルール作りやデータ運用 #データマネジメント #データ品質 #利用者問合せ #ガイドライン作り データ運用のつらさから データマネジメントの重要性を 痛感して勉強はじめました

Slide 3

Slide 3 text

© 2023 NTT DATA Japan Corporation 3 今日ディスカッションしたいこと Q1. データ品質要件はどのように決めていますか? Q2. 品質要件を守るために、どのような対策を入れていますか? Q3. データの品質をモニタリングする仕組みは入れていますか?

Slide 4

Slide 4 text

© 2023 NTT DATA Japan Corporation 4 目次 1.なぜデータ品質? 2.品質要件はどのように定義するのか(未解決) 3.データの品質要件を守るためにやっていること

Slide 5

Slide 5 text

© 2023 NTT DATA Japan Corporation 5 1.なぜデータ品質 一般的に・・ データ品質 … データが利用者の要求を満たすレベルであること データの品質が 悪い 分析結果が信用 ならない データをもとにした 意思決定ができ ない データ活用が 進まない 評価観点:ISO/IEC 25012(データ品質の評価) 正確性 完全性 一貫性 信憑性 最新性 アクセシビリティ 標準適合性 機密性 効率性 精度 追跡可能性 理解性 可用性 移植性 回復性

Slide 6

Slide 6 text

© 2023 NTT DATA Japan Corporation 6 1.なぜデータ品質 担当プロジェクト System1 System2 System N System M ビジネス側での利用状況把握が 不十分な状態で大量取り込み 旧データ基盤(オンプレミス) カタ ログ 他 データ基盤の利用者を増やす取り組みがスタート ●まずはデータが基盤に存在することを優先し、データ用途の把握が不十分な状態でデータを大量取り込み。

Slide 7

Slide 7 text

© 2023 NTT DATA Japan Corporation 7 1.なぜデータ品質 担当プロジェクト System1 System2 System N System M 旧データ基盤(オンプレミス) カタ ログ 他 データ基盤の利用者を増やす取り組みがスタート ●まずはデータが基盤に存在することを優先し、データ用途の把握が不十分な状態でデータを大量取込み。 ●スピード重視のデータ取り込みにより、データ品質が利用者の要望を満たせていない状態。 <DWHデータセットトラブル例> ・金額合算値の計算ロジックが不適切 ・レコード重複の発生 等 <利用者指摘で発覚するデータ不正例> ・文字化け項目の発生 ・DATE型の項目がVARCHAR型に ・周知なく遅延しているデータ

Slide 8

Slide 8 text

© 2023 NTT DATA Japan Corporation 8 1.なぜデータ品質 担当プロジェクト System1 System2 System N System M 旧データ基盤(オンプレミス) カタ ログ 他 データパイプライン開発プロセスの見直しや、DWHデータセット作成時の強化試験観点の整理などにより、 品質改善に取り組んできた <DWHデータセット> ・金額合算値の計算ロジックが不適切 ・レコード重複の発生 等 <データレイク一元管理のデータ> 利用者指摘で発覚するデータ不正 ・URL項目の文字化け ・DATE型の項目がVARCHAR型に ・周知なくデータが遅延してる 開発プロセスの振返り・修正 重要データセットの 強化試験の実施

Slide 9

Slide 9 text

© 2023 NTT DATA Japan Corporation 9 1.なぜデータ品質 担当プロジェクト System1 System2 System N System M 旧データ基盤(オンプレミス) カタ ログ 他 しかし、現在も利用者からは、データの使い方に関する問い合わせが多数発生。 開発プロセスを中心に対策を打ってきたもののまだまだ利用者が使いやすいデータになっていない。 →どこまでを満たせばいいのか・・?どう対策していけばいいのか・・? 同じ項目名なのに違 う意味のデータがあ る・・(件数が違う) カタログの項目説 明が異なっている 新サービスの分析がし たいが、どうやって抽 出すればいいか分から ない

Slide 10

Slide 10 text

© 2023 NTT DATA Japan Corporation 10 目次 1.なぜデータ品質? 2.品質要件はどのように定義するのか(未解決) 3.データの品質要件を守るためにやっていること

Slide 11

Slide 11 text

© 2023 NTT DATA Japan Corporation 11 2.品質要件はどのように定義するのか 大量データ取り込み時にデータ基盤全体のSLOを決めようとしたがふわっとしたものに。 それぞれのデータの 用途や品質要件が いまいち分からない 一律で最低限のチェックを入れ た方がいいのかもしれないが、 最低限のラインってなに?? 担当プロジェクトの悩みごと

Slide 12

Slide 12 text

© 2023 NTT DATA Japan Corporation 12 2.品質要件はどのように定義するのか 品質要件のライン 利用者指摘=利用者が使える状態のデータでない=品質要件を満たせていない では? しかし、利用者指摘を待つ →使おうとしたときにデータが汚染している →使えない・・・ 利用者指摘 たしかにそれは まずい・・ 全体周知 データ修正 誰も気づかない 間違ったデータから 施策実施 +α 潜在的な要件 品質要件最低ライン

Slide 13

Slide 13 text

© 2023 NTT DATA Japan Corporation 13 2.品質要件はどのように定義するのか 品質要件のライン 利用者指摘は最後の砦と考えて、品質要件を合意してその前に品質を守れるように防ぐまたは気づいて直すことが大事 パイプライン製造 時の試験 日々ファイル取込 時のアラート 利用者指摘 たしかにそれは まずい・・ 全体周知 全体周知 データ修正 データ修正 修正 誰も気づかない 間違ったデータから 施策実施 公開データ モニタリング 最後の砦 第3の砦 第2の砦 第1の砦 品質要件ライン? 検知 バグ発見 検知 全体周知 データ修正

Slide 14

Slide 14 text

© 2023 NTT DATA Japan Corporation 14 2.品質要件はどのように定義するのか 品質要件ってどうやって収集する? 既に取り込んだ2000テーブル の品質要件はどうやって設定 する・・?データの利用者は増 減することもあるのでは ①いっそ今までのトラブルを分析して一律の定義にするか ⇒一律守るべき条件というよりは可視化するパラメータくらいがいいかも。そこへのアクション優先度は用途次第 ②大量テーブル全部の用途を利用者に聞きにいくか ×直接聞いて回るのは人と時間がかかりすぎ ◎ユーザーにカタログや回答フォームからデータを使うタイミングで品質希望を投入してもらう?? ⇒動線をつくって投入してもらう ・現状を可視化して、フィードバックをもらうサイクル ・投入してもらった情報を押しなべて優先度判断ができるように定量的に取得

Slide 15

Slide 15 text

© 2023 NTT DATA Japan Corporation 15 2.品質要件はどのように定義するのか どんな軸で要求をだしてもらう? ●品質評価軸をベースに必要な項目だけヒアリングする?&項目ごとに求める品質は異なるのでは? 評価項目 内容 評価項目 内容 正確性 書式が正しいこと、データに誤りがないこと 例)日付や数字が記述されるべき欄に「不明」な ど数字以外の文字列が記述されていないか 要 機密性 ・データにアクセスできるのは、アクセスを許可された者に限 定されていること 例)ソフトウェアに脆弱性がないか、共有範囲に誤りがな いか 基盤全般 完全性 必須項目が欠損していないこと 例)データが取得できないという理由で必須項目 に空欄がないか 要 効率性 ・データに重複がない ・効率的に処理できる 例)全半角が混在していないこと、日付項目のずれ、外 部キーがない 要 一貫性 データセット間/内でデータに矛盾がないこと 例)テーブルAの支社コードとテーブルBの支社コー ドが一致しているか 要 精度 十分な精度があること 例)桁数が足りているか 要 信憑性 改ざんされていないか、出所は明らかか 例) データの出典や収集方法が不明でないか 問題なし 追跡可能性 原典まで遡れること 例)出所が明確か、変更記録があ るか 基盤全般 最新性 Freshne ss データは収集時から十分に短い期間で公開されて いること。 例)データが更新されていないものがないか。デー タの公開に半年近くかかるなどがあるか。 要 理解性 データ全体及びその各項目が意味するものを利用者が理 解できるようになっていること。 例)コード値説明やデータ説明があるか 要 アクセシビ リティ ファイルで提供している場合、データの使用権を持 つ全ての人が利用できるようになっていること 例)特殊なファイル形式になってないか、環境依 存文字などが使用されていないか 問題なし 可用性 必要なときにいつでもデータアクセスできること 例)アクセス可能な時間帯が限定されていないか 問題なし 標準適合 性 データがルールに沿っていること 例)和暦や略称を使っていないか 基盤全般 移植性 標準的な形式でデータをエクスポートできること 問題なし

Slide 16

Slide 16 text

© 2023 NTT DATA Japan Corporation 16 2.品質要件はどのように定義するのか どんな軸で要求をだしてもらう? ●品質評価軸をベースに必要な項目だけヒアリングする?&項目ごとに求める品質は異なるのでは? 項目名 PK 正確性 完全性 一貫性 最新性 精度 理解性 会員ID ● 100% 100% 100% 3日遅れまで は許容 ー 購入 商品ID 100% 100% 100% ー 購入 タイムスタン プ ・・・ ー 購入 支店名 ・・・ ー … ・・・ ー バッチ処理 日付 ・・・ ー

Slide 17

Slide 17 text

© 2023 NTT DATA Japan Corporation 17 2.品質要件はどのように定義するのか どんな軸で要求をだしてもらう? ●品質評価軸をベースに必要な項目だけヒアリングする?&項目ごとに求める品質は異なるのでは? 項目名 PK 正確性 完全性 一貫性 最新性 精度 理解性 会員ID ● 100% 100% 100% 3日遅れまで は許容 ー 購入 商品ID 100% 100% 100% ー 購入 タイムスタン プ ・・・ ー 購入 支店名 ・・・ ー … ・・・ ー バッチ処理 日付 ・・・ ー みなさん、データ品質要件はどのように決めていますか?

Slide 18

Slide 18 text

© 2023 NTT DATA Japan Corporation 18 目次 1.なぜデータ品質? 2.品質要件はどのように定義するのか(未解決) 3.データの品質要件を守るためにやっていること

Slide 19

Slide 19 text

© 2023 NTT DATA Japan Corporation 19 3.データの品質要件を守るために何をしているか 担当プロジェクトのチェックポイント データ収集→統合→運用 の各プロセスで汚染が混入する可能性があるがまずは開発プロセスでブロックすべき。 日々のデータのモニタリングを現状提供できていない。エンジニアリングチームってなにをモニタリングしている? パイプライン製造 時の試験 日々ファイル取込 時のアラート 利用者指摘 誰も気づかない 間違ったデータから 施策実施 公開データ モニタリング 最後の砦 第3の砦 第2の砦 第1の砦 品質要件ライン? 仕様の充足確認 鮮度/歯抜け/桁数超過 レイアウトチェック 遅延状況、VIEW遅延発生率 汚染状況 を公開 収 集 統 合 運 用 収 集 統 合 運 用 × × ×

Slide 20

Slide 20 text

© 2023 NTT DATA Japan Corporation 20 3.データの品質要件を守るために何をしているか 公開データモニタリングの必要性 モニタリングの必要性自体がまだ浸透していない。 To みなさん ・品質要件を守るために、どのような対策を入れていますか? ・データの品質をモニタリングする仕組みって入れていますか? ・要件に関わらず一律?エンジニアリングチームと分析チームどっちかがやっている? ※MONTE CARLO(https://www.montecarlodata.com/blog-what-is-data-observability/) 「ETL パイプラインがどれほど強力であっても、SQL を何回レビューしたとしても、データは信頼できませんでした。」 「データの可観測性は、DevOpsの可観測性と同様にDataOpsにとっても不可欠である」 Data Observability(可観測性) 1.鮮度 2.品質(正確性、完全性、一貫性、精度) 3.データ量 4.スキーマ変更(データのレイアウト変更) 5.リネージュ

Slide 21

Slide 21 text

© 2023 NTT DATA Japan Corporation 21 今日ディスカッションしたいこと Q1. データ品質要件はどのように決めていますか? Q2. 品質要件を守るために、どのような対策を入れていますか? Q3. データの品質をモニタリングする仕組みは入れていますか?

Slide 22

Slide 22 text

© 2023 NTT DATA Japan Corporation 22 Appendix

Slide 23

Slide 23 text

© 2023 NTT DATA Japan Corporation 23 データ品質に関する体系的な整理 データ品質に関して、3つのISO標準定義が存在している。 1.ISO/IEC 25012(データ品質の評価) データそのものの品質 ⇒品質評価指標15観点 2.ISO/IEC 25024(サービス品質の評価) データを使ったサービス実現プロセスに関する品質 3.ISO/TS 8000-61(データ管理プロセスの評価) データの整備から活用までの管理プロセスに関する品質 ■参考:政府CIOにて公開 2021年6月4日 『データ品質管理ガイドブック β版』 https://cio.go.jp/sites/default/files/uploads/documents/data_hinshitu_guide_beta.pdf 正確性 完全性 一貫性 信憑性 最新性 アクセシビリティ 標準適合性 機密性 効率性 精度 追跡可能性 理解性 可用性 移植性 回復性 データ設計 データ収集 データ統合 外部データ取得 外部サービス利用 データ処理(サービス内容) 提供 データ蓄積 廃棄 データ品質計画 データ品質コントロール データ品質保証 データ品質改善 データ関連サポート リソース規定