編者按：
一直以來，中國網(wǎng)游在世界上都處于舉足輕重的地位。從最早的端游到頁游再到手游，不僅市場用戶 爆發(fā)式增長，近15年來網(wǎng)游技術(shù)的發(fā)展也是無比迅速。和單機(jī)游戲不同，網(wǎng)游除了游戲制作本身以外還牽涉到服務(wù)器端，再好的游戲如果出現(xiàn)鏈接、延遲等問題時(shí) 也會(huì)造成巨大損失，這時(shí)候游戲運(yùn)維便發(fā)揮了舉足輕重的作用。中國網(wǎng)游的發(fā)展史，其實(shí)也是游戲運(yùn)維的變革史，今天便由經(jīng)典武俠手游《大掌門》運(yùn)維掌門人吳啟 超來向我們講述，進(jìn)入游戲領(lǐng)域10余年來的風(fēng)風(fēng)雨雨。
有服務(wù)器的地方就有運(yùn)維
如今我們說到游戲，可能想到的是火爆異常的VR，辦公室里一言不合帶上眼鏡就地開打；亦或是剛剛虐了李世石的AlphaGo，揚(yáng)言要挑戰(zhàn)《星際爭霸2》“教主”Flash。然而，除去這些還有一個(gè)游戲行業(yè)不可避免的潮流正在發(fā)生，那便是網(wǎng)絡(luò)化。
這里說的不止是網(wǎng)游，前不久育碧旗下網(wǎng)游大作《全境封鎖》上線時(shí)鬧出個(gè)小笑話：由于很多國內(nèi)玩 家下載之前沒注意是網(wǎng)游，下意識(shí)的以為育碧的游戲肯定是單機(jī)，好不容易下完之后才發(fā)現(xiàn)玩不上，進(jìn)而發(fā)生了不少的騷動(dòng)。這不是***個(gè)發(fā)生這種情況的傳統(tǒng)游戲 廠商，肯定也不是***一個(gè)，很多有名的游戲公司都在做類似的嘗試，Popcap的《植物大戰(zhàn)僵尸：花園戰(zhàn)爭》系列，暴雪的《暗黑3》等，甚至那些還有單機(jī) 成分的大作也早就開始網(wǎng)絡(luò)化：大名鼎鼎的《GTA5》、FPS風(fēng)向標(biāo)《使命召喚》系列和《戰(zhàn)地》系列，網(wǎng)絡(luò)聯(lián)機(jī)部分的比重也在一年一年的增加。
網(wǎng)絡(luò)聯(lián)機(jī)，意味著玩家需要登錄官方服務(wù)器，“有人的地方就有江湖”，這句話說的不僅是網(wǎng)游里的恩怨情仇，還包括游戲外的種種：“有服務(wù)器的地方就有運(yùn)維。”這便是今天我們要說的話題——游戲運(yùn)維。
游戲運(yùn)維編年史
1，石器時(shí)代：端游
想要了解如今的游戲運(yùn)維，不得不從早期的端游運(yùn)維開始說起。對于08年入行端游，11年經(jīng)歷過頁游***14年全面接觸手游的吳啟超來說，這幾年的游戲運(yùn)維經(jīng)歷讓他深切感受到運(yùn)維思路的巨大轉(zhuǎn)變。
1.1 端游的運(yùn)維工種：IDC運(yùn)維、系統(tǒng)型運(yùn)維、網(wǎng)絡(luò)運(yùn)維、業(yè)務(wù)型運(yùn)維、運(yùn)維值班等。各個(gè)工種分工各有側(cè)重。
IDC運(yùn)維：裝機(jī)、換配件、扛著2U的服務(wù)器全國各個(gè)機(jī)房來回跑。
系統(tǒng)運(yùn)維：安裝各種軟件，調(diào)試各種不兼容的軟件，在各種版本的Linux、Windows上。
網(wǎng)絡(luò)運(yùn)維：二層交換、三層交換、四層交換，還要區(qū)分華為、思科。
業(yè)務(wù)運(yùn)維：24點(diǎn)維護(hù)，零晨2點(diǎn)維護(hù)，零晨5點(diǎn)維護(hù)，早上7點(diǎn)維護(hù)……
運(yùn)維值班：0點(diǎn)盯著屏幕打電話，1點(diǎn)盯著屏幕打電話，2點(diǎn)盯著屏幕打電話……
運(yùn)維開發(fā)：寫著各種的邏輯，因?yàn)闃I(yè)務(wù)、網(wǎng)絡(luò)環(huán)境、BUG、剛剛幫忙扛完服務(wù)器。
1.2 端游運(yùn)維業(yè)務(wù)范圍：在端游時(shí)代，大部分游戲公司都是自主做各種業(yè)務(wù)環(huán)境，做各種游戲業(yè)務(wù)需要的各種環(huán)境。
資產(chǎn)管理：服務(wù)器、交換機(jī)、各種服務(wù)分布位置，端口等。
下載服務(wù)器：搭建BT集群，做種子、分發(fā)，供玩家下載游戲客戶端使用。
靜態(tài)緩存服務(wù)器：squid + apache|nginx
郵件服務(wù)器：postfix +sasl +ssl 收發(fā)服務(wù)、反垃圾郵件服務(wù)。
網(wǎng)絡(luò)質(zhì)量監(jiān)控：somkingping各個(gè)機(jī)房的交換，各個(gè)安放點(diǎn)服務(wù)器。
配置管理：nginx 、apache、lighttpd、MySQL。
批量管理：ssh公鑰/私鑰 。
監(jiān)控管理：nagios、catcai 然后是c|perl|python|shell +rrdtool各種業(yè)務(wù)監(jiān)控圖。
1.3 端游游戲服務(wù)器架構(gòu)：一般來講都是以一組服務(wù)器集群為一個(gè)區(qū)服單位，單機(jī)上的進(jìn)程提供不同的服務(wù)。
傳統(tǒng)運(yùn)維，任務(wù)道遠(yuǎn)，正因?yàn)橛羞^去那些年的翻譯文檔，兼顧整合方案，以及大批分享技術(shù)的前輩、社區(qū)，踩著前輩一步一個(gè)坑的走過來，才能有今天的運(yùn)維的局面。
2，青銅時(shí)代：頁游
在2011-2013年左右的頁游運(yùn)維，游戲市場處于探索期，其實(shí)運(yùn)維也處于探索期。端游時(shí)代 每個(gè)新服都要經(jīng)歷上架、裝系統(tǒng)，裝服務(wù)的過程，一般一到兩周可以上線一個(gè)區(qū)服，對于端游高粘性低流動(dòng)的特性來說可能還好，但是當(dāng)頁游出現(xiàn)時(shí)，轉(zhuǎn)變給運(yùn)維帶 來的沖擊無法估量。頁游時(shí)代1天開100多個(gè)新服的概念，是傳統(tǒng)端游運(yùn)維所不能理解的。當(dāng)時(shí)的運(yùn)維認(rèn)為頁游就是把所有服務(wù)器實(shí)現(xiàn)自動(dòng)部署服務(wù)，同時(shí)搭配運(yùn) 維自動(dòng)部服工具就可以了。但事實(shí)上如果在開服時(shí)一組一組的使用物理服務(wù)器，開服速度根本跟不上，資源浪費(fèi)還非常巨大，兩周后用戶留存率僅剩5%-7%。成 本巨大虧空，急需技術(shù)轉(zhuǎn)型，這個(gè)時(shí)間點(diǎn)上出現(xiàn)了兩種概念影響了以后的手游以及云的發(fā)展。
1. 虛擬化技術(shù)
在2010年11月份左右， kvm出現(xiàn)在RHEL6中，去掉了RHEL 5.X系列中集成的Xen。正是這一次虛擬化技術(shù)的轉(zhuǎn)型，而且當(dāng)時(shí)市場的需要，在2011年-2012年掀起了一場私有云建設(shè)的風(fēng)潮。在實(shí)踐過程中，優(yōu)點(diǎn) 很多，但暴露的缺點(diǎn)也不少。在端游占主要市場的情況下，實(shí)踐過程中表現(xiàn)出來的不適尤其明顯。
a. 虛擬機(jī)時(shí)鐘不準(zhǔn)
b. 虛擬機(jī)網(wǎng)卡，超負(fù)荷down、丟包
c. 多虛擬機(jī)間爭搶cpu、內(nèi)存
d. 多虛擬機(jī)間的安全訪問，虛擬機(jī)與物理機(jī)間的安全管控
e. 對于關(guān)系型數(shù)據(jù)庫磁盤讀寫慢問題突出。
f. 等等
以上幾點(diǎn)隨著時(shí)間的推移有的已經(jīng)然后解決，有的換上了代替方案。時(shí)至今日，端游在單純的虛擬云上部署仍是問題，但是隨著物理、虛掩混合云出現(xiàn)，這個(gè)局面應(yīng)該可以被打破。
2. 社交化的頁游
社區(qū)化的頁游戲，為什么這樣說呢，因?yàn)楫?dāng)時(shí)更多的頁游信托社區(qū)入口，導(dǎo)入用戶流量，當(dāng)時(shí)最火的 應(yīng)該是人人網(wǎng)（校內(nèi)網(wǎng)）的農(nóng)場偷菜。然后是DZ論壇一堆農(nóng)場插件襲卷全國，當(dāng)然這一切都是為了增加用戶粘稠度。但是也影響了頁游技術(shù)的選型，當(dāng)時(shí)基本上大 家不約而的選用了于社區(qū)相同的LAMP的技術(shù)，從而降低開發(fā)成本及接入成本。當(dāng)然現(xiàn)使用JAVA SSH2架構(gòu)的頁游也有。除技術(shù)選型外，同時(shí)還帶入了另一個(gè)概念：聯(lián)運(yùn)。聯(lián)運(yùn)這個(gè)概念在頁游時(shí)代對于端游運(yùn)維就像一個(gè)惡夢，不同區(qū)服要隨時(shí)跨服站，不同區(qū) 服要隨時(shí)可以合區(qū)，所有數(shù)據(jù)不再是以物理服務(wù)器為單位，而是要逐條打標(biāo)簽，再也看不到賬號，只能拿著一串長長的KEY，四處兌換，然后拿著不知道所謂的表 標(biāo)問第三方…….
在這個(gè)時(shí)期，是運(yùn)維開發(fā)的爆發(fā)年，隨著虛擬化技術(shù)的推廣，越來的越多的運(yùn)維開始接觸自動(dòng)化運(yùn)維的概念，開始了自動(dòng)化運(yùn)維的奮斗之路，開始了以項(xiàng)目管理的角度看待運(yùn)維腳本開發(fā)。
3，黃金時(shí)代：手游
隨著私有云轉(zhuǎn)為公有云、云時(shí)代推動(dòng)著云計(jì)算以及移動(dòng)互聯(lián)網(wǎng)的發(fā)展，網(wǎng)游行業(yè)慢慢進(jìn)入了手游黃金時(shí)代，云時(shí)代的變革不僅挑戰(zhàn)了整個(gè)游戲行業(yè)，也挑戰(zhàn)了游戲運(yùn)維。
3.1 手游的運(yùn)維工種：系統(tǒng)型運(yùn)維，業(yè)務(wù)型運(yùn)維。
3.2 手游運(yùn)維業(yè)務(wù)范圍：阿里云、 亞馬遜 、UCloud、 藍(lán)汛CDN、 聽云監(jiān)控。
3.3 手游游戲服務(wù)器架構(gòu)：一般來講都是以一組服務(wù)器集群為一個(gè)平臺(tái)單位，不同的集群提供不同的服務(wù)。
手游的架構(gòu)理念是提供一組虛擬服務(wù)器，當(dāng)短連接的時(shí)候，每開一組服，將玩家引導(dǎo)到Web集群， 隨后被分配到不同的MongoDB，數(shù)據(jù)緩存用在Redis。當(dāng)***個(gè)服務(wù)器玩家請求DB時(shí)，會(huì)落到Mongo1上；當(dāng)開第二個(gè)服的時(shí)候，還是將玩家引導(dǎo) 到Mongo1上；以此類推直到運(yùn)維發(fā)現(xiàn)壓力累積到一定程度時(shí)，便會(huì)新開一組MongoDB，Web集群也是如此但只有性能不夠時(shí)才會(huì)添加，一般情況下， 每50個(gè)新服可能需要添加1個(gè)MongoDB。這便實(shí)現(xiàn)并解釋了當(dāng)時(shí)在頁游里希望實(shí)現(xiàn)的快速開服方法。
到此為止我們已經(jīng)回顧了一遍游戲運(yùn)維從端游到頁游再到手游的演變過程，不難看出，手游對于區(qū)服 的架構(gòu)概念不同于端游：端游認(rèn)為一個(gè)物理集群是一個(gè)服，而手游認(rèn)為一個(gè)Web請求落到相應(yīng)的數(shù)據(jù)庫上就是一個(gè)服。這樣的好處是開服合服都簡單，如果前五十 組服務(wù)器需要合并，實(shí)現(xiàn)起來很容易，因?yàn)橥粋€(gè)DB的數(shù)據(jù)是互通的，所以只需發(fā)一個(gè)公告，服務(wù)器加標(biāo)識(shí)即可，不需要進(jìn)行物理操作也不需要數(shù)據(jù)遷移。
游戲運(yùn)維***指南
說完了游戲運(yùn)維的歷史，我們要開始今天的重頭戲，如何做好游戲運(yùn)維？這里就用吳啟超的一個(gè)冷笑 話作為開始：運(yùn)維為什么存在？a，有服務(wù)器；b，因?yàn)檠邪l(fā)忙不過來。不管是笑沒笑，運(yùn)維確實(shí)因?yàn)樯厦鎯蓚€(gè)原因才會(huì)誕生的。那么回到正題，想成為玩轉(zhuǎn)上千服 務(wù)器的游戲運(yùn)維應(yīng)該怎么樣做呢？系統(tǒng)部運(yùn)維構(gòu)建大致如下圖：
1，構(gòu)建CMDB
21世紀(jì)什么最重要？信息最重要！運(yùn)維所需信息要涉及：機(jī)房、物理服務(wù)器、虛擬機(jī)、交換機(jī)、網(wǎng) 絡(luò)、承載業(yè)務(wù)、業(yè)務(wù)配置、承載服務(wù)進(jìn)程、端口等信息。不管是自己采購還是購買云服務(wù)，物理服務(wù)器和虛擬服務(wù)器都做為資產(chǎn)存在，在采購后錄入相關(guān)的資產(chǎn)管 理，給它打上標(biāo)簽，屬于哪個(gè)游戲，哪個(gè)平臺(tái)，這樣不同游戲平臺(tái)間就不能混用服務(wù)器了。然后，是再給不同的服務(wù)器標(biāo)識(shí)它承擔(dān)的業(yè)務(wù)角色，比如它是 MongoDB，我們需要打上的標(biāo)簽會(huì)是大掌門-APPSTORE-MongoDB-主庫-90000端口-***組服務(wù)。這樣一個(gè)基礎(chǔ)信息錄入就完成了。
這樣的信息只要是用來將來批量化部署、管理服務(wù)器使用，以及當(dāng)出現(xiàn)故障時(shí)，運(yùn)維可以很方便的查詢相當(dāng)?shù)姆?wù)器以及服務(wù)信息。但是數(shù)據(jù)的及時(shí)性、準(zhǔn)確性、可檢查是一個(gè)難點(diǎn)。
2，集中批量化管理
CMDB不是TXT文件，而是要變成EXE文件。運(yùn)維在面臨大量服務(wù)器的情況下，批量化工具的 出現(xiàn)成為必須的結(jié)果，在日常的工作當(dāng)中需要把其流程固化下來，為完成批量化安裝、管理打下基礎(chǔ)。大掌門喜歡使用 ssh sshpass paramiko libssh2這些基礎(chǔ)的技術(shù)做批量管理。原因是不用安裝簡單、穩(wěn)定、安全、可控。當(dāng)然吳啟超也表示推薦大家使用在市面上流程行puppet、 Ansible、SaltStack等技術(shù)，為什么？簡單、簡單、簡單！下圖就是在做自動(dòng)化半自動(dòng)化運(yùn)維過程中的模型。
批量管理的難點(diǎn)在于：
a. 命令的并發(fā)執(zhí)行，要控制各點(diǎn)的超時(shí)時(shí)間
b. 執(zhí)行過程中，不同功能的不同權(quán)限要求
c. 數(shù)據(jù)通信安全的保證，以及能夠正常解析數(shù)據(jù)指令
d. 人員賬號權(quán)限管理，權(quán)限分發(fā)及回收
e. 物理服務(wù)器、云服務(wù)器統(tǒng)一化安裝及老項(xiàng)目改造
f. 網(wǎng)絡(luò)質(zhì)量不可靠的情況下，執(zhí)行不完整的情況下業(yè)務(wù)功能回滾。
3，性能與業(yè)務(wù)監(jiān)控
應(yīng)用性能監(jiān)控
1、每天都會(huì)對服務(wù)器進(jìn)行上線，升級等操作，每款游戲在一個(gè)平臺(tái)的集群數(shù)在幾十個(gè)到幾百個(gè)不等 （根據(jù)平臺(tái)大?。?。因此每天維護(hù)和升級服務(wù)器壓力極大，服務(wù)器異?；蝽憫?yīng)慢等問題的發(fā)生會(huì)給用戶體驗(yàn)帶來傷害。 這樣的隱患在于一旦發(fā)生游戲關(guān)服之后就必須對玩家進(jìn)行游戲中貨幣和元寶的賠償，平均每個(gè)玩家補(bǔ)償?shù)脑獙氈辽僭?元以上，游戲幣和各類游戲道具若干，以此類 推由于服務(wù)器故障造成的損失可想而知。
2、大掌門使用了聽云Server，能夠?qū)Ψ?wù)器響應(yīng)慢和不可用進(jìn)行定位，查看慢應(yīng)用追蹤和Web應(yīng)用過程功能，能夠?qū)崟r(shí)定位消耗資源***的代碼和語句，這樣就能幫助實(shí)時(shí)進(jìn)行有針對性的調(diào)整和優(yōu)化，并且可以快速定位問題時(shí)間，最快能到分鐘級別。
3、發(fā)生高并發(fā)、服務(wù)器壓力激增的情況時(shí)，平時(shí)運(yùn)行正常的服務(wù)器異常概率大幅增加，日?？赡艿?性能瓶頸點(diǎn)會(huì)被成倍放大，這就需要實(shí)時(shí)定位和解決性能瓶頸點(diǎn)，和提前進(jìn)行預(yù)防改善。一般來說，傳統(tǒng)日志收集方式耗時(shí)耗力，效果非常不好，大掌門用了聽云 Server后，可以進(jìn)行1分鐘級定位能迅速有效發(fā)現(xiàn)瓶頸點(diǎn)。同時(shí)還結(jié)合了聽云Network的壓測功能，能夠在服務(wù)器上線前提前發(fā)現(xiàn)到高壓力下的瓶頸 點(diǎn)，提前預(yù)防，避免由于高并發(fā)出現(xiàn)的服務(wù)器瓶頸
4、還有一種性能情況需要提前預(yù)防，游戲公司盈利在于玩家的充值，對于官網(wǎng)上從登陸到充值全流 程的成功率業(yè)務(wù)部門極其關(guān)注，玩家點(diǎn)擊跳轉(zhuǎn)的失敗會(huì)直接導(dǎo)致充值付費(fèi)用戶的轉(zhuǎn)化率。對此，大掌門通過聽云Network的事務(wù)流程功能能夠?qū)崟r(shí)對事物流程 進(jìn)行警報(bào)，幫助業(yè)務(wù)部門提升用戶充值的轉(zhuǎn)化率
業(yè)務(wù)監(jiān)控
除了性能和硬件監(jiān)控之外，對于游戲業(yè)務(wù)運(yùn)轉(zhuǎn)是否正常也需要建立一套標(biāo)準(zhǔn)去評判。
對此，大掌門開發(fā)了一套適用于全公司所有的游戲的統(tǒng)一登陸、充值、交易平臺(tái)，解決了前端的 SDK接入的問題，一個(gè)所有游戲或第三方的API接口統(tǒng)一接入的平臺(tái)。在做業(yè)務(wù)型監(jiān)控時(shí)，運(yùn)維會(huì)要求后端開發(fā)人員寫一個(gè)特定賬號，在訪問現(xiàn)有系統(tǒng)時(shí)，會(huì)完 整的走一遍業(yè)務(wù)流，這樣就可以看到需要的業(yè)務(wù)數(shù)字。
4，數(shù)據(jù)倉庫搭建
上圖為大掌門數(shù)據(jù)倉庫的結(jié)構(gòu)圖，由于數(shù)據(jù)倉庫搭建的話題比較大，只是簡單的從數(shù)據(jù)集市的角度來聊聊，DM指的是數(shù)據(jù)集市。由于數(shù)據(jù)集市需要面對不同的人群，因此在數(shù)據(jù)倉庫中需要建立不同的數(shù)據(jù)集市以面對各方的查詢需求，進(jìn)而對數(shù)據(jù)按照業(yè)務(wù)類型進(jìn)行分類。
1、財(cái)務(wù)：關(guān)心月度充值數(shù)據(jù)
2、商務(wù)：關(guān)心渠道結(jié)算數(shù)據(jù)
3、運(yùn)營：關(guān)心用戶登陸量、轉(zhuǎn)化率、留存率、平臺(tái)充值額
4、產(chǎn)品：關(guān)心功能熱度、用戶體驗(yàn)
5、客服：關(guān)心所有數(shù)據(jù)及玩家屬性
對于數(shù)據(jù)方面，運(yùn)維的壓力來自于需要貫穿及掌握所有的數(shù)據(jù)，并且為所有部門服務(wù)。簡單的以下圖的ETL為例：
數(shù)據(jù)對于運(yùn)維的痛點(diǎn)：
1、日志切割工作誰做？研發(fā)還是運(yùn)維。日志切割按什么規(guī)則？大小還是日期？
2、使用什么工具進(jìn)行日志收集？scribe 還是flume 還是 sls？
3、數(shù)據(jù)的準(zhǔn)確性誰來保證？日志內(nèi)容不對、切割不對、傳輸丟失、入hadoop過濾
4、數(shù)據(jù)ETL過程監(jiān)控，如果出現(xiàn)數(shù)據(jù)丟失怎么辦？
5、數(shù)據(jù)采集怎么樣盡可能的保證并發(fā)的采集，縮短時(shí)間。
6、數(shù)據(jù)的出現(xiàn)丟失或錯(cuò)誤，整體數(shù)據(jù)回滾。誰來保證？怎么保證？
7、大量數(shù)據(jù)下，核對數(shù)據(jù)丟失情況怎么樣核對？用什么方法？
那大掌門又是如何解決這些問題的呢：
1、 將數(shù)據(jù)日志進(jìn)行切割（按照業(yè)務(wù)打包日志）并合理命名。比如A登陸日志，B充值日志，C消費(fèi)日志。分門別類進(jìn)行打包后，對數(shù)據(jù)每5分鐘切割1次，并生成md5包。
2、 按照劃分IDC Region。原來從本機(jī)向外傳輸數(shù)據(jù)會(huì)占用大量帶寬，對于本身CPU的消耗大的話都會(huì)影響游戲的運(yùn)行?，F(xiàn)在按照IDC region做出劃分，每個(gè)區(qū)域中會(huì)有1-3個(gè)中心存儲(chǔ)服務(wù)器。將切割下來的數(shù)據(jù)放到中心存儲(chǔ)上，劃分成Aip1、Aip2、Aip3等md5壓縮包，此 處無需做合并（原因見3）。
3、 建立下載任務(wù)。建立好任務(wù)列表后，對每5分鐘的壓縮包進(jìn)行下載?？紤]到如果上面的步驟做了合并的話就可能會(huì)產(chǎn)生在傳輸?shù)臅r(shí)候丟數(shù)據(jù)卻無法確定的情況，因此2步驟無需對數(shù)據(jù)進(jìn)行合并。
4、將下載后的任務(wù)加到Hive數(shù)據(jù)倉庫里。將當(dāng)天的數(shù)據(jù)放到MySQL中，之前的數(shù)據(jù)放到 Hive里。當(dāng)運(yùn)營提出數(shù)據(jù)需求時(shí)便可以到Hive中下載數(shù)據(jù)。即使數(shù)據(jù)出現(xiàn)錯(cuò)誤，按照上面建立的每5分鐘的任務(wù)列表也可以重新以規(guī)定時(shí)間點(diǎn)將數(shù)據(jù)壓縮包 重新拉回來。并且該流程可以按照正向、反向雙向進(jìn)行。
采用5分鐘壓縮包的另外一個(gè)原因在于每臺(tái)服務(wù)器每天產(chǎn)生業(yè)務(wù)日志大概有5-6G的數(shù)據(jù)，分到5分鐘后，切割完每個(gè)文件就是20M－30M，壓縮后只占用很少的空間。這樣就解決了占用大量帶寬的問題。
5、數(shù)據(jù)傳輸后需將數(shù)據(jù)放到數(shù)據(jù)倉庫（DW）中，數(shù)據(jù)下載完畢后會(huì)根據(jù)文件進(jìn)行存儲(chǔ)，當(dāng)天的數(shù) 據(jù)按照5分鐘1個(gè)壓縮包進(jìn)入MySQL，MySQL則進(jìn)入當(dāng)天的查詢。在數(shù)據(jù)倉庫中，數(shù)據(jù)包按游戲及平臺(tái)進(jìn)行分類，這種格局的安排為了在并發(fā)時(shí)更好的運(yùn) 行。由于游戲與游戲之間是隔離的，因此按照這種模式是為了保證數(shù)據(jù)進(jìn)行順利并發(fā)。
