俺は分散を捨てるぞジョジョー http://atnd.org/events/34146

1. ドリコムのデータ分析環境のお
話
ところてん
@tokoroten

2. 合わせて読みたい
• 第2回 ioDrive+MySQL勉強会 @外道父 ioDriveの世界
へようこそ
– http://www.slideshare.net/GedowFather/welcome-to-
iodrive-world
• ActiveRecord Turntable
– ドリコム内製のDBの水平分割ミドルウェア
– http://www.slideshare.net/drecom/activerecordturntab
le
• ソーシャルゲームにレコメンドエンジンを導入した話
– http://www.slideshare.net/TokorotenNakayama/ss-
15111004

3. 自己紹介
• ところてん＠Drecom
– データ分析グループ
– 高機能雑用
• R&D&火消し&データ分析&企画
• 最近、インフラ業務が外れた
– 定額働きたい放題プラン、意識の高い社
畜
– Pythonista
– awkかわいいよawk
– Rubyは読めるけど書けない
• 注）DrecomはRailsの会社です 3

4. ドリコムのデータ分析の概要
• 言語
– Hadoop、hive、sh、R、SPSS、Knime、Python
• 環境
– 分析用の専用サーバ*2(1.2TBのFIO搭載)
– データ収集、分析用Hadoopクラスタ
• Impalaを本番投入準備中
• 仕事
– ゲームのバランスチェック、KPI設計、継続率、
収益予測、テキストマイニング、広告効果計測
4

5. ドリコムのデータ分析の構成例
Webサーバ
数十台
ActiveRecord Turntable
ユーザIDごとに水平分割
M-DB1 M-DB2 M-DB3 M-DB4 M-DB5 マスター5台
(FIO搭載)
S-DB1S S-DB2 S-DB3 S-DB4 S-DB5 スレーブ5台
(FIO搭載)
Fluentd 定期的にDBのダンプを取得
Fuse-HDFS FIOを搭載した分析用サーバ
ログサーバ
(HDFS) 1.2TBのFIO、16コア、メモリ
32GB
HDFSから必要なログを収集

6. データ分析の人的問題
• 全部を満たすのは難しい
–統計分析能力（必須）
–ゲームそのものに対する理解
–データ抽出、前処理能力
–機械学習、マイニング
–可視化
–並列処理、分散処理(hadoop)
6

7. 分析のトレードオフ
• おれは分散をやめるぞジョ
ジョーー！！
画像省略

8. ソーシャルゲームのデータ特性
• データ量はたかが知れてる
– アクセスログ、一日数十GB
– DBのダンプ、数百GB
• ゲームの仕様変更が頻繁
– あまりに古い物を参照しても仕方ない
– 三ヶ月前のログは比較しづらい
• 短期間の莫大な量のデータを解析する必
要
• 分散に向かない解析が必要なことも

9. hadoopのデータ特性、思想
• Hadoopは無限のストレージに無限の計算リ
ソースを利用して価値を生み出すシステム
• データは経年劣化しないことが前提
– 遺伝子情報
– ウェブページのスナップショット
– etc…
• ソーシャルゲームのデータ特性とは相性が
悪い
– ソーシャルゲームのデータは経年劣化する
– 二週間に一度、大規模なアップデート

10. 分析のトレードオフ
• Hadoopで分散より、スクリプト言語
– 分散処理のデバッグの時間が惜しい
• PDCAは三日程度
• 一日リリースが遅れるとXXXX万円の機会損失
– ゲームごとにスキーマが異なる
– スキーマは更新で頻繁に変わる
– 小さい処理ではHadoopのオーバーヘッドが
重たい
– KnimeやSPSSなどの高度なツールが使える
– FIOが早い、FIOが早い、FIOが早い

11. データ分析のワークフロー
• サービスのSlaveにクエリを投げて、
DBのスナップショットをFIO上に取得
• fuse-hdfsでマウントされたHDFSにログ
データを問い合わせ
– 何度もアクセスして負荷が激しい場合はFIO上
に再配置
• スクリプト言語でゴリゴリ処理
• 結果をRやExcelで可視化

12. データ分析の運用フロー
• 分析チームが分析用サーバでデータ
分析
• 定常化する必要がある場合は、イン
フラ部に依頼、
– Hiveバッチ化、hadoopバッチ化
– スクリプトを渡して運用を依頼
• 分析用サーバはよく落ちる(無茶をするの
で)
– 分析のための中間データの出力を依頼

13. Bigdataはどこで生まれるのか？
• データが生まれるのは運用の現場
研究 開発 運用
ログデータ
• 分析者がログデータを手に入れるには現
場との信頼関係が必須
– 大企業では信頼関係が構築しづらい

14. 自主規制

15. 分析のための組織構造
• 基本的に社員はすべてのデータが見
れる
– 組織が近いので、やり取りが迅速
– 分析者はアプリ開発者の真横に座る
ソーシャルゲーム事業部
戦国フ ユーザ
ビック ソード× データ
陰陽師 ロン 基盤部 サポー
リマン ソード 分析
ティア ト
アプリケーションごとの開発・運用ライ

16. ソーシャルゲームにおけるPDCA
• ログデータと開発が近いとPDCAが回
る 基盤部
Research
Plan 開発ライン
開発ライ Action Do 開発ライ
ン ン
Check データ分析

17. FIOってホントに早いの？実験
• 実験環境、分析用PC
– Hiveクエリ
– Fuse-hdfs
– FIO
– SASドライブ(3台のストライピング)
– 開発用ノートPC
• 対象データ
– あるアプリの一日分のアクセスログ
• gz圧縮 1.3GB 生データ 5.6GB

18. ユニークユーザカウント
• コマンド
– time zcat *.gz | awk -F"t" '{print $3}' | sort -u | wc –
l
– hive : select count(distinct userid)～ group by
userid
• 結果
– Hive 72秒
– Fuse-hdfs 89秒
– FIO 70秒 (解凍済みだと46秒)
– SASドライブ 71秒(解凍済みだと46秒)
– 開発用ノートPC 140秒

19. zcatでファイルを舐めるだけ
• コマンド
– time zcat *.gz > /dev/null
• 結果
– Fuse-hdfs 76秒
– FIO 57秒 (解凍済みだと1.55秒)
– SASドライブ 57秒(解凍済みだと1.54
秒)
– 開発用ノートPC 解凍済みで98秒

20. 原因はCPU
• 結果
– FIO≒SAS(3台ストライピング)>hive
>fuse-hdfs>>>ローカル
• CPUが足を引っ張る
– 処理時間の大半はgzの展開
• 並列化すると真価を発揮する
– データ分析のために過去のDB状態をバック
アップからリストア
– 8DBの同時復元を行っても速度変わらず

21. まとめ
• ドリコムのデータ分析チームは分散してない
– ソーシャルゲームのデータ特性
– PDCAサイクルが短い
– FIOが早い
• 安定したらインフラ部に依頼
– Hive、hadoopによる中間データの定常出力依頼
– スクリプトの引渡し、運用依頼、hadoopへの移植依
頼
• FIOの実験
– FIOの性能を活かしきるにはCPUがボトルネック
– 分析のためにDBの8並列リストアとかやってる