Download as PDF, PPTX
![/
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はイメージです](https://image.slidesharecdn.com/aimingstudyupload-160127054519/85/BigQuery-KPI-36-320.jpg)
Uploaded by(shibao)芝尾 (kouichiro)幸一郎
BigQueryで集計するシステムを作って分かったKPI集計ツール作成
株式会社 Aiming 主催の開発勉強会 第8回の発表資料になります。Aiming社でのデータ集計環境構築の話になります。 http://aiming.connpass.com/event/25004/
More Related Content
![[DLHacks LT] PytorchのDataLoader -torchtextのソースコードを読んでみた-](https://cdn.slidesharecdn.com/ss_thumbnails/torchtextupload-170918235754-thumbnail.jpg?width=640&height=640&fit=bounds)
![[DL輪読会]機械学習におけるカオス現象について](https://cdn.slidesharecdn.com/ss_thumbnails/20190419dlhacks-190510023936-thumbnail.jpg?width=640&height=640&fit=bounds)
![SSII2021 [OS2-01] 転移学習の基礎：異なるタスクの知識を利用するための機械学習の方法](https://cdn.slidesharecdn.com/ss_thumbnails/os2-02final-210610091211-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to BigQueryで集計するシステムを作って分かったKPI集計ツール作成
![[db tech showcase OSS 2017] A14: IoT時代のデータストア--躍進するNoSQL、拡張するRDB by OSSコンソーシア...](https://cdn.slidesharecdn.com/ss_thumbnails/20170616dbtechshowcaseossyoshida-170621081930-thumbnail.jpg?width=640&height=640&fit=bounds)
BigQueryで集計するシステムを作って分かったKPI集計ツール作成
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7. / 55 あまり⽬目⽴立立たない仕事 • ログ収集 • データ分析 • 課⾦金金 • 認証 7
- 8.
- 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.
- 15.
- 16.
- 17. / 55 集計項⽬目 • AU • RDAU • FQ5 • 新規 • 継続率率率 • ポイント消費 • ポイント購⼊入 • PU • ARPPU • 登録⽉月別AU • チュートリアル進捗 • クエスト進捗 • その他集計 17
- 18.
- 19.
- 20. / 55 データ集計環境構築の困難 • データが多い • データを集約するとミスに弱い • 再集計が⼤大変 • 集計が試⾏行行錯誤しにくい • データが増えると集計が⻑⾧長時間 • 導⼊入が⼤大変 20
- 21. / 55 欲しい集計システム • データがいくらでも⼊入る • データを集約せず⽣生データを保持 • 再集計が楽 • 集計が試⾏行行錯誤しやすい • データが増えても集計レスポンスが速い • 導⼊入が楽 21
- 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.
- 38. / 55 集計システムのポイント • 何も考えずに全てのレコードが集計対象 • キャッシュや事前集計などをせず、そのま ま全て集計 • ⾃自前で環境を構築せず、Googleの肩に乗 る 38
- 39. / 55 若若⼲干盛りました • 実際には、⼀一度度集計したグラフはその後数 時間キャッシュ化 • 基本的なKPIは事前に集計 • 基本的な構成は、シンプルなまま 39
- 40. / 55 改善したこと • 膨⼤大なレコードでも数秒で集計 • ログ遅延が起きても、遅れてテーブルに⼊入 りさえすれば⾃自動で再集計 • SaaSは楽 • 再集計がやりやすい(冪等性が担保される 様に実装した) 40
- 41. / 55 欲しい集計システム • ◯いくらでもデータが⼊入る • ◯データを集約せず⽣生データから集計する • ◯再集計が楽 • ◯集計が、試⾏行行錯誤しやすい • ◯データが増えても集計レスポンスが速い • 導⼊入が楽 41
- 42.
- 43.
- 44. / 55 教訓 • ログ送信遅延や、参照カラム間違えは起こ るので、エラー耐性のあるシステムを作 る。 • 集計の試⾏行行錯誤は多いので、レスポンスタ イムは⾺馬⿅鹿鹿にできない。 • オンプレミスはお勧めしない 44
- 45. / 55 ⽉月額コスト • 数千億レコード 100万以内 • 数億レコード 10万以内 • 数千万レコード 数千円 45
- 46.
- 47. / 55 SQL勉強会 • ⾃自分たちでSQLを書いて、ゲーム内のデー タを取る機運が⾼高まった。 • SQL勉強会を、⾮非エンジニア向けに⾏行行っ た。 47
- 48. / 55 データ集計以外の拡がり • データ集計以外にも活⽤用され始める • 企画による • ⾏行行動履履歴 • サポート業務の利利⽤用 • アイテム操作履履歴・戦闘履履歴 48
- 49.
- 50. / 55 データ分析に対する意識識の⾼高まり • どの様にデータを分析したら良良いか、互い にSlack上で試⾏行行錯誤を始めた。 • レスポンス速度度が速く、試⾏行行錯誤しやすい 50
- 51. / 55 企画・運営が⾃自分でSQLを使う • BigQueryにしたことで • 本番DBに悪影響がない • SQL記述ミスでデータを消さない • と案内した • 企画・運営が⾃自分でデータを分析する際に 不不安に思うことを減らせる 51
- 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