Share
Embed
データ品質管理の第一歩
DevelopersIO 2024 OSAKAで発表した内容となります。
- https://classmethod.connpass.com/event/322915/
Nayuta S.
July 31, 2024
Transcript
41 slides
-
はじめに 6 午前8時30分です。あなたはほとんど⽬が覚めておらず、 コーヒーを飲んで、⽬を覚まそうとしています。 ピン。 “こんにちは︕ 昨⽇の新規サブスクリプション数がLookerで30と表⽰されているのに、 Facebookの広告プラットフォームでは72なのが不思議なんですよね。“ こうして⼀⽇が始まる…。 ※
https://www.getdbt.com/blog/data-quality-frameworkより訳 こんなこと、ありませんか…? -
はじめに 7 データ提供者 データ連携基盤 データ利⽤者 改善要求 データ • 中央集権的な考え⽅だと、データ連携を担う基盤に負荷が集中してしまう ◦
データの流れの中で、どこを担う⼈がやるべきことなのかを整理しつつ、 仕組み全体として破綻しないプロセスを考えていく必要がある <中央集権的な構成でよくある課題> ⾼負荷 -
スピーカー紹介 8 ⽒名 鈴⽊ 那由太(スズキ ナユタ) 所属 データ事業本部 インテグレーション部 機械学習チーム
受賞 2024 Japan AWS Top Engineers(Analytics) -
参考⽂献 [1] データ連携基盤を通して提供されるデータの品質管理ガイドブック ◦ データの品質管理の取組に関するの情報提供の⼀環として公開しているガイドブック ◦ https://www.chisou.go.jp/tiiki/kokusentoc/supercity/pdf/supercity_230926_guidebook_honsi.pdf [2] データ品質管理ガイドブック ◦
⽇本国内におけるデータ品質指標に関する共通認識の形成や、⾼品質なデータ提供を実現するためのガイド ◦ https://github.com/JDA- DM/GIF/blob/v1.38/460_%E5%AE%9F%E8%B7%B5%E3%82%AC%E3%82%A4%E3%83%89%E3%83%96%E3%83%83%E3%82%AF/md/468 -1_guidebook_dataquality.md [3] ⼤規模データ管理(第⼀版) ◦ 組織内でスケールするデータ分析環境を⽤意するためにどのようにすればよいかに焦点を当てた書籍 ◦ 今⽉頭に第⼆版が⽇本語でも発売された ◦ https://www.oreilly.co.jp/books/9784814400089/ 11 -
想定されるアーキテクチャ 14 • ⽂献[1]で想定されるアーキテクチャ • データ提供者はデータ利⽤者がデータを使⽤できるよう、”データ連携基盤”に 品質管理を適切に実施したデータを共有する データ提供者 データ連携基盤 サービス提供者
サービス利⽤者 データ利⽤者 ※文献[1]の図2-1を簡略化 -
想定されるアーキテクチャ 15 • ⽂献[1]で想定されるアーキテクチャ • データ提供者はデータ利⽤者がデータを使⽤できるよう、”データ連携基盤”に 品質管理を適切に実施したデータを共有する データ提供者 データ連携基盤 サービス提供者
サービス利⽤者 データ利⽤者 データを作り出すチームが データ品質管理を知っておく 必要がある。 ※文献[1]の図2-1を簡略化 -
データ品質の特性 16 # 特性 概要 1 正確性 (Accuracy) データの誤り・誤字脱字などがないこと。 2
完全性 (Completeness) 分析に必要なデータ項目がそろっていること。 3 一貫性 (Consistency) データセットに矛盾がないこと。住所コードと住所が合わないなど。 4 信憑性 (Credibility) 出典や更新日があり、データが信頼できること。 5 最新性 (Currentness) 適切なサイクルでデータが新しく更新されていること。 6 アクセシビリティ (Accessibility) データの使用権を持つ人が利用できる状態になっていること。 7 標準適合性 (Compliance) データの入力データが定まっており、その通りになっているか。 8 機密性 (Confidentiality) ハッキング対策や権限制御など、データの機密性が確保されているか。 9 効率性 (Efficiency) 重複有無や一貫性など、処理時に効率的に使える状態になっているか。 10 精度 (Precision) 使用目的に応じて必要な精度があるか。 11 追跡可能性 (Traceability) データの出所や変更者・変更日が明らかか。 12 理解性 (Understandability) データの意味を正しく理解し活用できる状態になっているか。 13 可用性 (Availability) 必要な時にいつでもデータにアクセスできるようになっているか。 14 移植性 (Portability) 入替えやシステム間連携の際にデータを簡易に移行できるか。 15 回復性 (Recoverability) データセンターの事故時などに素早く復元できるか。 ※ 文献[1][2]より整理した、ISO/IEC 25012に沿った観点 -
基礎的品質特性の評価 18 <特性について> • データが信頼できることを担保するための、 利⽤シーンによらず、基本的に必要となる品質特性 • データ利⽤者からのクレームにも繋がりやすい <評価⽅法例> •
ツールなどによるバリデーションチェックを⾏う ◦ 例:本来はカタカナで記⼊すべき項⽬に、平仮名が記⼊されていないか • 以下基準にしたがって評価する ※ 文献[1] の表4-2, 4-3を引用 # 特性 概要 1 正確性 (Accuracy) データの誤り・誤字脱字などがないこと。 2 完全性 (Completeness) 分析に必要なデータ項目がそろっていること。 3 一貫性 (Consistency) データセットに矛盾がないこと。住所コードと住所が 合わないなど。 -
付加的品質特性の評価 19 <特性について> • 基礎的品質特性以外の品質特性 • データ利⽤者からのクレームにも繋がる可能性がある <評価⽅法例> • 各品質特性に関連付けされたメタデータの⼊⼒状況から評価する
• メタデータは必須かどうかを分けておき、網羅性を確認する No 必須区分 メタデータ項目 メタデータ項目の実体(値) 1 必須 タイトル データセットのタイトル 2 任意 サブタイトル データセットのサブタイトル 3 必須 説明 データセットの特徴を第三者に理解してもらうための 説明 4 任意 関連ドキュメント データセットに関する情報を記載するドキュメントへの リンク 5 任意 ランディングページ データセットに関する追加・補足情報を記載するページ へのリンク 6 推奨 標準モデル 参照とした標準モデル 理解性の例(文献[1]の表4-4) 「必須項目の記入判定」の表示イメージ(文献[1]の図4-2) -
データ提供者の品質管理プロセス 20 ※文献[1]の図3-2 データ 品質計画 データ 品質管理 データ 品質保証 データ
品質改善 P D C A データ関連 サポート リソース 提供 -
データ提供者の品質管理プロセス 21 データ 品質計画 データ 品質管理 データ 品質保証 データ 品質改善
P D C A データ関連 サポート リソース 提供 • データの要件と品質の⽬標を確⽴ • 組織全体で⼀貫したデータ品質管理を ⾏うための⼿順‧ルール策定 ※文献[1]の図3-2 -
データ提供者の品質管理プロセス 22 データ 品質計画 データ 品質管理 データ 品質保証 データ 品質改善
P D C A データ関連 サポート リソース 提供 •品質計画に基づいたデータの評価 ※文献[1]の図3-2 -
データ提供者の品質管理プロセス 23 データ 品質計画 データ 品質管理 データ 品質保証 データ 品質改善
P D C A データ関連 サポート リソース 提供 • データの品質が⽬標を満たせているか 測定する。 • 満たせていない場合に原因を確認する ⼿順を実施しているか評価する。 ※文献[1]の図3-2 -
データ提供者の品質管理プロセス 24 データ 品質計画 データ 品質管理 データ 品質保証 データ 品質改善
P D C A データ関連 サポート リソース 提供 •根本原因を特定し再発防⽌策を 実施する。 •恒久策が確⽴されているか確認‧ 評価する。 ※文献[1]の図3-2 -
データ提供者の品質管理プロセス 25 データ 品質計画 データ 品質管理 データ 品質保証 データ 品質改善
P D C A データ関連 サポート リソース 提供 •品質管理プロセスを⽀援するツールや ⽅針が維持‧管理されているか評価 する。 •組織単位で、品質管理プロセスを サポートするのに適切な⼈材や 知識‧スキルが配置‧利⽤されている ことを評価する。 ※文献[1]の図3-2 -
データ品質の責任の所在 27 データ提供者 データ連携基盤 サービス提供者 サービス利⽤者 データ利⽤者 • ⽂献[1]の考え⽅では、データ連携基盤データ利⽤者からデータ連携基盤を通して、 データ提供者へとデータ品質の改善要求/要望が向かう
• データ連携基盤ではなく、データ提供者が要求に対する対応を⾏う 改善要求 改善要求 改善要求 ※文献[1]の図2-1を簡略化 -
データ品質ルールの設計 データ品質チェックルールはチーム内で標準化ことになりそう • チーム内で安定した品質の統制がしやすい • 中央のデータガバナンスチームからの要求に応えやすい 29 ガバナンス担当 リーダー メンバー
こういう品質チェックは 必ずしてね こういう品質チェックは 必ずしてね わかりました! わかりました! 要求 プロジェクト ルール ガバナンスチーム 実行チーム -
付加的だがデータ利⽤に重要な品質特性 データの利⽤には理解性も重要 • 消費側のチームでデータの意味を理解できる情報を提供する データ⾃体も理解できるものとしておく ◦ 値のバリエーションがあるのかカタログに全て書いておく、など ◦ ⽂献[3]でいうところの”読み出し最適化されたデータ”を作る 30
このカラムの値が Aのものは商品Aの レコード。 Bのものは商品Bの レコード。 このカラムの値が大事なんだけど、 nullがいっぱいある。 A・Bのときはわかるけど、 nullのときはなんなんだろう? 意味がある?バグ? 利用 公開 公開されたデータ -
データカタログ 33 データ提供者内ではdbt(DWH向けのOSS)を使うと簡単に ドキュメントが⽣成できる。 モデル・テストの管理およびリネージが確認できる。 • dbt docs generate •
dbt docs serve --port 8001 Open Metadataなど別のデータカタログの製品で取り込みを サポートしている場合もある。 -
データ品質チェック 35 データウェアハウス Glue Data Qualityの接続先の例 AWS Glue Data Quality
データレイク AWS Glue Data Catalog •AWS対象だと、S3・Redshift向けにGlue Data Qualityを使⽤できる •Glueのコンピュートを使⽤し、対象のデータを取得してデータ品質ルールに沿っているか確認する •異常があった場合は、Cloud Watchなどに通知することができる(データオブザーバビリティ) -
まとめ 39 • データを利⽤して⽬的を達成するためには、品質の⾼いデータが必要となる • ISO/IEC 25012に沿ったものだと15の特性がある • データ提供者‧データ連携基盤‧データ利⽤者で役割を分担して対応する必要がある •
データ品質管理を実現するシステム的な仕組みとしては、例えば以下が使えるのでご紹介した ◦ dbt ◦ AWS Glue Data Quality ◦ Amazon DataZone ◦ Informatica CDGC