Contenu connexe Similaire à ログにまつわるエトセトラ (20) ログにまつわるエトセトラ2. 2
話しません(´;ω;`)
● GrowthHack
✔ Retention/ConversionUP施策
✔ A/BテストによるUI改善
● 可視化
✔ BIツール
5. 5
Page View (PV)
Impression (Imps)
Click (CTs)
Conversion (CV)
6. 6
アジェンダ
0. 自己紹介
1. Logを記録する
2. Logを集める
3. Logを集計する
4. Logを解析する
5. 質疑応答
7. 7
自己紹介
● 菊池佑太@yutakikuc
● EX. Yahoo! AD-Science
● 旅行で世界30都市制覇!
● 陸サーファー、時々サーファー
● http://d.hatena.ne.jp/yutakikuchi
10. 10
仕事内容
開発 20%
研究 10%
データ出し 10%
ログ調査 60%
開発
研究
データ出し
ログ調査
雑用がメイン
( キリッ
12. 12
LogやDataを軽視する人
/)
///)
/,.= ゙''"/
/ i f ,.r='"-‐'つ_
/ / _,.-‐'~/⌒ ⌒\
/ ,i ,二ニ⊃( ●). (●)\
/ ノ il ゙フ::::::⌒(__人__)⌒::::: \
, イ「ト、 ,!,!| |r┬-| |
/ i トヾヽ_/ ィ"\ `ー'´ /
Logはどうでもいいんだよ!!
13. 13
LogやData取得が後回しにされる理由
● サービスの開発が最優先、Logは無くても動く
● LogSystemの開発は簡単という誤解(怒)
● UserDataを取得するとUserの入力負荷が高くなる
● Data分析方法が分からない
17. 17
アジェンダ
0. 自己紹介
1. Logを記録する
2. Logを集める
3. Logを集計する
4. Logを解析する
5. 質疑応答
22. 22
Logの種類と記録項目
● AccessLog
✔ RequestTime(When), RequestURI(What), Referer(How)
✔ AccessIP, UA
✔ ResponseTime, Status
✔ Cookie(Who)
✔ BrowserID
✔ UserID
✔ UserAttribute
✔ DeviceID(Who)
23. 23
ServerLogの種類と記録項目
● ErrorLog
✔ RequestTime, RequestURI, UA, Cookie
✔ ErrorLevel, ErrorFile&Line, ErrorComment
● ApplicationLog
✔ Applicationが特定の状況下で記録するLog
26. 26
「mod_oreore」によるBrowserID発行
● Serverへの初回アクセス時にCookieを発行する
● ApacheModuleだからApplicationの実装が不要
● mod_usertrack,mod_session_cookieの不足点をカバー
● https://github.com/yutakikuchi/apache_module.git
● 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
どのFormatが良いか?
● Log項目の付け足し/削除は後から必ず発生する
● 付け足しが発生してもParse後の順番依存が無い事
● 人目で見ても項目と値が分かり易い
LTSVFormatがお勧め
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
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ツールで共有が必要(改善ポイント)
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
CVLogの活用
● Userの購入プロセスの状況把握
● 購入済み商品はRecommendの対象外
● 類似商品のRecommend
● 同じような行動履歴のUserへのRecommend
41. 41
アジェンダ
0. 自己紹介
1. Logを記録する
2. Logを集める
3. Logを集計する
4. Logを解析する
5. 質疑応答
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
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
RealTime Log転送で気をつけたい事
● 処理が詰まらないように(Server性能の限界を確認しておこう)
● 転送完了したファイル名とLine数を記録する
● HotStandyの用意
● Batchに切り替える手段を用意
● 小規模かつ重要でないLogから導入テストしてみるとか
45. 45
Batch Log転送で気をつけたい事
● Rotate処理と転送処理の時間が重なった時の取りこぼし
※ チェックサムの確認
● 転送時間が大きくならない事
※ 複数のデータセンターへの転送
● 冗長化サーバー毎に転送開始時間をづらす
● ファイルの圧縮
48. 48
+α
Imps,CTsはPush型
RealTime集計を準備中
※Imps保証数を必要以上に超過させない
RealTimeでのリターゲティング
Fluentd + fuent-plugin-redis
52. 52
アジェンダ
0. 自己紹介
1. Logを記録する
2. Logを集める
3. Logを集計する
4. Logを解析する
5. 質疑応答
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の付与状況
59. 59
緊急性と重要度
データの種類データの項目緊急性重要度格納先
広告Imps速報高中Redis
広告CTs速報高中Redis
広告効果レポート低高Mysql
サービスPV 低高Mysql
サービスCTR 低高Mysql
サービスPV / UU / UB 低高Mysql
全て生ログ低高FS
全て準生ログ高中MongoDB
61. 61
Mysql Table設計
●テーブル設計 = 集計する項目の決定
●Relationは作らない
– 冗長的な登録は許容
●古いデータは消す事が前提
– 日付のPartitioningでparge
●複雑な処理は多段集計
– 1次集計Table、2次集計Table
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
Redisの利用
● データ管理をMemoryとStorageの両方で旨くこなす凄い奴
● 大量データのINSERT/SELECTもMysqlより高速
● MemoryとStorageの両方から消えた場合が大変
● 広告のRealTimeのImps制御で利用
✔ 超過Impsは極力発生させたく無い
✔ RealTimeで広告IDとImpsした回数を書き込む
✔ 保険としてBatchでも整合性を確認
64. 64
MongoDBの利用
●スキーマ定義が不要でカラム追加の運用も要らない
●大量データのInsertがMysqlより速い(SELECTは同等)
● Index, Sharding等の機能もある
●fnd条件指定が簡単でCross集計も可能(例. Android×LoginしているUB数)
●準生ログを保存(BIツールからのみ参照させる)
●データが消えるという事例報告がある
67. 67
アジェンダ
0. 自己紹介
1. Logを記録する
2. Logを集める
3. Logを集計する
4. Logを分析する
5. 質疑応答
71. 71
その② 分類済み正解データからの推定
BrowserID : 1
UserID : A
女性× 20代
BrowserID : 2
UserID : ?
女性? 20代 ?
@cosme
zexy.net
@cosme
zexy.net
?
74. 74
性別推定
● Userの性別に対してコンテンツや広告をtargetingしたい
●性別が取れるUserは20%以下。※Login必須サイトで無い場合
● 2値分類(random推定でも50%)
●仕組みが単純で高精度が望ましい
●精度とカバー率の塩梅
75. 75
条件付き確率
●推定手法の一例
その他決定木やVectorでの分類がある
●仕組みが単純、実装しやすい
●並列分散処理OK
● P(C|D) P: 確率, C:カテゴリ, D:事象
例) 「サッカー」で検索したUserは80%男性である
●対数化や正規化などの処理が最後に必要
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
毎日推定
● 次にオンラインで
● 2年前はOozie × Pigで素性抽出/Model作成/推定を完全自動化
● 今ならhivemallを使いますかね
● R言語でも簡単にできます
● BrowserIDを基に推定確率をRedisに格納
82. 82
「Logを解析する」まとめ
● 分類済み正解データの取得
● 推定によりTargeting数を増やす
● 素性抽出、推定Model作成、推定
● 推定確率により配信する/しない