Prefect - 由 ClickHouse 驱动的事件驱动型工作流编排

Prefect 的编排和可观测性平台帮助开发者构建和理解他们的数据管道，以及至关重要的是，对它们做出反应。提供弹性且多功能的产品是他们不断发展、适应并保持与开发者需求相关的使命的指导。他们正在推动向事件驱动架构的转变，这并不令人意外，正如 Prefect 增长营销总监 Sarah Krasnik Bedell 解释说：“我们希望能够处理各种不同的数据管道和代码任务。最终目标是实现开发者、数据工程师、平台工程师和软件工程师所需的任何部署和触发模式，” 这也是 ClickHouse 成为 Prefect 不可或缺的一部分的原因。

有趣的是，Prefect 并不专注于管道的成功，而是专注于处理失败。Bedell 说：“我们希望以最有效的方式暴露错误，以帮助我们的用户对失败做出反应。” 她继续说，跟踪最重要的时刻是当事情失败时：“没有人登录到编排仪表板并说‘哇，我的管道今天很棒’，然后继续看着仪表板并待在那里，对吧？” 失败会产生观察和反应的紧迫性 — 而这正是 Prefect 的重点。

当用户捕获和处理大量数据时，工作流可观测性、灵活的自动化和通知变得越来越重要。这就是 Prefect Cloud 的用武之地，它建立在 Prefect 开源产品的强大基础上，以交钥匙、企业级和安全的方式满足这些需求：“通过 Prefect Cloud，我们将可观测性提升到一个新的水平，使人们能够观察和响应驱动其业务的任何代码的健康状况，” Bedell 说。

Prefect Cloud 并没有观察为什么某个特定的运行（工作流执行的实例）失败或出现问题，而是转向了更高层次的抽象，旨在为团队领导者服务。Bedell 希望提供可观测性，以便能够回答更复杂的问题，并具有涵盖业务影响的额外范围：“例如，我们希望使我们的客户能够回答‘在数据移动方面，最大的成本中心在哪里？’，或者可能是‘这些昂贵的机器学习管道是否优化了？’它比仅仅是批处理数据管道的代码库要广泛得多，这就是围绕 ClickHouse 的对话开始的地方。”

在一致的基础上，Prefect Cloud 每天运行超过一百万次“流程运行”——“流程”是 Prefect 中最基本的概念，代表工作流逻辑即代码的容器。Bedell 解释说：“每个流程运行的范围可能从几个到数百个任务不等。然后在每个流程运行中，从最大的对象到最小的对象进行分解，每个对象都会创建事件，这些事件可能是状态事件，也可能是创建的工件——不是一个任务，一个对象。” 拥有多租户架构意味着来自不同客户的事件都在同一个数据库中，所有事件都切片到分区中。事件也是客户的日志消息。因此，当客户在其流程过程中记录数据时，这些日志消息也是事件，正如 Prefect 的 Staff Software Engineer Chris Guidry 解释说：“我们在 Prefect Cloud 上的日志功能也由相同的事件流支持，因此容量与我们关注的基本指标相关联——人们每天运行多少流程运行。任何给定的流程都可能产生 200 多个事件。在 2 月份，Prefect 每天有 1.5 亿到 2 亿个事件，而且目标远不止于此。”

Prefect 团队最初在 Google BigQuery（一种传统的云数据仓库）上启动了可观测性平台，将其作为主要数据存储，并在前面使用了一个中等大小的 PostgreSQL 数据库实例作为热数据缓存。成功和增长很快意味着事件流达到数十亿，并且他们正在突破 PostgreSQL 功能的极限，因为这种事务性数据库并非旨在处理分析工作负载，“所有这些事件都进入 BigQuery 表中的长期存储。我们不得不垂直扩展它几个档次，而且我们绝对在突破 PostgreSQL 和 Cloud SQL 可以处理的极限，” 他继续说道。

当 Prefect 开始探索对客户工作流进行更高级别分析的可能性时，Guidry 说，在可靠地提取事件流并显示对象发生的所有事件或工作流运行期间发生的所有事件方面，已经存在挑战：“当我们开始讨论分析一周内发生的许多工作流的所有事件时，我们很快意识到这在我们的 PostgreSQL 上行不通，因为我们无法查询和聚合许多内容。” 他们需要重新思考技术堆栈，以匹配他们想要为客户交付的新价值。

此外，正如 Guidry 所描述的那样，构建用户期望实时获得答案的交互式、数据驱动的应用程序意味着成本正在上升：“在您的应用程序或用户可能每天查询该信息数百次或数千次的情况下。查询起来非常昂贵。” 成本上升是技术/用例不匹配的直接结果。Postgres 数据库非常适合处理事务性工作负载，但在回答分析性问题时，并没有有效地利用硬件资源，因为作为面向行的数据库，在仅对几列运行聚合时会扫描太多数据。另一方面，Google BigQuery 最初旨在处理数据仓库工作负载——不频繁的临时查询，因此，其基于数据扫描量的定价模型对于实时分析工作负载而言非常昂贵，在实时分析工作负载中，查询由应用程序生成并且并发性很高。

为了为他们的客户构建下一代工作流编排可观测性解决方案，Guidry 简单地说：“我们需要一个新的数据库。” 他们希望为 Prefect 用户提供更全面的指标和触发器，以及更强大的方式来询问这些数据的新问题：“对我们来说，ClickHouse 的优势在于查看大量面向时间的数据，它非常适合事件流，我们对 ClickHouse 应对挑战的方式非常满意。” ClickHouse 现在是 Prefect 数据库组合的一部分，但 Guidry 补充说：“这是一个非常重要的数据库，因为它将使我们已经在考虑的可观测性功能能够发展，并从 Prefect Cloud 中交付更多价值。”

Prefect Cloud 推出了 Metrics，作为利用 ClickHouse 进行更高级聚合的首批方式之一，这是朝着他们的可观测性愿景迈出的真正一步：“失败很可能是一个更大的问题的症状，需要修复。它是否每天都在特定时间发生？我们希望我们的用户能够更大规模地修复错误，” Bedell 解释说。虽然团队从小处着手，只使用了几张卡片来交付从查看过去一周的流程运行中得出的指标，但 Guidry 指出：“我们所做的事情如果没有 ClickHouse 是不可能实现的，这真是太了不起了！”

继 Metrics 之后，Automations 随之而来，Guidry 解释说，它是最早实现的功能之一，其宏伟目标不是捕获信息，而是至关重要的是使用户能够对其采取行动，并为 Prefect Cloud 用户提供旨在在其工作区内创建响应式系统的强大功能集。该系统现在可以通过触发后续操作来响应特定事件，因此用户可以更好地减轻风险并保持运营效率。例如，如果延迟流程发生次数的增加超过某个阈值，则向 Slack 发送的自动警报可以指示可能需要注意的潜在问题。Guidry 在解释其他场景时说：“用户可以执行自动化操作，例如数据库重启，以迅速解决潜在的数据库问题。如果故障率在特定时间范围内超过预定阈值，系统可以自动生成包含详细信息的新事件，以便快速解决。”

除了使 Prefect 能够实现他们构建在 ClickHouse 之上的实时数据驱动应用程序的愿景之外，从基于 BigQuery 和 PostgreSQL 的分析堆栈迁移还有助于简化操作和节省成本。

ClickHouse 允许 Prefect 将多个架构组件整合为一个，从而简化了他们的架构并使其更可靠：“ClickHouse 以一种全新的方式创建了弹性，需要维护的系统更少，我认为这是这项工作如此重要的另一个原因。” Bedell 说。Prefect 还拥有自主处理大规模中断和不可预见事件的工具，他们正在从该平台在创建弹性和适应性方面的潜力中获益

ClickHouse 是关键功能而非成本节约，但 ClickHouse 已将成本降低到每月不到 8,000 美元

Prefect 每月在 CloudSQL 和 BigQuery 超支上花费约 12,000 美元，因为他们的客户的查询非常复杂或需要访问大型数据集或历史数据，这将触发 BigQuery 的使用。Prefect 超出了他们的预算和使用限制，导致了额外成本。实施 ClickHouse 的主要动机是关键功能而非成本节约，但 ClickHouse 已将成本降低到每月不到 8,000 美元。正如 Guidry 总结道：“我们节省了成本，节省的成本不容小觑，但这并不是驱动因素。这是一个质的飞跃。在我们拥有 ClickHouse 之前，我们就是无法做我们想做的事情，这就是为什么我们对此如此兴奋。”

Prefect 是一个多功能的事件驱动型编排和工作流可观测性平台。它用于编排数据管道，简化了构建、调度和监控工作流的过程。基于 Python 的框架意味着用户可以将复杂的工作流定义为代码，从而更轻松地管理依赖项、处理错误和扩展工作流。Prefect 广泛应用于金融、医疗保健、电子商务等行业，在这些行业中，高效地管理和处理大量数据至关重要。Prefect 不断发展，并提供免费的开源社区版、付费的企业版和具有附加功能和支持的 Prefect Cloud 产品。