Machine Learning Casual Talks #4...
-
Upload
naoto-tamiya -
Category
Engineering
-
view
4.712 -
download
1
Transcript of Machine Learning Casual Talks #4...
DevOpsDevOpsとは、開発(Development)と運⽤(Operations)が協⼒し、ビジネス要求に対して、より柔軟に、スピーディに対応できるシステムを作り上げるためのプラクティスです。
DataOps5
ビッグデータを活⽤して売上貢献するにはどうするのか。
現状の問題点
■販売機会の損失• サービス使ってるのに
そのサービスのバナーやレコメンドが表⽰される
• 離脱していく顧客に対して、適切な案内・訴求を⾏っていない
■⼈⼿による限界• Googleの「もしかして**?」の
ように、予め登録しておくのは物量的に難しくなっている
• 商品毎にオススメ商品を設定するには、多種多様過ぎて困難。ましてや、ユーザー毎には無理。
■経営判断の遅れ• ⼈⼿で対応することにより、
レポートの提供が遅延
• レポートが完成するまでの時間が⻑く、迅速に判断出来ない
• 効果があったのかどうか曖昧
ビッグデータの活⽤
機械学習・AIを活⽤し、検索・レコメンドの⾃動化、⾼精度化
ユーザーの状態・趣味嗜好に基づいた情報の出し分け
レポート周りの業務を⾼速化、定型化、可視化し正しい判断
効果のあるユーザーに 適切なタイミングで ユーザーの求める情報を
商品探している 検索語句を間違って⼊⼒
商品買った後は
もしかして**?を提⽰
商品を買ったユーザーに 該当商品をオススメしない
しばらく使ってなければお得意様が メールで嗜好にあう情報を
検索 レコメンド
メルマガ
精度向上を目指す
サイト内広告 アフィリエイト
メルマガ
徐々に組み入れる
レポート
評価
ログデータ
改善
8
今回お話すること…。⽴ち上げフェーズ
• 組織の発⾜• 各所へのヒヤリング
運⽤フェーズ
• レコメンドの実装• 分析レポートの提供• 定形レポートの提供
導⼊フェーズ
• ログの設計• ログの実装依頼• データの収集
• 世間の流れ• 他社で経験した内容
• DMMで起こったこと• DMMでやったこと
こうすればよかった!こうした⽅がよい!
9
ビッグデータチームの結成の仕⽅により、戦略・推進の⽅法が異なることを
意識しないといけない
⽴ち上げフェーズ
• 組織の発⾜• 各所へのヒヤリング
運⽤フェーズ
• レコメンドの実装• 各種レポートの提供
導⼊フェーズ
• ログの設計• ログの実装依頼• データの収集
11
どこからの発令か
トップダウンで取組む
ボトムアップで取組む
どういう組織か
専⾨組織型先端的なテクノロジーを全事業に展開する企業の採⽤が多い
事業部⾨型データ分析⼈材がビジネスそのものに深く関わっている
専⾨組織+事業部⾨型専⾨部署と事業部⾨が連携しながら進める
これらの組み合わせによって、以降の会話が⼤きく変わります。
12
トップダウンで取組む
ボトムアップで取組む
• 組織の⽴ち上がり、スピード感
• ログの実装に強制⼒があった
• ⾃分たちで何をやるか決めていけた
• 規模の⼩さいものから徐々に広げていけた
• 既存事業部を巻き込むご説明
• ログの実装に強制⼒がない→ログが揃うまで、⺟集団が変わる
• メリットを提⽰出来ないうちは、事業部からの反発も多くあるかも。
• とりあえず、統計学者を集めるケース
13
どこからの発令か
トップダウンで取組む
ボトムアップで取組む
どういう組織か
専⾨組織+事業部⾨型専⾨部署と事業部⾨が連携しながら進める
CTO室と⾔うR&Dを⾏なう部隊
ビッグデータ周りの取組みの⼀貫で、検索 / レコメンド / ⾏動解析を軸に
各事業部と連携して、仕組みを提供する形式
14
**事業部
**したいので、ログ埋めていただけますか?
今、⼯数ないので無理です。
どう⾔うものか説明して。
(説明する)
事業部がやること??共通チームで出来ないの?
実は外注にレコメンドを作ってもらうよう依頼中
話が伝わっていなかった
個別個別にご説明
基本的に運⽤側は多忙
攻め⽅を間違った!!!15
データ収集について
DBをsqoopで転送
ログは共通チームで最⼩限
取組みの進め⽅
ヒヤリングを元に、求められているところ、結果が出せそうなところから
結果が出れば、信頼される希望的観測
PRJ個別ログも最⼩限
やりたいレコメンド、分析に対してログが不⾜した場合
データ収集もより協⼒的になっていくと考えた
ボトムアップならではの⾟さ
16
どこからの発令か
トップダウンで取組む
ボトムアップで取組む
どういう組織か
専⾨組織型先端的なテクノロジーを全事業に展開する企業の採⽤が多い
事業部⾨型データ分析⼈材がビジネスそのものに深く関わっている
専⾨組織+事業部⾨型専⾨部署と事業部⾨が連携しながら進める
⾃分たちがどの組み合わせで攻めるか
17
ビッグデータチームの結成の仕⽅により、戦略・推進の⽅法が異なることを
意識しないといけない
⽴ち上げフェーズ
• 組織の発⾜• 各所へのヒヤリング
運⽤フェーズ
• レコメンドの実装• 各種レポートの提供
導⼊フェーズ
• ログの設計• ログの実装依頼• データの収集
最初を間違うと結構苦労します…。
18
送信されるログ、転送してきたデータは完全ではないことを意識しておくこと
⽴ち上げフェーズ
• 組織の発⾜• 各所へのヒヤリング
運⽤フェーズ
• レコメンドの実装• 各種レポートの提供
導⼊フェーズ
• ログの設計• ログの実装依頼• データの収集
19
サーバーサイドで落とす
JavaScript / APIでコールする
• 割とライトに実装可能
• クローラーのログは少なめ• 実装側は⽐較的容易に扱える
• ブラウザ、デバイスの差異の吸収• 実装漏れ・ミスが多々ある
• クローラーのログが相当数乗っかる• 実装漏れ・ミスが多々ある• ライブラリ提供の際は、各種⾔語で
データベースから転送してくる
• Transactionが利くので⼀番正しい • サービス基準なので、解析基準のデータがあることは少ない
20
使⽤範囲・⽤途
経営レポートとして トレンドとして 取得出来たもののみ説明
データベース
レコメンドAPI
⾏動解析ツール / レポートツール
精度
サーバーサイド
JavaScript / API
21
絶対ミスが発⽣する
EXTARNALTABLE
(or TABLE)TABLE
send(‘ac)on’,‘op)on’,value);
like(‘op)on’,value); ※オプションも定義済み以外弾く
• ひたすら貼られるとデータ量、トラフィック的にキツイ• like / good / nice とか揺らぎ、タイプミスとかある
データ整形/クリーニングDB
23
送信されるログ、転送してきたデータは完全ではないことを意識しておくこと
⽴ち上げフェーズ
• 組織の発⾜• 各所へのヒヤリング
運⽤フェーズ
• レコメンドの実装• 各種レポートの提供
導⼊フェーズ
• ログの設計• ログの実装依頼• データの収集
データにゴミが⼊らない⼯夫を…。
24
集計したい対象は常に拡⼤するが、集計ロジックは増やさないように考慮する
⽴ち上げフェーズ
• 組織の発⾜• 各所へのヒヤリング
運⽤フェーズ
• レコメンドの実装• 各種レポートの提供
導⼊フェーズ
• ログの設計• ログの実装依頼• データの収集
25
レポート / ⾏動解析
UU、アクション、CVのそもそもの数値が不明
PC / SP、会員 / ⾮会員等のドリルダウンを所望
ドリルダウンの掛けあわせが確認したくなる
サーバーの負荷
集計ロジックの保守性
提供を受ける側が満たされると、次の要望が出てくる
成功した事例が出てくると、他も便乗したくなる
深掘
拡⼤
26
運⽤側からの要求はなくとも、予め範囲を広げて集計している
その上で、集計時間やサーバーの負荷状況を⾒積もる
依頼受けたサービス受けていないサービス サービス別 / 事業部別 全体 / PC / SP 他
【LATERAL VIEW】を使って、ロジックが増えることを抑制
27
session service url
abc... book h9p://〜
def... video h9p://〜
ghi... video_monthly h9p://〜
jkl... book h9p://〜
session service url
abc... all h9p://〜
def... all h9p://〜
ghi... all h9p://〜
jkl... all h9p://〜
abc... book h9p://〜
def... video h9p://〜
ghi... video_monthly h9p://〜
jkl... book h9p://〜
ログデータ
中間データ
LATERAL VIEW
28
SELECT *FROM ( SELECT session, service, url FROM activity ) a LATERAL VIEW explode(array(site, 'all')) a as site
session service url
abc... book h9p://〜
def... video h9p://〜
ghi... video_monthly h9p://〜
jkl... book h9p://〜
session service url
abc... all h9p://〜
def... all h9p://〜
ghi... all h9p://〜
jkl... all h9p://〜
abc... book h9p://〜
def... video h9p://〜
ghi... video_monthly h9p://〜
jkl... book h9p://〜29
SELECT *FROM ( SELECT * FROM activity ) a LATERAL VIEW explode(array(site, 'all')) a as site LATERAL VIEW explode(array(division, 'all')) a as division LATERAL VIEW explode(array(service, 'all')) a as service LATERAL VIEW explode(array(purchase_site, 'all')) a as site_kind LATERAL VIEW explode(array(view_type, 'all')) a as view_type
30
集計したい対象は常に拡⼤するが、集計ロジックは増やさないように考慮する
⽴ち上げフェーズ
• 組織の発⾜• 各所へのヒヤリング
運⽤フェーズ
• レコメンドの実装• 各種レポートの提供
導⼊フェーズ
• ログの設計• ログの実装依頼• データの収集
成果が出ると、⼀気にニーズが⾼まるので、予め捌けるようなロジック、インフラを準備
31
ログの実装は⾃分たちでやれる環境を整備しておくと運⽤側も実装側も平和
⽴ち上げフェーズ
• 組織の発⾜• 各所へのヒヤリング
運⽤フェーズ
• レコメンドの実装• 各種レポートの提供
導⼊フェーズ
• ログの設計• ログの実装依頼• データの収集
32
レコメンドを提供する際の登場⼈物
分析担当
• レコメンドのロジック• レポートの作成
開発チーム
• TrackingAPI / JS
プラットフォーム
• 共通ヘッダー• カート機能
インフラチーム
• Hadoop基盤の構築• APIサーバーの⼿配
サービス担当
• アクションの送信• レコメンドAPI組込み
関係者が多く、どこかが作業遅延すると全体に影響
いつだってサービス担当(運⽤サイド)は忙しい
33
ビッグデータ部の構成
分析担当
• レコメンドのロジック• レポートの作成
開発チーム
• TrackingAPI / JS
プラットフォーム
• 共通ヘッダー• カート機能
インフラチーム
• Hadoop基盤の構築• APIサーバーの⼿配
サービス担当
• アクションの送信• レコメンドAPI組込み
作業遅延が起こるリスク
ログの実装にミスがあることが出てくるリスク
34
レコメンドシステムinput
• 商品表⽰ログ• 商品購⼊ログ
output
• レコメンドAPI →JSON
• レコメンド表⽰ログ• レコメンド押下ログ
【Modern Information Retrieval】
検索エンジンの評価に関する項に記載のものをレコメンドでも当てはめてレコメンドのロジックを検証
• Presision and Recall• Single Value Summaries• User-Oriented Measures• Discounted Cumulated Gain
35
レコメンドシステムinput
• 商品表⽰ログ• 商品購⼊ログ
output
• レコメンドAPI(JSON)
• レコメンド表⽰ログ• レコメンド押下ログ
DBの購⼊データのみで作成することが可能• 商品表⽰ログ• 商品購⼊ログ
サービス側が欲しいモノ
サービス側レコメンドシステム側
要件は満たされた精度を上げる材料が揃っていない
効果あった or 効果なかった
36
サービス側
いつだって忙しい
効果があれば⼊れたい
よくわからないものに⼯数をかけたくない
実験台にはなりたくない
失敗したくない
売上が上がるから⼊れたい!!!
最短で⼊れたい!!!
俺も! うちも!! 私も!!!
ログ実装を依頼
⼯数かかるなんて知らなかった…。
差し込み案件があり、⼀ヶ⽉後に…。
実装したが、いくつかのサービスでログ実装を誤って実装した
ビッグデータチームにおいては、あんまり良くない状況…。
37
レコメンドシステムinput
• 商品表⽰ログ• 商品購⼊ログ
output
• レコメンド表⽰ログ• レコメンド押下ログ
input
• 商品表⽰ログ• 商品購⼊ログ
output
• レコメンドAPI →JSON
レコメンドシステム
• レコメンド表⽰ログ• レコメンド押下ログ
• レコメンドAPI→HTML→URLにTrackingを
38
ログの実装は⾃分たちでやれる環境を整備しておくと運⽤側も実装側も平和
⽴ち上げフェーズ
• 組織の発⾜• 各所へのヒヤリング
運⽤フェーズ
• レコメンドの実装• 各種レポートの提供
導⼊フェーズ
• ログの設計• ログの実装依頼• データの収集
最適なチームの構成と他に影響することのない⾃⾛出来る運⽤体制を構築すべき
39
レポート / データを提供しても使われないことを予め認識しておくこと
⽴ち上げフェーズ
• 組織の発⾜• 各所へのヒヤリング
運⽤フェーズ
• レコメンドの実装• 各種レポートの提供
導⼊フェーズ
• ログの設計• ログの実装依頼• データの収集
40
検索時に、条件を1つしか指定していないのと、2つ指定しているのとでは、リストのCTRが随分違うぞ!
△ 動画 > アニメ > ジャンル > アクション◯ 動画 > アニメ > ジャンル > アクション > 2000年代
アナリストさんがレポートを送信しました。
組み合わせデータの中でも、良く押されている組み合わせとそうでない組み合わせがあるぞ!
△ アクション > キッズ◯ アクション > 2000年代
アナリストさんが組み合わせデータ.csvを送信しました。
41
実装されない理由
2%〜3%の改善では、サービスに課せられている⽬標を達成出来ない
対応デバイス / ラインナップの拡⼤を求められているフェーズ
上述背景もあって、⼯数が取れない
データチーム
DB
DB
サービス側
DB
CreateAPI
42
レポート / データを提供しても使われないことを予め認識しておくこと
⽴ち上げフェーズ
• 組織の発⾜• 各所へのヒヤリング
運⽤フェーズ
• レコメンドの実装• 各種レポートの提供
導⼊フェーズ
• ログの設計• ログの実装依頼• データの収集
サービス側に頼らず、改善案が提供出来る仕組みを作る
44
管理ツールは事業部⾨のためではなく、専⾨部⾨のためのツールになっていく
⽴ち上げフェーズ
• 組織の発⾜• 各所へのヒヤリング
運⽤フェーズ
• レコメンドの実装• 分析レポートの提供• 定形レポートの提供
導⼊フェーズ
• ログの設計• ログの実装依頼• データの収集
45
事業部が増えると、こっちのリソースも増やさないといけないし、レコメンドのロジックをチューニング出来る管理ツールを提供しよう
**事業部
今後はツールから、チューニング出来ますから。
提供されてもわからないよ。
何を元に判断すればいいの?
指標もツールで⾒れますよ。
事業部がやること??専⾨チームがやるべきでは?
そう⾔う⼈材いないから任せられても…。
46
どういう組織か
専⾨組織型先端的なテクノロジーを全事業に展開する企業の採⽤が多い
事業部⾨型データ分析⼈材がビジネスそのものに深く関わっている
専⾨組織+事業部⾨型専⾨部署と事業部⾨が連携しながら進める
CTO室の役割
専⾨組織+事業部⾨型専⾨部署と事業部⾨が連携しながら進める
求められた役割
専⾨組織型先端的なテクノロジーを全事業に展開する企業の採⽤が多い
今までの付き合い⽅に関する考えを、結構変えなくては…。
各事業部にデータに詳しい⼈材はいない、配置出来ない
逆に捉えると、任せられるようになった!!!!47
管理ツールは事業部⾨のためではなく、専⾨部⾨のためのツールになっていく
⽴ち上げフェーズ
• 組織の発⾜• 各所へのヒヤリング
運⽤フェーズ
• レコメンドの実装• 分析レポートの提供• 定形レポートの提供
導⼊フェーズ
• ログの設計• ログの実装依頼• データの収集
提供しても使うための知識・操作の習得が追いつかないので、結局頼られることになる
48
⽴ち上げフェーズ
ビッグデータチームの結成の仕⽅により、戦略・推進の⽅法が異なることを意識しないといけない
導⼊フェーズ
送信されるログ、転送してきたデータは完全ではないことを意識しておくこと
運⽤フェーズ
集計したい対象は常に拡⼤するが、集計ロジックは増やさないように考慮する
ログの実装は⾃分たちでやれる環境を整備しておくと運⽤側も実装側も平和
レポート / データを提供しても使われないことを予め認識しておくこと
管理ツールは事業部⾨のためではなく、専⾨部⾨のためのツールになっていく
50
⽴ち上げフェーズ
ビッグデータチームの結成の仕⽅により、戦略・推進の⽅法が異なることを意識しないといけない
導⼊フェーズ
送信されるログ、転送してきたデータは完全ではないことを意識しておくこと
運⽤フェーズ
集計したい対象は常に拡⼤するが、集計ロジックは増やさないように考慮する
ログの実装は⾃分たちでやれる環境を整備しておくと運⽤側も実装側も平和
レポート / データを提供しても使われないことを予め認識しておくこと
管理ツールは事業部⾨のためではなく、専⾨部⾨のためのツールになっていく
51
DevOpsDevOpsとは、開発(Development)と運⽤(Operations)が協⼒し、ビジネス要求に対して、より柔軟に、スピーディに対応できるシステムを作り上げるためのプラクティスです。
DataOps52
DataOpsDataOpsとは、【ビッグデータチーム(Data)】と【サービス側(Operations)】のやり取りおいて、より柔軟に、スピーディに対応できるシステムを作り上げるためのプラクティスです。
その1つとして、ビッグデータチームがログの実装、インフラから、改善案の提供までを、チーム体制含め、必要なメンバーをアサインし、サービス側に依存することなく、⾃⾛出来る環境を整備することで、実現できると考えられています。
53
新たなステージへ
⽴ち上げフェーズ
• 組織の発⾜• 各所へのヒヤリング
運⽤フェーズ
• レコメンドの実装• 分析レポートの提供• 定形レポートの提供
導⼊フェーズ
• ログの設計• ログの実装依頼• データの収集
ボトムアップ / R&Dの成果が⾝を結びつつ有る
様々な経験からのDMM.com流ベスト・プラクティス
ビッグデータ部拡⼤と貢献
54
ビッグデータ部12⽉1⽇に発⾜したばかり
まだオフィシャルに求⼈出回ってないかも…
発⾜メンバーがゆえの、活躍できるチャンスも…。
絶賛募集中!!!詳しくは、お近くのDMM.comラボのスタッフまでお尋ねください
55