Embed Size (px)
DESCRIPTION
俺は分散を捨てるぞジョジョー http://atnd.org/events/34146
Citation preview
ドリコムのデータ分析環境のお話
ところてん
@tokoroten
合わせて読みたい
• 第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
自己紹介
• ところてん＠Drecom–データ分析グループ–高機能雑用
• R&D&火消し&データ分析&企画• 最近、インフラ業務が外れた
–定額働きたい放題プラン、意識の高い社畜
– Pythonista– awkかわいいよawk– Rubyは読めるけど書けない
• 注）DrecomはRailsの会社です 3
ドリコムのデータ分析の概要
• 言語– Hadoop、hive、sh、R、SPSS、Knime、Python
• 環境– 分析用の専用サーバ*2(1.2TBのFIO搭載)– データ収集、分析用Hadoopクラスタ
• Impalaを本番投入準備中
• 仕事– ゲームのバランスチェック、KPI設計、継続率、収益予測、テキストマイニング、広告効果計測
4
ドリコムのデータ分析の構成例
M-DB1 M-DB2 M-DB3 M-DB4 M-DB5
S-DB1S S-DB2 S-DB3 S-DB4 S-DB5
ActiveRecord TurntableユーザIDごとに水平分割
Webサーバ数十台
マスター5台(FIO搭載)
スレーブ5台(FIO搭載)
FIOを搭載した分析用サーバ1.2TBのFIO、16コア、メモリ32GB
定期的にDBのダンプを取得
ログサーバ(HDFS)
HDFSから必要なログを収集
Fluentd
Fuse-HDFS
データ分析の人的問題
• 全部を満たすのは難しい
–統計分析能力（必須）
–ゲームそのものに対する理解
–データ抽出、前処理能力
–機械学習、マイニング
–可視化
–並列処理、分散処理(hadoop)
6
分析のトレードオフ
• おれは分散をやめるぞジョジョーー！！
画像省略
ソーシャルゲームのデータ特性
• データ量はたかが知れてる
–アクセスログ、一日数十GB
– DBのダンプ、数百GB
• ゲームの仕様変更が頻繁
–あまりに古い物を参照しても仕方ない
–三ヶ月前のログは比較しづらい
• 短期間の莫大な量のデータを解析する必要
• 分散に向かない解析が必要なことも
hadoopのデータ特性、思想
• Hadoopは無限のストレージに無限の計算リソースを利用して価値を生み出すシステム
• データは経年劣化しないことが前提–遺伝子情報–ウェブページのスナップショット– etc…
• ソーシャルゲームのデータ特性とは相性が悪い–ソーシャルゲームのデータは経年劣化する–二週間に一度、大規模なアップデート
分析のトレードオフ
• Hadoopで分散より、スクリプト言語–分散処理のデバッグの時間が惜しい
• PDCAは三日程度
• 一日リリースが遅れるとXXXX万円の機会損失
–ゲームごとにスキーマが異なる
–スキーマは更新で頻繁に変わる
–小さい処理ではHadoopのオーバーヘッドが重たい
– KnimeやSPSSなどの高度なツールが使える
– FIOが早い、FIOが早い、FIOが早い
データ分析のワークフロー
• サービスのSlaveにクエリを投げて、DBのスナップショットをFIO上に取得
• fuse-hdfsでマウントされたHDFSにログデータを問い合わせ
– 何度もアクセスして負荷が激しい場合はFIO上に再配置
• スクリプト言語でゴリゴリ処理
• 結果をRやExcelで可視化
データ分析の運用フロー
• 分析チームが分析用サーバでデータ分析
• 定常化する必要がある場合は、インフラ部に依頼、–Hiveバッチ化、hadoopバッチ化
–スクリプトを渡して運用を依頼• 分析用サーバはよく落ちる(無茶をするので)
–分析のための中間データの出力を依頼• 徐々に移管していく
Bigdataはどこで生まれるのか？
• データが生まれるのは運用の現場
• 分析者がログデータを手に入れるには現場との信頼関係が必須–大企業では信頼関係が構築しづらい
研究 開発 運用
ログデータ
自主規制
分析のための組織構造
• 基本的に社員はすべてのデータが見れる
–組織が近いので、やり取りが迅速
–分析者はアプリ開発者の真横に座る
ソーシャルゲーム事業部
陰陽師ビックリマン
ソード×
ソード
戦国フロン
ティア
データ分析
基盤部ユーザサポート
アプリケーションごとの開発・運用ライン
ソーシャルゲームにおけるPDCA
• ログデータと開発が近いとPDCAが回る
Plan
Do
Check
Action 開発ライン
データ分析
開発ラインResearch
基盤部
開発ライン
FIOってホントに早いの？実験
• 実験環境、分析用PC– Hiveクエリ
– Fuse-hdfs
– FIO
– SASドライブ(3台のストライピング)
–開発用ノートPC
• 対象データ–あるアプリの一日分のアクセスログ
• gz圧縮 1.3GB 生データ 5.6GB
ユニークユーザカウント
• コマンド– 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秒
zcatでファイルを舐めるだけ
• コマンド
–time zcat *.gz > /dev/null
• 結果
–Fuse-hdfs 76秒
–FIO 57秒 (解凍済みだと1.55秒)
–SASドライブ 57秒(解凍済みだと1.54秒)
–開発用ノートPC 解凍済みで98秒
原因はCPU
• 結果– FIO≒SAS(3台ストライピング)>hive>fuse-hdfs>>>ローカル
• CPUが足を引っ張る–処理時間の大半はgzの展開
• 並列化すると真価を発揮する–データ分析のために過去のDB状態をバックアップからリストア
– 8DBの同時復元を行っても速度変わらず
まとめ
• ドリコムのデータ分析チームは分散してない– ソーシャルゲームのデータ特性– PDCAサイクルが短い– FIOが早い
• 安定したらインフラ部に依頼– Hive、hadoopによる中間データの定常出力依頼– スクリプトの引渡し、運用依頼、hadoopへの移植依頼
• FIOの実験– FIOの性能を活かしきるにはCPUがボトルネック– 分析のためにDBの8並列リストアとかやってる
