工作池(Work pools)是 Prefect 编排层与运行流程(flows)的基础设施之间的桥梁。 使用工作池的主要原因是为了动态供应和配置基础设施。例如,你可能有一个运行频率较低且对基础设施要求很高的工作流。在这种情况下,你肯定不希望在该基础设施内运行一个空闲进程。 工作池的其他优势:
- 在工作池上配置默认基础设施配置,所有任务都会继承这些配置,并可根据需要进行覆盖。
- 允许平台团队利用工作池,为他们所管理的基础设施提供经过精心设计(且强制执行)的接口。
- 通过使用 工作队列,允许工作池对流程运行进行优先级排序(或限制)。
工作池始终是配置部署基础设施的一致接口,但只有部分工作池类型需要你运行 Worker(工作进程)。
| 类型 | 描述 | 你需要运行 Worker |
|---|
| 混合式 (Hybrid) | 你基础设施中的 Worker 会向你的基础设施提交任务运行 | 是 |
| 推送式 (Push) | 任务会自动提交到你配置的无服务器(Serverless)基础设施提供商 | 否 |
| 托管式 (Managed) | 任务会自动提交到 Prefect 托管的基础设施 | 否 |
每种类型的工作池都针对不同的使用场景进行了优化,让你能够为特定的基础设施和工作流需求选择最合适的方案。通过使用工作池,你可以高效地管理 Prefect 流程在不同环境和基础设施中的分发与执行。
工作池类似于发布/订阅(pub/sub)主题工作池通过一个已知的渠道(即池本身)帮助协调部署与 Worker。这类似于发布/订阅或消息系统中“主题”连接生产者和消费者的方式。通过切换部署的工作池,用户可以快速更改将执行其任务的 Worker,从而轻松地在不同环境中推广任务,甚至进行本地调试。
下图提供了基于工作池的部署在概念上的高层概述,该部署由 Worker 轮询并根据该部署执行流程运行。
工作池类型
Prefect 支持以下工作池类型
Prefect Cloud
自托管 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 - Push | 在 Modal 上执行流程运行。需要 Modal 账户。流程运行直接推送到你的 Modal 工作区,无需 Prefect Worker。 |
| Coiled | 使用 Coiled 在你选择的云平台上执行流程运行。无需设置 Kubernetes 或其他云基础设施即可轻松在你自己的账户中运行。 |
| Prefect Managed | 在 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 集群。 |
工作队列
工作队列提供了对任务执行方式的先进控制。每个工作池都有一个“默认”队列,如果未指定其他工作队列名称,则使用该队列。向工作池添加额外队列,可通过细粒度的优先级和并发控制,实现对工作交付的更强把控。
队列优先级
每个工作队列都有一个由唯一正整数表示的优先级。数字越小,在任务分配中的优先级越高,其中 1 为最高优先级。你可以添加新队列,而无需更改高优先级队列的排序。
队列并发限制
工作队列也可以拥有自己的并发限制。每个队列还受全局工作池并发限制的约束,该限制不可被超出。
通过优先级和并发实现精确控制
结合使用工作队列优先级和并发性,可以实现对工作的精确控制。例如,一个池可能有三个队列:
- 一个优先级为
10 且无并发限制的“低”队列
- 一个优先级为
5 且并发限制为 3 的“高”队列
- 一个优先级为
1 且并发限制为 1 的“关键”队列
这种安排实现了一种两级优先级的模式:“高”和“低”用于定期调度的流程运行,而剩余的“关键”队列用于非计划的紧急工作,例如回填(backfill)。 优先级决定了提交执行的流程运行顺序。如果所有流程运行都可以在没有并发限制或其他限制的情况下执行,优先级仍用于决定提交顺序,但对执行没有影响。 如果并非所有流程运行都能执行(通常是由于并发限制),优先级决定了哪些队列有优先权提交运行。 流程运行提交的优先级从最高到最低进行。在前面的例子中,来自“关键”队列(优先级 1)的所有工作都会在“高”(优先级 5)队列提交任何工作之前被提交。一旦“关键”队列中的工作提交完毕,“高”队列中的工作便开始提交。 如果在流程运行仍在“高”和“低”队列中排队时,新的流程运行被接收到“关键”队列中,流程运行的提交会回退以确保所有已调度的“关键”工作优先得到满足。这种情况会以瀑布式从最高优先级队列开始,直到队列清空。工作队列状态当工作队列在过去 60 秒内被 Worker 轮询过时,它处于 READY 状态。暂停工作队列使其进入 PAUSED 状态,这意味着它在恢复之前不会接受任何新任务。用户可以在 UI 中控制工作队列的暂停状态。恢复工作队列会使其进入 NOT_READY 状态,除非它在过去 60 秒内被 Worker 轮询过。
扩展阅读