網易雷火UX在GDC演講：大資料視角下的多人線上開服策略

北京時間7月23日，在遊戲開發者大會（GDC2021）上，來自網易雷火UX使用者體驗中心的資料探勘工程師Sure進行了精彩的分享，遊戲開發者大會每年在舊金山舉行，如今已有35屆，是一場高質量的大型遊戲開發者盛會。


Sure於2018年校招進入網易，參與了多款端手遊專案的資料探勘工作，具有豐富的資料探勘經驗，他所在的網易雷火UX使用者體驗中心是全球知名的一流使用者體驗團隊，業務包含使用者研究，大資料研發，體驗設計等領域。GDC全球開發者大會二十年來的非贊助類演講中，雷火UX入圍數佔中國遊戲行業的40%以上，與多所高校建立了密切的合作關係。

大家好，我是來自網易雷火使用者體驗中心的資深資料探勘工程師Sure。今天我要帶來的主題是大資料方向，題目是“排隊：大資料視角下的多人線上開服策略”。

遊戲開發者如何在有限伺服器資源情況下保證玩家的遊戲體驗一直是備受關注的問題，設定遊戲玩家負載上限是解決該問題的最佳方式，但該方式帶來的直接影響就是玩家需要排隊登陸伺服器，就遊戲體驗來說排隊時間過長或者伺服器排隊不均會直接導致玩家流失，甚至引起輿論，因此實時動態掌握伺服器的排隊情況進而調整開服策略至關重要。

因此本議題是站在大資料的視角，基於大型多人線上遊戲提出對開服排隊情況進行實時監控以及優化策略。議題介紹了多人線上遊戲的日誌源實時日誌獲取、解析、優化儲存方式到可操作的資料計算，進而實時獲得伺服器的排隊人數和排隊玩家的情況。通過玩家資訊資料(排隊時間、排隊伺服器等)和玩家遊戲內部資料(遊戲等級、付費狀況、線上時間、任務參與度等等)相結合的方式優化伺服器排隊,保證老玩家能有一定的優先權。除此之外策略也可以營造排隊氛圍保持伺服器的高熱度。

我們會從資料流的角度，結合開服排隊案例深入講解大資料在多人線上開服策略方面的優化。通過本次分享，大家可以瞭解遊戲領域關於日誌處理、實時計算以及優化開服策略的方式，並適用到個人或者公司的遊戲專案中。


眾所周知，很多大型線上遊戲在開服的時候都會採用排隊方式。排隊機制會天然的給玩家帶來較差的遊戲體驗，只能是一種拿時間換資源的權衡方式。既然排隊往往是無法避免的，玩家進入伺服器前會有等待時間，我們應該儘可能的利用這個時間創造更多價值。為了能夠做到上述價值，及時的準確的監控玩家的排隊“情緒”是至關重要的。下圖展示了遊戲中標準的資料流迴圈。


遊戲都會產生日誌，通過對日誌進行加工做成資料產品比如BI報表，然後使用者通過資料產品能夠對遊戲狀態更加及時準確的掌握，進而優化調整反饋到遊戲中，做出更多的操作。遊戲優化後繼續產生新的日誌，因此產生了一種正向的迴圈，持續的提升遊戲。

針對開服策略提出了兩種基於大資料的開服策略，分別是“分流”和“導流”方案，前者通過對遊戲排隊及伺服器日誌的實時監控，計算各項指標(排隊耗時分佈、伺服器資源等等)，判斷伺服器負載風險，進行及時的開服分流排隊。後者方案更傾向於一種全流程的策劃運營方案，如打造具備顯著特徵的伺服器，比如社交聊天屬性等等，結合玩家遊戲畫像，引流到策劃方案指定的伺服器，從而帶來更好的遊戲體驗，兩種方案都是建立在優先考慮玩家自主選擇的基礎上。

分流的開服策略，這也是和常規的開服策略最貼近的一種，目標也是相對簡單，就是為伺服器分擔壓力。面對這種開服策略，大資料需要獲得資訊有兩方面，分別是伺服器資訊和排隊資訊。如果是遇到伺服器壓力大的時候最簡單的操作就是加伺服器。在策略執行的整個過程只需要資料，決策者以及開發人員即可。除了分流的方式，還會有導流的方式。不同於分流的目的，導流是更加面向定製化，旨在打造更加好遊戲體驗的伺服器。想要做到這點，就需要對玩家特徵進行獲取，這也是不同於分流的地方。在這個過程中參與的角色也比較多，比如資料，開發，決策者，策劃，運營等等。

為了能夠做到上述策略的執行，需要對資料部分進行分析，分析的資料分為兩部分，伺服器和玩家。針對遊戲玩家，主要分析的有這麼幾點，首先是排隊狀態，比如排隊時間分佈、排隊時間玩家分佈等等，其次是“是否是老玩家”，通過對老玩家在其他伺服器的遊戲行為資料進行分析彙總出玩家特徵，最後是玩家遊戲畫像。伺服器資料主要是關注伺服器的狀態，比如伺服器線上人數、ACU/PCU、伺服器資源等等。


從遊戲日誌到BI資料產品的標準流程如圖所示，首先是收集玩家的遊戲日誌，根據預先設計的資料指標進行計算玩家和伺服器日誌資料，接著資料的視覺化，最後是決策者使用資料產品進行遊戲的策略調整。

為了做到上述指標的計算，需要考慮的指標特點主要是三個方面，分別是延遲容忍度、特徵重要性以及計算開銷，根據這三個方面決定使用何種計算方式。


我挑選了一些比較典型的案例，比如紫色線段展示的是高延遲容忍、特徵不是很重要，而且計算開銷比較大的話就會選擇計算一次或者T+1的計算方式。再比如綠色線段，低延遲、特徵也不是很重要，那麼可以選擇近實時的方案，藍色線段：低延遲容忍，特徵很重要，那麼就會選擇實時計算。

在確立指標計算方式之後，就需要對整個資料計算進行框架設計，如圖顯示為整個計算架構圖。


選用了四種顏色代表了四條技術路線，也可是計算粒度的區別。整個架構拆分為多個層次，其中最為關鍵部分是Collect、Prestore、Compute、Tag以及Store部分，紫色代表著T+1， 黃色和綠色代表著近實時，以及藍色代表著實時。T+1計算方式使用Flink收集日誌寫入HDFS，通過Hive SQL計算資料，最後將計算結果寫入Hbase和Redis提供服務。此外，使用者畫像也採用T+1計算方法。近乎實時的技術路線有兩條，一種是使用ELK計算，Logstash收集日誌，Elasticsearch儲存資料，使用Python計算資料。另一種是結合Kudu，使用Flink收集日誌，kudu預存資料，最後Impala計算資料。兩條路由都會將計算結果寫入MySQL。

最後一種是實時方式，使用Kafka預存資料，Flink進行計算。在服務層，所有方案都會使用 Django和Docker。


首先介紹的是T+1的方式，在這部分有過兩個階段的實踐，在很久之前我們在Collect和Prestore採用 Logstash+Local FS的方式，固定時間週期上傳到HDFS上，後來日誌量的增多就帶來很多瓶頸，比如單機記憶體不足等等，然後我們引入Flink解決上述瓶頸問題，直接寫入到HDFS，採用Hive SQL方式對指標進行計算。考慮到指標的複雜性，在使用者畫像部分也是採用T+1的方式計算。最終將計算完的指標寫入到Hbase和Redis。之所以選擇Hbase和Redis是考慮到可以做到高吞吐低延遲的效果。整個過程是小時級或者天級的。T+1方案主要是用來計算低頻更新的資料指標。前面提到的使用者畫像，之所以採用T+1方案，是因為需要計算的指標都相對複雜，也需要資料分析工作，如玩家的聚類和行為分析，最終彙總成玩家的Tag。使用者畫像日誌量大，計算開銷也大並且需要人工的參與，因此T+1的方式是最合適的。


我們在探索近實時的實踐過程中保留著兩種技術路線，分別是增量計算和全量計算。第一種就是黃色路線所示，利用ES對文字的強大搜尋能力進行計算，同時使用Python作為程式語言能夠做到快速實現和靈活的資料轉化。第二種就是使用Kudu的OLAP能力，同時加上Impala的計算引擎做到資料的近實時計算。第二種因為是全量計算，消耗的資源比較多，通常作為第一種方案的補充，以及第一種方案的資料校驗。該方案主要用於計算重要而且複雜的資料指標。


最後就是實時的方案，也就是使用Flink和Kafka對資料進行轉化計算，整個過程會更加複雜，依然有著各種優缺點。

在Web服務則是使用了Django、Docker以及K8s，可以做到快速開發，快速迭代，快速部署以及方便擴充。通用開發方案是以近實時為主，實時和T+1為輔的技術方案，做到了計算開銷與指標重要度的權衡。

感謝大家，希望能對大家的工作起到一些幫助。