Upgrade to Pro — share decks privately, control downloads, hide ads and more …

DeNAデータプラットフォームにおけるデータ品質への取組み【DeNA TechCon 2021...

DeNA_Tech
September 29, 2021

DeNAデータプラットフォームにおけるデータ品質への取組み【DeNA TechCon 2021 Autumn】/techcon2021autumn-09

DeNA データプラットフォームは、アナリスト(データ分析担当者)から企画、経営層まで幅広く利用され、データ分析にもとづいた施策や意思決定が行われています。
データプラットフォームにおけるデータ品質の低下は、データ利用者の業務の効率低下を始め、誤集計に基づいた正しくない意思決定による機会損失や信頼の低下による事業損失など様々な弊害を招きます。
DeNA のデータエンジニアは、このようなリスクを低減させ、データ活用ができる環境を整えるべくデータ品質向上に取り組んでいます。
本セッションでは、データ利活用において担保すべき品質基準、モニタリング指標、運用などデータ品質向上の取り組みの具体例をもとにお話します。

DeNA_Tech

September 29, 2021
Tweet

More Decks by DeNA_Tech

Other Decks in Technology

Transcript

  1. Speaker 野本 大貴(Hirotaka Nomoto) - データエンジニア - 2019年9月入社 - データパイプラインの開発・運用

    - ゲーム事業のデータプラットフォームのクラウド移行を推進 - データ品質への取り組みをリード
  2. 現在のデータプラットフォーム 概要 - Google Cloud を使った構成 詳細はこちら Google Cloud を使ったデータ

    プラットフォームへの変革と 最新の活用状況について Google Cloud Data Platform Day #2 2020/03/31 https://cloudonair.withgoo gle.com/events/jp-data-pla tform-day
  3. これまでの取り組み ✅ データマネジメント(BigQuery の分析コスト最適化) ✅ Looker を活用したデータの民主化・データガバナンスの強化 詳細はこちら DeNA のデータ活用を支える

    BigQuery データの民主化とガバナンス強化の軌跡 第 11 回 Google Cloud INSIDE Games & Apps: Online(2020/09/09)     https://www.slideshare.net/GoogleCloudPlatformJP /dena-bigquery-google-cloud-inside-games-apps-online データは分散管理へ Looker を活用した次世代データパイプライン BEACON Japan 2020(2020/09/10) https://dev.classmethod.jp/articles/report-looker-beacon-japan-20200910-dena/ より便利で安心なデータプラットフォームを目指して
  4. 最近の取り組み - データマネジメント知識体系ガイド(DMBOK)への準拠を進めています - データ品質 - メタデータ管理 - データセキュリティ DAMAホイール

    データマネジメント 知識体系ガイド 第二版より より便利で安心なデータプラットフォームを目指して
  5. データ品質への取り組みのアウトライン  PLAN - ゴール(利用者の期待)を明確化 - ターゲットの設定 DO - モニタリングシステムの構築 -

    対象のデータの依存関係の把握 - 可視化(システム・Dashboard 作成) ACT - 改善 - 振り返り CHECK - 品質レベルの共有 - 通知
  6. データ品質への取り組みのアウトライン  PLAN - ゴール(利用者の期待)を明確化 - ターゲットの設定 DO - モニタリングシステムの構築 -

    対象のデータの依存関係の把握 - 可視化(システム・Dashboard 作成) ACT - 改善 - 振り返り CHECK - 品質レベルの共有 - 通知 イマココ(1サイクル目) @Pococha
  7. データ品質への取り組みの改善サイクル  PLAN - ゴール(利用者の期待)を明確化 - ターゲットの設定 DO - モニタリングシステムの構築 -

    対象のデータの依存関係の把握 - 可視化(システム・Dashboard 作成) ACT - 改善 - 振り返り CHECK - 品質レベルの共有 - 通知
  8. PLAN: ゴール(利用者の期待)を明確化  ✅ 利用者の業務とデータに求められる基準を把握する - 利用者へヒアリング - 閲覧履歴などのメタデータ分析 - 頻繁に検索されているテーブル

    - 閲覧件数が多いレポート 用途 約束相手 連絡先・周知先 利用データ 約束事項(SLA) 違反時の影響範囲 主要KPI レポート 事業部全体 アナリスト Slack #foo 売上に関する テーブル <dataset.table> 毎日朝10時までに異常なく 前日までのデータが 該当テーブルに集計されること - 間違った数値に基づいて意思決定 してしまう - 数値がみれず意思決定が遅れる ヒアリングの例
  9. PLAN: ターゲットの設定 ✅ 対象のデータを決定 - 売上など主要な KPI の中間テーブル(22テーブル) ✅ 評価軸・目標を決定

    1. NULL や重複がないこと 2. データ件数が正常であること 3. テーブル間で不整合がないこと 4. 必要な時間までにテーブルが更新されていること 重要な業務・データを優先 的に設定 計測可能なデータの特徴や 特性で重要なものを設定
  10. データ品質への取り組みの改善サイクル  PLAN ✔ ゴール(利用者の期待)を明確化 ✔ ターゲットの設定 DO - モニタリングシステムの構築 -

    対象のデータの依存関係の把握 - 可視化(システム・Dashboard 作成) ACT - 改善 - 振り返り CHECK - 品質レベルの共有 - 通知 対象: 売上など主要な KPI の中間テーブル(22テーブル) -> これらだけをモニタリングすればいい? NO!元となる上流データもモニタリング必要!
  11. DO: 対象のデータの依存関係の把握 - 上流のデータでモニタリング必要だが、数が多く依存関係の把握が大変。。。 => 工夫) メタデータから依存関係を抽出・可視化 作成した依存関係抽出ツールの構成: System Activity

    BigQuery INFORMATION_SCHMA.JOBS_BY 依存関係を確認 したいテーブル名 依存関係を抽出した テーブルのリスト 再帰的に依存関係を抽出 自動で最新の依存関係を把握 BigQuery
  12. DO: 対象のデータの依存関係の把握 把握したい依存関係の例: ②依存関係のあるテーブルを抽出: 1. 依存関係を確認したいテーブルが出力先の JOB 履歴を検索し、参照元を抽出する。 (出力先: 中間テーブル,

    参照元: 上流データ3,4) 2. 1.で抽出した参照元が出力先の JOB 履歴を検索し、参照元を抽出する。 (出力先: 上流データ3, 参照元: 上流データ1,2) これを繰り返す 参照元 出力先 上流データ1 上流データ3 上流データ2 上流データ3 上流データ3 中間テーブル 上流データ4 中間テーブル 中間テーブル レポートID … 依存関係の抽出の例: ①メタデータから入出力を整形: …
  13. データ品質への取り組みの改善サイクル  PLAN ✔ ゴール(利用者の期待)を明確化 ✔ ターゲットの設定 DO - モニタリングシステムの構築 ✔

    対象のデータの依存関係の把握 - 可視化(システム・Dashboard 作成) ACT - 改善 - 振り返り CHECK - 品質レベルの共有 - 通知 1. NULL や重複がないこと 2. データ件数が正常であること 3. テーブル間で不整合がないこと 4. 必要な時間までにテーブルが更新されていること
  14.  目的: 主キーだがNULL/重複があるなどの異常をチェック DO: 可視化(1/4) NULL/重複チェック DashBoard の例 select countif(safe_cast(date as

    string) || safe_cast(user_id as string) is null ) as cnt_pk_null, [ struct(col1 as column_name, countif( col1 is null ) as cnt_null, ... 入力 table_name partition_key check_col tableA date, user_id col1, col2,... 生成されるクエリの例 tableA tableA tableA col1 col2 col3 % CHECK データのプロファイルを 数値で確認 BQには主キーがない
  15. DO: 可視化(2/4) データ件数の変動チェック  目的: 正常でない急激な件数の変化をチェック % DashBoard の例 table_name count_col

    tags_key tableA user_id key_col 入力 select struct (’key_col’ as key, cast(key_col as string) as value) as tags, … from ( select key_col, count(user_id) as cnt, from `tableA` group by key_col ) 生成されるクエリの例 tableA tableA tableA key_col key_col key_col foo bar val CHECK 視覚的に異常がわかる
  16. DO: 可視化(4/4) 遅延の検知(テーブル更新時間のチェック)  目的: 遅延のチェック(関連テーブルの更新時刻・処理時間の長さのチェック) - BigQuery のメタデータ:INFORMATION_SCHMA, __TABLES__ から抽出

    tableA tableB tableC tableD tableE 平均 更新時刻 平均 処理時間[分] 処理時間の長い箇所を把握 ー>必要に応じて対応 遅延の有無を確認 更新済み:1 遅延:-1 未更新:0 遅延判定 時刻
  17. データ品質への取り組みの改善サイクル  DO ✔ モニタリングシステムの構築 ✔ 対象のデータの依存関係の把握 ✔ 可視化(システム・Dashboard 作成) ACT

    - 改善 - 振り返り CHECK - 品質レベルの共有 - 通知 PLAN ✔ ゴール(利用者の期待)を明確化 ✔ ターゲットの設定
  18. CHECK: 品質レベルの共有, 通知 - 品質レベルの共有(基本的に月1開催) - 対象とした22テーブルの内の数テーブルで、主キーに NULL があった -

    近いうちに、更新時間が必要な時間を超過する懸念 - 異常の通知の構成(試行錯誤中) or アラート機能 定期実行 slack通知 Assert 関数 Dashboard を用いて品質レベルを 定量的に共有できた BigQuery
  19. データ品質への取り組みの改善サイクル  DO ✔ モニタリングシステムの構築 ✔ 対象のデータの依存関係の把握 ✔ 可視化(システム・Dashboard 作成) ACT

    - 改善 - 振り返り CHECK ✔ 品質レベルの共有 ✔ 通知 PLAN ✔ ゴール(利用者の期待)を明確化 ✔ ターゲットの設定
  20. ACT: 改善 - 改善 ✅ 対象とした22テーブルの内の数テーブルで、主キーに NULL があったが、ほぼ解消できた    ✅

    更新時間が必要な時間を超過する前に検知し、対処できた 👍 利用者からのコメント    「データ品質が担保されている」という状態から分析をスタートできる     ようになり、大変な安心感が生まれた 地道に集計ロジックを修正し てくれたアナリストに感謝!
  21. 今後の展望  - 振り返り - チェック項目の追加・精査 - プロセスの磨き込み - オープンソースの活用の検討 -

    Cloud Data Quality Engine(dataplex) https://github.com/GoogleCloudPlatform/cloud-data-quality - Data Validation Tool https://github.com/GoogleCloudPlatform/professional-services-data-validator - 各サービスへ横展開を進めていく