【IT168 專稿】本文根據洪增林老師在2018年5月12日【第九屆中國數據庫技術大會】現場演講内容整理而成。

講師簡介：

洪增林，網易遊戲資深開發工程師，網易遊戲數據中心開發負責人，專注于統一數據流建設、大數據作業平台設計開發和大數據組件優化等工作。

摘要：

1. 網易遊戲的數據業務特點和數據流的挑戰

2. 數據流采集架構和實踐 （1）. 數據流平台架構 （2）. 服務器日志采集的設計與實現 （3）. 客戶端數據提交入口設計 （4）. 後續疊代計劃

3. 基于數據流支撐的業務介紹 （1）. 遊戲數據集成 （2）. 程序/運維類日志歸集與應用 （3）. 通用數據處理和轉換

4. 總結展望 技術點：日志歸集、數據集成、數據流平台、golang、高并發、性能優化 面向人群：大數據平台設計和開發人員

正文：

一、網易遊戲統一數據流背景

首先，我簡單介紹一下網易遊戲開發部門，我們目前運營在線的遊戲有上百款。從2014年開始，公司從端遊市場轉向手遊，與端遊市場相比，手遊市場的研發周期大幅縮短，上線周期和疊代速度加快，對服務器的需求量大增，以陰陽師為例，上線之前内部規劃采購幾十台服務器，上線之後預計砸了上千台服務器，基礎設施數據流波動非常大。

此外，手遊生命周期相對較短，大部分遊戲半年之内熱度會明顯下降，如何有效回收利用資源成為一大難點。

總結來說，我們面臨的最大挑戰是應對突增數據（流量高峰）的能力，每天的新增數據大概在百TB級别，這些數據主要來自玩家運營數據、客戶端性能監控數據以及基礎架構數據。

以上是網易遊戲數據分析業務部分示意圖，我們團隊主要負責綠色模塊以下的部分，我們在數據管道建設以及整個組件封裝上投入了很大精力，主要提供機器學習服務、實時計算、離線計算和OLAP能力。

其中，OLAP部分主要使用Kylin和Presto實現。在此之上，我們不希望組件和計算存儲過多直接暴露給用戶，所以封裝了一些作業平台以及SaaS服務。

對于數據分析服務，下遊通常會使用各種高大上的存儲和分析引擎以支持上遊數據分析業務，所以我們需要一個穩健的數據流支撐。接下來，我主要想跟大家分享網易遊戲的數據流轉過程。

如果你對日志和數據流有所了解，那你對上圖一定不陌生。如果一家公司沒有統一的數據流，那麼數據生産方和使用方會非常混亂，這也是網易遊戲最開始的生存現狀。

我們的數據大概有兩種來源，一是玩家客戶端；二是遊戲服務器，但我們下遊有非常多使用方，使用方之間相互調用混亂，我們希望最終可以出現統一的中間層（如下圖），目前我們也在用這種方式實踐整體架構。

如果要做統一數據流層，我們就需要思考基本要求是什麼。在網易遊戲，我們做了如下幾點思考：一是數據歸集分發，我們希望将數據傳送到統一的中間層，因此需要對下遊使用方進行統一分發；二是保證數據不重不丢；三是傳輸低延遲，因為下遊有很多實時業務包括實時推薦，因此整體延時性不能太高；四是低成本，因為我們有很多海外節點，所以需要考慮節點之間傳輸不能占用太多傳輸帶寬，需要把控整體成本不能過高。

二、統一數據流架構

上圖為網易遊戲數據流平台示意圖，我們的數據來源主要有三種途徑——服務器日志、客戶端日志和數據庫，客戶端日志存放了各種用戶行為日志，比如玩家副本信息等，數據庫可能會存儲一些業務數據，主要涉及MySQL數據庫、MongoDB等，三種來源的數據最終經過統一數據流平台，将整個細節屏蔽最終放到Kafka集群中。

下遊，我們主要用到了一些組件，比如實時性相關的Storm、Spark Streaming和Flink；存儲、離線部分主要應用了HDFS、Hive、HBase三大組件。目前業務系統使用較多的是SQL組件，比如MySQL、MongoDB和Redis，這三者在我們内部基礎架構中有相應的SaaS服務。

最後是Kafka集群，我們的Kafka中涉及多個使用方，每個使用方的數據可能都是一個子集，因此我們需要進行額外分發，将某一個子集轉發到專門的Kafka topic中。

如果想把數據從客戶端和服務器日志流轉到數據中心，我個人認為大概需要兩個維度配合：客戶端和服務器。我們希望可以将客戶端與服務器統一放到服務器日志Agent層，也就是說，我們需要把客戶端玩家上傳的數據放到服務器上。

首先，我們需要一個外網數據API或者Proxy收集數據，之後統一用服務器日志Agent上傳。每個遊戲擁有自己的服務器Agent，我們現在大概有幾萬台遊戲服務器，我們需要在每一台重新部署Agent。

日志到達Agent之後，Agent負責統一定義要采集的信息，然後動态掃描哪些文件已經更新，讀取更新文件的增量更新，傳遞到Kafka Proxy。整個過程中的大部分組件都是我們自研的，接下來我會具體介紹這些組件分别解決了哪些問題。

對于外網數據API，我認為最基本的兩個要求是高可用和高性能。如果做不到高可用，玩家上傳數據就可能會丢，即便客戶端可以重試，但重試也有上限。

其餘兩個要求是全球主要Region和管理系統，因為網易遊戲是全球戰略，因此全球主要的Region，比如日本、北美、歐洲以及東南亞等均有發行，外網數據API也會發布到相應節點，底層直接使用AWS服務器即可。至于管理系統，主要作用是降低整體成本。

外網數據API主要通過web服務器收集日志請求并落盤，我們自研了高性能web端，可支持動态加載配置；日志按照業務落盤，複用日志Agent數據流；日志rotate，監控metrics上報。一些開源組件也可實現上述操作，我們目前的整個流程如上圖所示。

首先，客戶端通過https傳輸數據，這部分數據經過LB入口（海外走elb）到達服務器後，我們會做三件事情，一是數據校驗，攔截非法請求和預期之外的數據提交；二是自定義數據轉換，我們會将全球所有數據放在一起分析，在前端根據域名直接将各區域的時區自動轉換好，三是持久化到文件，第二步的數據轉換完成之後，我們就可以通過go channel将其持久化到文件中，然後管理它的rotate。

上圖為我們定義外網數據采集時自動生成的配置頁面，Web接收數據端會根據生成的配置監聽各域名提交數據的方法、磁盤位置以及rotate配置。

這裡需要說明的一個問題是version，如果我們在中央區配置更新，這個版本号會自動刷新，web端每隔一分鐘會進行一次輪詢，如果發現版本與内存版本不同就會觸發reload。我們通過這種方式解決配置自動加載問題，但并不是實時配置更新。當然，我們認為一分鐘時效是可以接受的。

在性能層面，我們内部使用的是32核、64G的服務器，Goland 1.9.1，fasthttp，單機50w qps左右，整個資源占用率較低，至少目前可以滿足我們的内部需求，并保有很大餘量。

通過自研web端，數據從玩家端上傳到服務器，這時，我們要用日志Agent接力上傳。日志Agent需要保證日志不重不丢，在運行過程中保持傳送狀态，這個狀态是事務更新的；降低配置成本，我們會做中央化管理，根據機器tag分配任務；支持多種業務同時傳輸。

因為無論是系統日志分析還是程序日志檢索，入口都是Agent，因此我們要在一台服務器上支持多種業務同時傳輸，并可根據任務優先級做出有效調整，最後是高效運維，具備完善的管控平台。

以上是我們自研的日志Agent架構設計，基本原理與開源Flume等類似。首先，這裡會涉及一個Scanner的概念，Scanner的字面意思就是掃描，我首先需要弄清楚一台遊戲服務器上到底有多少文件和目錄需要掃描上傳，我們會在配置中心定義這些東西，文件掃描使用FileScanner，DB方面使用DBScanner，目前主要涉及MySQL和MongoDB。

Scanner掃描數據初始化時要加載offset記錄，增量掃描所監聽的文件和目錄，如果獲取到更新消息可使用batch讀的方式傳到Reader中，我們額外會有單獨的線程周期性發一個心跳，這是内部監控中用的。

最後，所有數據會傳到 Queue中，這是一個數據緩沖區的大小，如果有網絡IO或者磁盤IO的場景，你可能需要緩沖區來解耦生産者和消費者，不然吞吐量上不去。

之後，我們會把Queue封裝成一個優先隊列，高優先級任務數據率先通過并發Sender讀取，Thrift RPC會将這些日志發送到kafka proxy中。

為了保證數據可靠性，整個過程必須是同步的，如果發送成功，就更新offset；如果發送失敗，則進入等待重試隊列，如果重試了幾次均失敗，就報警給SRE的同學。

整個過程中需要配置的部分同樣在配置中心完成，配置中心同樣有版本号的概念，每隔一分鐘刷新一次。主要的核心配置，比如數據源配置、緩沖區大小、并發數等是為了調整發送效率，數據路由會根據業務特性進行調整。

除了上述提到的掃描更新方式外，Scanner還有一種顯而易見的方式就是事件通知，可以通過系統方法啟動進程并監聽文件，事件更新之後對外發出通知。當處于某些極端場景下時，這種方式的性能就會變得很差。

假設我現在需要掃描的文件夾下有一萬個文件，我們的做法是對文件進行冷熱tag标記，如果這個文件在一段時間内沒有被更新，我們就會把它标記為冷文件，冷文件的掃描周期比熱文件長。當然，冷熱文件列表一直處于交換更新狀态，通過這種方式可以達到更優的性能并避免實時監聽的性能損耗。

上圖為中央化任務發布流程圖，SRE和業務方會基于機器tag定義任務，CMDB會管理整個tag列表，比如某台機器要采集某路徑上的某個文件，CMDB會對該類任務進行完整定義和管理，機器會在啟動或者輪詢時發起請求，我們将SRE與CMDB的請求打通，根據IP映射到具體tag列表，最終合并出機器任務列表返回日志Agent。我們也會根據合并列表生成版本号與Agent進行比對，确定是否需要Reload。

在配置中，我們将元數據稱為Meta，通過日志Agent進行管理，這裡涉及兩個名詞需要解釋——Timestamp和offset，Timestamp并不是指日志裡面的時間，因為日志本身可能并沒有時間，Timestamp指Agent讀的時間，而offset是指Agent按照batch方式讀時，每行可能都有一個offset位置。

如果你需要對日志進行精準排序，Timestamp和offset組合索引可以還原日志順序。當然，不同的應用場景可以不斷擴展meta。

發送效率如何呢？在網易遊戲的場景下，主要有四大因素影響發送效率：一是發送并發數；二是數據緩沖區大小；三是batch讀取大小；四是冷文件掃描周期。當Agent性能處于正常情況下時，batch讀取大小和冷文件掃描周期不會過多影響發送效率；當日志數量突然猛增，二者才會産生影響。雖然，我們可以提供多種組合配置，但我們内部并未對SRE和産品完全開放，目前提供的默認配置是35MB/S，高性能配置是70MB/S。這裡的前提是不對原始服務器也就是用戶服務器有過高資源占用。

我之前一直在強調保證日志不重不丢，所以日志可靠性是我們非常關注的事情。對于日志異常監控，我們主要做了三件事情：Heartbeat心跳；心跳錨點計算傳輸延遲；文件傳輸延遲LAG。具體來說，如果Heartbeat停止并且持續一段時間沒有恢複，我們就認為Agent可能出現了問題，我們會立刻監督Agent的狀态。

其次，心跳信息不僅僅是一個心跳，還包括服務器、主機名、負載以及觸發心跳的時間等信息，我們在下遊設置了統一實時Flink程序處理信息，當Flink收到心跳觸發時間後，它會根據當前時間計算當前從遊戲服務器到數據中心的實時延遲。如果延遲過大，我們會關注是否出現異常。

對于上文提到的日志數突然猛增的情況，我們做的主要工作是通過元數據記錄查詢并計算文件傳輸延遲，同時也在嘗試使用自動化的方式解析每個日志的時間。如果延遲過大，會觸發報警機制。

上圖為數據傳送流程，數據通過Agent上報Kafka Proxy，我們内部會有多個Kafka集群，我們希望在Proxy層隐藏上層細節，不希望Kafka集群的訪問權限或者端口開放給數萬台遊戲服務器，我們希望Kafka集群繼續放在純内網環境中運行，與遊戲服務器的外網連接隔離。

經過近一年的努力，我們形成了統一的數據流，支撐了網易遊戲大概50 産品，有1萬多台服務器日志上報；上線Docker平台日志采集；通用類日志采集；支持Windows服務器。

三、數據流業務實踐

以上是我們在數據采集、數據流轉、數據分發方面做的事情，我們的下遊業務最主要還是與數據流緊密相關，也可以說是緊接着kafka内層做的事情。第一層就是實時日志清洗與分發，這是我們技術團隊直接接管的，簡單來說，我們會管理下遊日志到達Kafka之後的去向和使用者等信息。目前，我們的大部分任務還是通過Storm完成，最近部分切換成了Flink。

實時計算主要指業務方向的實時計算。業務方将實時計算邏輯打成包，放到托管平台上運行。此外，我們基于Spark Streaming封裝了一套ETL框架，不需要寫代碼，隻需要進行一些配置就可以轉換讀取數據，包括開放自定義接口并将數據寫到不同的存儲中，比如Kafka、HDFS等。

最後是通用日志檢索，我先簡單介紹一下程序日志檢索的概念，狹隘來說，程序日志檢索就是通過服務器查看日志信息。我以微服務場景為例講解一下整個概念，微服務的好處在于我們可以将服務器拆分為不同組件，每個組件由不同的人開發，擁有獨立的技術棧、疊代周期和上線更新頻率。

最大的問題在于請求調用鍊變得非常長，查詢用戶異常信息的過程異常痛苦。我們最終的解決方案是在每個請求的入口注入trace ID或者在前端和proxy網關上做，所有請求都會有自己的ID，我們通過這個可以很容易得檢索一條請求鍊。

總結來看，大規模程序日志檢索主要有三點要求：檢索效率高，低延遲和查詢時保證順序。目前的程序日志檢索流程如下圖所示，我們會對數據流進行實時清洗切分，然後将結果放到ES之中，最後通過查詢Server實現查詢。

四、想法與總結

以上是我今天分享的全部内容，通過整個過程，我自己對技術開發有如下三點感受：

追求簡單、可靠、靈活的解決方案；

解決方案需要針對具體的場景，沒有一種技術可以解決所有問題；

架構設計和選型有很多的Trade offs。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!