トピックモデルの評価指標 Perplexity とは何なのか？
Le téléchargement de votre SlideShare est en cours.
×
Consultez-les par la suite
Plus De Contenu Connexe
Diaporamas pour vous (20)
Similaire à BigQueryで集計するシステムを作って分かったKPI集計ツール作成 (20)
Plus par (shibao)芝尾 (kouichiro)幸一郎 (20)
Plus récents (20)
BigQueryで集計するシステムを作って分かったKPI集計ツール作成
- 1. BigQueryで集計するシステムを 作って分かったKPI集計ツール作成 Aiming 芝尾幸⼀一郎郎
- 2. / 55 ゲーム開発 2 華やかな世界
- 3. / 553
- 4. / 554
- 5. / 555
- 6. / 556
- 7. / 55 あまり⽬目⽴立立たない仕事 • ログ収集 • データ分析 • 課⾦金金 • 認証 7
- 8. / 558 今回は⽬目⽴立立たない 仕事を紹介します
- 9. / 55 芝尾幸⼀一郎郎 • データ分析担当 • ここ４年年はデータ分析 • 個⼈人でもニコニコ動画 のランキングサイト 作ってます。 • http://nico-‐‑‒ran.jp/ • @shibacow 9
- 10. / 55 データ分析チーム • 集計システム作成 3名 • データ分析 1名 • プロジェクトマネージャー 1名 • プロダクトオーナー 2名 10
- 11. / 55 宣伝 • 本を書きました。 • ゲーム開発が変わる！ Google Cloud Platform 実践インフ ラ構築 11
- 12. / 55 今回話す内容 • 集計システムを作成したので、その勘所を 紹介する • 集計システムを整備することでどのような 変化が起こったか • 今回はBQに対して突っ込んだ設計の話は しません。 12
- 13. / 55 全社データ集計基盤 • 名称はMonolith • 全タイトルを横断的に集計 • 個別の集計作成を防ぐ • 集計システムの品質を上げる • タイトル横断でKPIを⽐比較 13
- 14. / 55 実際に作った集計ツール(Monolith) 14
- 15. / 55 実際に作った集計ツール 15
- 16. / 55 実際に作った集計ツール 16
- 17. / 55 集計項⽬目 • AU • RDAU • FQ5 • 新規 • 継続率率率 • ポイント消費 • ポイント購⼊入 • PU • ARPPU • 登録⽉月別AU • チュートリアル進捗 • クエスト進捗 • その他集計 17
- 18. / 55 システム概要 18 ログ一件一件 SQL発行&結果受け取り
- 19. 集計システムの作成
- 20. / 55 データ集計環境構築の困難 • データが多い • データを集約するとミスに弱い • 再集計が⼤大変 • 集計が試⾏行行錯誤しにくい • データが増えると集計が⻑⾧長時間 • 導⼊入が⼤大変 20
- 21. / 55 欲しい集計システム • データがいくらでも⼊入る • データを集約せず⽣生データを保持 • 再集計が楽 • 集計が試⾏行行錯誤しやすい • データが増えても集計レスポンスが速い • 導⼊入が楽 21
- 22. / 55 このような集計 • このような集計をするため(例例えばAU)に どのようなシステムが考えられるか？ 22 架空のグラフ
- 23. / 55 過去の集計システム • MySQLを使ったシステム • Hadoopを使ったシステム 23 現在の集計システム • BigQueryを使ったシステム 個人の経験に基づいてお話します
- 24. / 55 時系列列 24 2012年 2013年 2014年 2015年 MySQLシステム Hadoop システム BigQueryシステム
- 25. / 55 MySQL • 代表的なRDBMS • ゲーム開発で⼀一般的に利利⽤用される • ノウハウは豊富 25
- 26. / 55 MySQL • ログを集約して保存 • 事前集計して可視化 • 過去集計分は保存し該当期間のみ集計 26
- 27. / 55 MySQL • 重複するログを集約後、集約前のレコード を削除する(ログ量量が多いので)。 27 ユーザーID ログイン時間 1 2015/1/1 1:04 1 2015/1/1 1:06 2 2015/1/1 1:10 1 2015/1/1 1:14 ユーザーID ログイン時間(1時 間で丸める) ログイン回数 1 2015-‐‑‒01-‐‑‒01 01 3 2 2015-‐‑‒01-‐‑‒01 01 2
- 28. / 55 不不具合 • ログ送信が遅延すると、レコードを集約出来 ない(再集計が煩雑)。集計に依存関係がある • MySQLは数千万レコードを超えると集約関 数を使った時に集計時間が予測できなくなっ た • 参照カラムを間違える等、SQL修正で過去分 再集計 28
- 29. / 55 Hadoop • Java製分散環境集計フレームワーク • BigDataの処理理を得意とする • 複数台のマシンを利利⽤用して並列列に処理理が可 能 • ノウハウは最近充実 29
- 30. / 55 Hadoop • ログを⼀一件⼀一件保持 • 事前集計して可視化 30
- 31. / 55 変更更すると • 数億件⼊入れてもレスポンスは遅くなりにく い(数分)。 • SQLは過去分も集計するので、次回定期集 計で修正される。 • ⼀一件⼀一件の⽣生ログが残っているのでログ遅 延が起こっても、再集計が楽。 31
- 32. / 55 欲しい集計システム • ◯データがいくらでも⼊入る • ◯データを集約せず⽣生データを保持 • ◯再集計が楽 • 集計が試⾏行行錯誤しやすい • データが増えても集計レスポンスが速い • 導⼊入が楽 32
- 33. / 55 それでも残る不不満 • Hadoop(Hive)数億件でも集計に数分だ が、数万件でも集計に数分 • 集計に時間がかかるので、試⾏行行錯誤しづら い • 集計中に寝てしまう 33
- 34. / 55 BigQuery • Google製データ分析環境 • 数千台のマシンに分散してデータを保存 • 数千台のマシンを使って集計 • カラム型ストレージで⾼高い圧縮率率率 • ノウハウまだなし 34
- 35. / 55 BigQueryに変更更 • ⼀一件⼀一件の⽣生ログを保存 • リクエスト毎に都度度集計 35
- 36. / 55 集計のSQL(架空のSQL) 36 SELECT world, date_format(time,'%Y-‐%m-‐%d') as date, count_distinct(user_id) as dau FROM [table20150101-‐20150131] GROUP BY world,date ORDER BY world,date; SQLはイメージです
- 37. / 55 この様に集計される 37 このグラフは イメージです
- 38. / 55 集計システムのポイント • 何も考えずに全てのレコードが集計対象 • キャッシュや事前集計などをせず、そのま ま全て集計 • ⾃自前で環境を構築せず、Googleの肩に乗 る 38
- 39. / 55 若若⼲干盛りました • 実際には、⼀一度度集計したグラフはその後数 時間キャッシュ化 • 基本的なKPIは事前に集計 • 基本的な構成は、シンプルなまま 39
- 40. / 55 改善したこと • 膨⼤大なレコードでも数秒で集計 • ログ遅延が起きても、遅れてテーブルに⼊入 りさえすれば⾃自動で再集計 • SaaSは楽 • 再集計がやりやすい(冪等性が担保される 様に実装した) 40
- 41. / 55 欲しい集計システム • ◯いくらでもデータが⼊入る • ◯データを集約せず⽣生データから集計する • ◯再集計が楽 • ◯集計が、試⾏行行錯誤しやすい • ◯データが増えても集計レスポンスが速い • 導⼊入が楽 41
- 42. / 55 DEMO(13億件集計) 42 実際のゲームのログ 13億件を集計
- 43. / 5543 DEMO
- 44. / 55 教訓 • ログ送信遅延や、参照カラム間違えは起こ るので、エラー耐性のあるシステムを作 る。 • 集計の試⾏行行錯誤は多いので、レスポンスタ イムは⾺馬⿅鹿鹿にできない。 • オンプレミスはお勧めしない 44
- 45. / 55 ⽉月額コスト • 数千億レコード 100万以内 • 数億レコード 10万以内 • 数千万レコード 数千円 45
- 46. データ集計環境が整備されて何が起こっ たか？
- 47. / 55 SQL勉強会 • ⾃自分たちでSQLを書いて、ゲーム内のデー タを取る機運が⾼高まった。 • SQL勉強会を、⾮非エンジニア向けに⾏行行っ た。 47
- 48. / 55 データ集計以外の拡がり • データ集計以外にも活⽤用され始める • 企画による • ⾏行行動履履歴 • サポート業務の利利⽤用 • アイテム操作履履歴・戦闘履履歴 48
- 49. / 55 データ分析チーム以外の活躍 • ⼤大阪スタジオのwebエンジニアがデータ可 視化についてレクチャー 49
- 50. / 55 データ分析に対する意識識の⾼高まり • どの様にデータを分析したら良良いか、互い にSlack上で試⾏行行錯誤を始めた。 • レスポンス速度度が速く、試⾏行行錯誤しやすい 50
- 51. / 55 企画・運営が⾃自分でSQLを使う • BigQueryにしたことで • 本番DBに悪影響がない • SQL記述ミスでデータを消さない • と案内した • 企画・運営が⾃自分でデータを分析する際に 不不安に思うことを減らせる 51
- 52. / 55 データを⾒見見る⽂文化 • データ集計環境を整備することで、企画・ 運営が⾃自分たちで集計をしたり、タイトル のエンジニアが主体的にデータ分析の仕⽅方 をレクチャーしたり、データを⾒見見て⾏行行動を 起こす⽂文化が根付きつつある。 52
- 53. / 55 終わり • Aimingでは共にデータ分析をしてくれる ⼈人を募集しています。 • http://aiming-‐‑‒inc.com/ja/jobs/ • Aimingで検索索して下さい 53
- 54. / 55 宣伝 • ゲーム開発が変わる！ Google Cloud Platform 実践インフ ラ構築 • BQのスキーマのガイ ドラインや、テーブル 分割の⽅方法はこちらに 載ってます 54
- 55. / 55 本の内容 • データ分析環境の紹介 • -‐‑‒ 過去の分析環境の紹介 • -‐‑‒ BigQueryを使った新しい分析環境 • -‐‑‒ データ分析システムの⽐比較 • -‐‑‒ データ分析環境を作る • -‐‑‒ 実際にログを収集する • -‐‑‒ 実際に集計、可視化する • -‐‑‒ 収集したデータの活⽤用とKPI • -‐‑‒ BigQueryのコスト • -‐‑‒ SQL実例例あれこれ • -‐‑‒ データ分析環境を作ってみての変化 • -‐‑‒ まとめ 55
