Prochain SlideShare
Machine Learning Casual Talks #4 ビッグデータチームを発足するにあたって気をつけておきたいn個のこと
- 1. ビッグデータチームを発⾜するにあたって 気をつけておきたいn個のこと DMM.comラボ ⽥宮 直⼈ 1
- 2. ⾃⼰紹介 ⽥宮 直⼈ マーケティング開発部 （マネージャー） でした…。（過去形） 2
- 3. ⾃⼰紹介 エンジニア歴 10年 Web分析担当 3年 解析基盤整備 1年半 某新聞社の案件 起業 ミッドタウンにある会社 渋⾕にある会社 渋⾕にある会社 何かしらデータ⾒て、ごにょごにょしてる期間 3
- 4. 機械学習やっている⼈ データサイエンティスト Webアナリスト データ使って、 何かしようとしている⼈ 4
- 5. DevOps DevOpsとは、開発（Development）と運⽤（Operations）が協⼒し、 ビジネス要求に対して、より柔軟に、スピーディに対応できるシステムを 作り上げるためのプラクティスです。 DataOps 5
- 6. そして、突然ですが… ビッグデータ部が 出来ました！！！ ビッグデータ部が 出来ました！！！ にも 6
- 7. ⾃⼰紹介 ⽥宮 直⼈ マーケティング開発部 （マネージャー） ビッグデータ部 データプラットフォーム課 （グループリーダー） 7
- 8. ビッグデータを活⽤して売上貢献するにはどうするのか。 現状の問題点 ■販売機会の損失 • サービス使ってるのに そのサービスのバナーやレコメン ドが表⽰される • 離脱していく顧客に対して、 適切な案内・訴求を⾏っていない ■⼈⼿による限界 • Googleの「もしかして＊＊？」の ように、予め登録しておくのは 物量的に難しくなっている • 商品毎にオススメ商品を設定する には、多種多様過ぎて困難。 ましてや、ユーザー毎には無理。 ■経営判断の遅れ • ⼈⼿で対応することにより、 レポートの提供が遅延 • レポートが完成するまでの時間が ⻑く、迅速に判断出来ない • 効果があったのかどうか曖昧 ビッグデータの活⽤ 機械学習・AIを活⽤し、検索・レコメンドの⾃動化、⾼精度化 ユーザーの状態・趣味嗜好に基づいた情報の出し分け レポート周りの業務を⾼速化、定型化、可視化し正しい判断 効果のあるユーザーに 適切なタイミングで ユーザーの求める情報を 商品探している 検索語句を間違って⼊⼒ 商品買った後は もしかして＊＊？を提⽰ 商品を買ったユーザーに 該当商品をオススメしない しばらく使ってなければお得意様が メールで嗜好にあう情報を 検索 レコメンド メルマガ 精度向上を目指す サイト内広告 アフィリエイト メルマガ 徐々に組み入れる レポート 評価 ログデータ 改善 8
- 9. 今回お話すること…。 ⽴ち上げフェーズ • 組織の発⾜ • 各所へのヒヤリング 運⽤フェーズ • レコメンドの実装 • 分析レポートの提供 • 定形レポートの提供 導⼊フェーズ • ログの設計 • ログの実装依頼 • データの収集 • 世間の流れ • 他社で経験した内容 • DMMで起こったこと • DMMでやったこと こうすればよかった！こうした⽅がよい！ 9
- 10. ビッグデータチームを発⾜するにあたって 気をつけておきたいn個のこと 10
- 11. ビッグデータチームの結成の仕⽅により、 戦略・推進の⽅法が異なることを 意識しないといけない ⽴ち上げフェーズ • 組織の発⾜ • 各所へのヒヤリング 運⽤フェーズ • レコメンドの実装 • 各種レポートの提供 導⼊フェーズ • ログの設計 • ログの実装依頼 • データの収集 11
- 12. どこからの発令か トップダウンで取組む ボトムアップで取組む どういう組織か 専⾨組織型 先端的なテクノロジーを全事業に展開 する企業の採⽤が多い 事業部⾨型 データ分析⼈材がビジネスそのものに 深く関わっている 専⾨組織＋事業部⾨型 専⾨部署と事業部⾨が連携しながら 進める これらの組み合わせによって、以降の会話が⼤きく変わります。 12
- 13. トップダウンで取組む ボトムアップで取組む • 組織の⽴ち上がり、スピード感 • ログの実装に強制⼒があった • ⾃分たちで何をやるか決めていけた • 規模の⼩さいものから徐々に広げて いけた • 既存事業部を巻き込むご説明 • ログの実装に強制⼒がない →ログが揃うまで、⺟集団が変わる • メリットを提⽰出来ないうちは、 事業部からの反発も多くあるかも。 • とりあえず、統計学者を集めるケース 13
- 14. どこからの発令か トップダウンで取組む ボトムアップで取組む どういう組織か 専⾨組織＋事業部⾨型 専⾨部署と事業部⾨が連携しながら 進める CTO室と⾔うR&Dを⾏なう部隊 ビッグデータ周りの取組みの⼀貫で、検索 / レコメンド / ⾏動解析を軸に 各事業部と連携して、仕組みを提供する形式 14
- 15. ＊＊事業部 ＊＊したいので、ログ埋めて いただけますか？ 今、⼯数ないので無理です。 どう⾔うものか説明して。 （説明する） 事業部がやること？？ 共通チームで出来ないの？ 実は外注にレコメンドを 作ってもらうよう依頼中 話が伝わっていなかった 個別個別にご説明 基本的に運⽤側は多忙 攻め⽅を間違った！！！ 15
- 16. データ収集について DBをsqoopで転送 ログは共通チームで最⼩限 取組みの進め⽅ ヒヤリングを元に、 求められているところ、 結果が出せそうなところから 結果が出れば、信頼される 希望的観測 PRJ個別ログも最⼩限 やりたいレコメンド、分析に 対してログが不⾜した場合 データ収集もより協⼒的に なっていくと考えた ボトムアップならではの⾟さ 16
- 17. どこからの発令か トップダウンで取組む ボトムアップで取組む どういう組織か 専⾨組織型 先端的なテクノロジーを全事業に展開 する企業の採⽤が多い 事業部⾨型 データ分析⼈材がビジネスそのものに 深く関わっている 専⾨組織＋事業部⾨型 専⾨部署と事業部⾨が連携しながら 進める ⾃分たちがどの組み合わせで攻めるか 17
- 18. ビッグデータチームの結成の仕⽅により、 戦略・推進の⽅法が異なることを 意識しないといけない ⽴ち上げフェーズ • 組織の発⾜ • 各所へのヒヤリング 運⽤フェーズ • レコメンドの実装 • 各種レポートの提供 導⼊フェーズ • ログの設計 • ログの実装依頼 • データの収集 最初を間違うと結構苦労します…。 18
- 19. 送信されるログ、転送してきたデータは 完全ではないことを意識しておくこと ⽴ち上げフェーズ • 組織の発⾜ • 各所へのヒヤリング 運⽤フェーズ • レコメンドの実装 • 各種レポートの提供 導⼊フェーズ • ログの設計 • ログの実装依頼 • データの収集 19
- 20. サーバーサイドで落とす JavaScript / APIでコールする • 割とライトに実装可能 • クローラーのログは少なめ • 実装側は⽐較的容易に扱える • ブラウザ、デバイスの差異の吸収 • 実装漏れ・ミスが多々ある • クローラーのログが相当数乗っかる • 実装漏れ・ミスが多々ある • ライブラリ提供の際は、各種⾔語で データベースから転送してくる • Transactionが利くので⼀番正しい • サービス基準なので、解析基準の データがあることは少ない 20
- 21. 使⽤範囲・⽤途 経営レポートとして トレンドとして 取得出来たもののみ説明 データベース レコメンドAPI ⾏動解析ツール / レポートツール 精度 サーバーサイド JavaScript / API 21 絶対ミスが発⽣する
- 22. session管理 TrackingAPI DB DB 22
- 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
- 37. サービス側 いつだって忙しい 効果があれば⼊れたい よくわからないものに ⼯数をかけたくない 実験台にはなりたくない 失敗したくない 売上が上がるから⼊れたい！！！ 最短で⼊れたい！！！ 俺も！ うちも！！ 私も！！！ ログ実装を依頼 ⼯数かかるなんて知らなかった…。 差し込み案件があり、⼀ヶ⽉後に…。 実装したが、いくつかのサービスで ログ実装を誤って実装した ビッグデータチームにおいては、あんまり良くない状況…。 37
- 38. レコメンドシステム input • 商品表⽰ログ • 商品購⼊ログ output • レコメンド表⽰ログ • レコメンド押下ログ input • 商品表⽰ログ • 商品購⼊ログ output • レコメンドAPI →JSON レコメンドシステム • レコメンド表⽰ログ • レコメンド押下ログ • レコメンドAPI →HTML →URLにTrackingを 38
- 39. ログの実装は⾃分たちでやれる環境を 整備しておくと運⽤側も実装側も平和 ⽴ち上げフェーズ • 組織の発⾜ • 各所へのヒヤリング 運⽤フェーズ • レコメンドの実装 • 各種レポートの提供 導⼊フェーズ • ログの設計 • ログの実装依頼 • データの収集 最適なチームの構成と他に影響することのない ⾃⾛出来る運⽤体制を構築すべき 39
- 40. レポート / データを提供しても 使われないことを予め認識しておくこと ⽴ち上げフェーズ • 組織の発⾜ • 各所へのヒヤリング 運⽤フェーズ • レコメンドの実装 • 各種レポートの提供 導⼊フェーズ • ログの設計 • ログの実装依頼 • データの収集 40
- 41. 検索時に、条件を１つしか指定していないのと、２つ指定しているのと では、リストのCTRが随分違うぞ！ △ 動画 > アニメ > ジャンル > アクション ◯ 動画 > アニメ > ジャンル > アクション > 2000年代 アナリストさんが レポートを送信しました。 組み合わせデータの中でも、良く押されている組み合わせと そうでない組み合わせがあるぞ！ △ アクション > キッズ ◯ アクション > 2000年代 アナリストさんが 組み合わせデータ.csvを 送信しました。 41
- 42. 実装されない理由 2%〜3%の改善では、サービスに課せられている⽬標を達成出来ない 対応デバイス / ラインナップの拡⼤を求められているフェーズ 上述背景もあって、⼯数が取れない データチーム DB DB サービス側 DB Create API 42
- 43. データチーム DB DB サービス側 DB Create API データチーム DB DB サービス側 API 43
- 44. レポート / データを提供しても 使われないことを予め認識しておくこと ⽴ち上げフェーズ • 組織の発⾜ • 各所へのヒヤリング 運⽤フェーズ • レコメンドの実装 • 各種レポートの提供 導⼊フェーズ • ログの設計 • ログの実装依頼 • データの収集 サービス側に頼らず、 改善案が提供出来る仕組みを作る 44
- 45. 管理ツールは事業部⾨のためではなく、 専⾨部⾨のためのツールになっていく ⽴ち上げフェーズ • 組織の発⾜ • 各所へのヒヤリング 運⽤フェーズ • レコメンドの実装 • 分析レポートの提供 • 定形レポートの提供 導⼊フェーズ • ログの設計 • ログの実装依頼 • データの収集 45
- 46. 事業部が増えると、こっちのリソースも増やさないといけないし、 レコメンドのロジックをチューニング出来る管理ツールを提供しよう ＊＊事業部 今後はツールから、 チューニング出来ますから。 提供されてもわからないよ。 何を元に判断すればいいの？ 指標もツールで⾒れますよ。 事業部がやること？？ 専⾨チームがやるべきでは？ そう⾔う⼈材いないから 任せられても…。 46
- 47. どういう組織か 専⾨組織型 先端的なテクノロジーを全事業に展開 する企業の採⽤が多い 事業部⾨型 データ分析⼈材がビジネスそのものに 深く関わっている 専⾨組織＋事業部⾨型 専⾨部署と事業部⾨が連携しながら 進める CTO室の役割 専⾨組織＋事業部⾨型 専⾨部署と事業部⾨が連携しながら進める 求められた役割 専⾨組織型 先端的なテクノロジーを全事業に展開する企業の採⽤が多い 今までの付き合い⽅に関する考えを、結構変えなくては…。 各事業部にデータに詳しい⼈材はいない、配置出来ない 逆に捉えると、任せられるようになった！！！！ 47
- 48. 管理ツールは事業部⾨のためではなく、 専⾨部⾨のためのツールになっていく ⽴ち上げフェーズ • 組織の発⾜ • 各所へのヒヤリング 運⽤フェーズ • レコメンドの実装 • 分析レポートの提供 • 定形レポートの提供 導⼊フェーズ • ログの設計 • ログの実装依頼 • データの収集 提供しても使うための知識・操作の習得が 追いつかないので、結局頼られることになる 48
- 49. まとめ 49
- 50. ⽴ち上げフェーズ ビッグデータチームの結成の仕⽅により、戦略・推進の⽅法が 異なることを意識しないといけない 導⼊フェーズ 送信されるログ、転送してきたデータは完全ではないことを 意識しておくこと 運⽤フェーズ 集計したい対象は常に拡⼤するが、集計ロジックは増やさないように 考慮する ログの実装は⾃分たちでやれる環境を整備しておくと運⽤側も実装側も平和 レポート / データを提供しても使われないことを予め認識しておくこと 管理ツールは事業部⾨のためではなく、専⾨部⾨のためのツールに なっていく 50
- 51. ⽴ち上げフェーズ ビッグデータチームの結成の仕⽅により、戦略・推進の⽅法が 異なることを意識しないといけない 導⼊フェーズ 送信されるログ、転送してきたデータは完全ではないことを 意識しておくこと 運⽤フェーズ 集計したい対象は常に拡⼤するが、集計ロジックは増やさないように 考慮する ログの実装は⾃分たちでやれる環境を整備しておくと運⽤側も実装側も平和 レポート / データを提供しても使われないことを予め認識しておくこと 管理ツールは事業部⾨のためではなく、専⾨部⾨のためのツールに なっていく 51
- 52. DevOpsDevOpsとは、開発（Development）と運⽤（Operations）が協⼒し、 ビジネス要求に対して、より柔軟に、スピーディに対応できるシステムを 作り上げるためのプラクティスです。 DataOps 52
- 53. DataOpsDataOpsとは、 【ビッグデータチーム（Data）】と【サービス側（Operations）】 のやり取りおいて、より柔軟に、スピーディに対応できるシステムを 作り上げるためのプラクティスです。 その１つとして、ビッグデータチームがログの実装、インフラから、 改善案の提供までを、チーム体制含め、必要なメンバーをアサインし、 サービス側に依存することなく、⾃⾛出来る環境を整備することで、 実現できると考えられています。 53
- 54. 新たなステージへ ⽴ち上げフェーズ • 組織の発⾜ • 各所へのヒヤリング 運⽤フェーズ • レコメンドの実装 • 分析レポートの提供 • 定形レポートの提供 導⼊フェーズ • ログの設計 • ログの実装依頼 • データの収集 ボトムアップ / R&Dの成果が⾝を結びつつ有る 様々な経験からのDMM.com流ベスト・プラクティス ビッグデータ部 拡⼤と貢献 54
- 55. ビッグデータ部 12⽉1⽇に発⾜したばかり まだオフィシャルに求⼈出回ってないかも… 発⾜メンバーがゆえの、活躍できるチャンスも…。 絶賛募集中！！！ 詳しくは、お近くのDMM.comラボのスタッフまでお尋ねください 55
- 56. 56 ご清聴ありがとうございました。
Identifiez-vous pour voir les commentaires