Google Cloud構建移動游戲分析平臺  參考架構,2021google游戲出海峰會

Google Cloud構建移動游戲分析平臺  參考架構

移動游戲應用生成大量的玩家遙測和游戲事件數據。這些數據有可能提供有關玩家行為及其與游戲互動的數據分析。移動游戲的本質，即大量客戶端設備、不規則和慢速的互聯網連接、電池和電源管理問題等意味著玩家遙測和游戲事件分析面臨著獨特的挑戰。

該參考架構提供了一種在Google Cloud Platform上收集、存儲和分析大量玩家遙測數據的高級方法。

更具體地說，您將學習兩種用于分析移動游戲事件的主要架構模式：

使用流處理模式實時處理各個事件

使用批處理模式批量處理聚合事件

圖1：游戲遙測參考架構

圖1顯示了兩種模式的處理流水線，以及一些可選組件，以進一步探索、可視化和共享結果。參考架構具有高可用性，可以隨著數據量的增加而擴縮。另請注意，此架構僅由數據分析流水線的托管服務組成，無需運行虛擬機或管理操作系統。如果您的游戲服務器通過App Engine處理用戶身份驗證，則尤其如此。本文的其余部分將逐步介紹此架構。

使用流處理模式的實時事件處理

本節探討了一個示例架構模式，它從許多不同的數據源同時提取、處理和分析大量事件。處理過程在游戲中的事件展開時發生，使您能夠實時響應并做出決策。

許多移動游戲會產生大量的事件消息。有些是由玩家觸發，有些是在一天中的某個時間觸發等等。因此，數據集是無限制的，您不知道要提前處理多少事件。對此，正確的方法是使用流處理執行引擎處理數據。

想象一下，您的移動應用是一個角色扮演游戲，允許玩家通過接受任務擊敗強大的怪物來對抗邪惡勢力。為了跟蹤玩家的進度，典型的事件消息包括玩家的唯一標識符、事件時間戳、指示任務的指標、玩家的當前生命值等等。在某種程度上它看起來與本示例類似，顯示了一個事件標識符為

playerkillednpc

的戰斗結束事件消息。

此示例包含與戰斗相關的事件，但事件消息可包括與您的業務相關的任何類型的信息，例如，游戲內的購買事件。

由于您無法預測將來要對您的數據做出哪些操作，一個很好的策略是盡可能多地記錄數據點。這為您將來的數據查詢提供了所需的其他上下文。例如，以下哪個事件數據更具洞察力，是玩家在游戲中進行了價值50美分的購買行為，還是他們在任務15中為了對抗頭目而購買了強大的法術，或者玩家在沒有購買該法術時，僅30分鐘內就被該頭目連續擊敗了5次？如果能夠捕獲豐富的事件數據，就可讓您詳細了解游戲中正在發生的事情。

消息來源：移動設備還是游戲服務器？

無論事件消息的內容字段如何，您都必須決定是將事件消息直接從運行移動應用的最終用戶設備發國際快遞Cloud Pub/Sub提取層，還是通過游戲服務器發快遞。通過游戲服務器發快遞事件消息的最大優點是身份驗證和驗證由您的應用處理。缺點是需要額外的服務器處理能力來處理來自移動設備的事件消息的負載。

注意：要直接從手機向Cloud Pub/Sub發快遞消息，您需要手動處理客戶端應用的身份驗證和密鑰管理。這可能是一項非常重要的工作。如果采用這種方法，一種方案是在每一代移動應用中部署一個新的服務帳號，并為該帳號關聯一個不同的Cloud Pub/Sub主題。這將允許您隨著時間的推移輪播您的密鑰。要提升安全性，您還可以包含可由Cloud Dataflow驗證的簽名。

圖2：實時處理來自游戲客戶端和游戲服務器的事件

無論數據源如何，后端架構基本保持不變。如圖2所示，這個架構有五大部分，包括：

1、實時事件消息由大量數據源（如數百萬個移動應用）發快遞。

2、身份驗證由游戲服務器處理。

3、Cloud Pub/Sub提取并臨時存儲這些消息。

4、Cloud Dataflow將JSON事件轉換為基于架構的結構化數據。

5、這些數據被加載到BigQuery分析引擎中。

Cloud Pub/Sub：大規模提取事件

要處理此負載，您需要一個能夠接收和臨時存儲這些事件消息的可擴縮服務。由于每個單獨的事件都非常小，因此相比整體存儲要求，消息總數才更值得注意。

此提取服務的另一個要求是允許多種輸出方法。這意味著事件應該可以被多個目的地提取。最后，應該在充當隊列的服務（每個目的地輪詢以獲取新消息）和推快遞方法之間選擇其一，以便在收到事件時主動發快遞事件。

幸運的是，Cloud Pub/Sub服務提供了所有這些功能。例如下圖3顯示的推薦提取層，它能夠每秒處理數百萬條消息，并在永久性存儲上存儲7天之久。Cloud Pub/Sub采用發布/訂閱模式，因此您可以讓一個或多個發布商向一個或多個主題發快遞消息。此外，每個主題也可以有多個訂閱者。

圖3：具有永久性存儲的Cloud Pub/Sub發布訂閱模型

您可以選擇主題數量和每個主題的分組。因為主題數量與您創建的Cloud Dataflow流水線數量之間存在直接關系，所以最好將邏輯連接的事件分組。例如，發布者可以是單個移動設備或游戲服務器，而多個發布者又可以訂閱單個主題。您需要的只是通過HTTPS進行身份驗證和發快遞格式正確的消息的能力。

Cloud Pub/Sub服務接收消息（在本例中是玩家遙測事件）后，就會將其永久地存儲在Message Store中，直到每個主題訂閱都已經檢索到該消息。

Cloud Dataflow流處理流水線

Cloud Dataflow提供了一種高級語言，可以輕松地描述數據處理流水線。您可以使用Cloud Dataflow托管服務運行這些流水線。Cloud Dataflow流水線以流處理模式運行，并通過訂閱在消息到達時從Cloud Pub/Sub主題獲取消息。然后，Cloud Dataflow會在將消息添加到BigQuery表之前進行必需的處理操作。

此處理可以采用簡單的元素智能形式，例如將所有用戶名設置為小寫；或者將元素與其他數據源連接，例如將用戶名表加入到玩家統計信息中。

圖4：將JSON消息轉換為BigQuery表格式

Cloud Dataflow可以執行任意數量的數據處理任務，包括輸入數據的實時驗證。一個用例是作弊檢測，例如突出顯示最大生命值超出合理范圍的玩家。另一個用例是數據清理，例如確保事件消息格式正確并與BigQuery架構匹配。

圖4中的示例解組了來自游戲服務器的原始JSON消息，并將其轉換為BigQuery架構。關鍵是您無需管理任何服務器或虛擬機來執行此操作，Cloud Dataflow就可以啟動、運行和停止計算資源以并行處理您的流水線。不僅如此，您還可以在進行流處理和批處理時使用相同的代碼。

開源Cloud Dataflow SDK提供與Cloud Dataflow程序執行獨立的流水線執行。具體來說，您的Cloud Dataflow程序構造流水線，而您編寫的代碼生成一系列由流水線運行程序執行的步驟。流水線運行程序可以是GCP上的Cloud Dataflow托管服務、Spark和Flink之類的第三方運行程序服務，也可以是直接在本地環境中執行步驟的本地流水線運行程序（尤為適合開發和測試）。

Cloud Dataflow確保每個元素只處理一次，您還可以利用時間窗口和觸發器功能以根據事件發生的實際時間（事件時間）聚合事件，而不是根據將這些事件發國際快遞Cloud Dataflow的時間（處理時間）。雖然由于移動互聯網連接或電池電量耗盡等問題，某些消息可能會從數據源開始延遲發快遞，但您仍希望最終按照用戶會話將事件分組。借助Cloud Dataflow的內置會話窗口功能即可實現。請參閱批處理之外的世界：流處理入門以了解數據窗口的策略。

或者，如果您的事件包含唯一的會話字段，例如通用唯一標識符(UUID)，您也可以使用此密鑰對相關事件進行分組。最合適的選擇視您的具體情況而定。

BigQuery：用于大規模數據分析的完全托管數據倉庫

BigQuery由兩大部分組成，包括一個存儲系統，通過地理冗余和高可用性提供數據的永久存儲。另一個是分析引擎，使您能夠對大量數據集運行類似SQL的查詢。由于BigQuery將其數據組織到可包含多個表的數據集中，因此需要為每個表定義一個架構，上一節就介紹過Cloud Dataflow的主要作業是使用內置的BigQuery連接器將JSON格式的原始事件數據構建為BigQuery架構結構。

將數據加載到BigQuery表后，您可以對其運行交互式SQL查詢以提取有價值的情報。BigQuery是為大規模數據構建的，允許您對具有快速響應時間的PB級數據集運行聚合查詢。這非常適合交互式分析。

數據可視化工具

Google Data Studio允許您創建和共享訪問各種數據源（包括BigQuery）的交互式信息中心。

不僅如此，BigQuery還集成了幾種流行的第三方BI和可視化工具，例如Tableau和QlikView。如果您熟悉Jupyter（以前稱為IPython）筆記本，Cloud Datalab服務也提供與BigQuery的內置連接。最后，您可以直接從Google表格和Microsoft Excel運行BigQuery查詢。

使用批處理模式進行批量處理

另一個主要模式是定期處理不要求實時的大型有界數據集。批處理流水線通常用于創建報告或與實時數據源相結合，以實現兩全其美的結果，即得到可靠的歷史數據，包括通過實時流處理流水線傳入的最新信息。

圖5：從游戲服務器批處理事件和日志

Cloud Storage是存儲大文件的推薦方案。它是一種具備耐用性、高可用性且經濟高效的對象存儲服務。但您可能會疑惑，如何先將數據導入Cloud Storage？答案取決于您的數據源，這也是接下來幾節將介紹的主題。其中您將了解三種不同的數據源場景，包括本地部署、其他云提供商和GCP。

場景1：從本地服務器傳輸文件

您可以使用多種方法從本地數據中心安全地傳輸日志文件。最常見的方法是使用開源

gsutil

命令行實用程序來設置周期性文件傳輸。

gsutil

命令提供了一些有用的功能，包括多線程并行上傳大量文件、自動同步本地目錄、大文件的可恢復上傳，以及對于非常大的文件，將文件分成更小的部分并并行上傳這些小文件。這些功能可縮短上傳時間，并盡量利用您的網絡連接。

如果您沒有足夠的互聯網帶寬來實現及時上傳，您可以使用直接對等互連或運營商對等互連直接連接到GCP。或者，如果您希望發快遞物理媒體，那么可使用一個名為離線媒體導入/導出的第三方服務以接收您的媒體并代您進行上傳。

場景2：從其他云提供商傳輸文件

某些日志文件可存儲在其他云提供商處。也許您在那里運行游戲服務器并將日志輸出到該云提供商的存儲服務。或者您使用具有默認存儲目標的服務。例如，Amazon Cloudfront（一種內容分發網絡服務）將其日志存儲在Amazon S3存儲分區中。幸運的是，將數據從Amazon S3遷移到Cloud Storage非常簡單。

如果您每天將大量文件從Amazon S3傳輸到Cloud Storage，則可以使用Storage Transfer Service從包括Amazon S3和HTTP/HTTPS服務在內的數據源傳輸文件。Storage Transfer Service提供了多種高級選項，以便您可以定期設置周期性傳輸。該服務利用主要云提供商之間的大網絡帶寬，并使用先進的帶寬優化技術來實現非常高的傳輸速度。

該指南是描述使用此服務進行傳輸時，每次傳輸開銷1 TB0 TB或更多數據量，因為它可以節省在多臺服務器上運行場景1中提到的

gsutil

工具的操作開銷。對于較小規模的傳輸，或者您需要每天多次傳輸數據，則場景1中提到的

gsutil

工具更為適合。

場景3：數據已經在GCP中

在某些情況下，您想要的數據會默認自動存儲在Cloud Storage中。例如，可以通過您的Google Play開發者帳號下的Cloud Storage存儲分區中獲得來自Google Play商店的數據（包括評論、財務報告、安裝、崩潰和應用無響應（ANR）報告）。在這些情況下，您可以將數據保存在導出的原始存儲分區中，除非您有理由將其移動到另一個存儲分區。

異步傳輸服務模式

一種長期且可擴縮的方法是實現異步傳輸服務模式，即您可以使用一個或多個隊列和消息傳遞來基于事件或觸發器啟動傳輸。例如，當新的日志文件寫入磁盤或源文件存儲空間時，會向隊列發快遞一條消息，然后工作器承擔成功將該對象傳輸到Cloud Storage的作業，僅在成功完成傳輸時，才會從隊列中移除該消息。

替代的批處理模式：從Cloud Storage直接加載到BigQuery

難道在Cloud Storage和BigQuery之間必須使用Cloud Dataflow？答案是否定的，因為您可以通過提供一個架構并啟動加載作業，直接從Cloud Storage中的JSON文件加載文件。或者，您可以直接查詢在Cloud Storage存儲分區中的CSV、JSON或Cloud Datastore備份文件。此入門解決方案也可以滿足需求，但請記住使用Cloud Dataflow可獲得如下好處：

在提交到存儲之前轉換數據。例如，您可以在將數據加載到BigQuery之前聚合數據，將不同類型的數據分組到不同的表中。這可以通過最大限度地減少您查詢的行數來降低BigQuery的成本。在實時場景中，您可以使用Cloud Dataflow計算單個會話或公會和團隊等同類群組中的排行榜。

可互換地使用在Cloud Dataflow中編寫的流處理和批處理數據流水線。更改數據源和數據接收器，例如將Cloud Pub/Sub更改為Cloud Storage，相同的代碼將在兩種使用場景中都有效。

更靈活的數據庫架構。例如，如果您隨著時間的推移向事件添加了其他字段，則可能希望將其他原始JSON數據添加到架構中的catchall字段，并使用BigQuery JSON查詢功能在該字段內查詢。然后，您可以查詢多個BigQuery表，即使源事件嚴格要求使用不同的架構也是如此，如圖6所示。

圖6：用于捕獲原始JSON中的新事件字段的附加列

參考架構的操作注意事項

建立并創建流水線后，就必須監控性能和可能發生的任何異常。Cloud Dataflow監控用戶界面提供了一個圖形視圖以監控您的數據流水線作業以及關鍵指標。您可以在圖7中看到此示例的截圖。

圖7：內置Cloud Dataflow監控控制臺

Cloud Dataflow控制臺提供有關流水線執行圖的信息以及當前性能統計信息，例如每一步處理的消息數、估計的系統延遲和數據水印。如需了解Cloud Dataflow與Stackdriver Logging服務集成的詳細信息，您可以查看圖8中的示例截圖。

圖8：Stackdriver Logging與Cloud Dataflow集成

特別聲明：以上文章內容僅代表作者本人觀點，不代表ESG跨境電商觀點或立場。如有關于作品內容、版權或其它問題請于作品發表后的30日內與ESG跨境電商聯系。