Machine Learning Casual Talks #4 ビッグデータチームを発足するにあたって気をつけておきたいn個のこと
•
18 likes•6,812 views
Machine Learning Casual Talks #4で登壇した際のスライドです。 今までデータに関わってきた立場、サービス開発してきた立場として、データに関わる人たちが平和になるスキームを現在模索しています。 DMM.comラボでのビッグデータの取組みをご紹介すると共に、この辺を意識して取組むべきでは？と言う投げかけを行ないました。 ご参考になればと願いつつ。 ------- 【ビッグデータチームを発足するにあたって気をつけておきたいn個のこと】 1.ビッグデータチームの結成の仕方により、戦略・推進の方法が異なることを意識しないといけない 2.送信されるログ、転送してきたデータは完全ではないことを意識しておくこと 3.集計したい対象は常に拡大するが、集計ロジックは増やさないように考慮する 4.ログの実装は自分たちでやれる環境を整備しておくと運用側も実装側も平和 5.レポート / データを提供しても使われないことを予め認識しておくこと 6.管理ツールは事業部門のためではなく、専門部門のためのツールになっていく
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Machine Learning Casual Talks #4 ビッグデータチームを発足するにあたって気をつけておきたいn個のこと
Similar to Machine Learning Casual Talks #4 ビッグデータチームを発足するにあたって気をつけておきたいn個のこと (20)
Machine Learning Casual Talks #4 ビッグデータチームを発足するにあたって気をつけておきたいn個のこと
- 3. ⾃⼰紹介 エンジニア歴 10年 Web分析担当 3年 解析基盤整備 1年半 某新聞社の案件 起業 ミッドタウンにある会社 渋⾕にある会社 渋⾕にある会社 何かしらデータ⾒て、ごにょごにょしてる期間 3
- 8. ビッグデータを活⽤して売上貢献するにはどうするのか。 現状の問題点 ■販売機会の損失 • サービス使ってるのに そのサービスのバナーやレコメン ドが表⽰される • 離脱していく顧客に対して、 適切な案内・訴求を⾏っていない ■⼈⼿による限界 • Googleの「もしかして＊＊？」の ように、予め登録しておくのは 物量的に難しくなっている • 商品毎にオススメ商品を設定する には、多種多様過ぎて困難。 ましてや、ユーザー毎には無理。 ■経営判断の遅れ • ⼈⼿で対応することにより、 レポートの提供が遅延 • レポートが完成するまでの時間が ⻑く、迅速に判断出来ない • 効果があったのかどうか曖昧 ビッグデータの活⽤ 機械学習・AIを活⽤し、検索・レコメンドの⾃動化、⾼精度化 ユーザーの状態・趣味嗜好に基づいた情報の出し分け レポート周りの業務を⾼速化、定型化、可視化し正しい判断 効果のあるユーザーに 適切なタイミングで ユーザーの求める情報を 商品探している 検索語句を間違って⼊⼒ 商品買った後は もしかして＊＊？を提⽰ 商品を買ったユーザーに 該当商品をオススメしない しばらく使ってなければお得意様が メールで嗜好にあう情報を 検索 レコメンド メルマガ 精度向上を目指す サイト内広告 アフィリエイト メルマガ 徐々に組み入れる レポート 評価 ログデータ 改善 8
- 9. 今回お話すること…。 ⽴ち上げフェーズ • 組織の発⾜ • 各所へのヒヤリング 運⽤フェーズ • レコメンドの実装 • 分析レポートの提供 • 定形レポートの提供 導⼊フェーズ • ログの設計 • ログの実装依頼 • データの収集 • 世間の流れ • 他社で経験した内容 • DMMで起こったこと • DMMでやったこと こうすればよかった！こうした⽅がよい！ 9
- 11. ビッグデータチームの結成の仕⽅により、 戦略・推進の⽅法が異なることを 意識しないといけない ⽴ち上げフェーズ • 組織の発⾜ • 各所へのヒヤリング 運⽤フェーズ • レコメンドの実装 • 各種レポートの提供 導⼊フェーズ • ログの設計 • ログの実装依頼 • データの収集 11
- 13. トップダウンで取組む ボトムアップで取組む • 組織の⽴ち上がり、スピード感 • ログの実装に強制⼒があった • ⾃分たちで何をやるか決めていけた • 規模の⼩さいものから徐々に広げて いけた • 既存事業部を巻き込むご説明 • ログの実装に強制⼒がない →ログが揃うまで、⺟集団が変わる • メリットを提⽰出来ないうちは、 事業部からの反発も多くあるかも。 • とりあえず、統計学者を集めるケース 13
- 14. どこからの発令か トップダウンで取組む ボトムアップで取組む どういう組織か 専⾨組織＋事業部⾨型 専⾨部署と事業部⾨が連携しながら 進める CTO室と⾔うR&Dを⾏なう部隊 ビッグデータ周りの取組みの⼀貫で、検索 / レコメンド / ⾏動解析を軸に 各事業部と連携して、仕組みを提供する形式 14
- 18. ビッグデータチームの結成の仕⽅により、 戦略・推進の⽅法が異なることを 意識しないといけない ⽴ち上げフェーズ • 組織の発⾜ • 各所へのヒヤリング 運⽤フェーズ • レコメンドの実装 • 各種レポートの提供 導⼊フェーズ • ログの設計 • ログの実装依頼 • データの収集 最初を間違うと結構苦労します…。 18
- 19. 送信されるログ、転送してきたデータは 完全ではないことを意識しておくこと ⽴ち上げフェーズ • 組織の発⾜ • 各所へのヒヤリング 運⽤フェーズ • レコメンドの実装 • 各種レポートの提供 導⼊フェーズ • ログの設計 • ログの実装依頼 • データの収集 19
- 20. サーバーサイドで落とす JavaScript / APIでコールする • 割とライトに実装可能 • クローラーのログは少なめ • 実装側は⽐較的容易に扱える • ブラウザ、デバイスの差異の吸収 • 実装漏れ・ミスが多々ある • クローラーのログが相当数乗っかる • 実装漏れ・ミスが多々ある • ライブラリ提供の際は、各種⾔語で データベースから転送してくる • Transactionが利くので⼀番正しい • サービス基準なので、解析基準の データがあることは少ない 20
- 21. 使⽤範囲・⽤途 経営レポートとして トレンドとして 取得出来たもののみ説明 データベース レコメンドAPI ⾏動解析ツール / レポートツール 精度 サーバーサイド JavaScript / API 21 絶対ミスが発⽣する
- 23. EXTARNAL TABLE (or TABLE) TABLE send(‘ac)on’, ‘op)on’, value); like(‘op)on’, value); ※オプションも定義済み以外弾く • ひたすら貼られるとデータ量、トラフィック的にキツイ • like / good / nice とか揺らぎ、タイプミスとかある データ整形/クリーニング DB 23
- 24. 送信されるログ、転送してきたデータは 完全ではないことを意識しておくこと ⽴ち上げフェーズ • 組織の発⾜ • 各所へのヒヤリング 運⽤フェーズ • レコメンドの実装 • 各種レポートの提供 導⼊フェーズ • ログの設計 • ログの実装依頼 • データの収集 データにゴミが⼊らない⼯夫を…。 24
- 25. 集計したい対象は常に拡⼤するが、 集計ロジックは増やさないように考慮する ⽴ち上げフェーズ • 組織の発⾜ • 各所へのヒヤリング 運⽤フェーズ • レコメンドの実装 • 各種レポートの提供 導⼊フェーズ • ログの設計 • ログの実装依頼 • データの収集 25
- 26. レポート / ⾏動解析 UU、アクション、CVの そもそもの数値が不明 PC / SP、会員 / ⾮会員等 のドリルダウンを所望 ドリルダウンの掛けあわせ が確認したくなる サーバーの負荷 集計ロジックの保守性 提供を受ける側が満たされると、次の要望が出てくる 成功した事例が出てくると、他も便乗したくなる 深掘 拡⼤ 26
- 27. 運⽤側からの要求はなくとも、予め範囲を広げて集計している その上で、集計時間やサーバーの負荷状況を⾒積もる 依頼受けたサービス 受けていないサービス サービス別 / 事業部別 全体 / PC / SP 他 【LATERAL VIEW】を使って、ロジックが増えることを抑制 27
- 28. 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
- 29. 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
- 30. 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. 集計したい対象は常に拡⼤するが、 集計ロジックは増やさないように考慮する ⽴ち上げフェーズ • 組織の発⾜ • 各所へのヒヤリング 運⽤フェーズ • レコメンドの実装 • 各種レポートの提供 導⼊フェーズ • ログの設計 • ログの実装依頼 • データの収集 成果が出ると、⼀気にニーズが⾼まるので、 予め捌けるようなロジック、インフラを準備 31
- 32. ログの実装は⾃分たちでやれる環境を 整備しておくと運⽤側も実装側も平和 ⽴ち上げフェーズ • 組織の発⾜ • 各所へのヒヤリング 運⽤フェーズ • レコメンドの実装 • 各種レポートの提供 導⼊フェーズ • ログの設計 • ログの実装依頼 • データの収集 32
- 33. レコメンドを提供する際の登場⼈物 分析担当 • レコメンドのロジック • レポートの作成 開発チーム • TrackingAPI / JS プラットフォーム • 共通ヘッダー • カート機能 インフラチーム • Hadoop基盤の構築 • APIサーバーの⼿配 サービス担当 • アクションの送信 • レコメンドAPI組込み 関係者が多く、どこかが作業遅延すると全体に影響 いつだってサービス担当（運⽤サイド）は忙しい 33
- 34. ビッグデータ部の構成 分析担当 • レコメンドのロジック • レポートの作成 開発チーム • TrackingAPI / JS プラットフォーム • 共通ヘッダー • カート機能 インフラチーム • Hadoop基盤の構築 • APIサーバーの⼿配 サービス担当 • アクションの送信 • レコメンドAPI組込み 作業遅延が起こるリスク ログの実装にミスがあることが出てくるリスク 34
- 35. レコメンドシステム input • 商品表⽰ログ • 商品購⼊ログ output • レコメンドAPI →JSON • レコメンド表⽰ログ • レコメンド押下ログ 【Modern Information Retrieval】 検索エンジンの評価に関する項に記載のものを レコメンドでも当てはめてレコメンドのロジックを検証 • Presision and Recall • Single Value Summaries • User-Oriented Measures • Discounted Cumulated Gain 35
- 36. レコメンドシステム input • 商品表⽰ログ • 商品購⼊ログ output • レコメンドAPI(JSON) • レコメンド表⽰ログ • レコメンド押下ログ DBの購⼊データのみで作成することが可能 • 商品表⽰ログ • 商品購⼊ログ サービス側が欲しいモノ サービス側レコメンドシステム側 要件は満たされた精度を上げる材料が揃っていない 効果あった or 効果なかった 36
- 38. レコメンドシステム input • 商品表⽰ログ • 商品購⼊ログ output • レコメンド表⽰ログ • レコメンド押下ログ input • 商品表⽰ログ • 商品購⼊ログ output • レコメンドAPI →JSON レコメンドシステム • レコメンド表⽰ログ • レコメンド押下ログ • レコメンドAPI →HTML →URLにTrackingを 38
- 39. ログの実装は⾃分たちでやれる環境を 整備しておくと運⽤側も実装側も平和 ⽴ち上げフェーズ • 組織の発⾜ • 各所へのヒヤリング 運⽤フェーズ • レコメンドの実装 • 各種レポートの提供 導⼊フェーズ • ログの設計 • ログの実装依頼 • データの収集 最適なチームの構成と他に影響することのない ⾃⾛出来る運⽤体制を構築すべき 39
- 40. レポート / データを提供しても 使われないことを予め認識しておくこと ⽴ち上げフェーズ • 組織の発⾜ • 各所へのヒヤリング 運⽤フェーズ • レコメンドの実装 • 各種レポートの提供 導⼊フェーズ • ログの設計 • ログの実装依頼 • データの収集 40
- 41. 検索時に、条件を１つしか指定していないのと、２つ指定しているのと では、リストのCTRが随分違うぞ！ △ 動画 > アニメ > ジャンル > アクション ◯ 動画 > アニメ > ジャンル > アクション > 2000年代 アナリストさんが レポートを送信しました。 組み合わせデータの中でも、良く押されている組み合わせと そうでない組み合わせがあるぞ！ △ アクション > キッズ ◯ アクション > 2000年代 アナリストさんが 組み合わせデータ.csvを 送信しました。 41
- 44. レポート / データを提供しても 使われないことを予め認識しておくこと ⽴ち上げフェーズ • 組織の発⾜ • 各所へのヒヤリング 運⽤フェーズ • レコメンドの実装 • 各種レポートの提供 導⼊フェーズ • ログの設計 • ログの実装依頼 • データの収集 サービス側に頼らず、 改善案が提供出来る仕組みを作る 44
- 45. 管理ツールは事業部⾨のためではなく、 専⾨部⾨のためのツールになっていく ⽴ち上げフェーズ • 組織の発⾜ • 各所へのヒヤリング 運⽤フェーズ • レコメンドの実装 • 分析レポートの提供 • 定形レポートの提供 導⼊フェーズ • ログの設計 • ログの実装依頼 • データの収集 45
- 48. 管理ツールは事業部⾨のためではなく、 専⾨部⾨のためのツールになっていく ⽴ち上げフェーズ • 組織の発⾜ • 各所へのヒヤリング 運⽤フェーズ • レコメンドの実装 • 分析レポートの提供 • 定形レポートの提供 導⼊フェーズ • ログの設計 • ログの実装依頼 • データの収集 提供しても使うための知識・操作の習得が 追いつかないので、結局頼られることになる 48
- 49. まとめ 49
- 54. 新たなステージへ ⽴ち上げフェーズ • 組織の発⾜ • 各所へのヒヤリング 運⽤フェーズ • レコメンドの実装 • 分析レポートの提供 • 定形レポートの提供 導⼊フェーズ • ログの設計 • ログの実装依頼 • データの収集 ボトムアップ / R&Dの成果が⾝を結びつつ有る 様々な経験からのDMM.com流ベスト・プラクティス ビッグデータ部 拡⼤と貢献 54