使用 Cloud Pub/Sub 执行长时间运行的任务

此解决方案介绍如何将 Google Cloud Pub/Sub 用作队列系统来处理可能长时间运行的任务。此解决方案使用音频文件自动转录作为示例。

虽然音频可作为各种媒体类型的重要补充,但有时将语音转录为文本也很有用。使用场景包括观看有字幕的视频以及分析呼叫中心通话内容等。在需要每隔几秒上传长达数小时的视频,或每天创建数小时的支持团队通话内容的情况下,与手动转录相比,自动批处理可以节省数小时的时间。

在此解决方案中,您将了解媒体处理基础架构如何实现,在这个过程中,音频文件会上传到云端以存储,例如在录制通话内容后。然后,这些文件会被转录,其结果将保存到数据库中以供进一步分析。此处介绍的架构也适用于较大的图片或视频,它们可能需要数小时来完成处理。

架构和工作流

下图展示了架构和工作流:

文件上传和处理概览。以下文字中描述了步骤。

在此图中,用户上传内容后,系统作出的反应如下:

  1. 监视器应用选取已上传的新媒体。
  2. 链接到监视器的 webhook 会将含有媒体详细信息的消息添加到队列中。
  3. 订阅队列的工作器之一拉取该消息。
  4. 同一个工作器从存储空间中获取合适的媒体并对其进行处理。
  5. 完成后,工作器将结果保存到输出存储空间位置。
  6. 然后,工作器确认该消息,以便将其从队列中删除。

要求和基础架构

该架构需要多个组成部分。

存储空间

媒体需要被妥善存储,以便用户轻松访问、处理和交付。存储空间应具备高可用性、低延迟、能够处理 TB 级(最好是 PB 级)的数据,并且支持全局访问。

Google Cloud Storage 提供三种对象存储解决方案,其具备相同的可用性和耐用性:

  • 标准。用于处理和存储数据。可以在几毫秒内访问数据。它还利用免费的内容分发网络 (CDN),使用 Google 的边缘网络实现公开内容分发。
  • NearlineNearline 存储空间提供低费用、高度耐用的备份方案。可以在几毫秒内访问数据的第一个字节,从而提供快速恢复选项。
  • ColdlineColdline 存储空间费用极低,最适合存储您计划每年最多访问一次的数据。Coldline 对于长期数据归档、在线备份和灾难恢复非常有用。Coldline 还提供快速数据检索。

此解决方案使用标准存储空间保存要处理的文件。

通知

文件可以随时到达对象存储空间。为了快速响应,系统需要一个监视存储空间位置的组件,并在添加新媒体文件时自动创建事件。您可以配置 Cloud Pub/Sub Notifications for Cloud Storage 功能以监视存储分区,并在存储分区内的内容发生更改时向 Cloud Pub/Sub 发送事件。

消息队列

如果要处理的传入媒体文件很多,系统将需要多个工作器快速处理媒体。等待处理的文件越多,需要的工作器就越多。为了降低费用并保持在预配限额之内,您可以使用处理队列以将并发运行所需的工作器数量减到最少。

Google Cloud Pub/Sub 是一个高可用性的消息传递和队列系统。它可以通过 HTTP API 访问并提供通信配置,如一对多(扇出)、多对一(扇入)和多对多。Cloud Pub/Sub 支持推送和拉取订阅模式。

此解决方案使用 Cloud Pub/Sub 创建一个容错且高效的队列,该队列具有以下特点:

  • 为每个新文件发布消息的单个发布者,消息中包含描述文件及其位置的元数据。

  • 包含所有发布消息的单个队列。

  • 从队列中拉取消息的一组工作器。使用推送订阅模式可确保工作器有足够的时间在处理完一个媒体文件后再处理下一个文件。

  • 如果工作器从队列中拉取消息但未确认其已完成处理该媒体文件,则队列系统会假定工作器已失败并将该消息返回到队列。

  • 工作器仅在完成处理媒体后才会确认消息。确认会使 Cloud Pub/Sub 从队列中删除该消息。

  • 对于需要很长时间完成的处理,您可以定期刷新确认截止时间,这样一来,如果原始工作器仍在处理消息,Cloud Pub/Sub 不会将该消息返回队列中。

  • 每条消息都有生命周期。如果消息在到期之前尚未处理,则其将从队列中删除。这可以防止队列变得太大。

下图说明了此解决方案如何使用 Cloud Pub/Sub 处理消息。

处理消息。以下文字中描述了步骤。

在上图中,您可以看到在工作器拉取消息后,消息仍保留在队列中。它被标记为已认领,且无法由其他工作器处理。只有在指定的确认截止时间到来之前,订阅未收到认领该消息的工作器的确认时,它才会再次可由其他工作器处理。

计算

处理与消息队列关联的文件有以下几个步骤:

  1. 读取队列。
  2. 读取音频文件。
  3. 转录音频。
  4. 保存结果。

扩缩

为了及时执行所有步骤,系统需要一组可扩缩以满足传入需求的工作器。扩缩可以手动或自动处理。如果传入文件的数量和大小比较稳定,并且您知道需要多少工作器来处理这些处理负载,则手动扩缩比较合适。自动扩缩适用于传入文件数量突然变化的情况。

基于前述要求,系统需要具备转换媒体文件的计算能力,以及自动横向扩缩以按需提供额外工作器的能力。

Compute Engine 实例基于模板创建。

借助 Google Compute Engine,您可以创建虚拟机实例以执行计算任务。

托管实例组支持手动扩缩和自动扩缩。实例组管理员可以使用机器映像或容器实例模板创建相同的机器组。

通过手动扩缩,实例组管理员可按需创建新实例,并终止无响应的实例,从而确保始终启动并运行指定数量的虚拟机实例。

使用自动扩缩时,实例组管理员会根据您选择的指标创建或终止实例,例如平均 CPU、HTTP 负载平衡器上的负载、实例自定义指标或 Cloud Pub/Sub 队列大小。

托管实例组可以基于 Cloud Pub/Sub 和 instance/cpu/utilization 的组合使用自动扩缩。这样,工作器的数量可以根据队列大小增加或减少,并且当虚拟机仍在处理媒体文件时不会终止实例。

音频处理

配置计算平台后,下一个考虑因素是如何解析媒体文件。在某些情况下,某些作业必须自定义,并且需要大量计算能力。此解决方案专注于队列架构而非媒体处理,其使用 Cloud Speech API 同步处理某些音频文件。

让工作器保持运行可能需要足够的时间,因此队列可以在变大的同时保持解决方案的简单性。

数据存储

处理完媒体后,可以保存音频文件的结果以供进一步分析。BigQuery 提供了一个简单的 SQL 界面,同时提供了其他 Google 工具可以利用的存储空间,因而非常有用。

Google Cloud Platform 基础架构

下图说明了如何使用 Google Cloud Platform 构建媒体处理解决方案。

媒体处理解决方案架构。

后续步骤

  • 根据您自己的情况试用其他 Google Cloud Platform 功能。查阅我们的教程
此页内容是否有用?请给出您的反馈和评价:

发送以下问题的反馈:

此网页
Solutions