
本文字数:4068;估计阅读时间:11 分钟
作者:Sarah & Chris
本文在公众号【ClickHouseInc】首发

Prefect 的编排和可观测性平台帮助开发者构建和理解他们的数据管道,并能够对其做出响应。通过提供一个有弹性和多功能的产品,Prefect 实现了其不断进化、适应并保持与开发者需求相关性的使命。正如 Prefect 的增长营销总监 Sarah Krasnik Bedell 所解释的那样:“我们希望能够处理各种类型的数据管道和代码任务。最终的目标是满足开发者、数据工程师、平台工程师和软件工程师所需的任何部署和触发模式。” 这就是为什么 ClickHouse 已成为 Prefect 的核心组成部分。

Prefect - 大规模事件驱动的工作流自动化
值得注意的是,Prefect 不专注于管道的成功,而是处理失败。“我们希望以最有效的方式暴露错误,帮助用户应对失败,” Bedell 说。跟踪最重要的时刻是当事情失败时,她继续说道:“没有人会登录到编排仪表板并说‘哇,我的管道今天运行得很好’,然后继续查看仪表板并停留在那里。”失败创造了观察和反应的紧迫性——这正是 Prefect 的重点。
当用户捕获和处理大量数据时,工作流的可观测性、灵活的自动化和通知变得越来越重要。Prefect Cloud 诞生了,它建立在 Prefect 开源产品的强大基础上,以即插即用、企业级和安全的方式满足这些需求:“有了 Prefect Cloud,我们将可观测性提高了一个档次,使人们能够观察和反应任何驱动其业务的代码的健康状况,” Bedell 说。
相比于观察某次特定运行(工作流执行实例)失败或出现问题的原因,Prefect Cloud 正在向一个更高层次的抽象发展,旨在为团队领导提供支持。Bedell 希望提供一种可观测性,能够解答涵盖业务影响的更复杂问题:“例如,我们希望让客户能够回答‘在数据移动方面最大的成本中心在哪里?’,或者‘这些昂贵的机器学习管道是否得到了优化?’这远不只是批处理数据管道的代码库,这也是关于 ClickHouse 讨论的起点。”
通常情况下,Prefect Cloud 每天运行超过一百万次“流任务”——“流”是 Prefect 中表示工作流逻辑的最基本概念。Bedell 解释说:“每次流任务可能包含从几项到数百项任务。在每个流任务中,从最大对象到最小对象,每个都会创建事件,这些事件可以是状态事件,也可以是创建的工件——这不是一项任务,一个对象。”拥有多租户架构意味着来自不同客户的事件位于同一个数据库中,并分割成分区。这些事件也是客户的日志消息。因此,当客户在其流过程中记录数据时,这些日志消息也是事件,正如 Prefect 的高级软件工程师 Chris Guidry 所解释的:“我们在 Prefect Cloud 上的日志功能也是由相同的事件流支持的,因此流量与我们关注的基本指标相关联——人们每天运行多少次流任务。任何给定的流可能产生 200 多个事件。在二月,Prefect 每天有 1.5 到 2 亿个事件,雄心还远不止这些。”
原始数据堆栈 - Google BigQuery 和 PostgreSQL
Prefect 团队最初在 Google BigQuery 上建立了监控平台,这是一个传统的云数据仓库,作为主要数据存储,并在前端使用一个中等规模的 PostgreSQL 数据库实例作为缓存热数据。随着业务成功和增长,事件流迅速增长到数十亿级别,他们开始逼近 PostgreSQL 的性能极限,因为这种事务型数据库并不是为处理分析工作负载而设计的。“所有这些事件都进入 BigQuery 表的长期存储。我们不得不将其垂直扩展了好几倍,我们显然在逼近 PostgreSQL 和 Cloud SQL 所能处理的极限,”他继续说道。
随着 Prefect 开始探索对客户工作流进行更高层次分析的可能性,Guidry 说已经面临着可靠地提取事件流并显示对象发生的所有事件或工作流运行过程中发生的所有事件的挑战:“当我们开始讨论一周内发生的所有工作流事件的分析时,我们很快意识到这在 PostgreSQL 上是行不通的,因为我们无法对大量数据进行高效查询和聚合。”他们需要重新思考技术堆栈,以匹配他们想要提供给客户的新价值。
此外,正如 Guidry 所描述的那样,构建交互式的数据驱动应用程序,其中用户期望实时获得答案,这意味着成本在上升:“你的应用程序或用户可能每天查询这些信息数百次甚至数千次,这样的查询成本相当高。”成本上升是技术和使用案例不匹配的直接结果。Postgres 数据库非常适合处理事务性工作负载,但在回答分析性问题时不能有效地利用硬件资源,因为作为行导向数据库在对少数列进行聚合时会扫描过多数据。另一方面,Google BigQuery 最初设计用于处理数据仓库工作负载——不频繁的临时查询,因此其基于扫描数据量的定价模型对于实时分析工作负载来说是非常昂贵的,其中查询由应用程序生成,并且并发性很高。
ClickHouse Cloud - 支持下一代工作流可观测性的实时分析平台

为了为客户构建下一代工作流可观测性解决方案,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
Prefect 是一个多功能的事件驱动编排和工作流可观测性平台。用于数据管道的编排,它简化了构建、调度和监控工作流的过程。基于 Python 的框架意味着用户可以将复杂的工作流定义为代码,从而更容易管理依赖关系、处理错误和扩展工作流。Prefect 广泛应用于金融、医疗、电子商务等行业,在这些行业中,高效管理和处理大量数据至关重要。Prefect 不断发展,提供免费的开源社区版、付费企业版和具有附加功能和支持的 Prefect Cloud。
征稿启示
面向社区长期正文,文章内容包括但不限于关于 ClickHouse 的技术研究、项目实践和创新做法等。建议行文风格干货输出&图文并茂。质量合格的文章将会发布在本公众号,优秀者也有机会推荐到 ClickHouse 官网。请将文章稿件的 WORD 版本发邮件至:Tracy.Wang@clickhouse.com

64

被折叠的 条评论
为什么被折叠?



