大數據之實踐案例分析

前言

公司由頁游轉手游，公司的數據分析需要針對手游進行設計，所以原來的那一套針對頁游的數據分析框架就顯得不是很合適了，一方面在于手游和頁游一些業務邏輯上的不同，另外一方面是數據量級上的改變，以及渠道、區服之間的聯系、以及手游BI系統的渠道區服交叉查詢。使得原本從4399游戲那一套針對頁游而來的框架就顯得有些吃力。這里分析的就是頁游到手游這個過程中，針對大數據分析所做的調整工作，以及在此之間的分析案例。

頁游合作場景

頁游階段，如果一款頁游準備推上某個平臺，那么需要與該平臺進行對接，在該平臺上進行考試，達到一定分數，平臺才可以提供資源進行上線擴服。那么如果想上另外一個平臺，那么需要跟另外一個平臺進行相同的流程。目前頁游公司與平臺方的合作方式大部分如此。那么其實游戲，平臺與區服就都是一一對應的，一個平臺可開設多個區服，且一個區服只屬于一個平臺（跟手游不一樣）。

頁游數據采集分析過程

公司隨著游戲開服，需要查看游戲的數分析，比如說留存流失情況，付費情況，活躍用戶情況，崩潰情況等等，這就是很多BI系統中的一個子系統（數據分析系統：用于用戶行為分析、產品質量監控、活動參與度統計等等）。那么這一流程大致如下圖：

分析：
1.平臺與平臺之間的數據是隔離的
2.在使用ETL處理項目組數據時保持原來的游戲平臺-區服分庫，如果針對一些特殊的表，可以進行拉取匯總表，比如說login表，付費表。
3.編寫統計腳本，放到Linux定時任務中，統計結果放到結果庫，結果庫按照平臺分庫。
4.根據BI系統數據分析從結果庫中的統計結果，展示相關指標數據的圖表。
5.這個過程中會有少量實時數據的分析需求，這個就需要在BI系統中直接去連接項目組數或者通過短時間定時任務進行拉取到結果庫。

手游數據采集分析過程

手游階段，如果一款游戲需要再某一渠道上線，那么需要跟渠道商進行合作，IOS和安卓就是平臺，并且同一平臺下的不同渠道的游戲數據可以寫到同一個區服里，也就是說渠道與區服是多對多的關系。那么跟頁游情況相比較就有不一樣了，一個服里的數據可能來自多個渠道，一個渠道的數據被分在多個區服里。大致分析流程如下：

分析：
1.渠道與服直接是多對多的關系
2.etl拉取清洗時依然根據渠道-區服進行分庫
3.編寫統計腳本，統計結果保存到結果庫，一個游戲只有一個結果庫（包含所有渠道，所有區服）
4.因為只有一個結果庫，所以需要考慮分表，避免單表過大查詢慢。分析如下：
假設50個渠道，100個區服，單表維度不超過5個，根據經驗估算[10W-15W]/天增量，那么按照季度進行分表，每個子表數據量在900W到1350W之間，另外針對一些記錄相對活躍的統計表，可能需要按月分表或者更細。總而言之就是盡可能的減少單個表的大小，但是這個會帶來一個問題就是在BI系統中如何進行查詢、分頁呀等等問題，不過這個問題已經有相應的組件幫我們完成，比如說：阿里的mycat、當當網的Sharding-JDBC，我計劃使用Sharding-JDBC，因為mycat針對查詢、分頁我感覺有點重了。如果你們也需要使用類似的功能，請結合自己需要選擇即可。