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

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

Transcript

1. DeNAデータプラットフォーム におけるデータ品質への取組み 野本 大貴(Hirotaka Nomoto)
2. Speaker 野本 大貴(Hirotaka Nomoto) - データエンジニア - 2019年9月入社 - データパイプラインの開発・運用 - ゲーム事業のデータプラットフォームのクラウド移行を推進 - データ品質への取り組みをリード
3. DeNA のデータエンジニアの位置付け - 全社のデータ活用水準の向上を目的としている ゲーム事業 システム本部（全社横断組織） 分析推進部 データエンジニアリング G その他の事業, 横断組織 ライブストリーミング 事業 サポート サポート サポート
4. 背景・データ品質への取り組もうとした理由　 🎉 データプラットフォームを刷新するクラウド移行が完遂！ その裏で、データ品質に起因する様々な苦労・利用者の業務へ影響が発生してしまいました。。。 😱 元データの型が変わり、集計でエラーが発生するようになる 😱 データ件数が前日と比べて異常に少なく、データ利用者から問い合わせがくる 😱 データ抽出が遅れて、データ提供先への連携が遅れる etc... ⇒ 利用者の業務へ影響を防ぎ、業務へ集中してもらいたい！ 　　　　 この様な背景に共感を覚える方は、 是非ご視聴下さい！
5. コメント、質問をお待ちしております　 - Twitter からの投稿お待ちしております！ - #データ品質 のハッシュタグで質問ツイートをいただけると 本日回答できなかった場合にも DeNA Analytics Blog - Medium などで 後日回答差し上げます。
6. 本日お話すること　 - イントロダクション - DeNA のデータプラットフォームについて - データ品質への取り組みについて - 取り組みのプロセス - モニタリング方法
7. DeNA のデータプラットフォームについて
8. 現在のデータプラットフォーム 概要 - Google Cloud を使った構成 詳細はこちら Google Cloud を使ったデータ プラットフォームへの変革と 最新の活用状況について Google Cloud Data Platform Day #2 2020/03/31 https://cloudonair.withgoo gle.com/events/jp-data-pla tform-day
9. 現在のデータプラットフォーム 規模　 Tables 600k + Projects 100 + Scan 300TB/day
10. これまでの取り組み ✅ データマネジメント(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/ より便利で安心なデータプラットフォームを目指して
11. 最近の取り組み - データマネジメント知識体系ガイド（DMBOK）への準拠を進めています - データ品質 - メタデータ管理 - データセキュリティ DAMAホイール データマネジメント 知識体系ガイド 第二版より より便利で安心なデータプラットフォームを目指して
12. データ品質への取り組みについて 〜課題や概要の紹介〜
13. データ品質が低下すると... ⚠ 例) データの遅延、重複や欠損などが発生！ データ利用者の業務の効率低下 😠 必要なタイミングでデータが揃っておらず、業務ができない 😠 データが正しいか確認に時間がかかる・手戻りが発生する 組織を成功から遠ざける 🔥 誤集計に基づいた正しくない意思決定による機会損失 🔥 組織に対する信頼の低下による事業損失 解決したい課題（低減したいデータ品質の低下に伴うリスク）
14. データ品質が高い = 利用者の期待と要望を満たされている 効率的にデータ利用ができる 👍 必要なタイミングで正しいデータが揃っていて、円滑に業務ができる 組織を成功へ近づける 👍 正しい集計に基づいた適切な意思決定ができる 👍 組織に対する信頼の維持と向上 データ品質の目指すところ
15. データ品質が高い = 利用者の期待と要望を満たされている 効率的にデータ利用ができる 👍 必要なタイミングで正しいデータが揃っていて、円滑に業務ができる 組織を成功へ近づける 👍 正しい集計に基づいた適切な意思決定ができる 👍 組織に対する信頼の維持と向上 データ品質の目指すところ 「データが正しい」は当たり前では？？
16. データ品質の目指すところと取り組みの 1st step データ品質が高い = 利用者の期待と要望を満たす 「正しい」データとは？？ - 利用者の期待値は暗黙的(な場合が多い) - ニーズによって期待・要望は異なる -> 利用者と協力し、期待を明確化が必要
17. データ品質への取り組みのアウトライン　 PLAN - ゴール(利用者の期待)を明確化 - ターゲットの設定 DO - モニタリングシステムの構築 - 対象のデータの依存関係の把握 - 可視化(システム・Dashboard 作成) ACT - 改善 - 振り返り CHECK - 品質レベルの共有 - 通知
18. データ品質への取り組みのアウトライン　 PLAN - ゴール(利用者の期待)を明確化 - ターゲットの設定 DO - モニタリングシステムの構築 - 対象のデータの依存関係の把握 - 可視化(システム・Dashboard 作成) ACT - 改善 - 振り返り CHECK - 品質レベルの共有 - 通知 イマココ(1サイクル目) ＠Pococha
19. データ品質への取り組みについて 〜実施した活動の紹介〜
20. データ品質への取り組みの改善サイクル　 PLAN - ゴール(利用者の期待)を明確化 - ターゲットの設定 DO - モニタリングシステムの構築 - 対象のデータの依存関係の把握 - 可視化(システム・Dashboard 作成) ACT - 改善 - 振り返り CHECK - 品質レベルの共有 - 通知
21. PLAN: ゴール(利用者の期待)を明確化　 ✅ 利用者の業務とデータに求められる基準を把握する - 利用者へヒアリング - 閲覧履歴などのメタデータ分析 - 頻繁に検索されているテーブル - 閲覧件数が多いレポート 用途 約束相手 連絡先・周知先 利用データ 約束事項（SLA） 違反時の影響範囲 主要KPI レポート 事業部全体 アナリスト Slack #foo 売上に関する テーブル <dataset.table> 毎日朝10時までに異常なく 前日までのデータが 該当テーブルに集計されること - 間違った数値に基づいて意思決定 してしまう - 数値がみれず意思決定が遅れる ヒアリングの例
22. PLAN: ターゲットの設定 ✅ 対象のデータを決定 - 売上など主要な KPI の中間テーブル(22テーブル) ✅ 評価軸・目標を決定 1. NULL や重複がないこと 2. データ件数が正常であること 3. テーブル間で不整合がないこと 4. 必要な時間までにテーブルが更新されていること 重要な業務・データを優先 的に設定 計測可能なデータの特徴や 特性で重要なものを設定
23. データ品質への取り組みの改善サイクル　 PLAN ✔ ゴール(利用者の期待)を明確化 ✔ ターゲットの設定 DO - モニタリングシステムの構築 - 対象のデータの依存関係の把握 - 可視化(システム・Dashboard 作成) ACT - 改善 - 振り返り CHECK - 品質レベルの共有 - 通知 対象: 売上など主要な KPI の中間テーブル(22テーブル) -> これらだけをモニタリングすればいい？ NO！元となる上流データもモニタリング必要！
24. DO: 対象のデータの依存関係の把握 依存関係の例: - 上流のデータは、数が多く依存関係の把握が大変。。。 毎朝 10 時に確認 中間テーブルとその上流データは 10時より前に集計が完了している必要がある
25. DO: 対象のデータの依存関係の把握 - 上流のデータでモニタリング必要だが、数が多く依存関係の把握が大変。。。 => 工夫) メタデータから依存関係を抽出・可視化 作成した依存関係抽出ツールの構成: System Activity BigQuery INFORMATION_SCHMA.JOBS_BY 依存関係を確認 したいテーブル名 依存関係を抽出した テーブルのリスト 再帰的に依存関係を抽出 自動で最新の依存関係を把握 BigQuery
26. DO: 対象のデータの依存関係の把握 把握したい依存関係の例: ②依存関係のあるテーブルを抽出: 1. 依存関係を確認したいテーブルが出力先の JOB 履歴を検索し、参照元を抽出する。 (出力先: 中間テーブル, 参照元: 上流データ3,4) 2. 1.で抽出した参照元が出力先の JOB 履歴を検索し、参照元を抽出する。 (出力先: 上流データ3, 参照元: 上流データ1,2) これを繰り返す 参照元 出力先 上流データ1 上流データ３ 上流データ2 上流データ３ 上流データ３ 中間テーブル 上流データ４ 中間テーブル 中間テーブル レポートID … 依存関係の抽出の例: ①メタデータから入出力を整形: …
27. データ品質への取り組みの改善サイクル　 PLAN ✔ ゴール(利用者の期待)を明確化 ✔ ターゲットの設定 DO - モニタリングシステムの構築 ✔ 対象のデータの依存関係の把握 - 可視化(システム・Dashboard 作成) ACT - 改善 - 振り返り CHECK - 品質レベルの共有 - 通知 1. NULL や重複がないこと 2. データ件数が正常であること 3. テーブル間で不整合がないこと 4. 必要な時間までにテーブルが更新されていること
28. DO: モニタリングシステムの構築 　✅ スケールする構成(技術に詳しくない人でも簡単に設定できる)
29. 　目的: 主キーだが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には主キーがない
30. 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 視覚的に異常がわかる
31. DO: 可視化(3/4) テーブル間の整合性チェック 　目的: 誤集計のチェック（集計前後などでの数値チェックして確認） - サービスでユニーク・複雑なチェックは個別にチェック用のクエリのテンプレートを準備 元データ 例：購入履歴 中間テーブル 例：種別ごとの売上 元データや集計ロジックの 変更で不整合が生じる懸念 集計 チェック チェック チェック結果を比較 例：総和を比較
32. DO: 可視化(4/4) 遅延の検知(テーブル更新時間のチェック) 　目的: 遅延のチェック(関連テーブルの更新時刻・処理時間の長さのチェック) - BigQuery のメタデータ：INFORMATION_SCHMA, __TABLES__ から抽出 tableA tableB tableC tableD tableE 平均 更新時刻 平均 処理時間[分] 処理時間の長い箇所を把握 ｰ>必要に応じて対応 遅延の有無を確認 更新済み:1 遅延:-1 未更新:0 遅延判定 時刻
33. DO: 可視化(4/4) 遅延の検知(テーブル更新時間のチェック) 　目的: 遅延の予防(日次変化をプロットし、変動をチェック) - BigQuery のメタデータ：INFORMATION_SCHMA から抽出 更新時間が必要な時間を 超過する懸念を可視化し、 事前に対策を打つことができた 必要な時間まで の余裕[分] 日付 ←業務に必要な時刻
34. データ品質への取り組みの改善サイクル　 DO ✔ モニタリングシステムの構築 ✔ 対象のデータの依存関係の把握 ✔ 可視化(システム・Dashboard 作成) ACT - 改善 - 振り返り CHECK - 品質レベルの共有 - 通知 PLAN ✔ ゴール(利用者の期待)を明確化 ✔ ターゲットの設定
35. CHECK: 品質レベルの共有, 通知 - 品質レベルの共有(基本的に月１開催) - 対象とした22テーブルの内の数テーブルで、主キーに NULL があった - 近いうちに、更新時間が必要な時間を超過する懸念 - 異常の通知の構成(試行錯誤中) or アラート機能 定期実行 slack通知 Assert 関数 Dashboard を用いて品質レベルを 定量的に共有できた BigQuery
36. データ品質への取り組みの改善サイクル　 DO ✔ モニタリングシステムの構築 ✔ 対象のデータの依存関係の把握 ✔ 可視化(システム・Dashboard 作成) ACT - 改善 - 振り返り CHECK ✔ 品質レベルの共有 ✔ 通知 PLAN ✔ ゴール(利用者の期待)を明確化 ✔ ターゲットの設定
37. ACT: 改善 - 改善 ✅ 対象とした22テーブルの内の数テーブルで、主キーに NULL があったが、ほぼ解消できた 　　 ✅ 更新時間が必要な時間を超過する前に検知し、対処できた 👍 利用者からのコメント 　　 「データ品質が担保されている」という状態から分析をスタートできる 　　　 ようになり、大変な安心感が生まれた 地道に集計ロジックを修正し てくれたアナリストに感謝！
38. 今後の展望　 - 振り返り - チェック項目の追加・精査 - プロセスの磨き込み - オープンソースの活用の検討 - Cloud Data Quality Engine(dataplex) https://github.com/GoogleCloudPlatform/cloud-data-quality - Data Validation Tool https://github.com/GoogleCloudPlatform/professional-services-data-validator - 各サービスへ横展開を進めていく
39. まとめ　 - 「より便利で安心なデータプラットフォーム」を目指したデータ品質向上の取り組み を紹介した - 取り組みのプロセス - モニタリング方法 - データ利用者との協力体制は重要