analytics with mongodb
TRANSCRIPT
Analytics with MongoDB
@bibrost
Page : 1
@bibrost
Freelance Engineer
MongoDB JP / GraphDB JP
Made Analytics system for SocialApps
Joined SV startup from September 2011
- Python(Tornado) / Scala( Lift )
Page : 2
Today‘s Theme
１．What’s Analytics?
２．Why MongoDB?
３．Case study
Page : 3
What’s Analytics?
Page : 4
データを分析し「行動」を変え結果を向上させる継続的活動
Data
Analytics
Action
Page : 5
One Big Issue
Page : 6
vs
Discover gold dust in desert
Discover gold in mine
Page : 7
Garbage in garbage out
ゴミのようなデータを使っていくら
解析しても出てくる結果はゴミばかり
Page : 8
コスト
データ量
現実的ライン
砂漠
鉱山
Page : 9
Do you want to
discover gold in mine?
Page : 10
Garbage to garbage box
ゴミはゴミ箱に捨てて忘れる、という戦略
具体的には
・無計画に保存されたログ
・ルールが無く解釈が困難なログ
・必要な情報が不足しているログ
Page : 11
Strategic Logging
きちんとプランニングした上で分析のためのデータを生成する
プランニング 実装 収集・分析
なんのために？
どんな結果を得たい？
どう行動につなげる？
どうログを送れば
意図した結果を
得ることができるか？
より高速にするには？
どのプロダクトを使うか？
わかりやすい表現は？
Page : 12
Why MongoDB?
Page : 13
Relational DB
Key-value Store
Columnar DB
Document DB
Graph DB
is DocumentDB
Oracle, PostgreSQL, etc
Redis, etc
Hbase , Cassandra, etc
MongoDB, CouchDB , etc
Neo4j, FlockDB, etc
Page : 14
- Structured
- Schemaless
- Scalable
Strategicなログ収集に利用しやすい
MongoDBが持つ３つの特性
Page : 15
Structured
構造化データを持ち、更にクエリを利用できる
activity = {
user:”1”,
date:2011024,
actions:{
battle:[{target:”5”,result:”win”}, {target:”59,result:”lose”}],
paid:[{item:”5”,amount:1,unit:50,price:50}]
}
}
db.activity.find{date:{‘$gte’:20111001,’$lte’:20111015}
インデックスを貼ることができ構造データの高速サーチが可能
Page : 16
Schemaless
構造化されていながら、スキーマを持たず柔軟に利用可能
activity = {
user:”1”,
date:2011024,
actions:{
battle:[{target:”5”,result:”win”}, {target:”59,result:”lose”}],
paid:[{item:”5”,amount:1,unit:50,price:50}]
}
}
ドキュメントによってフィールドがあったりなかったりしてもOK。
後からいくらでも構成変更ができる上、リストを持つことも可能
Page : 17
Scalable
巨大なデータをさばける拡張性と速度
・ログの保存に適した高速なCappedCollectionの提供
※データサイズを固定し、Indexを持たないことで非常に高速に保存可能
読み込みにはtailable cursorを用いる
・fire-and-forgetによる結果を待たないinsert
※unsafeではあるが、高速にクライアントへレスポンスを返す事が可能
・Bulk insertによる一括インサート
などを利用することで、大規模なアプリのストリーミングデータを
取り込むのに十分な性能を出すことができます。
Page : 18
３つの特性を活かすことで効率化がしやすい
Page : 19
Case study
Page : 20
Nijiboxさんのソーシャルアプリ向けに
MongoDBを利用した解析用の
バックエンドシステムを開発
Page : 21
Mission
- 改善のアクションに繋げられるツールを作る
- フロントエンドにやさしいUI
- 効率よく、早く実行できるシステム
- スケーラビリティの高い仕組み
Page : 22
アプリA Clientクラス
アプリB Clientクラス
アプリC Clientクラス
レシーバー
管理画面
Database
各アプリケーションにクライアントライブラリを配布し、
そこから構造化データを送る。データは分析用のクラスタに送られ、
最終的に専用の管理ツールから閲覧できるようになっている。
Page : 23
Httpとjsonが扱えれば使えるコードを提供して導入コストを抑える
フレームワークに組込ロジック側では一文で送信可能に
require_once('Client.php');
$userid = 1000;
$server = "http://xxxx/";
$appid = "test";
Client::init($userid,$server,$appid);
// ここまではフレームワークに組込
// アプリ上ではこの一行でログ送信OK
_ntls()->setAction("mission",array("type"=>"taiman","gekiha" => 100));
Page : 24
内部的には、入ってきたローデータを一度中間形式に変更し
そこから各種解析をかける仕組み。
基本的なデータ（KPI等）は定期的に解析データをキャッシュ。
必要であれば中間データからオンデマンドに解析を実施できる
インターフェイスを提供している。
Page : 25
Point, Challenge
- 開発初期から参加し、どのようなデータを
送るかについて議論した上で進めた
- 認証機構をチームで使っているBacklogを通す事で簡素化
- 能動的に取得するログに絞込むことで負荷軽減
- ログ送信のためのクラスを作り、フレームワークに組込
- 開発チームのメンバが利用できるインターフェイスを用意
Page : 26
Message
Page : 27
Analystになろう
- アナリスト≠技術者。ビジネスやアプリへの理解が必要
- 勿論、解析のためのテクノロジを利用する技術は必要
- それと同等に仮説、マーケ、検証、継続マネジメントも重要
- これから需要は増えそうだが、プレイヤーが少ない
→ 市場価値を高める一手としてオススメ
Page : 28
Questions
Thanks
@bibrost