Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ビッグデータとioDriveの夕べ:ドリコムのデータ分析環境のお話

6,753 views

Published on

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

Published in: Technology

ビッグデータとioDriveの夕べ:ドリコムのデータ分析環境のお話

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

×