Tweet
Tweet

Slide 1

Slide 1 text

DeNAデータプラットフォーム におけるデータ品質への取組み 野本 大貴(Hirotaka Nomoto)

Slide 2

Slide 2 text

Speaker 野本 大貴(Hirotaka Nomoto) - データエンジニア - 2019年9月入社 - データパイプラインの開発・運用 - ゲーム事業のデータプラットフォームのクラウド移行を推進 - データ品質への取り組みをリード

Slide 3

Slide 3 text

DeNA のデータエンジニアの位置付け - 全社のデータ活用水準の向上を目的としている ゲーム事業 システム本部（全社横断組織） 分析推進部 データエンジニアリング G その他の事業, 横断組織 ライブストリーミング 事業 サポート サポート サポート

Slide 4

Slide 4 text

背景・データ品質への取り組もうとした理由　 🎉 データプラットフォームを刷新するクラウド移行が完遂！ その裏で、データ品質に起因する様々な苦労・利用者の業務へ影響が発生してしまいました。。。 😱 元データの型が変わり、集計でエラーが発生するようになる 😱 データ件数が前日と比べて異常に少なく、データ利用者から問い合わせがくる 😱 データ抽出が遅れて、データ提供先への連携が遅れる etc... ⇒ 利用者の業務へ影響を防ぎ、業務へ集中してもらいたい！ 　　　　 この様な背景に共感を覚える方は、 是非ご視聴下さい！

Slide 5

Slide 5 text

コメント、質問をお待ちしております　 - Twitter からの投稿お待ちしております！ - #データ品質 のハッシュタグで質問ツイートをいただけると 本日回答できなかった場合にも DeNA Analytics Blog - Medium などで 後日回答差し上げます。

Slide 6

Slide 6 text

本日お話すること　 - イントロダクション - DeNA のデータプラットフォームについて - データ品質への取り組みについて - 取り組みのプロセス - モニタリング方法

Slide 7

Slide 7 text

DeNA のデータプラットフォームについて

Slide 8

Slide 8 text

現在のデータプラットフォーム 概要 - Google Cloud を使った構成 詳細はこちら Google Cloud を使ったデータ プラットフォームへの変革と 最新の活用状況について Google Cloud Data Platform Day #2 2020/03/31 https://cloudonair.withgoo gle.com/events/jp-data-pla tform-day

Slide 9

Slide 9 text

現在のデータプラットフォーム 規模　 Tables 600k + Projects 100 + Scan 300TB/day

Slide 10

Slide 10 text

これまでの取り組み ✅ データマネジメント(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/ より便利で安心なデータプラットフォームを目指して

Slide 11

Slide 11 text

最近の取り組み - データマネジメント知識体系ガイド（DMBOK）への準拠を進めています - データ品質 - メタデータ管理 - データセキュリティ DAMAホイール データマネジメント 知識体系ガイド 第二版より より便利で安心なデータプラットフォームを目指して

Slide 12

Slide 12 text

データ品質への取り組みについて 〜課題や概要の紹介〜

Slide 13

Slide 13 text

データ品質が低下すると... ⚠ 例) データの遅延、重複や欠損などが発生！ データ利用者の業務の効率低下 😠 必要なタイミングでデータが揃っておらず、業務ができない 😠 データが正しいか確認に時間がかかる・手戻りが発生する 組織を成功から遠ざける 🔥 誤集計に基づいた正しくない意思決定による機会損失 🔥 組織に対する信頼の低下による事業損失 解決したい課題（低減したいデータ品質の低下に伴うリスク）

Slide 14

Slide 14 text

データ品質が高い = 利用者の期待と要望を満たされている 効率的にデータ利用ができる 👍 必要なタイミングで正しいデータが揃っていて、円滑に業務ができる 組織を成功へ近づける 👍 正しい集計に基づいた適切な意思決定ができる 👍 組織に対する信頼の維持と向上 データ品質の目指すところ

Slide 15

Slide 15 text

データ品質が高い = 利用者の期待と要望を満たされている 効率的にデータ利用ができる 👍 必要なタイミングで正しいデータが揃っていて、円滑に業務ができる 組織を成功へ近づける 👍 正しい集計に基づいた適切な意思決定ができる 👍 組織に対する信頼の維持と向上 データ品質の目指すところ 「データが正しい」は当たり前では？？

Slide 16

Slide 16 text

データ品質の目指すところと取り組みの 1st step データ品質が高い = 利用者の期待と要望を満たす 「正しい」データとは？？ - 利用者の期待値は暗黙的(な場合が多い) - ニーズによって期待・要望は異なる -> 利用者と協力し、期待を明確化が必要

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

データ品質への取り組みについて 〜実施した活動の紹介〜

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

PLAN: ゴール(利用者の期待)を明確化　 ✅ 利用者の業務とデータに求められる基準を把握する - 利用者へヒアリング - 閲覧履歴などのメタデータ分析 - 頻繁に検索されているテーブル - 閲覧件数が多いレポート 用途 約束相手 連絡先・周知先 利用データ 約束事項（SLA） 違反時の影響範囲 主要KPI レポート 事業部全体 アナリスト Slack #foo 売上に関する テーブル 毎日朝10時までに異常なく 前日までのデータが 該当テーブルに集計されること - 間違った数値に基づいて意思決定 してしまう - 数値がみれず意思決定が遅れる ヒアリングの例

Slide 22

Slide 22 text

PLAN: ターゲットの設定 ✅ 対象のデータを決定 - 売上など主要な KPI の中間テーブル(22テーブル) ✅ 評価軸・目標を決定 1. NULL や重複がないこと 2. データ件数が正常であること 3. テーブル間で不整合がないこと 4. 必要な時間までにテーブルが更新されていること 重要な業務・データを優先 的に設定 計測可能なデータの特徴や 特性で重要なものを設定

Slide 23

Slide 23 text

データ品質への取り組みの改善サイクル　 PLAN ✔ ゴール(利用者の期待)を明確化 ✔ ターゲットの設定 DO - モニタリングシステムの構築 - 対象のデータの依存関係の把握 - 可視化(システム・Dashboard 作成) ACT - 改善 - 振り返り CHECK - 品質レベルの共有 - 通知 対象: 売上など主要な KPI の中間テーブル(22テーブル) -> これらだけをモニタリングすればいい？ NO！元となる上流データもモニタリング必要！

Slide 24

Slide 24 text

DO: 対象のデータの依存関係の把握 依存関係の例: - 上流のデータは、数が多く依存関係の把握が大変。。。 毎朝 10 時に確認 中間テーブルとその上流データは 10時より前に集計が完了している必要がある

Slide 25

Slide 25 text

DO: 対象のデータの依存関係の把握 - 上流のデータでモニタリング必要だが、数が多く依存関係の把握が大変。。。 => 工夫) メタデータから依存関係を抽出・可視化 作成した依存関係抽出ツールの構成: System Activity BigQuery INFORMATION_SCHMA.JOBS_BY 依存関係を確認 したいテーブル名 依存関係を抽出した テーブルのリスト 再帰的に依存関係を抽出 自動で最新の依存関係を把握 BigQuery

Slide 26

Slide 26 text

DO: 対象のデータの依存関係の把握 把握したい依存関係の例: ②依存関係のあるテーブルを抽出: 1. 依存関係を確認したいテーブルが出力先の JOB 履歴を検索し、参照元を抽出する。 (出力先: 中間テーブル, 参照元: 上流データ3,4) 2. 1.で抽出した参照元が出力先の JOB 履歴を検索し、参照元を抽出する。 (出力先: 上流データ3, 参照元: 上流データ1,2) これを繰り返す 参照元 出力先 上流データ1 上流データ３ 上流データ2 上流データ３ 上流データ３ 中間テーブル 上流データ４ 中間テーブル 中間テーブル レポートID … 依存関係の抽出の例: ①メタデータから入出力を整形: …

Slide 27

Slide 27 text

データ品質への取り組みの改善サイクル　 PLAN ✔ ゴール(利用者の期待)を明確化 ✔ ターゲットの設定 DO - モニタリングシステムの構築 ✔ 対象のデータの依存関係の把握 - 可視化(システム・Dashboard 作成) ACT - 改善 - 振り返り CHECK - 品質レベルの共有 - 通知 1. NULL や重複がないこと 2. データ件数が正常であること 3. テーブル間で不整合がないこと 4. 必要な時間までにテーブルが更新されていること

Slide 28

Slide 28 text

DO: モニタリングシステムの構築 　✅ スケールする構成(技術に詳しくない人でも簡単に設定できる)

Slide 29

Slide 29 text

　目的: 主キーだが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には主キーがない

Slide 30

Slide 30 text

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 視覚的に異常がわかる

Slide 31

Slide 31 text

DO: 可視化(3/4) テーブル間の整合性チェック 　目的: 誤集計のチェック（集計前後などでの数値チェックして確認） - サービスでユニーク・複雑なチェックは個別にチェック用のクエリのテンプレートを準備 元データ 例：購入履歴 中間テーブル 例：種別ごとの売上 元データや集計ロジックの 変更で不整合が生じる懸念 集計 チェック チェック チェック結果を比較 例：総和を比較

Slide 32

Slide 32 text

DO: 可視化(4/4) 遅延の検知(テーブル更新時間のチェック) 　目的: 遅延のチェック(関連テーブルの更新時刻・処理時間の長さのチェック) - BigQuery のメタデータ：INFORMATION_SCHMA, __TABLES__ から抽出 tableA tableB tableC tableD tableE 平均 更新時刻 平均 処理時間[分] 処理時間の長い箇所を把握 ｰ>必要に応じて対応 遅延の有無を確認 更新済み:1 遅延:-1 未更新:0 遅延判定 時刻

Slide 33

Slide 33 text

DO: 可視化(4/4) 遅延の検知(テーブル更新時間のチェック) 　目的: 遅延の予防(日次変化をプロットし、変動をチェック) - BigQuery のメタデータ：INFORMATION_SCHMA から抽出 更新時間が必要な時間を 超過する懸念を可視化し、 事前に対策を打つことができた 必要な時間まで の余裕[分] 日付 ←業務に必要な時刻

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

CHECK: 品質レベルの共有, 通知 - 品質レベルの共有(基本的に月１開催) - 対象とした22テーブルの内の数テーブルで、主キーに NULL があった - 近いうちに、更新時間が必要な時間を超過する懸念 - 異常の通知の構成(試行錯誤中) or アラート機能 定期実行 slack通知 Assert 関数 Dashboard を用いて品質レベルを 定量的に共有できた BigQuery

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

ACT: 改善 - 改善 ✅ 対象とした22テーブルの内の数テーブルで、主キーに NULL があったが、ほぼ解消できた 　　 ✅ 更新時間が必要な時間を超過する前に検知し、対処できた 👍 利用者からのコメント 　　 「データ品質が担保されている」という状態から分析をスタートできる 　　　 ようになり、大変な安心感が生まれた 地道に集計ロジックを修正し てくれたアナリストに感謝！

Slide 38

Slide 38 text

今後の展望　 - 振り返り - チェック項目の追加・精査 - プロセスの磨き込み - オープンソースの活用の検討 - Cloud Data Quality Engine(dataplex) https://github.com/GoogleCloudPlatform/cloud-data-quality - Data Validation Tool https://github.com/GoogleCloudPlatform/professional-services-data-validator - 各サービスへ横展開を進めていく

Slide 39

Slide 39 text

まとめ　 - 「より便利で安心なデータプラットフォーム」を目指したデータ品質向上の取り組み を紹介した - 取り組みのプロセス - モニタリング方法 - データ利用者との協力体制は重要

Slide 40

Slide 40 text

No content