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 的工作人员软件工程师 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 补充说：“它非常重要，因为它将使我们正在考虑的演进和交付更多价值的 Observability 功能成为可能 Prefect Cloud。”

Prefect Cloud 推出了指标功能，这是利用 ClickHouse 实现更高级聚合的早期方式之一，朝着其可观测性愿景迈出了重要一步：“故障可能是需要解决的更大问题的症状。它是否每天在特定时间发生？我们希望用户能够在更大范围内修复错误，” Bedell 解释道。虽然团队从一小部分开始，只提供从过去一周的流程运行中提取的指标，但 Guidry 指出：“如果没有 ClickHouse，我们所做的将不可能实现，这产生了巨大的影响！”

在指标之后，推出了自动化功能，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 产品，其中包含更多功能和支持。