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 补充说：“它非常重要，因为它将使我们已经考虑到的可观察性功能得以发展，并从 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 已将成本降至每月不到 8000 美元。

Prefect 每月在 CloudSQL 和 BigQuery 超额使用方面花费约 12000 美元，因为他们的客户的查询非常复杂，或者需要访问大型数据集或历史数据，然后会触发 BigQuery 的使用。Prefect 超过了他们的预算和使用限制，导致额外成本。实施 ClickHouse 的主要动机是关键功能，而不是成本节约，但 ClickHouse 已将成本降至每月不到 8000 美元。正如 Guidry 总结的那样：“我们节省了成本，节省的成本不容小觑，但这不是驱动因素。这是一项质的飞跃。在我们拥有 ClickHouse 之前，我们无法做到我们想要做的事情，这就是我们如此兴奋的原因。”

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