サイバーエージェントにおけるデータの品質管理について #cwt2016

サイバーエージェントにおけるデータの品質管理について

2016 November 8th

CyberAgent, Inc. All Rights Reserved

株式会社サイバーエージェント技術本部田中克季

Cloudera World Tokyo 2016

タイトル TITLE自己紹介

2

• 株式会社サイバーエージェント • 基盤系システムエンジニア • 主担当はデータ分析基盤開発運用やサービスの

分析コンサルや分析システムの導入

名前：田中克季

タイトル TITLEサイバーエージェントの事業

インターネット広告事業メディア事業ゲーム事業

広告代理事業

自社広告商品(アドテク）など

などなど

3

タイトル TITLE事業の多様性

4

タイトル TITLE事業の多様性

5

ガチャ回転率課金・スペンド…

view数投稿数視聴時間…

新規登録数DAU継続率…

タイトル TITLEデータ分析基盤システム概要

6

• データ分析基盤 (Patriot)• Flume, HDFS, Hive, HBase• システム規模 : Hadoopクラスタ 73 node データ量 : 2PB (レプリケーション含む) ※2016年11月現在

タイトル TITLEデータ分析基盤システム概要

7

• 一昨年はデータ分析基盤でのHBase活用事例について紹介

http://www.slideshare.net/cyberagent/20141106cwtzenmyonaito-41840992

http://www.slideshare.net/cyberagent/cloudera-world-tokyo-2013

• 2013年にデータ分析基盤について紹介

タイトル TITLE各サービスからのデータフロー

8

Amebaやスマフォプラットフォームなど

各サービスサーバ

分析データ取得

データ分析基盤

タイトル TITLEデータ集計環境における課題

9

• メディアサービスやゲームサービスのユーザ行動データ特性の多様化

• 各プラットフォームやサービスのデータ集計方法, ユーザ識別の複雑化

• データの品質劣化に伴う分析コストの増大

複雑さを解消し、データ品質の担保や管理の必要性

タイトル TITLEデータ品質管理向上の注力ポイント

10

1.データ集計基盤一元化 2.データフォーマットの統一（スキーマ定義） 3.スキーマ定義に基づいたデータ検証 4.データ標準化


11


タイトル TITLEデータ集計基盤の一元化

12

• 対象サービス管理の一元化 • 様々なデータ転送方式のサポート(https, flume, fluentd, Google Cloud Pub/Sub etc…)・サービス毎のデータ転送コントロール

Https


13


タイトル TITLEデータフォーマットの統一

14

• データフォーマットはjson • Snowplow の Canonical Event Modelを参考

に基本スキーマを定義 https://github.com/snowplow/snowplow/wiki/canonical-event-model•1ユーザ1行動を1単位

タイトル TITLEスキーマ定義

15

Header部

Contents部

{"uuid": "e8b507ee-a805-432b-a2cf-90aaed1fa1d1"

"schema": "like/1-2-0", "action_type": "like",

"arrival_time": “2016-10-27T21:03:17.589+09:00","mine_id": "rHTbhVAJ",

"page": {}, "platform": "native", "time": "2016-10-27T21:03:15.731+09:00", "user": { "service_user_id": "6577109897303400875" }, "client": { "device_model": "SC-05G", "ip": "xx.98.1x3.98", "os": "Android", "os_version": "6.0.1", "useragent": "" }, "contents": { "like_type": "liked", "pass_num": 1, "super": false, "target_user_id": "4717712170393248212" }}


16

Header部

Contents部





Header部はユーザ識別子や環境、状態を記述


17

Header部

Contents部





Contents部はユーザ行動毎の詳細情報

タイトル TITLEHeader部

18


"schema": “like/1-2-0", "time": "2016-10-27T21:03:15.731+09:00", "arrival_time": "2016-10-27T21:03:17.589+09:00", "mine_id": "rHTbhVAJ",

"client": { "device_model": "SC-05G", "ip": "xx.98.1x3.98", "os": "Android", "os_version": "6.0.1", "useragent": "" }, "platform": "native",

"action_type": "like", "page": { "page_id": "top_page1",

}, "user": {

"service_user_id": "6577109897303400875" }, …

uuid: ログ識別子


19


"schema": "like/1-2-0", "time": "2016-10-27T21:03:15.731+09:00", "arrival_time": "2016-10-27T21:03:17.589+09:00", "mine_id": "rHTbhVAJ",



}, "user": {

"service_user_id": "6577109897303400875" }, …

schema:ログ仕様バージョン


20


"schema": "like/1-2-0", "time": "2016-10-27T21:03:15.731+09:00", "arrival_time": “2016-10-27T21:03:17.589+09:00", "mine_id": "rHTbhVAJ",



}, "user": {

"service_user_id": "6577109897303400875" }, …

,time:行動発生時間

arrival_time: データ到着時間

iso8601に準拠


21





}, "user": {

"service_user_id": "6577109897303400875" }, …

mine_id: サービスID


22





}, "user": {

"service_user_id": "6577109897303400875" }, …

client部:

ユーザ行動発生時の端末情報。IP, OS, UAなど


23





}, "user": {

"service_user_id": "6577109897303400875" }, …

platform:行動が発生したプラットフォーム(ブラウザ, ネイティブアプリ, TVなど)


24





}, "user": {

"service_user_id": "6577109897303400875" }, …

action_type: ユーザ行動タイプ


25





}, "user": {

"service_user_id": "6577109897303400875" }, …

page:ページ、view情報など


26





}, "user": {

"service_user_id": "6577109897303400875" }, …

26

user:ユーザ識別子などユーザ情報

タイトル TITLEContents部

27

{…

"action_type": "like", …

"contents": { "like_type": "liked", "pass_num": 1, "super": false, "target_user_id": "4717712170393248212" }}

contents:行動タイプに対応する行動詳細情報


28


タイトル TITLEデータ検証方法

29

• JsonSchemaによるデータ仕様の検証• http://json-schema.org/• latest IETF published draft v4

検証内容の例：必須/任意, データ型, FromTo, Enum, 固定値, 相関チェック, URL形式, IP形式などなど

タイトル TITLEJson Schema例

30

行動タイプregisterに対するJsonSchema抜粋

{ "$schema" : "http://json-schema.org/draft-04/schema#", "type" : "object", "properties" : { "action_type" : { "type" : "string","enum" : [ "register" ]}, "contents" : { "properties" : { "nickname" : { "type" : "string"}, "sex" : { "type" : "string", "enum" : [ "male", "female", "unknown" ] }, … }, …}

action_typeは型がstring,

固定値"register"

タイトル TITLEJson Schema例

31

行動タイプregisterに対するJsonSchema抜粋

{ "$schema" : "http://json-schema.org/draft-04/schema#", "type" : "object", "properties" : { "action_type" : { "type" : "string","enum" : [ "register" ]}, "contents" : { "properties" : { "nickname" : { "type" : "string"},

"sex" : { "type" : "string", "enum" : [ "male", "female", "unknown" ] }, … }, …}

contents内部のnickname

は型がstring,

sexは型がstring, "male",

"female", "unknown"の値をとる

タイトル TITLE違反検知例

32

行動タイプregisterのデータ検証違反{ "action_type": "register", "arrival_time": "2016-11-01T21:00:14.536+09:00", "schema": "register/1-0–0”, "time": "2016-11-01T1:00:14.451+09:00", "contents": { "sex": "special" }, "mine_id": "hIHYdsma", "platform": "native",

"user": { "active_user": true, "as_user_id": “8998897244"

}, "uuid": "34350542-F01C-47B6-B434-E8365F7B5113" }

", 行動registerのsexキーは"male", "female", "unknown"しかとらないので、"special"は異常として検知する

t e : 0 6 0 :00: . 5 09:00 , "contents": { "sex": "special" }, "mine id": "hIHYdsma"

タイトル TITLEデータ仕様のversion管理

33

データ仕様はサービス施策や分析要件によって変化していくため検証仕様も変化させる必要があり、仕様のversion管理が必要 (GitHub管理)

"schema":"register/1-0-0"g

対象の行動タイプメジューバージョン、マイナーバージョン、リビジョン

タイトル TITLEデータ検証の流れ

34

1. データ仕様決定

サービス分析担当分析基盤管理

2. データ仕様(JsonSchema)登録

3. JsonSchemaデプロイ

5. データ検証

4. サービスデータ転送

6. エラーレポートの確認

タイトル TITLEデータ検証の仕組み

35

検証UDF

RAWデータ

正常データ

違反データ

サービスからのユーザ行動データ

JsonSchema

タイトル TITLEデータ検証の仕組み

36

検証UDF

RAWデータ

正常データ

違反データ

サービスからのユーザ行動データ

JsonSchema

違反データ分析や集計はこちらを利用する

タイトル TITLEエラーレポート

37

データ検証で検知された違反データのサマリーレポートを作成し、サービス側に提供

違反カテゴリ件数カテゴリ毎のエラー件数

違反カテゴリ毎の違反詳細検証違反データのピックアップ


38


タイトル TITLEデータ標準化

39

ログ層標準化層集約層

Rawデータ格納集計しやすい状態にデータ整形

分析用途でのデータのサマリー集計や積み上げ集計の結果

Google BigQuery

HBase

Google SpreadSheet

タイトル TITLEログ層

40

• 送信されたデータをそのまま保持する層 • 集計の大元データ

標準化層• 送信されたログを集計しやすい形にし、格納す

る層 • データ検証で一定のデータ品質を担保 • 日, サービス毎のパーティション

タイトル TITLE集約層

41

• 標準化層データを日毎に集計した結果を格納 • 1日のアクセスメッシュ集計(アクティブユーザ

やアクション別など)• ユーザ単位の行動記録のサマリー集計(初回アク

セス日, アクセスデバイス, OSなど)


42

• ユーザアクセスメッシュテーブルフィールドデータ型説明user_id string ユーザ識別子access_mesh binary アクセスの1minメッシュby_term Map<string, binary> デバイス/OS/クライアント毎のアクセ

ス1minメッシュservice string サービス識別子(パーティション)dt string 集計対象日付(パーティション)

0000001111111100000000110…000111111111111000001minメッシュ

01 0111111110 11111111111110 0110

サービス滞在時間や視聴時間などの指標で利用できる


43

• ユーザアクセス集約テーブルフィールドデータ型説明user_id string ユーザ識別子first_access_date string 初回アクセス日last_access_date string 最終アクセス日access_dates_count bigint 通算アクセス日数recent_access_dates array<string> 過去1ヶ月のアクセス日recent_access_weeks array<string> 過去24週のアクセス週recent_access_months array<string> 過去2年のアクセス月service string サービス識別子(パーティション)dt string 集計対象日付(パーティション)

DAU, 継続率, 呼び戻し率などのユーザの行動集約情報が必要な指標積み上げ情報なので最新のパーティションに絞ることが可能

タイトル TITLE取り組みから得られた結果

44

• これまで発生していたサービス毎の基本指標に対する集計実装コストの大幅な削減

• 集計で問題が発生したときの調査コストの削減

• 集約テーブルから取得できる数値や指標のクエリ実行時間の短縮

タイトル TITLE取り組みから得られた結果

45

• 集約情報作成までの一連の流れが自動化されているので、基本指標においてはデータ送信した翌日から分析担当は容易に取得可能に

• サービスエンジニアの分析用ログの品質への意識が高まった

タイトル TITLE今後の課題や展望

46

1.データ検証の向上 • 現在はJsonSchemaによる静的な検証のみ。集計データ

の行動の順序性や行動間の情報整合性なども検証対象に • ストリーミングデータで逐次的な検証

2.分析データ実装簡易化(サービスエンジニアにかかるデータ転送部分開発の負担軽減)

3.分析指標のセグメント設定

さいごにAmeba Technology Laboratory & 基盤システムグループでは分析基盤エンジニアを募集しています！ Hadoop / データマイニング / 機会学習 / 検索などに興味がある方はお声掛けください。

詳細はコーポレイトサイトにも掲載されています https://www.cyberagent.co.jp/recruit/career/jobs/

ご静聴ありがとうございました