Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

データアナリティクスの新たな一歩とそれを支えるインフラ

3,111 views

Published on

2017-11-22 wed.
第 2 回 Google Cloud INSIDE Games & Apps

株式会社プレイド エンジニア 牧野 祐己 氏の登壇スライドです。

Published in: Engineering
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

データアナリティクスの新たな一歩とそれを支えるインフラ

  1. 1. 第2回 Google Cloud INSIDE Games & Apps データアナリティクスの新たな一歩 とそれを支えるインフラ
  2. 2. 牧野 祐己 2009年 東京大学工学系研究科システム量子工学専攻修士課程修了 2009年より2014年まで、日本IBMソフトウェア開発研究所 インメモリ型分散データベースの開発 並列プログラミング言語X10の研究開発 テキスト分析システムWatson Explorerの開発 Watsonの知識グラフ処理システムの研究開発 2015年 プレイド入社 主にリアルタイム解析システムの開発
  3. 3. データアナリティクスの新たな一歩 とそれを支えるインフラ データアナリティクスの新たな一歩 データアナリティクスのステップ 新たな一歩に必要なこと それを支えるインフラ
  4. 4. データアナリティクスの新たな一歩
  5. 5. データアナリティクスのステップ 処理 古典統計 ベイズ統計 & Machine Learning 理解 理解 モデルの作成 -> Science 意思決定 処理 理解 意思決定
  6. 6. Data Exploration 処理 古典統計 ベイズ統計 & Machine Learning 理解 理解 モデルの作成 -> Science 意思決定 処理 理解 (With 人) キューブ、BIツール 発見的なアプローチ 意思決定
  7. 7. 最近盛り上がっているところ 処理 古典統計 ベイズ統計 & Machine Learning 理解 理解 モデルの作成 -> Science 意思決定 ここがHOT! - 非線形なモデル - ディープなやつ 人の解釈が必ずしも必要とされ ない
  8. 8. 課題 より現実的な意思決定、創造につなげようとすると(ディープなやつより)もっと動的 で複雑なモデルが必要 結構難しい... -> 人を挟んで、意思決定や創造をさせる その結果に基づく学びを取り入れる、制御や強化学習的なスタンス
  9. 9. 意思決定も取り込んだアナリティクス 処理 古典統計 Machine Learning (ベイズ統計に基づく) 理解 感じる! 理解 モデルの作成 -> science 意思決定 処理 感じる (With 人) 意思決定 創造
  10. 10. それに必要なこと 1. ”感じ”させる 意思決定につながる可視化 (!= data visualization) 類推 自然な理解 多様なデータをまとめる 2. すぐに意思決定、創造、アクションができる 3. 結果がすぐにわかる (Advanced: このあたりに高度なモデ ルが使えないだろうか??)
  11. 11. リアルタイムにWebサイト上の アクションが行えるプラット フォーム “知る”(感じる)と ”合わせる”(創造) それを支えるインフラとUI
  12. 12. それを支えるインフラ (UIも大事)
  13. 13. インフラが実現すべきこと 1. “感じ”させる 可視化 -> 最新の重要な統計量をすぐ見え使える形にする 多様なデータをまとめるあげる 2. すぐに意思決定、創造、アクションができる -> リアルタイムに解析結果をアクションに使えるようにする 3. 結果がすぐにわかる -> ニアリアルタイムに複雑な条件で解析ができる
  14. 14. 大量データの代表的な処理方法 バッチ処理 最短数秒で大量のデータを処理 BigQuery, Presto, Spark, Hadoop ストリーミング処理 秒以内で短期間のウィンドウのデータを処理 Spark Streaming, Storm
  15. 15. 秒以内に全データの 解析処理結果が欲しい 結果に基づいたアクションをしたい 但し、アクションのために実時間で欲しい解析結果の軸は、ビジネスやサービスで 固定であることが多い
  16. 16. 独自エンジンの制約と特徴 制約 : 解析軸をあらかじめ決め解析 (KARTEだとユーザー軸) 特徴 : 0.x秒でイベント送信と同期的に結果整合性のある結果 さらに、その結果に基づいたアクションが可能 即座にルールやアクションの変更が可能 スキーマレス スケーラブル ラムダ、カッパーアーキテクチャー(の亜種)
  17. 17. 基本構成 Client End User Track Realtime Admin Batch </ > Analyze Event Action
  18. 18. 基本構成 Client End User Track Realtime Admin Batch </ > Realtime Layer Batch Layer
  19. 19. 基本構成 Client End User Track Realtime Admin Batch </ > Realtime Layer Batch Layer
  20. 20. Region #ECEFF1 Batch Layer Track Cloud Load Balancing Track Compute Engine Autoscaling Distributed Queue Cloud Pub/Sub End User Devices Redis Analyze Analyze Compute Engine Autoscaling Batch Cloud Bigtable Cloud Bigtable BigQuery MongoDB Compute Engine Cloud Storage Admin Admin Compute Engine Autoscaling Client Cloud Load Balancing Tracker.js Stackdriver Cloud CDNor Cloud Front Realtime Layer API AWS Redislabs MongoDB Compute Engine ...
  21. 21. 全体のstats 平均トラッキングイベント 6000 events / sec 平均vCPU 1000 vCPU 解析UU  12.5 億UU 流通金額 5000 億円 GCP歴 2年以上
  22. 22. なぜGCPなのか 移行の背景 コアのDBを先に移行 BigQuery (2年前から) Bigtable (1年前GAから) スケーラビリティー トラッキングイベント数 は1年で、3 - 4倍 一方コストは1.5倍 パフォーマンスは落ちない Cost Events
  23. 23. Region #ECEFF1 Batch Layer Track Cloud Load Balancing Track Compute Engine Autoscaling Distributed Queue Cloud Pub/Sub End User Devices Redis Analyze Analyze Compute Engine Autoscaling Batch Cloud Bigtable Cloud Bigtable BigQuery MongoDB Compute Engine Cloud Storage Admin Admin Compute Engine Autoscaling Client Cloud Load Balancing Tracker.js Stackdriver Cloud CDNor Cloud Front Realtime Layer API AWS Redislabs MongoDB Compute Engine ...
  24. 24. Bigtable 25 nodes Read: 1GB/s Write: 200MB/s Latency: - 20 msec 100TB
  25. 25. Bigtableのポイント 主にリアルタイムに解析、解析結果の読み書きを使用 ● 高スループット、低レイテンシ ● Atomic Updateにより一貫性を保つ ● カラムを後から追加できスキーマレスなデータを扱える ● index likeなデータが必要なクエリはMongoDBで補完 ● キー方向Scanが高速
  26. 26. <Hash>_<key>_922337057251.. Row Scan ... <Hash>_<key>_922337057252.. <Hash>_<key>_(Long.MAX - time) <Hash>_<key>_922337057260..
  27. 27. Region #ECEFF1 Batch Layer Track Cloud Load Balancing Track Compute Engine Autoscaling Distributed Queue Cloud Pub/Sub End User Devices Redis Analyze Analyze Compute Engine Autoscaling Batch Cloud Bigtable Cloud Bigtable BigQuery MongoDB Compute Engine Cloud Storage Admin Admin Compute Engine Autoscaling Client Cloud Load Balancing Tracker.js Stackdriver Cloud CDNor Cloud Front Realtime Layer API AWS Redislabs MongoDB Compute Engine ...
  28. 28. BigQuery 容量 約500TB 解析データ 約30PB / Month
  29. 29. BigQueryのポイント ニアリアルタイムのユーザー軸以上の解析に使用 ● Streaming Insertがバッファリングなど考えないで良いので非常に便利 ● 中間レイヤが少なくて済む ○ シンプルなクエリのレスポンスタイムはかなり短くスケーラブル ○ プロダクション環境から直接クエリ ○ BigQuery table to BigQuery tableの変換が非常に便利 ● データ連携が容易
  30. 30. 多様なデータを取り込む より”感じ”させ行動につなげる 既存のデータなど様々なデータを使って理解する 会員情報、リアルの行動データ、外部サービスのデータ BigQueryを中心としたデータ連携
  31. 31. Region #ECEFF1 Batch Layer Track Cloud Load Balancing Track Compute Engine Autoscaling Distributed Queue Cloud Pub/Sub End User Devices Redis Analyze Analyze Compute Engine Autoscaling Batch Cloud Bigtable Cloud Bigtable BigQuery MongoDB Compute Engine Cloud Storage Admin Admin Compute Engine Autoscaling Client Cloud Load Balancing Tracker.js Stackdriver Cloud CDNor Cloud Front Realtime Layer External System External System ... ... Cloud Dataflow Cloud Dataflow API AWS Redislabs AWS S3 Treasure Data AWS S3 Treasure Data ... MongoDB Compute Engine ...
  32. 32. リクルートライフスタイル様の共通分析基盤と連携! リクルート ライフスタイル 共通分析基盤 S3 (Storage)
  33. 33. S3 (Storage) リクルートライフスタイル様の共通分析基盤と連携! (Plan) リクルート ライフスタイル 共通分析基盤 BigQuery経由の直データ連携
  34. 34. まとめ データ分析の新たな一歩 処理からアクションまでを統合 それを支えるインフラ コアとなる基本要素にGCPのシステムを置くことで実現

×