オンラインゲーム分析：むかしの苦労話から，今のソリューションに至るまでを振り返る
本記事は移転しました。新サイトにリダイレクトします。
トレジャーデータはクラウドでデータマネージメントサービスを提供しています。
現在私はトレジャーデータのデータサイエンティストというポジションにありますが，「サイエンティスト」という名にあるような，特定のサービスの専任アナリストとして高度な分析を行うスペシャリストではありません。トレジャーデータサービスが全ての分析者の心強い手足となるようにアドバイスやユースケースを提示するようなスペシャリストです。
そんな私もトレジャーデータに来るまでは，１つのサービスの専任分析者として突き詰めていた時代がありました。その時代は現在のようなデータ分析プラットフォームが成熟しておらず，自分であれこれ試行錯誤しながら独自プラットフォームを作っておりました。
現在トレジャーデータが提供する「オンラインゲームソリューション」は，当時の私の経験を踏まえ，誰にも苦労してもらうことなしに分析を始めてもらえるような形となっております。
本記事ではあえて昔の苦労話を展開し，それがトレジャーデータではどのように解決されたかという今と昔を振り返ることで多くの人の共感とトレジャーデータの素晴らしさを実感してもらえればと考えております。
本記事では以下の3つのポイントで Before After を記述していきます。
-
異なるデータソースの管理・運用
-
データの蓄積・集計エンジン
-
分析フロントエンド
今から約5年前，学生だった若い私はとあるソーシャルゲーム会社で専任アナリストとしてデータ分析を行っておりました。分析プラットフォームの中心として Mongo DB の価値を見いだし，コミュニティ活動も精力的に行っておりました。
1. 異なるデータソースの管理・運用 (Before Treasure Data)
当時，分析のインプットとして4つのデータソースを管理しておりました：
- ユーザーID付きのアクセスログ（From Web Server）
- ユーザーごとの様々な行動ログ（From App Server）
- ユーザーの課金，登録情報（From My SQL）
- ユーザーの現在のステータス（From Cassandra）
有効な分析のためには，これら4種類のログを相互活用できることは大変ありがたい事でした。一方で，それぞれが異なるデータソースに，異なるインターバルで蓄積され続けていましたので，その管理・運用はとてもとても大変でした。当時は Fluentd も無かった時代で，様々なデータソースに対するコレクターの運用管理に気を取られ，データの遅延や取得エラーで毎日泣かされる日々でした。
1. 異なるデータソースの管理・運用 (After Treasure Data)
Fluentd はデータソースの管理運用問題を劇的に改善してくれました。Fluentd は異なるデータソースに対しても，設定ファイルの変更のみで統一的に管理でき，エラーハンドリングまで行ってくれ，かつ一定時間のインターバルでのストリーミング収集まで可能にしてくれます。
2. データの蓄積・集計エンジン (Before Treasure Data)
異なるデータソースから集められたログは，統一的に扱うために同一のデータサーバーに蓄積されていくことになります。当時は Mongo DB がその役割をになっていました。
当時集まってくるログの中で，行動ログとゲームセーブデータログは，フォーマットの不確定なものでした。定期的に行われるイベントをウォッチするためには，そのイベント固有のログを新しく出していく必要がありました。従来のRDBMSではこのスキーマの変化に柔軟に対応しきれませんでした。Mongo DB は見た目JSONの形で，同じコレクション（テーブル）の中にキー・バリューセットの異なる様々な行動ログを受け入れてくれました。また，そこからのデータ取り出しも容易に行ってくれました。
分析とはトライアルエラーの繰り返しで有り，日々改善されていくものですから，そのためにデータの取得項目が変化していくことへの対応はマストなものでした。
また，当時の行動ログ ↑ は非構造な形で集められておりました。様々な行動のログが文字列として入ってくるために，これをMongoDBに入れる際にはパース・整形の処理でキーバリューセットを作ることが必要でした。ログの量がそれなりにありましたので，それに Hadoop を使っておりました。
2. データの蓄積・集計エンジン (After Treasure Data)
トレジャーデータサービスのクラウドストレージは，前述のようなログの多様性を受け入れてくれるものであるにも関わらず，MongoDBが苦手だった巨大なデータセットに対する分散処理にも適しています。それに加えて，データを収集する際に構造化データ：キーバリューセットしか受け入れないというスタンスを取ることで，ログを吐き出す時点でログの構造が意識され，当時の行動ログのように非構造化レコードを１レコードずつパースするというフェーズが無くなりました。
トレジャーデータのオンラインゲームソリューションでは，基本的な行動に関しては上図の様にテンプレートを用意しております。もちろん，スキーマレスのトレジャーストレージでは上記の項目が変更・追加されても問題無く受け付けてくれます。
↑ 構造化としてログを吐き出すというのは，上図のように JSON の形式で，キーバリューセットで吐き出すと言うことです。
トレジャーデータは当時私がとても苦労していたログの収集・蓄積の負担を大幅に軽減し，かつログの多様性を受け入れてくれるものになっています。
3. 分析フロントエンド (Before Treasure Data)
当時の分析フロントエンドは，MongoDBに対して jQuery で集計データを取得しwebを通じて主要KPIを参照してもらう形でした。また，個々の深い分析要件に対してはcsvファイルで分析用ファイルを取得し，R等で分析していました。ソーシャルゲームのソーシャル性に関する，招待や友達同志の関係を分析するためにGraphDBを活用していました。Graph DBに関する資料は過去の私の資料をご参照下さい。
3. 分析フロントエンド (After Treasure Data)
Metric Insights
当時新しいKPIが増えるごとに，HTMLソースに編集するという非効率な作業を行っておりましたが，トレジャーデータではOEM提供する MetricInsights が面倒なソースの編集作業を無くしてくれます。
↑ MetricInsightsでは，データソースの独立したウィジェット1つ1つにKPIロジック（SQL）を設定すれば簡単にKPIを追加することができるようになります。
ウィジェットでは，折れ線グラフや棒グラフに加え上図のような様々な可視化手段を備えております。また，ピボットテーブルなどのテーブル操作も可能です。
まとめ
トレジャーデータのオンラインゲームソリューションではデータの収集運用から可視化の部分までの一気通貫したサービスで，分析者の手をわずらわせることなく本質的な分析「自身」にフォーカスして運用していくことが可能です。
