您可以使用已部署容器的VM示例并在其上执行作业。最后杀死或停止您的VM。
但是，就个人而言，我更喜欢无服务器的解决方案和方法，比如Cloud Run。然而，云跑上的长时间运行作业将到来，一天！在此之前，您必须处理60分钟的限制或使用其他服务。

**作为解决方法，**我建议您使用Cloud Build。是的，Cloud Build用于在其中运行任何容器。I wrote an article on this .我在Cloud Build上运行了一个Terraform容器，但实际上，您可以运行任何容器。

正确设置超时，注意default service account and assigned role，还有，Cloud Run上还没有提供的东西，选择CPU的数量（1，8或32）进行处理并加快您的进程。
想要奖金吗？你有120 minutes free per day and per billing account（* 小心，它不是每个项目！* ）

更新时间：2021- 10月
Cloudrun支持后台活动。

Configure CPU to be always-allocated if you use background activities
Background activity is anything that happens after your HTTP response has been delivered. To determine whether there is background activity in your service that is not readily apparent, check your logs for anything that is logged after the entry for the HTTP request.

Configure CPU to be always-allocated
If you want to support background activities in your Cloud Run service, set your Cloud Run service CPU to be always allocated so you can run background activities outside of requests and still have CPU access.

GCP Cloud Run是长时间运行的后台进程的好选择吗？
这不是一个好的选择，因为你的容器是通过传入的HTTP请求“复活”的，只要容器响应（例如发送一些东西回来），谷歌假设处理的请求已经完成，并切断了CPU。
这可以解释这个：
解决方案已在GCP云运行上交付，但在云运行2到3秒后，容器关闭，出现503错误。

您可以尝试使用通过Cloud Dataflow部署的Apache Beam pipeline。使用Python，您可以通过以下步骤执行该任务：
阶段1.从BigQuery表中读取数据。

beam.io.Read(beam.io.BigQuerySource(query=your_query,use_standard_sql=True))

阶段2.将阶段1结果上传到GCS存储桶上的CSV文件中。

beam.io.WriteToText(file_path_prefix="", \
                    file_name_suffix='.csv', \
                    header='list of csv file headers')

阶段3.调用ParDo函数，该函数将获取在阶段2中创建的CSV文件并将其上传到SFTP服务器。您可以参考this链接。

您可以考虑无服务器、事件驱动的方法：

• 配置谷歌存储触发云函数运行转换
• 提取/导出BigQuery到CF触发器bucker -这是获取BigQuery数据的最快方法

有时以这种方式导出的数据可能太大，不适合以该形式进行云函数处理，这是由于最大执行时间（目前为9分钟）或内存限制2GB等限制，在这种情况下，您可以将原始数据文件拆分为较小的片段和/或使用storage mirror推送到Pub/Sub
我们已经使用CF处理了10亿条记录，从构建布隆过滤器到将数据发布到aerospike，整个过程只需几分钟。

如果您将Cloud Run用于长时间运行的CPU密集型任务，则需要考虑以下几个缺点：
1.请求超时：Cloud Run有最大请求持续时间限制，当前设置为60分钟。如果您的CPU密集型任务超过此限制，请求将被强制终止。如果您的任务需要更多的时间来完成，这可能会有问题。
1.资源分配：Cloud Run旨在处理短期和无状态请求，其中资源基于传入流量动态分配。但是，长时间运行的CPU密集型任务可能需要持续的高CPU使用率，这可能会使Cloud Run的资源分配模型变得紧张。
1.费用考虑：Cloud Run根据您的请求所消耗的CPU和内存资源进行收费。长时间运行的CPU密集型任务可能会消耗大量资源，导致成本高于专为持续CPU密集型工作负载设计的替代计算选项，例如Compute Engine或Kubernetes Engine。
考虑到这些缺点，通常建议将Cloud Run用于短期、无状态和可突发的工作负载，而不是长期运行的CPU密集型任务。如果你有CPU密集型任务，需要持续的高CPU使用率和更长的执行时间，你可以考虑云运行作业或其他计算选项，如计算引擎或Kubernetes引擎可能更合适。

云运行作业

Cloud Run Job专为运行短期、一次性任务或批处理作业而设计。

• 它适合运行具有定义的开始和结束的任务，例如数据处理，周期性cron作业或ETL（提取，转换，加载）操作。
• 与常规Cloud Run服务不同，Cloud Run Job示例不会根据传入流量自动扩展。
• Cloud Run Job示例将一直运行到完成或达到可配置的超时，从而允许您运行可能需要更长时间才能执行的任务。

我将尝试使用Dataflow从Big Query创建.csv文件，并将该文件上传到GCS。