大資料之實踐案例分析

標籤：項目   準備   圖表   展示   blog   分享圖片   lin   text   size   

前言

公司由頁遊轉手遊，公司的資料分析需要針對手遊進行設計，所以原來的那一套針對頁遊的資料分析架構就顯得不是很合適了，一方面在於手遊和頁遊一些商務邏輯上的不同，另外一方面是資料量級上的改變，以及渠道、區服之間的聯絡、以及手遊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針對查詢、分頁我感覺有點重了。如果你們也需要使用類似的功能，請結合自己需要選擇即可。

大資料之實踐案例分析