【51CTO.com原創(chuàng)稿件】電子競技作為近年來競技體育項目中發(fā)展最迅猛的一個獨特分支，正在引起大量的社會關(guān)注和重視。和其他競技體育項目一樣，電子競技對于數(shù)據(jù)的分析和應(yīng)用有著獨特的要求。電子競技項目中，由于職業(yè)玩家和業(yè)余玩家的距離更近、業(yè)余玩家對于項目的參與度更高，使得其比賽數(shù)據(jù)的體量和數(shù)據(jù)分析的技術(shù)要求較之傳統(tǒng)體育有著幾何級數(shù)的增長。

本期《大咖·來了》欄目邀請了VPGame CTO 俞圓圓（Y3），進行了主題為《從游戲到科學(xué)：AI和電子競技》的分享，圍繞如何利用前沿技術(shù)對海量電競數(shù)據(jù)進行處理、存儲與分析展開。

FunData大數(shù)據(jù)系統(tǒng)

電競數(shù)據(jù)的量級遠(yuǎn)遠(yuǎn)大于傳統(tǒng)競技體育，所以VPGame是采用什么技術(shù)框架進行處理的呢？下面介紹一下FunData大數(shù)據(jù)系統(tǒng)以及其ETL層、接口層、數(shù)據(jù)處理層等部分的具體細(xì)節(jié)。如下圖，為通用FunData大數(shù)據(jù)系統(tǒng)架構(gòu)

FunData大數(shù)據(jù)系統(tǒng)分為四層：ETL層的作用是數(shù)據(jù)提取、清洗過濾和加載，接口層的作用是為前端產(chǎn)品應(yīng)用提供服務(wù)，數(shù)據(jù)處理層的作用是運用流計算、批計算等方式、對原始數(shù)據(jù)進行提取，最終得到可用性較高的總結(jié)性、概覽性數(shù)據(jù)，存儲層作用是對數(shù)據(jù)進行分級，選取不同的技術(shù)方案進行存儲。

FunData大數(shù)據(jù)系統(tǒng)之ETL范式

如下圖，為FunData ETL整體范式。

從廠商數(shù)據(jù)接口、直播視頻或錄像文件等渠道獲取到的數(shù)據(jù)源，通過外部消息隊列推送到據(jù)上報模塊，由內(nèi)部消息列隊通知不同的數(shù)據(jù)清洗和分析系統(tǒng)，將原始數(shù)據(jù)進行分門別類的歸檔和存儲，再次通過內(nèi)部消息隊列一步步將這些數(shù)據(jù)加載或存入到不同的底層存儲服務(wù)中。

FunData大數(shù)據(jù)系統(tǒng)之接口層

如下圖，為基于Kubernetes的彈性API系統(tǒng)架構(gòu)。

數(shù)據(jù)要如何運用呢？不管是服務(wù)于VPGame應(yīng)用，還是第三方應(yīng)用，都是通過基于Kubernetes搭建的API集群實現(xiàn)的。API系統(tǒng)架構(gòu)不是一成不變的，當(dāng)不斷深入或拓展到其他游戲IP時，會同步進行很多優(yōu)化，同一個游戲在不同階段會提供豐富度不同的API，當(dāng)然整個擴容的過程一定是平滑的。API系統(tǒng)架構(gòu)一定要具備彈性擴容能力，以便可以很好的應(yīng)對比賽過程中出現(xiàn)的API請求激增的情況。

FunData大數(shù)據(jù)系統(tǒng)之?dāng)?shù)據(jù)處理層

數(shù)據(jù)處理層的挑戰(zhàn)在于不同游戲，甚至同一個游戲的不同場景，數(shù)據(jù)邏輯都是不一樣的，所以如果是采用基于虛擬機的單體程序設(shè)計的話，對于彈性流量的適應(yīng)會存在很大困難。如下圖，為數(shù)據(jù)處理層的工作邏輯。

VPGame的數(shù)據(jù)處理邏輯構(gòu)建基于Serverless的彈性框架，對實時激增的數(shù)據(jù)進行處理和計算。于整個框架而言，對業(yè)務(wù)方的要求僅僅是編寫好業(yè)務(wù)邏輯即可，不必操心容量規(guī)劃方面的問題。

如下為VM系統(tǒng)與Serverless架構(gòu)對比圖。

VM系統(tǒng)與Serverless架構(gòu)存在明顯差異，主要體現(xiàn)在資源利用率、資源的虛擬化和計算能力等方面。對于VM系統(tǒng)，當(dāng)訪問量增加時需要聯(lián)系運維新增機器，恢復(fù)正常訪問量再聯(lián)系運維減少機器。對于Serverless架構(gòu)，可以依據(jù)實際請求量和機器狀況動態(tài)分布，統(tǒng)一由Vfunctions管理，不需要運維和業(yè)務(wù)方的介入。還有就是隨時間推移，游戲數(shù)據(jù)量會存在突刺，熱門時間（大賽/節(jié)假日）比賽數(shù)量激增的情況，原來基于VM的方式處理數(shù)據(jù)會導(dǎo)致大量數(shù)據(jù)處理任務(wù)堆積，系統(tǒng)壓力飆升，部分處理任務(wù)超時，不得不人工接入進行擴容。改為Serverless架構(gòu)，收到新的數(shù)據(jù)后，由Serverless調(diào)度器隨機分配一個Worker啟動對應(yīng)的算法容器進行數(shù)據(jù)處理與提取。

數(shù)據(jù)處理層還要面對的問題是，不同維度和層面的數(shù)據(jù)，對于實時性的要求不同，對于資源和時間的計算、處理，其要求也是不同的。這里就需要把處理模塊大致分為Hadoop (數(shù)據(jù)批處理）和Flink （數(shù)據(jù)流處理）。

批處理的數(shù)據(jù)一般是全局性的統(tǒng)計數(shù)據(jù)，如這場比賽出現(xiàn)多少英雄，他們的裝備、技能選擇等數(shù)據(jù)，這些數(shù)據(jù)相對深入，訪問頻次相對較低，故對及時性的相對要求也不高。但像單局比賽的基礎(chǔ)數(shù)據(jù)，就屬于熱點數(shù)據(jù)，需要比賽結(jié)束后第一時間進行處理，這里就需要采用流處理框架，保障收到數(shù)據(jù)后，秒級產(chǎn)出數(shù)據(jù)結(jié)果。以DOTA2單局比賽個人數(shù)據(jù)處理為例，詳見下圖。

通過消息隊列進來的數(shù)據(jù)信號會知道這些ID有新的比賽產(chǎn)生，接著Filter會把無效的比賽ID過濾掉之后，進一步對數(shù)據(jù)結(jié)構(gòu)做部分轉(zhuǎn)化，清理不需要的字段，將這些處理流寫入不同維度的算子，最后用Reduce算子做一些聚合。

綜上所述關(guān)于大數(shù)據(jù)系統(tǒng)的內(nèi)容為本次分享的第一部分，后面還有對FunData海量存儲和基于OCR與機器學(xué)習(xí)的數(shù)據(jù)識別和挖掘兩部分精彩內(nèi)容，請戳視頻：http://aix.51cto.com/activity/10021.html

【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】