移动游戏应用生成大量的玩家遥测和游戏事件数据。这些数据有可能提供有关玩家行为及其与游戏互动的数据分析。移动游戏的本质，即大量客户端设备、不规则和慢速的互联网连接、电池和电源管理问题等意味着玩家遥测和游戏事件分析面临着独特的挑战。

该参考架构提供了一种在 Google Cloud Platform 上收集、存储和分析大量玩家遥测数据的高级方法。

更具体地说，您将学习两种用于分析移动游戏事件的主要架构模式：

使用流处理模式实时处理各个事件
使用批处理模式批量处理聚合事件

图1：游戏遥测参考架构

图 1 显示了两种模式的处理流水线，以及一些可选组件，以进一步探索、可视化和共享结果。参考架构具有高可用性，可以随着数据量的增加而扩缩。另请注意，此架构仅由数据分析流水线的托管服务组成，无需运行虚拟机或管理操作系统。如果您的游戏服务器通过 App Engine 处理用户身份验证，则尤其如此。本文的其余部分将逐步介绍此架构。

使用流处理模式的实时事件处理

本节探讨了一个示例架构模式，它从许多不同的数据源同时提取、处理和分析大量事件。处理过程在游戏中的事件展开时发生，使您能够实时响应并做出决策。

许多移动游戏会产生大量的事件消息。有些是由玩家触发，有些是在一天中的某个时间触发等等。因此，数据集是无限制的，您不知道要提前处理多少事件。对此，正确的方法是使用流处理执行引擎处理数据。

想象一下，您的移动应用是一个角色扮演游戏，允许玩家通过接受任务击败强大的怪物来对抗邪恶势力。为了跟踪玩家的进度，典型的事件消息包括玩家的唯一标识符、事件时间戳、指示任务的指标、玩家的当前生命值等等。在某种程度上它看起来与本示例类似，显示了一个事件标识符为

playerkillednpc

的战斗结束事件消息。

{
"eventTime":"2015-10-27T20:34:12.675362426+08:00",
"userId":"gamer@example.com",
"sessionId":"b6ff8881-0c30-9add-374c-c32052cee256",
"eventId":"playerkillednpc",
…
"attackRoll":17,
"damageRoll":13
}

此示例包含与战斗相关的事件，但事件消息可包括与您的业务相关的任何类型的信息，例如，游戏内的购买事件。

由于您无法预测将来要对您的数据做出哪些操作，一个很好的策略是尽可能多地记录数据点。这为您将来的数据查询提供了所需的其他上下文。例如，以下哪个事件数据更具洞察力，是玩家在游戏中进行了价值 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 TB - 10 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 数据添加到架构中的 catch-all 字段，并使用 BigQuery JSON 查询功能在该字段内查询。然后，您可以查询多个 BigQuery 表，即使源事件严格要求使用不同的架构也是如此，如图 6 所示。

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

参考架构的操作注意事项

建立并创建流水线后，就必须监控性能和可能发生的任何异常。Cloud Dataflow 监控用户界面提供了一个图形视图以监控您的数据流水线作业以及关键指标。您可以在图 7 中看到此示例的截图。

图 7：内置 Cloud Dataflow 监控控制台

Cloud Dataflow 控制台提供有关流水线执行图的信息以及当前性能统计信息，例如每一步处理的消息数、估计的系统延迟和数据水印。如需了解 Cloud Dataflow 与 Stackdriver Logging 服务集成的详细信息，您可以查看图 8 中的示例截图。

图 8：Stackdriver Logging 与 Cloud Dataflow 集成

延伸阅读和更多资源

批处理之外的世界：流处理入门 - 现代数据处理概念的高级导览
Google Dataflow：批处理和流处理数据的统一模型
使用 Cloud Dataflow 大规模处理日志
移动游戏流水线示例

创作场景

构建移动游戏分析平台 - 参考架构