Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
1 
Logにまつわるエトセトラ 
2014.8.28@ヒカラボ 菊池佑太
2 
話しません(´;ω;`) 
● GrowthHack 
✔ Retention/ConversionUP施策 
✔ A/BテストによるUI改善 
● 可視化 
✔ BIツール
3 
Log集計/解析 
必要な事
4 
WebサービスLog 
広告Log
5 
Page View (PV) 
Impression (Imps) 
Click (CTs) 
Conversion (CV)
6 
アジェンダ 
0. 自己紹介 
1. Logを記録する 
2. Logを集める 
3. Logを集計する 
4. Logを解析する 
5. 質疑応答
7 
自己紹介 
● 菊池佑太@yutakikuc 
● EX. Yahoo! AD-Science 
● 旅行で世界30都市制覇! 
● 陸サーファー、時々サーファー 
● http://d.hatena.ne.jp/yutakikuchi
ワイハーのお土産あるお! 
8
9 
経験のあるテクノロジー
10 
仕事内容 
開発 20% 
研究 10% 
データ出し 10% 
ログ調査 60% 
開発 
研究 
データ出し 
ログ調査 
雑用がメイン 
( キリッ
11 
解決しなければならない 
大きな問題
12 
LogやDataを軽視する人 
              /) 
           ///) 
          /,.= ゙''"/ 
   /     i f ,.r='"-‐'つ_ 
  /      /   _,.-‐'...
13 
LogやData取得が後回しにされる理由 
● サービスの開発が最優先、Logは無くても動く 
● LogSystemの開発は簡単という誤解(怒) 
● UserDataを取得するとUserの入力負荷が高くなる 
● Data分析方法が...
14 
Logエンジニアの現場人数 
アプリエンジニアの1/20
15
16 
理解して欲しいこと 
Logの重要性
17 
アジェンダ 
0. 自己紹介 
1. Logを記録する 
2. Logを集める 
3. Logを集計する 
4. Logを解析する 
5. 質疑応答
18 
Logの記録目的(冗談) 
元気があれば何でもできる! 
Logがあれば何でも分かる!
19 
Logの記録目的(真面目) 
Log ≒ Evidence 
Log ⇒ Next Strategy
20 
大事な事なので2度言います 
Log分析は 
サービス戦略に繋がる
21 
Logの記録で重要な事 
3W1H (When,Who,What,How) 
Logだけで情報が揃うように
22 
Logの種類と記録項目 
● AccessLog 
✔ RequestTime(When), RequestURI(What), Referer(How) 
✔ AccessIP, UA 
✔ ResponseTime, Status ...
23 
ServerLogの種類と記録項目 
● ErrorLog 
✔ RequestTime, RequestURI, UA, Cookie 
✔ ErrorLevel, ErrorFile&Line, ErrorComment 
● Ap...
24 
BrowserID 
UserID/Attribute 
超重要
25 
何が重要なの? 
(後で!)
26 
「mod_oreore」によるBrowserID発行 
● Serverへの初回アクセス時にCookieを発行する 
● ApacheModuleだからApplicationの実装が不要 
● mod_usertrack,mod_ses...
27 
UserID/Attributeの記録 
● UserID/AttributeはLoginをした段階でCookieに付与 
(Applicationのレイヤーで実装) 
● Hackingされないように変換や暗号化
CookieをLogに落とす 
28
29 
Logに落とすCookieの例 
oreore_cookie:id=MTkyLjE2OC41Ni4xMDE0MDkxMTk2ODQ 
wMzg3MTMyMDE2NTQyNzI1MDMzMTY0OA..&attr=Mjg0Z 
mUyMz...
30 
LogFormat 
● Default(Apache) 
::1 - - [08/Feb/2014:21:32:10 +0900] "GET / HTTP/1.1" 403 5039 "-" "curl/7.19.7 (x86_64-...
31 
どのFormatが良いか? 
● Log項目の付け足し/削除は後から必ず発生する 
● 付け足しが発生してもParse後の順番依存が無い事 
● 人目で見ても項目と値が分かり易い 
LTSVFormatがお勧め
32 
LogServer構成
33 
PV, Imps, CTs, CVLog 
③BeaconRequest 
⑤Staus:302 
Location:Url 
ConversionBeacon 
⑧ConversionRequest 
①Request        ...
34 
CTsとCVLog 
少し詳しく
35 
Click情報 
どこに掲載したら 
Clickされたのか
36 
導入したClick検知方法 
● 外部Domainへの遷移検知にはRedirectorを入れる 
● Logにどのページのどのリンクが押されたのか記録する 
✔ 予約Parameter(?__uri=hoo&__link=bar_1) ...
37 
Click検知の失敗点 
アプリエンジニアの実装にミスが発生する! 
CTR集計結果に影響が出る!! 
戦略チームから@yutakikucが怒られる!!! 
@yutakikucがアクセスログから実装ミスをカバーする!!!!
38 
CVLogに必要な事 
● (外部)サイトに検知用Beaconタグを埋め込んでもらう 
● LogにどのサイトでどのようなCVが発生したのか記録する 
- Parameterで表現する 
(例)<img src='http://cbea...
39 
CVLogの活用 
● Userの購入プロセスの状況把握 
● 購入済み商品はRecommendの対象外 
● 類似商品のRecommend 
● 同じような行動履歴のUserへのRecommend
40 
「Logを記録する」まとめ 
●Log分析は戦略に繋がる 
●BrowserID,User,Attributeの記録 
●LTSV Format 
●CTs,CVLogの記録
41 
アジェンダ 
0. 自己紹介 
1. Logを記録する 
2. Logを集める 
3. Logを集計する 
4. Logを解析する 
5. 質疑応答
42 
Logの管理構成 
RealTime or Batch ? 
Push or Pull ? 
IP 
Restriction 
WebServer① 
WebServer② 
BeaconServer 
Redirector 
LogA...
43 
RealTime or Batch 
Push or Pull 
● RealTime(Fluentd,Storm) 
✔ 即時集計/解析 
✔ 一度の転送量を抑える 
✗ Batchと比較して転送/解析の技術 
ハードルが高い 
● ...
44 
RealTime Log転送で気をつけたい事 
● 処理が詰まらないように(Server性能の限界を確認しておこう) 
● 転送完了したファイル名とLine数を記録する 
● HotStandyの用意 
● Batchに切り替える手段を...
45 
Batch Log転送で気をつけたい事 
● Rotate処理と転送処理の時間が重なった時の取りこぼし 
※ チェックサムの確認 
● 転送時間が大きくならない事 
※ 複数のデータセンターへの転送 
● 冗長化サーバー毎に転送開始時間...
46 
広告配信での実例 
Imps:500,000、Clicks:2000、Log容量:200M
47 
集計の土台 
安定したPull型Batch 
※Batchは1日1回 
広告主への正確なレポート提出のため 
Rsync + FuelPHP Task
48 
+α 
Imps,CTsはPush型 
RealTime集計を準備中 
※Imps保証数を必要以上に超過させない 
RealTimeでのリターゲティング 
Fluentd + fuent-plugin-redis
49 
最小構成でも 
トラフィック問題は 
発生せず... or2
50 
冗長化対応での問題 
回収先サーバーの 
追加設定漏れ
51 
「Logを集める」まとめ 
●回収方法の特性を理解 
●集計の土台はPull型Batchで安定稼働 
●配信制御に関わる事は極力RealTimeで
52 
アジェンダ 
0. 自己紹介 
1. Logを記録する 
2. Logを集める 
3. Logを集計する 
4. Logを解析する 
5. 質疑応答
53 
KPI / KGI
54 
原始的な集計 
cut -f 2 log.txt | sort | uniq | wc -l
55 
強力なツール 
※要件が合えば利用
56 
強力ツールで出来ない事 
●ページ内コンテンツの配信数 
● Browser毎の履歴集計 
●無料では出来る事が限られる 
●長期的なログ蓄積には不向き
GoogleAnalytics(GA)とRequestLogの違い 
57 
GA RequestLog 
1400000 
1200000 
1000000 
800000 
600000 
400000 
200000 
0 
100000...
58 
独自集計 
ツールとの棲み分け 
緊急性と重要度の判定
59 
緊急性と重要度 
データの種類データの項目緊急性重要度格納先 
広告Imps速報高中Redis 
広告CTs速報高中Redis 
広告効果レポート低高Mysql 
サービスPV 低高Mysql 
サービスCTR 低高Mysql 
サービ...
60 
Mysqlは安定している 
心配なのはWrite速度
61 
Mysql Table設計 
●テーブル設計 = 集計する項目の決定 
●Relationは作らない 
– 冗長的な登録は許容 
●古いデータは消す事が前提 
– 日付のPartitioningでparge 
●複雑な処理は多段集計 
...
62 
MysqlへのWrite 
● Batch処理 
✔ BatchでOnMemory(連想配列)に集計結果を乗せてからBulkInsert 
✔ Hadoopで集計しSqoopで結果をImport 
● RealTime処理 
✔ Run...
63 
Redisの利用 
● データ管理をMemoryとStorageの両方で旨くこなす凄い奴 
● 大量データのINSERT/SELECTもMysqlより高速 
● MemoryとStorageの両方から消えた場合が大変 
● 広告のRea...
64 
MongoDBの利用 
●スキーマ定義が不要でカラム追加の運用も要らない 
●大量データのInsertがMysqlより速い(SELECTは同等) 
● Index, Sharding等の機能もある 
●fnd条件指定が簡単でCross集...
65 
Performance担保への最終手段 
サンプリング集計 
※広告は除く
66 
「Logを集計する」まとめ 
●集計の緊急度と重要度で集計方法を変える 
●MysqlのINSERT速度が心配 
●MongoDBやRedisも導入すると良い
67 
アジェンダ 
0. 自己紹介 
1. Logを記録する 
2. Logを集める 
3. Logを集計する 
4. Logを分析する 
5. 質疑応答
68 
BrowserID 
UserID/Attribute 
超重要
69 
何が重要なの?
70 
その① 行動履歴の集約 
識別子をkeyにsortで纏める 
行動素性の抽出 
MapReduceとの相性
71 
その② 分類済み正解データからの推定 
BrowserID : 1 
UserID : A 
女性× 20代 
BrowserID : 2 
UserID : ? 
女性? 20代 ? 
@cosme 
zexy.net 
@cosme...
72 
その③ User×デバイスデータ取得可能 
1人で複数台利用 
(1つのUserIDでの紐付け) 
複数人で1台を利用 
(複数のUserIDでの紐付け) 
※分析データから除外する
73 
性別推定
74 
性別推定 
● Userの性別に対してコンテンツや広告をtargetingしたい 
●性別が取れるUserは20%以下。※Login必須サイトで無い場合 
● 2値分類(random推定でも50%) 
●仕組みが単純で高精度が望ましい ...
75 
条件付き確率 
●推定手法の一例 
その他決定木やVectorでの分類がある 
●仕組みが単純、実装しやすい 
●並列分散処理OK 
● P(C|D) P: 確率, C:カテゴリ, D:事象 
例) 「サッカー」で検索したUserは80...
76 
「Naive Bayes」 
でぐぐれ!
77 
推定Model作成と評価 
● まずはオフラインで 
● 素性はスペース区切り検索Query 
● 訓練データ、推定対象データの準備 (過去28日間) 
✔訓練データ: 性別が分かるBrowserID×Query 
✔推定対象データ: ...
78 
毎日推定 
● 次にオンラインで 
● 2年前はOozie × Pigで素性抽出/Model作成/推定を完全自動化 
● 今ならhivemallを使いますかね 
● R言語でも簡単にできます 
● BrowserIDを基に推定確率をRe...
79 
精度とカバー率と配信の閾値 
80%は女性と推定 
精度80%以上のカバー率は3割 
この人は女性で配信しますか? 
配信側の閾値調整
80 
気をつけたい事 
●導入後のKPI変動の監視 
✔ Targeting増 => CTs増 => CV下 
✔導入前のシミュレーションも欠かさずに行う 
●推定Modelの定期的な評価 
✔完全自動化での安定運用のため
年代(10歳区切り)推定 
マルチ分類への応用 
81
82 
「Logを解析する」まとめ 
● 分類済み正解データの取得 
● 推定によりTargeting数を増やす 
● 素性抽出、推定Model作成、推定 
● 推定確率により配信する/しない
83 
以上
84 
質疑応答
Upcoming SlideShare
Loading in …5
×

ログにまつわるエトセトラ

960 views

Published on

2014.8.28@ヒカラボ 菊池佑太

Published in: Science
  • Be the first to comment

ログにまつわるエトセトラ

  1. 1. 1 Logにまつわるエトセトラ 2014.8.28@ヒカラボ 菊池佑太
  2. 2. 2 話しません(´;ω;`) ● GrowthHack ✔ Retention/ConversionUP施策 ✔ A/BテストによるUI改善 ● 可視化 ✔ BIツール
  3. 3. 3 Log集計/解析 必要な事
  4. 4. 4 WebサービスLog 広告Log
  5. 5. 5 Page View (PV) Impression (Imps) Click (CTs) Conversion (CV)
  6. 6. 6 アジェンダ 0. 自己紹介 1. Logを記録する 2. Logを集める 3. Logを集計する 4. Logを解析する 5. 質疑応答
  7. 7. 7 自己紹介 ● 菊池佑太@yutakikuc ● EX. Yahoo! AD-Science ● 旅行で世界30都市制覇! ● 陸サーファー、時々サーファー ● http://d.hatena.ne.jp/yutakikuchi
  8. 8. ワイハーのお土産あるお! 8
  9. 9. 9 経験のあるテクノロジー
  10. 10. 10 仕事内容 開発 20% 研究 10% データ出し 10% ログ調査 60% 開発 研究 データ出し ログ調査 雑用がメイン ( キリッ
  11. 11. 11 解決しなければならない 大きな問題
  12. 12. 12 LogやDataを軽視する人               /)            ///)           /,.= ゙''"/    /     i f ,.r='"-‐'つ_   /      /   _,.-‐'~/⌒  ⌒\     /  ,i   ,二ニ⊃( ●). (●)\    /    ノ  il ゙フ::::::⌒(__人__)⌒::::: \       , イ「ト、  ,!,!|     |r┬-|     |      / i トヾヽ_/ ィ"\   `ー'´     / Logはどうでもいいんだよ!!
  13. 13. 13 LogやData取得が後回しにされる理由 ● サービスの開発が最優先、Logは無くても動く ● LogSystemの開発は簡単という誤解(怒) ● UserDataを取得するとUserの入力負荷が高くなる ● Data分析方法が分からない
  14. 14. 14 Logエンジニアの現場人数 アプリエンジニアの1/20
  15. 15. 15
  16. 16. 16 理解して欲しいこと Logの重要性
  17. 17. 17 アジェンダ 0. 自己紹介 1. Logを記録する 2. Logを集める 3. Logを集計する 4. Logを解析する 5. 質疑応答
  18. 18. 18 Logの記録目的(冗談) 元気があれば何でもできる! Logがあれば何でも分かる!
  19. 19. 19 Logの記録目的(真面目) Log ≒ Evidence Log ⇒ Next Strategy
  20. 20. 20 大事な事なので2度言います Log分析は サービス戦略に繋がる
  21. 21. 21 Logの記録で重要な事 3W1H (When,Who,What,How) Logだけで情報が揃うように
  22. 22. 22 Logの種類と記録項目 ● AccessLog ✔ RequestTime(When), RequestURI(What), Referer(How) ✔ AccessIP, UA ✔ ResponseTime, Status ✔ Cookie(Who) ✔ BrowserID ✔ UserID ✔ UserAttribute ✔ DeviceID(Who)
  23. 23. 23 ServerLogの種類と記録項目 ● ErrorLog ✔ RequestTime, RequestURI, UA, Cookie ✔ ErrorLevel, ErrorFile&Line, ErrorComment ● ApplicationLog ✔ Applicationが特定の状況下で記録するLog
  24. 24. 24 BrowserID UserID/Attribute 超重要
  25. 25. 25 何が重要なの? (後で!)
  26. 26. 26 「mod_oreore」によるBrowserID発行 ● Serverへの初回アクセス時にCookieを発行する ● ApacheModuleだからApplicationの実装が不要 ● mod_usertrack,mod_session_cookieの不足点をカバー ● https://github.com/yutakikuchi/apache_module.git ● 30秒で設定可能
  27. 27. 27 UserID/Attributeの記録 ● UserID/AttributeはLoginをした段階でCookieに付与 (Applicationのレイヤーで実装) ● Hackingされないように変換や暗号化
  28. 28. CookieをLogに落とす 28
  29. 29. 29 Logに落とすCookieの例 oreore_cookie:id=MTkyLjE2OC41Ni4xMDE0MDkxMTk2ODQ wMzg3MTMyMDE2NTQyNzI1MDMzMTY0OA..&attr=Mjg0Z mUyMzk0Yzg0ZGIzZTIzYTI3N2ExYzhmYTZmMGY3Mzk1MjM 4Ng.. ● id : TimeStamp + LocalIP + ProcessNum + ConnectionNum ● attr: UserID + Gender + Age をAES-CBCで暗号化
  30. 30. 30 LogFormat ● Default(Apache) ::1 - - [08/Feb/2014:21:32:10 +0900] "GET / HTTP/1.1" 403 5039 "-" "curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2" ● Labeled Tab-Separated Values(LTSV) host:::1<Tab>ident:-<Tab>user:-<Tab>time:[08/Feb/2014:21:32:10 +0900]<Tab>Request:GET / HTTP/1.1<Tab>status: 403 <Tab>size:5039<Tab>referer:-<Tab>agent:curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2 ● ControllCharcter Separeted Values host<^B>::1<^A>ident<^B>-<^A>user<^B>-<^A>time<^B>[08/Feb/2014:21:32:10 +0900]<^A>Request<^B>GET / HTTP/1.1<^A>status<^B> 403 <^A>size<^B>5039<^A>referer<^B>-<^A>agent<^B>curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
  31. 31. 31 どのFormatが良いか? ● Log項目の付け足し/削除は後から必ず発生する ● 付け足しが発生してもParse後の順番依存が無い事 ● 人目で見ても項目と値が分かり易い LTSVFormatがお勧め
  32. 32. 32 LogServer構成
  33. 33. 33 PV, Imps, CTs, CVLog ③BeaconRequest ⑤Staus:302 Location:Url ConversionBeacon ⑧ConversionRequest ①Request                  ②HTML,BeaconURL ⑥Buy ④Click ⑦HTML,BeaconURL WebServer PV/ImpBeacon 広告主Server ClickRedirector
  34. 34. 34 CTsとCVLog 少し詳しく
  35. 35. 35 Click情報 どこに掲載したら Clickされたのか
  36. 36. 36 導入したClick検知方法 ● 外部Domainへの遷移検知にはRedirectorを入れる ● Logにどのページのどのリンクが押されたのか記録する ✔ 予約Parameter(?__uri=hoo&__link=bar_1) ✔ Click計測用Cookie(ClickCookie:__uri=hoo&__link=bar_1) ✔ ※Refererは送信しないブラウザがあるので注意 ● 識別子の付与はJavascript:Onclick()で出来ると吉 ● 集計処理でParameterの値をCountUP ● 識別子の管理がFEとBIツールで共有が必要(改善ポイント)
  37. 37. 37 Click検知の失敗点 アプリエンジニアの実装にミスが発生する! CTR集計結果に影響が出る!! 戦略チームから@yutakikucが怒られる!!! @yutakikucがアクセスログから実装ミスをカバーする!!!!
  38. 38. 38 CVLogに必要な事 ● (外部)サイトに検知用Beaconタグを埋め込んでもらう ● LogにどのサイトでどのようなCVが発生したのか記録する - Parameterで表現する (例)<img src='http://cbeacon.hikalab.com? siteid=25&productid=13&actionid=2&sign=hikalabo0828' /> ● BrowserID等のCookieは当然記録する
  39. 39. 39 CVLogの活用 ● Userの購入プロセスの状況把握 ● 購入済み商品はRecommendの対象外 ● 類似商品のRecommend ● 同じような行動履歴のUserへのRecommend
  40. 40. 40 「Logを記録する」まとめ ●Log分析は戦略に繋がる ●BrowserID,User,Attributeの記録 ●LTSV Format ●CTs,CVLogの記録
  41. 41. 41 アジェンダ 0. 自己紹介 1. Logを記録する 2. Logを集める 3. Logを集計する 4. Logを解析する 5. 質疑応答
  42. 42. 42 Logの管理構成 RealTime or Batch ? Push or Pull ? IP Restriction WebServer① WebServer② BeaconServer Redirector LogAggregator MongoDB FS Redis LogFile Reference Batch Mysql Save Result
  43. 43. 43 RealTime or Batch Push or Pull ● RealTime(Fluentd,Storm) ✔ 即時集計/解析 ✔ 一度の転送量を抑える ✗ Batchと比較して転送/解析の技術 ハードルが高い ● Batch(Rsyslog,[RD]sync) ✔ 定期集計/解析 ✔ 安定した集計 ✗ 一度の転送量が多くなる ● Push(Fluentd,[RD]Sync) ✔ 送信元ServerがLog転送する ✔ Logを出力=>転送が自然な流れ ✗ 送信元Serverの負荷が心配 ● Pull(Rsyslog,Storm,[RD]Sync) ✔ 受信元ServerLogがLogを回収する ✔ メインの設定が受信元Serverで出来 る ✔ 送信元Serverの負荷は軽減? ✗ 実装/設定が面倒
  44. 44. 44 RealTime Log転送で気をつけたい事 ● 処理が詰まらないように(Server性能の限界を確認しておこう) ● 転送完了したファイル名とLine数を記録する ● HotStandyの用意 ● Batchに切り替える手段を用意 ● 小規模かつ重要でないLogから導入テストしてみるとか
  45. 45. 45 Batch Log転送で気をつけたい事 ● Rotate処理と転送処理の時間が重なった時の取りこぼし ※ チェックサムの確認 ● 転送時間が大きくならない事 ※ 複数のデータセンターへの転送 ● 冗長化サーバー毎に転送開始時間をづらす ● ファイルの圧縮
  46. 46. 46 広告配信での実例 Imps:500,000、Clicks:2000、Log容量:200M
  47. 47. 47 集計の土台 安定したPull型Batch ※Batchは1日1回 広告主への正確なレポート提出のため Rsync + FuelPHP Task
  48. 48. 48 +α Imps,CTsはPush型 RealTime集計を準備中 ※Imps保証数を必要以上に超過させない RealTimeでのリターゲティング Fluentd + fuent-plugin-redis
  49. 49. 49 最小構成でも トラフィック問題は 発生せず... or2
  50. 50. 50 冗長化対応での問題 回収先サーバーの 追加設定漏れ
  51. 51. 51 「Logを集める」まとめ ●回収方法の特性を理解 ●集計の土台はPull型Batchで安定稼働 ●配信制御に関わる事は極力RealTimeで
  52. 52. 52 アジェンダ 0. 自己紹介 1. Logを記録する 2. Logを集める 3. Logを集計する 4. Logを解析する 5. 質疑応答
  53. 53. 53 KPI / KGI
  54. 54. 54 原始的な集計 cut -f 2 log.txt | sort | uniq | wc -l
  55. 55. 55 強力なツール ※要件が合えば利用
  56. 56. 56 強力ツールで出来ない事 ●ページ内コンテンツの配信数 ● Browser毎の履歴集計 ●無料では出来る事が限られる ●長期的なログ蓄積には不向き
  57. 57. GoogleAnalytics(GA)とRequestLogの違い 57 GA RequestLog 1400000 1200000 1000000 800000 600000 400000 200000 0 1000000 1200000 300000 250000 PV User ✔ RequestLogのPV値はGAの120%程 ✔ RequestLogのUser値はGAの70%程 ✔ CSCとSSC : 表示数とRequest数の違い ✔ GA集計はBlackBox ✔ 通信Error, noscript, 非対応機種... ✔ GoogleCookieと独自Cookieの付与状況
  58. 58. 58 独自集計 ツールとの棲み分け 緊急性と重要度の判定
  59. 59. 59 緊急性と重要度 データの種類データの項目緊急性重要度格納先 広告Imps速報高中Redis 広告CTs速報高中Redis 広告効果レポート低高Mysql サービスPV 低高Mysql サービスCTR 低高Mysql サービスPV / UU / UB 低高Mysql 全て生ログ低高FS 全て準生ログ高中MongoDB
  60. 60. 60 Mysqlは安定している 心配なのはWrite速度
  61. 61. 61 Mysql Table設計 ●テーブル設計 = 集計する項目の決定 ●Relationは作らない – 冗長的な登録は許容 ●古いデータは消す事が前提 – 日付のPartitioningでparge ●複雑な処理は多段集計 – 1次集計Table、2次集計Table
  62. 62. 62 MysqlへのWrite ● Batch処理 ✔ BatchでOnMemory(連想配列)に集計結果を乗せてからBulkInsert ✔ Hadoopで集計しSqoopで結果をImport ● RealTime処理 ✔ RunTimeでMongoDBへ格納。MogoDBのデータをBatchで集計 し、Mysqlへ格納 ✔ MysqlのBlackHoleEngineを利用。実体をSlaveに ✔ 特定行数を一度Queue/Summaryして、BulkInsert
  63. 63. 63 Redisの利用 ● データ管理をMemoryとStorageの両方で旨くこなす凄い奴 ● 大量データのINSERT/SELECTもMysqlより高速 ● MemoryとStorageの両方から消えた場合が大変 ● 広告のRealTimeのImps制御で利用 ✔ 超過Impsは極力発生させたく無い ✔ RealTimeで広告IDとImpsした回数を書き込む ✔ 保険としてBatchでも整合性を確認
  64. 64. 64 MongoDBの利用 ●スキーマ定義が不要でカラム追加の運用も要らない ●大量データのInsertがMysqlより速い(SELECTは同等) ● Index, Sharding等の機能もある ●fnd条件指定が簡単でCross集計も可能(例. Android×LoginしているUB数) ●準生ログを保存(BIツールからのみ参照させる) ●データが消えるという事例報告がある
  65. 65. 65 Performance担保への最終手段 サンプリング集計 ※広告は除く
  66. 66. 66 「Logを集計する」まとめ ●集計の緊急度と重要度で集計方法を変える ●MysqlのINSERT速度が心配 ●MongoDBやRedisも導入すると良い
  67. 67. 67 アジェンダ 0. 自己紹介 1. Logを記録する 2. Logを集める 3. Logを集計する 4. Logを分析する 5. 質疑応答
  68. 68. 68 BrowserID UserID/Attribute 超重要
  69. 69. 69 何が重要なの?
  70. 70. 70 その① 行動履歴の集約 識別子をkeyにsortで纏める 行動素性の抽出 MapReduceとの相性
  71. 71. 71 その② 分類済み正解データからの推定 BrowserID : 1 UserID : A 女性× 20代 BrowserID : 2 UserID : ? 女性? 20代 ? @cosme zexy.net @cosme zexy.net ?
  72. 72. 72 その③ User×デバイスデータ取得可能 1人で複数台利用 (1つのUserIDでの紐付け) 複数人で1台を利用 (複数のUserIDでの紐付け) ※分析データから除外する
  73. 73. 73 性別推定
  74. 74. 74 性別推定 ● Userの性別に対してコンテンツや広告をtargetingしたい ●性別が取れるUserは20%以下。※Login必須サイトで無い場合 ● 2値分類(random推定でも50%) ●仕組みが単純で高精度が望ましい ●精度とカバー率の塩梅
  75. 75. 75 条件付き確率 ●推定手法の一例 その他決定木やVectorでの分類がある ●仕組みが単純、実装しやすい ●並列分散処理OK ● P(C|D) P: 確率, C:カテゴリ, D:事象 例) 「サッカー」で検索したUserは80%男性である ●対数化や正規化などの処理が最後に必要
  76. 76. 76 「Naive Bayes」 でぐぐれ!
  77. 77. 77 推定Model作成と評価 ● まずはオフラインで ● 素性はスペース区切り検索Query ● 訓練データ、推定対象データの準備 (過去28日間) ✔訓練データ: 性別が分かるBrowserID×Query ✔推定対象データ: 性別が分からないBrowserID×Query ✔複数のUserIDが紐づくBrowserIDは対象外 ● 訓練データから推定Modelを評価 ✔K-fold Cross Validation(k-1個のデータセットからModelを作成し、その他1個で精度評 価) ● Modelを使って推定対象データから予測 ✔男性の確率:90%、女性の確率:10%
  78. 78. 78 毎日推定 ● 次にオンラインで ● 2年前はOozie × Pigで素性抽出/Model作成/推定を完全自動化 ● 今ならhivemallを使いますかね ● R言語でも簡単にできます ● BrowserIDを基に推定確率をRedisに格納
  79. 79. 79 精度とカバー率と配信の閾値 80%は女性と推定 精度80%以上のカバー率は3割 この人は女性で配信しますか? 配信側の閾値調整
  80. 80. 80 気をつけたい事 ●導入後のKPI変動の監視 ✔ Targeting増 => CTs増 => CV下 ✔導入前のシミュレーションも欠かさずに行う ●推定Modelの定期的な評価 ✔完全自動化での安定運用のため
  81. 81. 年代(10歳区切り)推定 マルチ分類への応用 81
  82. 82. 82 「Logを解析する」まとめ ● 分類済み正解データの取得 ● 推定によりTargeting数を増やす ● 素性抽出、推定Model作成、推定 ● 推定確率により配信する/しない
  83. 83. 83 以上
  84. 84. 84 質疑応答

×