大數(shù)據(jù)之實(shí)踐案例分析

前言

公司由頁游轉(zhuǎn)手游，公司的數(shù)據(jù)分析需要針對(duì)手游進(jìn)行設(shè)計(jì)，所以原來的那一套針對(duì)頁游的數(shù)據(jù)分析框架就顯得不是很合適了，一方面在于手游和頁游一些業(yè)務(wù)邏輯上的不同，另外一方面是數(shù)據(jù)量級(jí)上的改變，以及渠道、區(qū)服之間的聯(lián)系、以及手游BI系統(tǒng)的渠道區(qū)服交叉查詢。使得原本從4399游戲那一套針對(duì)頁游而來的框架就顯得有些吃力。這里分析的就是頁游到手游這個(gè)過程中，針對(duì)大數(shù)據(jù)分析所做的調(diào)整工作，以及在此之間的分析案例。

頁游合作場(chǎng)景

頁游階段，如果一款頁游準(zhǔn)備推上某個(gè)平臺(tái)，那么需要與該平臺(tái)進(jìn)行對(duì)接，在該平臺(tái)上進(jìn)行考試，達(dá)到一定分?jǐn)?shù)，平臺(tái)才可以提供資源進(jìn)行上線擴(kuò)服。那么如果想上另外一個(gè)平臺(tái)，那么需要跟另外一個(gè)平臺(tái)進(jìn)行相同的流程。目前頁游公司與平臺(tái)方的合作方式大部分如此。那么其實(shí)游戲，平臺(tái)與區(qū)服就都是一一對(duì)應(yīng)的，一個(gè)平臺(tái)可開設(shè)多個(gè)區(qū)服，且一個(gè)區(qū)服只屬于一個(gè)平臺(tái)（跟手游不一樣）。

頁游數(shù)據(jù)采集分析過程

公司隨著游戲開服，需要查看游戲的數(shù)分析，比如說留存流失情況，付費(fèi)情況，活躍用戶情況，崩潰情況等等，這就是很多BI系統(tǒng)中的一個(gè)子系統(tǒng)（數(shù)據(jù)分析系統(tǒng)：用于用戶行為分析、產(chǎn)品質(zhì)量監(jiān)控、活動(dòng)參與度統(tǒng)計(jì)等等）。那么這一流程大致如下圖：

分析：
1.平臺(tái)與平臺(tái)之間的數(shù)據(jù)是隔離的
2.在使用ETL處理項(xiàng)目組數(shù)據(jù)時(shí)保持原來的游戲平臺(tái)-區(qū)服分庫，如果針對(duì)一些特殊的表，可以進(jìn)行拉取匯總表，比如說login表，付費(fèi)表。
3.編寫統(tǒng)計(jì)腳本，放到Linux定時(shí)任務(wù)中，統(tǒng)計(jì)結(jié)果放到結(jié)果庫，結(jié)果庫按照平臺(tái)分庫。
4.根據(jù)BI系統(tǒng)數(shù)據(jù)分析從結(jié)果庫中的統(tǒng)計(jì)結(jié)果，展示相關(guān)指標(biāo)數(shù)據(jù)的圖表。
5.這個(gè)過程中會(huì)有少量實(shí)時(shí)數(shù)據(jù)的分析需求，這個(gè)就需要在BI系統(tǒng)中直接去連接項(xiàng)目組數(shù)或者通過短時(shí)間定時(shí)任務(wù)進(jìn)行拉取到結(jié)果庫。

手游數(shù)據(jù)采集分析過程

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

分析：
1.渠道與服直接是多對(duì)多的關(guān)系
2.etl拉取清洗時(shí)依然根據(jù)渠道-區(qū)服進(jìn)行分庫
3.編寫統(tǒng)計(jì)腳本，統(tǒng)計(jì)結(jié)果保存到結(jié)果庫，一個(gè)游戲只有一個(gè)結(jié)果庫（包含所有渠道，所有區(qū)服）
4.因?yàn)橹挥幸粋€(gè)結(jié)果庫，所以需要考慮分表，避免單表過大查詢慢。分析如下：
假設(shè)50個(gè)渠道，100個(gè)區(qū)服，單表維度不超過5個(gè)，根據(jù)經(jīng)驗(yàn)估算[10W-15W]/天增量，那么按照季度進(jìn)行分表，每個(gè)子表數(shù)據(jù)量在900W到1350W之間，另外針對(duì)一些記錄相對(duì)活躍的統(tǒng)計(jì)表，可能需要按月分表或者更細(xì)?？偠灾褪潜M可能的減少單個(gè)表的大小，但是這個(gè)會(huì)帶來一個(gè)問題就是在BI系統(tǒng)中如何進(jìn)行查詢、分頁呀等等問題，不過這個(gè)問題已經(jīng)有相應(yīng)的組件幫我們完成，比如說：阿里的mycat、當(dāng)當(dāng)網(wǎng)的Sharding-JDBC，我計(jì)劃使用Sharding-JDBC，因?yàn)閙ycat針對(duì)查詢、分頁我感覺有點(diǎn)重了。如果你們也需要使用類似的功能，請(qǐng)結(jié)合自己需要選擇即可。