machine learning casual talks #4...

ビッグデータチームを発⾜するにあたって気をつけておきたいn個のこと

DMM.comラボ⽥宮直⼈

1

⾃⼰紹介

⽥宮直⼈マーケティング開発部（マネージャー）

でした…。（過去形）

2

⾃⼰紹介

エンジニア歴 10年Web分析担当 3年

解析基盤整備 1年半

某新聞社の案件

起業

ミッドタウンにある会社

渋⾕にある会社渋⾕にある会社

何かしらデータ⾒て、ごにょごにょしてる期間

3

機械学習やっている⼈

データサイエンティスト

Webアナリスト

データ使って、何かしようとしている⼈

4

DevOpsDevOpsとは、開発（Development）と運⽤（Operations）が協⼒し、ビジネス要求に対して、より柔軟に、スピーディに対応できるシステムを作り上げるためのプラクティスです。

DataOps5

そして、突然ですが…

ビッグデータ部が出来ました！！！ビッグデータ部が出来ました！！！

にも

6

⾃⼰紹介

⽥宮直⼈マーケティング開発部（マネージャー）

ビッグデータ部データプラットフォーム課（グループリーダー）

7

ビッグデータを活⽤して売上貢献するにはどうするのか。

現状の問題点

■販売機会の損失•  サービス使ってるのに

そのサービスのバナーやレコメンドが表⽰される

•  離脱していく顧客に対して、適切な案内・訴求を⾏っていない

■⼈⼿による限界•  Googleの「もしかして＊＊？」の

ように、予め登録しておくのは物量的に難しくなっている

•  商品毎にオススメ商品を設定するには、多種多様過ぎて困難。ましてや、ユーザー毎には無理。

■経営判断の遅れ•  ⼈⼿で対応することにより、

レポートの提供が遅延

•  レポートが完成するまでの時間が⻑く、迅速に判断出来ない

•  効果があったのかどうか曖昧

ビッグデータの活⽤

機械学習・AIを活⽤し、検索・レコメンドの⾃動化、⾼精度化

ユーザーの状態・趣味嗜好に基づいた情報の出し分け

レポート周りの業務を⾼速化、定型化、可視化し正しい判断

効果のあるユーザーに適切なタイミングでユーザーの求める情報を

商品探している検索語句を間違って⼊⼒

商品買った後は

もしかして＊＊？を提⽰

商品を買ったユーザーに該当商品をオススメしない

しばらく使ってなければお得意様がメールで嗜好にあう情報を

検索レコメンド

メルマガ

精度向上を目指す

サイト内広告アフィリエイト

メルマガ

徐々に組み入れる

レポート

評価

ログデータ

改善

8

今回お話すること…。⽴ち上げフェーズ

•  組織の発⾜•  各所へのヒヤリング

運⽤フェーズ

•  レコメンドの実装•  分析レポートの提供•  定形レポートの提供

導⼊フェーズ

•  ログの設計•  ログの実装依頼•  データの収集

•  世間の流れ•  他社で経験した内容

•  DMMで起こったこと•  DMMでやったこと

こうすればよかった！こうした⽅がよい！

9

ビッグデータチームを発⾜するにあたって気をつけておきたいn個のこと

10

ビッグデータチームの結成の仕⽅により、戦略・推進の⽅法が異なることを

意識しないといけない

⽴ち上げフェーズ


運⽤フェーズ

•  レコメンドの実装•  各種レポートの提供

導⼊フェーズ


11

どこからの発令か

トップダウンで取組む

ボトムアップで取組む

どういう組織か

専⾨組織型先端的なテクノロジーを全事業に展開する企業の採⽤が多い

事業部⾨型データ分析⼈材がビジネスそのものに深く関わっている

専⾨組織＋事業部⾨型専⾨部署と事業部⾨が連携しながら進める

これらの組み合わせによって、以降の会話が⼤きく変わります。

12



•  組織の⽴ち上がり、スピード感

•  ログの実装に強制⼒があった

•  ⾃分たちで何をやるか決めていけた

•  規模の⼩さいものから徐々に広げていけた

•  既存事業部を巻き込むご説明

•  ログの実装に強制⼒がない→ログが揃うまで、⺟集団が変わる

•  メリットを提⽰出来ないうちは、事業部からの反発も多くあるかも。

•  とりあえず、統計学者を集めるケース

13






CTO室と⾔うR&Dを⾏なう部隊

ビッグデータ周りの取組みの⼀貫で、検索 / レコメンド / ⾏動解析を軸に

各事業部と連携して、仕組みを提供する形式

14

＊＊事業部

＊＊したいので、ログ埋めていただけますか？

今、⼯数ないので無理です。

どう⾔うものか説明して。

（説明する）

事業部がやること？？共通チームで出来ないの？

実は外注にレコメンドを作ってもらうよう依頼中

話が伝わっていなかった

個別個別にご説明

基本的に運⽤側は多忙

攻め⽅を間違った！！！15

データ収集について

DBをsqoopで転送

ログは共通チームで最⼩限

取組みの進め⽅

ヒヤリングを元に、求められているところ、結果が出せそうなところから

結果が出れば、信頼される希望的観測

PRJ個別ログも最⼩限

やりたいレコメンド、分析に対してログが不⾜した場合

データ収集もより協⼒的になっていくと考えた

ボトムアップならではの⾟さ

16








⾃分たちがどの組み合わせで攻めるか

17

ビッグデータチームの結成の仕⽅により、戦略・推進の⽅法が異なることを

意識しないといけない



運⽤フェーズ


導⼊フェーズ


最初を間違うと結構苦労します…。

18

送信されるログ、転送してきたデータは完全ではないことを意識しておくこと



運⽤フェーズ


導⼊フェーズ


19

サーバーサイドで落とす

JavaScript / APIでコールする

•  割とライトに実装可能

•  クローラーのログは少なめ•  実装側は⽐較的容易に扱える

•  ブラウザ、デバイスの差異の吸収•  実装漏れ・ミスが多々ある

•  クローラーのログが相当数乗っかる•  実装漏れ・ミスが多々ある•  ライブラリ提供の際は、各種⾔語で

データベースから転送してくる

•  Transactionが利くので⼀番正しい •  サービス基準なので、解析基準のデータがあることは少ない

20

使⽤範囲・⽤途

経営レポートとしてトレンドとして取得出来たもののみ説明

データベース

レコメンドAPI

⾏動解析ツール / レポートツール

精度

サーバーサイド

JavaScript / API

21

絶対ミスが発⽣する

session管理

TrackingAPI

DB

DB

22

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://〜





ログデータ

中間データ

LATERAL VIEW

28

SELECT *FROM ( SELECT session, service, url FROM activity ) a LATERAL VIEW explode(array(site, 'all')) a as site

session service url





session service url

abc... all h9p://〜

def... all h9p://〜

ghi... all h9p://〜

jkl... all 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



output

•  レコメンドAPI(JSON)


DBの購⼊データのみで作成することが可能•  商品表⽰ログ•  商品購⼊ログ

サービス側が欲しいモノ

サービス側レコメンドシステム側

要件は満たされた精度を上げる材料が揃っていない

効果あった or 効果なかった

36

サービス側

いつだって忙しい

効果があれば⼊れたい

よくわからないものに⼯数をかけたくない

実験台にはなりたくない

失敗したくない

売上が上がるから⼊れたい！！！

最短で⼊れたい！！！

俺も！うちも！！私も！！！

ログ実装を依頼

⼯数かかるなんて知らなかった…。

差し込み案件があり、⼀ヶ⽉後に…。

実装したが、いくつかのサービスでログ実装を誤って実装した

ビッグデータチームにおいては、あんまり良くない状況…。

37



output


input


output

•  レコメンドAPI →JSON

レコメンドシステム


•  レコメンドAPI→HTML→URLにTrackingを

38




運⽤フェーズ


導⼊フェーズ


最適なチームの構成と他に影響することのない⾃⾛出来る運⽤体制を構築すべき

39

レポート / データを提供しても使われないことを予め認識しておくこと



運⽤フェーズ


導⼊フェーズ


40

検索時に、条件を１つしか指定していないのと、２つ指定しているのとでは、リストのCTRが随分違うぞ！

△ 動画 > アニメ > ジャンル > アクション◯ 動画 > アニメ > ジャンル > アクション > 2000年代

アナリストさんがレポートを送信しました。

組み合わせデータの中でも、良く押されている組み合わせとそうでない組み合わせがあるぞ！

△ アクション > キッズ◯ アクション > 2000年代

アナリストさんが組み合わせデータ.csvを送信しました。

41

実装されない理由

2%〜3%の改善では、サービスに課せられている⽬標を達成出来ない

対応デバイス / ラインナップの拡⼤を求められているフェーズ

上述背景もあって、⼯数が取れない

データチーム

DB

DB

サービス側

DB

CreateAPI

42

データチーム

DB

DB

サービス側

DB

CreateAPI

データチーム

DB

DB

サービス側

API

43




運⽤フェーズ


導⼊フェーズ


サービス側に頼らず、改善案が提供出来る仕組みを作る

44

管理ツールは事業部⾨のためではなく、専⾨部⾨のためのツールになっていく



運⽤フェーズ


導⼊フェーズ


45

事業部が増えると、こっちのリソースも増やさないといけないし、レコメンドのロジックをチューニング出来る管理ツールを提供しよう

＊＊事業部

今後はツールから、チューニング出来ますから。

提供されてもわからないよ。

何を元に判断すればいいの？

指標もツールで⾒れますよ。

事業部がやること？？専⾨チームがやるべきでは？

そう⾔う⼈材いないから任せられても…。

46





CTO室の役割


求められた役割


今までの付き合い⽅に関する考えを、結構変えなくては…。

各事業部にデータに詳しい⼈材はいない、配置出来ない

逆に捉えると、任せられるようになった！！！！47




運⽤フェーズ


導⼊フェーズ


提供しても使うための知識・操作の習得が追いつかないので、結局頼られることになる

48

まとめ49


ビッグデータチームの結成の仕⽅により、戦略・推進の⽅法が異なることを意識しないといけない

導⼊フェーズ


運⽤フェーズ





50


ビッグデータチームの結成の仕⽅により、戦略・推進の⽅法が異なることを意識しないといけない

導⼊フェーズ


運⽤フェーズ





51

DevOpsDevOpsとは、開発（Development）と運⽤（Operations）が協⼒し、ビジネス要求に対して、より柔軟に、スピーディに対応できるシステムを作り上げるためのプラクティスです。

DataOps52

DataOpsDataOpsとは、【ビッグデータチーム（Data）】と【サービス側（Operations）】のやり取りおいて、より柔軟に、スピーディに対応できるシステムを作り上げるためのプラクティスです。

その１つとして、ビッグデータチームがログの実装、インフラから、改善案の提供までを、チーム体制含め、必要なメンバーをアサインし、サービス側に依存することなく、⾃⾛出来る環境を整備することで、実現できると考えられています。

53

新たなステージへ



運⽤フェーズ


導⼊フェーズ


ボトムアップ / R&Dの成果が⾝を結びつつ有る

様々な経験からのDMM.com流ベスト・プラクティス

ビッグデータ部拡⼤と貢献

54

ビッグデータ部12⽉1⽇に発⾜したばかり

まだオフィシャルに求⼈出回ってないかも…

発⾜メンバーがゆえの、活躍できるチャンスも…。

絶賛募集中！！！詳しくは、お近くのDMM.comラボのスタッフまでお尋ねください

55

56

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

machine learning casual talks #4...

Engineering