优化分析事件和日志的大规模注入

Last reviewed 2022-08-22 UTC

本文介绍了一种对在 Google Cloud 上的大规模分析提取进行优化的架构。在本文中，“大规模”意味着每秒超过 100,000 个事件，或者总聚合事件的载荷大小超过每秒 100 MB。

您可以使用 Google Cloud 的弹性和可扩缩托管式服务来收集大量传入的日志和分析事件，然后对其进行处理并放入数据仓库，例如 BigQuery。

任何用于提取大量分析数据的架构都应考虑到您需要近乎实时访问哪些数据，以及在短暂延迟后可以处理的数据，并将它们分开。这种分开数据的方法具有以下优点：

  • 日志完整性。您可以查看完整的日志，不会由于串流配额限制或采样而丢失任何日志。
  • 降低成本。相比使用批量作业从 Cloud Storage 中插入事件和日志，流式插入事件和日志的费率更高。
  • 预留查询资源。移动优先级较低的日志以进行批量加载，使它们不会对预留查询资源产生影响。

以下架构图显示了满足上述要求的系统，并介绍了提取的热路径和冷路径的概念：

一般提取路径

架构概览

在此架构中，数据有两个潜在来源：

从任一来源注入数据后，根据消息的延迟时间要求，数据会放入热路径或冷路径。其中，热路径使用流式输入，可以处理连续的数据流，而冷路径使用批处理，可以按照您确定的时间表加载数据。

日志记录事件

您可以使用 Cloud Logging 来提取由标准操作系统日志记录工具生成的日志记录事件。默认情况下，许多 Compute Engine 环境中都提供了 Cloud Logging，包括标准映像。另外，您也可以使用 Cloud Logging 代理在许多操作系统上安装 Cloud Logging。Cloud Logging 代理是 App Engine 和 Google Kubernetes Engine 的默认日志记录接收器。

热路径

热路径日志记录

在热路径中，通过在 Cloud Logging 接收器中指定过滤器，然后流式传输到多个 BigQuery 表格来选择监控和分析服务所需的关键日志。对 ERROR 和 WARN 日志记录级别使用单独的表，如果需要高容量，则按服务进一步拆分。利用这种最佳做法，能够使每个表格的每秒插入数量保持在 100000 限制之下，并使针对此数据的查询保持良好运行状态。

冷路径

冷路径日志记录

对于冷路径，系统会使用指向 Cloud Storage 存储分区的 Cloud Logging 接收器选择不需要近实时分析的日志。这些日志会集合成批并写入日志文件，以便进行 Cloud Storage 每小时批处理。然后，您可以使用标准 Cloud Storage 文件导入过程将这些日志批量加载到 BigQuery 中。使用 Google Cloud Console、命令行界面 (CLI)，甚至是简单的脚本就可以启动该过程。请注意，批量加载不会影响热路径的流式提取和查询性能。在大多数情况下，最好将冷路径日志直接合并到热路径日志使用的相同表格中，以简化问题排查和报告生成。

分析事件

分析事件可以由您在 Google Cloud 中的应用服务生成，也可以从远程客户端发送。通过 Pub/Sub 提取这些分析事件，然后在 Dataflow 中对其进行处理，可打造具有短延时的高吞吐量系统。虽然可以将热和冷分析事件发送到两个单独的 Pub/Sub 主题，但您应该将所有事件发送到一个主题，并使用单独的热路径和冷路径 Dataflow 作业对其进行处理。这样，您就可以通过更新 Dataflow 作业来更改分析事件所遵循的路径，这比部署新的应用或客户端版本更容易。

热路径

热路径事件

有时，您需要立即分析某些事件。例如，某事件可能会揭示不必要的客户端行为或不良行为者。为此，您应该使用自动扩缩 Dataflow 作业并将它们直接发送到 BigQuery 以从 Pub/Sub 提取此类事件。另外，您还可以通过 Dataflow 作业对此数据进行分区，以确保不会超过每个表格每秒 100000 行的限制。这同样可以保证查询保持良好的运行状态。

冷路径

冷路径事件

对于需要每小时或每天跟踪和分析，但从未立即进行的事件，可以由 Dataflow 推送到 Cloud Storage 上的对象。您可以使用 Cloud 控制台、Google Cloud CLI，甚至是简单的脚本将负载从 Cloud Storage 启动到 BigQuery。另外，您也可以将它们合并到与热路径事件相同的表格中。与日志记录冷路径一样，批量加载的分析事件不会对预留查询资源产生影响，并使流式提取路径的负载保持在合理水平。

如需详细了解如何将数据加载到 BigQuery 中，请参阅加载数据简介。

后续步骤