跳转至主要内容
工作池(Work pools)是 Prefect 编排层与运行流程(flows)的基础设施之间的桥梁。 使用工作池的主要原因是为了动态供应和配置基础设施。例如,你可能有一个运行频率较低且对基础设施要求很高的工作流。在这种情况下,你肯定不希望在该基础设施内运行一个空闲进程。 工作池的其他优势:
  • 在工作池上配置默认基础设施配置,所有任务都会继承这些配置,并可根据需要进行覆盖。
  • 允许平台团队利用工作池,为他们所管理的基础设施提供经过精心设计(且强制执行)的接口。
  • 通过使用 工作队列,允许工作池对流程运行进行优先级排序(或限制)。
工作池始终是配置部署基础设施的一致接口,但只有部分工作池类型需要你运行 Worker(工作进程)
类型描述你需要运行 Worker
混合式 (Hybrid)你基础设施中的 Worker 会向你的基础设施提交任务运行
推送式 (Push)任务会自动提交到你配置的无服务器(Serverless)基础设施提供商
托管式 (Managed)任务会自动提交到 Prefect 托管的基础设施
每种类型的工作池都针对不同的使用场景进行了优化,让你能够为特定的基础设施和工作流需求选择最合适的方案。通过使用工作池,你可以高效地管理 Prefect 流程在不同环境和基础设施中的分发与执行。
工作池类似于发布/订阅(pub/sub)主题工作池通过一个已知的渠道(即池本身)帮助协调部署与 Worker。这类似于发布/订阅或消息系统中“主题”连接生产者和消费者的方式。通过切换部署的工作池,用户可以快速更改将执行其任务的 Worker,从而轻松地在不同环境中推广任务,甚至进行本地调试。
下图提供了基于工作池的部署在概念上的高层概述,该部署由 Worker 轮询并根据该部署执行流程运行。

工作池类型

Prefect 支持以下工作池类型
基础设施类型描述
进程 (Process)在 Worker 上以子进程形式执行流程运行。非常适合刚开始时的本地执行。
AWS Elastic Container Service (ECS)在 AWS ECS 的容器内执行流程运行。适用于 EC2 和 Fargate 集群。需要 AWS 账户。
Azure Container Instances在 Azure 容器实例服务中的容器内执行流程运行。需要 Azure 账户。
Docker在 Docker 容器内执行流程运行。非常适合通过 Docker 镜像管理流程执行环境。需要访问正在运行的 Docker 守护进程。
Google Cloud Run在 Google Cloud Run 的容器内执行流程运行。需要 Google Cloud Platform 账户。
Google Cloud Run V2在 Google Cloud Run (V2 API) 的容器内执行流程运行。需要 Google Cloud Platform 账户。
Google Vertex AI在 Google Vertex AI 的容器内执行流程运行。需要 Google Cloud Platform 账户。
Kubernetes在 Kubernetes 集群上调度的作业(Job)内执行流程运行。需要 Kubernetes 集群。
Google Cloud Run - Push在 Google Cloud Run 的容器内执行流程运行。需要 Google Cloud Platform 账户。流程运行直接推送到你的环境,无需 Prefect Worker。
AWS Elastic Container Service - Push在 AWS ECS 的容器内执行流程运行。适用于现有的 ECS 集群和通过 AWS Fargate 进行的无服务器执行。需要 AWS 账户。流程运行直接推送到你的环境,无需 Prefect Worker。
Azure Container Instances - Push在 Azure 容器实例服务中的容器内执行流程运行。需要 Azure 账户。流程运行直接推送到你的环境,无需 Prefect Worker。
Modal - PushModal 上执行流程运行。需要 Modal 账户。流程运行直接推送到你的 Modal 工作区,无需 Prefect Worker。
Coiled使用 Coiled 在你选择的云平台上执行流程运行。无需设置 Kubernetes 或其他云基础设施即可轻松在你自己的账户中运行。
Prefect Managed在 Prefect 托管的基础设施上的容器内执行流程运行。

工作队列

工作队列提供了对任务执行方式的先进控制。每个工作池都有一个“默认”队列,如果未指定其他工作队列名称,则使用该队列。向工作池添加额外队列,可通过细粒度的优先级和并发控制,实现对工作交付的更强把控。

队列优先级

每个工作队列都有一个由唯一正整数表示的优先级。数字越小,在任务分配中的优先级越高,其中 1 为最高优先级。你可以添加新队列,而无需更改高优先级队列的排序。

队列并发限制

工作队列也可以拥有自己的并发限制。每个队列还受全局工作池并发限制的约束,该限制不可被超出。

通过优先级和并发实现精确控制

结合使用工作队列优先级和并发性,可以实现对工作的精确控制。例如,一个池可能有三个队列:
  • 一个优先级为 10 且无并发限制的“低”队列
  • 一个优先级为 5 且并发限制为 3 的“高”队列
  • 一个优先级为 1 且并发限制为 1 的“关键”队列
这种安排实现了一种两级优先级的模式:“高”和“低”用于定期调度的流程运行,而剩余的“关键”队列用于非计划的紧急工作,例如回填(backfill)。 优先级决定了提交执行的流程运行顺序。如果所有流程运行都可以在没有并发限制或其他限制的情况下执行,优先级仍用于决定提交顺序,但对执行没有影响。 如果并非所有流程运行都能执行(通常是由于并发限制),优先级决定了哪些队列有优先权提交运行。 流程运行提交的优先级从最高到最低进行。在前面的例子中,来自“关键”队列(优先级 1)的所有工作都会在“高”(优先级 5)队列提交任何工作之前被提交。一旦“关键”队列中的工作提交完毕,“高”队列中的工作便开始提交。 如果在流程运行仍在“高”和“低”队列中排队时,新的流程运行被接收到“关键”队列中,流程运行的提交会回退以确保所有已调度的“关键”工作优先得到满足。这种情况会以瀑布式从最高优先级队列开始,直到队列清空。
工作队列状态当工作队列在过去 60 秒内被 Worker 轮询过时,它处于 READY 状态。暂停工作队列使其进入 PAUSED 状态,这意味着它在恢复之前不会接受任何新任务。用户可以在 UI 中控制工作队列的暂停状态。恢复工作队列会使其进入 NOT_READY 状态,除非它在过去 60 秒内被 Worker 轮询过。

扩展阅读