電競(jìng)大數(shù)據(jù)時(shí)代，數(shù)據(jù)對(duì)比賽的觀賞性和專業(yè)性都起到了至關(guān)重要的作用。同樣的，這也對(duì)電競(jìng)數(shù)據(jù)的豐富性與實(shí)時(shí)性提出了越來(lái)越高的要求。

 

 

電競(jìng)數(shù)據(jù)的豐富性從受眾角度來(lái)看，可分為賽事、戰(zhàn)隊(duì)和玩家數(shù)據(jù);從游戲角度來(lái)看，維度可由英雄、戰(zhàn)斗、道具以及技能等組成;電競(jìng)數(shù)據(jù)的實(shí)時(shí)性包括賽前兩支戰(zhàn)隊(duì)的歷史交戰(zhàn)記錄、賽中的實(shí)時(shí)比分、勝率預(yù)測(cè)、賽后比賽分析和英雄對(duì)比等。

因此多維度的數(shù)據(jù)支持，TB到PB級(jí)別的海量數(shù)據(jù)存儲(chǔ)與實(shí)時(shí)分析都對(duì)底層系統(tǒng)的架構(gòu)設(shè)計(jì)有著更高的要求，亦帶來(lái)了更嚴(yán)峻的挑戰(zhàn)。

本文將介紹電競(jìng)數(shù)據(jù)平臺(tái)FunData架構(gòu)演進(jìn)中的設(shè)計(jì)思路及相關(guān)技術(shù)，包括大數(shù)據(jù)流處理方案、結(jié)構(gòu)化存儲(chǔ)轉(zhuǎn)非結(jié)構(gòu)化存儲(chǔ)方案和數(shù)據(jù)API服務(wù)設(shè)計(jì)等。在其v1.0 beta版本中，F(xiàn)unData為頂級(jí)MOBA類游戲DOTA2(由Valve公司出品)提供了相關(guān)的數(shù)據(jù)接口。

1.0架構(gòu)

項(xiàng)目發(fā)展初期，依照MVP理論(最小化可行產(chǎn)品)，我們迅速推出FunData的第一版系統(tǒng)(架構(gòu)圖如圖1)。系統(tǒng)主要有兩個(gè)模塊：Master與Slave。

 

 

圖1 1.0ETL架構(gòu)圖

Master模塊功能如下：

• 定時(shí)調(diào)用Steam接口獲取比賽ID與基礎(chǔ)信息;

• 通過(guò)In-Memory的消息隊(duì)列分發(fā)比賽分析任務(wù)到Slave節(jié)點(diǎn);

• 記錄比賽分析進(jìn)度，并探測(cè)各Slave節(jié)點(diǎn)狀態(tài)。

Slave模塊功能如下：

• 監(jiān)聽(tīng)隊(duì)列消息并獲取任務(wù)，任務(wù)主要為錄像分析，錄像分析參考GitHub項(xiàng)目Clarity與Manta;

• 分析數(shù)據(jù)入庫(kù)。

系統(tǒng)上線初期運(yùn)行相對(duì)穩(wěn)定，各維度的數(shù)據(jù)都可快速拉取。然而隨著數(shù)據(jù)量的增多，數(shù)據(jù)與系統(tǒng)的可維護(hù)性問(wèn)題卻日益突出：

• 新增數(shù)據(jù)字段需要重新構(gòu)建DB索引，數(shù)據(jù)表行數(shù)過(guò)億構(gòu)建時(shí)間太長(zhǎng)且造成長(zhǎng)時(shí)間鎖表;

• 系統(tǒng)耦合度高，不易于維護(hù)，Master節(jié)點(diǎn)的更新重啟后，Slave無(wú)重連機(jī)制需要全部重啟;同時(shí)In-Memory消息隊(duì)列有丟消息的風(fēng)險(xiǎn);

• 系統(tǒng)可擴(kuò)展性低，Slave節(jié)點(diǎn)擴(kuò)容時(shí)需要頻繁的制作虛擬機(jī)鏡像，配置無(wú)統(tǒng)一管理，維護(hù)成本高;

• DB為主從模式且存儲(chǔ)空間有限，導(dǎo)致數(shù)據(jù)API層需要定制邏輯來(lái)分庫(kù)讀取數(shù)據(jù)做聚合分析;

• 節(jié)點(diǎn)粒度大，Slave可能承載的多個(gè)分析任務(wù)，故障時(shí)影響面大。

在開始2.0架構(gòu)設(shè)計(jì)與改造前，我們嘗試使用冷存儲(chǔ)方法，通過(guò)遷移數(shù)據(jù)的方式來(lái)減輕系統(tǒng)壓力(架構(gòu)設(shè)計(jì)如圖2)。由于數(shù)據(jù)表數(shù)據(jù)量太大，并發(fā)多個(gè)數(shù)據(jù)遷移任務(wù)需要大量時(shí)間，清理數(shù)據(jù)的過(guò)程同樣會(huì)觸發(fā)重新構(gòu)建索引，方案的上線并沒(méi)有根本性地解決問(wèn)題。

 

 

圖2 冷存儲(chǔ)方案

2.0架構(gòu)

吸取1.0系統(tǒng)的經(jīng)驗(yàn)，在2.0架構(gòu)設(shè)計(jì)(架構(gòu)圖如圖3)中，我們從維護(hù)性、擴(kuò)展性和穩(wěn)定性三個(gè)方面來(lái)考慮新數(shù)據(jù)系統(tǒng)架構(gòu)應(yīng)該具備的基本特性：

• 數(shù)據(jù)處理任務(wù)粒度細(xì)化，且支持高并發(fā)處理(全球一天DOTA2比賽的場(chǎng)次在120萬(wàn)場(chǎng)，錄像分析相對(duì)耗時(shí)，串行處理會(huì)導(dǎo)致任務(wù)堆積嚴(yán)重);

• 數(shù)據(jù)分布式存儲(chǔ);

• 系統(tǒng)解耦，各節(jié)點(diǎn)可優(yōu)雅重啟與更新。

 

 

圖3 2.0ETL總架構(gòu)圖

2.0系統(tǒng)選擇Google Cloud Platform來(lái)構(gòu)建整個(gè)數(shù)據(jù)ETL系統(tǒng)，利用PubSub(類似Kafka)作為消息總線，任務(wù)被細(xì)化成多個(gè)Topic進(jìn)行監(jiān)聽(tīng)，由不同的Worker進(jìn)行處理。這樣一方面減少了不同任務(wù)的耦合度，防止一個(gè)任務(wù)處理異常導(dǎo)致其他任務(wù)中斷;另一方面，任務(wù)基于消息總線傳遞，不同的數(shù)據(jù)任務(wù)擴(kuò)展性變得更好，性能不足時(shí)可快速橫向擴(kuò)展。

任務(wù)粒度細(xì)化

從任務(wù)粒度上看(如圖3)，數(shù)據(jù)處理分為基礎(chǔ)數(shù)據(jù)處理與高階數(shù)據(jù)處理兩部分。基礎(chǔ)數(shù)據(jù)，即比賽的詳情信息(KDA、傷害與補(bǔ)刀等數(shù)據(jù))和錄像分析數(shù)據(jù)(Roshan擊殺數(shù)據(jù)、傷害類型與英雄分路熱力圖等數(shù)據(jù))由Supervisor獲取Steam數(shù)據(jù)觸發(fā)，經(jīng)過(guò)worker的清理后存入Google Bigtable;高階數(shù)據(jù)，即多維度的統(tǒng)計(jì)數(shù)據(jù)(如英雄、道具和團(tuán)戰(zhàn)等數(shù)據(jù))，在錄像分析后觸發(fā)，并通過(guò)GCP的Dataflow和自建的分析節(jié)點(diǎn)(worker)聚合，最終存入MongoDB與Google Bigtable。

從Leauge-ETL的細(xì)化架構(gòu)看(如圖4)，原有的單個(gè)Slave節(jié)點(diǎn)被拆分成4個(gè)子模塊，分別是聯(lián)賽數(shù)據(jù)分析模塊、聯(lián)賽錄像分析模塊、分析/挖掘數(shù)據(jù)DB代理模塊和聯(lián)賽分析監(jiān)控模塊。

• 聯(lián)賽數(shù)據(jù)分析模塊負(fù)責(zé)錄像文件的拉取(Salt、Meta文件與Replay文件的獲取)與比賽基本數(shù)據(jù)分析;

• 聯(lián)賽錄像分析模塊負(fù)責(zé)比賽錄像解析并將分析后數(shù)據(jù)推送至PubSub;

• 分析/挖掘數(shù)據(jù)DB代理負(fù)責(zé)接收錄像分析數(shù)據(jù)并批量寫入Bigtable;

• 聯(lián)賽分析監(jiān)控模塊負(fù)責(zé)監(jiān)控各任務(wù)進(jìn)度情況并實(shí)時(shí)告警。

同時(shí)所有的模塊選擇Golang重構(gòu)，利用其“天生”的并發(fā)能力，提高整個(gè)系統(tǒng)數(shù)據(jù)挖掘和數(shù)據(jù)處理的性能。

 

 

圖4 League-ETL架構(gòu)

分布式存儲(chǔ)

如上文提到，1.0架構(gòu)中我們使用MySQL存儲(chǔ)大量比賽數(shù)據(jù)及錄像分析數(shù)據(jù)。MySQL在大數(shù)據(jù)高并發(fā)的場(chǎng)景下，整體應(yīng)用的開發(fā)變得越來(lái)越復(fù)雜，如無(wú)法支持schema經(jīng)常變化，架構(gòu)設(shè)計(jì)上需要合理地考慮分庫(kù)分表的時(shí)機(jī)，子庫(kù)的數(shù)據(jù)到一定量級(jí)時(shí)面臨的擴(kuò)展性問(wèn)題。

參考Google的Bigtable，作為一種分布式的、可伸縮的大數(shù)據(jù)存儲(chǔ)系統(tǒng)，Bigtable與HBase能很好的支持?jǐn)?shù)據(jù)隨機(jī)與實(shí)時(shí)讀寫訪問(wèn)，更適合FunData數(shù)據(jù)系統(tǒng)的數(shù)據(jù)量級(jí)和復(fù)雜度。

 

 

 

 

圖5 Hadoop生態(tài)

在數(shù)據(jù)模型上，Bigtable與HBase通過(guò)RowKey、列簇列名及時(shí)間戳來(lái)定位一塊數(shù)據(jù)(Cell，如圖6)。

 

 

圖6 數(shù)據(jù)索引

例如，在FunData數(shù)據(jù)系統(tǒng)中，比賽數(shù)據(jù)的RowKey以hash_key+match_id的方式構(gòu)建，因?yàn)镈OTA2的match_id是順序增大的(數(shù)值自增量不唯一)，每個(gè)match_id前加入一致性哈希算法算出的hash_key，可以防止在分布式存儲(chǔ)中出現(xiàn)單機(jī)熱點(diǎn)的問(wèn)題，提升整個(gè)存儲(chǔ)系統(tǒng)的數(shù)據(jù)負(fù)載均衡能力，做到更好的分片(Sharding)，保障后續(xù)DataNode的擴(kuò)展性。

如圖7，我們?cè)趆ash環(huán)上先預(yù)設(shè)多個(gè)key值作為RowKey的前綴，當(dāng)獲取到match_id時(shí)，通過(guò)一致性哈希算法得到match_id對(duì)應(yīng)在hash環(huán)節(jié)點(diǎn)的key值，最后通過(guò)key值與match_id拼接構(gòu)建RowKey。

 

 

 

 

圖7 一致性hash構(gòu)建RowKey

時(shí)間戳的使用方便我們?cè)诰酆蠑?shù)據(jù)時(shí)對(duì)同一個(gè)RowKey和Column的數(shù)據(jù)重復(fù)寫入，HBase/Bigtable內(nèi)部有自定的GC策略，對(duì)于過(guò)期的時(shí)間戳數(shù)據(jù)會(huì)做清理，讀取時(shí)取最新時(shí)間節(jié)點(diǎn)的數(shù)據(jù)即可。

這里大家可能會(huì)有個(gè)疑問(wèn)，Bigtable與HBase只能做一級(jí)索引，RowKey加上hash_key之后，是無(wú)法使用row_range的方式批量讀或者根據(jù)時(shí)間為維度進(jìn)行批量查詢的。在使用Bigtable與HBase的過(guò)程中，二級(jí)索引需要業(yè)務(wù)上自定義。在實(shí)際場(chǎng)景里，我們的worker在處理每個(gè)比賽數(shù)據(jù)時(shí)，同時(shí)會(huì)對(duì)時(shí)間戳-RowKey構(gòu)建一次索引并存入MySQL，當(dāng)需要基于時(shí)間批量查詢時(shí)，先查詢索引表拉取RowKey的列表，再獲取對(duì)應(yīng)的數(shù)據(jù)列表。

在數(shù)據(jù)讀寫上，Bigtable/HBase與MySQL也有很大的不同。一般MySQL使用查詢緩存，Schema更新時(shí)緩存會(huì)失效，另外查詢緩存是依賴全局鎖保護(hù)，緩存大量數(shù)據(jù)時(shí)，如果查詢緩存失效，會(huì)導(dǎo)致表鎖死。

如圖8，以HBase為例，讀取數(shù)據(jù)時(shí)，client先通過(guò)zookeeper定位到RowKey所在的RegionServer，讀取請(qǐng)求達(dá)到RegionServer后，由RegionServer來(lái)組織Scan的操作并最終歸并查詢結(jié)果返回?cái)?shù)據(jù)。因?yàn)橐淮尾樵儾僮骺赡馨�括多個(gè)RegionServer和多個(gè)Region，數(shù)據(jù)的查找是并發(fā)執(zhí)行的且HBase的LRUBlockCache，數(shù)據(jù)的查詢不會(huì)出現(xiàn)全部鎖死的情況。

 

 

圖8 HBase架構(gòu)

基于新的存儲(chǔ)架構(gòu)，我們的數(shù)據(jù)維度從單局比賽擴(kuò)展到了玩家、英雄、聯(lián)賽等，如圖9。

 

 

 

 

圖9 數(shù)據(jù)維度

系統(tǒng)解耦

上文我們提到1.0架構(gòu)中使用In-Memory的消息隊(duì)列做數(shù)據(jù)傳遞，由于內(nèi)存中隊(duì)列數(shù)據(jù)沒(méi)有持久化存儲(chǔ)并與Master模塊強(qiáng)耦合，Master節(jié)點(diǎn)更新或者異常Panic后會(huì)導(dǎo)致數(shù)據(jù)丟失，且恢復(fù)時(shí)間冗長(zhǎng)。因此，在2.0架構(gòu)中采用了第三方的消息隊(duì)列作為消息總線，保障系統(tǒng)“上下游”節(jié)點(diǎn)解耦，可多次迭代更新，歷史消息變得可追蹤，基于云平臺(tái)消息堆積也變得可視化(如圖10)。

 

 

圖10 數(shù)據(jù)監(jiān)控

數(shù)據(jù)API層

1.0系統(tǒng)的數(shù)據(jù)API層為實(shí)現(xiàn)快速上線，在架構(gòu)上未做太多的設(shè)計(jì)與優(yōu)化，采用域名的方式實(shí)現(xiàn)負(fù)載均衡，并使用開源的DreamFactory搭建的ORM層，利用其RESTful的接口做數(shù)據(jù)訪問(wèn)。

該架構(gòu)在開發(fā)和使用過(guò)程中遇到許多問(wèn)題：

• API層部署在國(guó)內(nèi)阿里云上，數(shù)據(jù)訪問(wèn)需要跨洋;

• ORM層提供的API獲取表的全字段數(shù)據(jù)，數(shù)據(jù)粒度大;

• 無(wú)緩存，應(yīng)對(duì)大流量場(chǎng)景(如17年震中杯與ESL)經(jīng)常出現(xiàn)服務(wù)不可用;

• 多DB的數(shù)據(jù)聚合放在了API層，性能不足;

• 服務(wù)更新維護(hù)成本高，每次更新需要從域名中先剔除機(jī)器。

針對(duì)上述問(wèn)題，我們從兩個(gè)方面重構(gòu)了1.0數(shù)據(jù)API層，如圖11。

 

 

圖11 數(shù)據(jù)API新架構(gòu)

鏈路的穩(wěn)定性

全球鏈路上，我們使用CDN動(dòng)態(tài)加速保證訪問(wèn)的穩(wěn)定性。同時(shí)利用多云廠商CDN做備份容災(zāi)，做到秒級(jí)切換。

在調(diào)度能力和恢復(fù)能力上，我們搭建了自己的灰度系統(tǒng)，將不同維度的數(shù)據(jù)請(qǐng)求調(diào)度到不同的數(shù)據(jù)API，減少不同維度數(shù)據(jù)請(qǐng)求量對(duì)系統(tǒng)的影響;借助灰度系統(tǒng)，API服務(wù)更新的風(fēng)險(xiǎn)和異常時(shí)的影響面也被有效控制。依賴云平臺(tái)可用區(qū)的特性，灰度系統(tǒng)也能方便地實(shí)現(xiàn)后端API服務(wù)跨可用區(qū)，做到物理架構(gòu)上的容災(zāi)。

另外，為保證內(nèi)部跨洋訪問(wèn)鏈路的穩(wěn)定性，我們?cè)诎⒗镌频谋泵罊C(jī)房搭建數(shù)據(jù)代理層，利用海外專線來(lái)提升訪問(wèn)速度。

數(shù)據(jù)高可用性

接入分布式存儲(chǔ)系統(tǒng)后，對(duì)外數(shù)據(jù)API層也根據(jù)擴(kuò)展的數(shù)據(jù)維度進(jìn)行拆分，由多個(gè)數(shù)據(jù)API對(duì)外提供服務(wù)，例如比賽數(shù)據(jù)和聯(lián)賽賽程等數(shù)據(jù)訪問(wèn)量大，應(yīng)該與英雄、個(gè)人及道具數(shù)據(jù)分開，防止比賽/賽事接口異常影響所有數(shù)據(jù)不可訪問(wèn)。

針對(duì)熱點(diǎn)數(shù)據(jù)，內(nèi)部Cache層會(huì)做定時(shí)寫入緩存的操作，數(shù)據(jù)的更新也會(huì)觸發(fā)Cache的重寫，保障賽事期間的數(shù)據(jù)可用。

結(jié)語(yǔ)

本文介紹了FunData數(shù)據(jù)平臺(tái)架構(gòu)演進(jìn)的過(guò)程，分析了舊系統(tǒng)在架構(gòu)上的缺點(diǎn)，以及在新系統(tǒng)中通過(guò)什么技術(shù)和架構(gòu)手段來(lái)解決。

FunData自4月10日上線以來(lái)，已有300多位技術(shù)開發(fā)者申請(qǐng)了API-KEY。目前也在著力于新數(shù)據(jù)點(diǎn)的快速迭代開發(fā)，如聯(lián)賽統(tǒng)計(jì)數(shù)據(jù)。比賽實(shí)時(shí)數(shù)據(jù)等。

作者：肖丁，VPGAME上海技術(shù)團(tuán)隊(duì)負(fù)責(zé)人，美國(guó)團(tuán)隊(duì)架構(gòu)師，曾任職于UCloud，負(fù)責(zé)基礎(chǔ)架構(gòu)、中間件及分布式系統(tǒng)的工作。

聲明：本文為作者投稿，版權(quán)歸作者個(gè)人所有，首發(fā)于CSDN。

標(biāo)簽： Google Mysql 大數(shù)據(jù) 大數(shù)據(jù)時(shí)代 機(jī)房 開發(fā)者 數(shù)據(jù)分析 域名

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請(qǐng)與原作者聯(lián)系。