我尝试了那个号称要终结 Apache Airflow 的工具 (Kestra)

中文العربيةDeutschEnglishEspañolFrançaisहिन्दीBahasa Indonesia日本語한국어PortuguêsРусский
BBetter Stack
컴퓨터/소프트웨어창업/스타트업AI/미래기술

스크립트

00:00:00这是 Kestra，一家最近获得了 2500 万美元融资的初创公司，其核心承诺是：
00:00:06干掉 Apache Airflow。而他们的方法简单到甚至让人觉得有些侮辱智商。
00:00:12你不再用 Python 编写数据管道，而是改用 YAML。
00:00:17先别走开，因为这件事的意义远比看起来重要。
00:00:21接下来的几分钟里，让我来为你演示它是如何运作的。
00:00:29现在想象一下一系列必须按顺序运行的作业。提取数据、清理数据、
00:00:35加载到数据库中，然后调用 API 启动下一个环节。你可以用
00:00:41Cron 来实现。但一旦某一步失败，就麻烦了。没有重试，没有日志，根本不知道哪里出了错。
00:00:48这正是编排工具旨在解决的痛点。而 Airflow 多年来一直是
00:00:54该领域的王者。但 Airflow 的问题在于，每一条管道都是
00:00:58一个你需要编写、维护和调试的 Python 程序。整个系统非常笨重，甚至
00:01:04在自己的电脑上运行它，恐怕我们大多数人也不会感到愉快。如果你喜欢能加速工作流程的编码工具，
00:01:09一定要订阅。我们会持续更新这类视频。
00:01:14现在，Kestra 的核心理念是工作流程根本不该是一个程序。它应该只是
00:01:19一种配置。让我向你展示一下这意味着什么。我已经在浏览器编辑器中，
00:01:24并用 YAML 写了一个微型工作流。只需要几步：一步运行 Python 脚本，一步运行 shell
00:01:32命令。我可以点击执行并观察屏幕。当每一步运行时，图表会实时高亮显示当前执行的步骤。
00:01:41我可以跳转到时间轴视图，查看每个环节所花费的时间，并直接点击
00:01:47查看任何步骤的日志。整个管道刚刚运行完毕，而我甚至没写过一行
00:01:53编排代码。那么它是如何运行的呢？每个工作流程就是他们所称的
00:02:00“Flow”，本质上就是 YAML。它是一系列任务和一个启动任务的触发器。任务是
00:02:08语言无关的，这点非常重要。一个 Flow 可以运行 Python、Node、Bash、SQL 查询，
00:02:15甚至启动一个容器，全部在一条流程中完成。Airflow 强迫你使用 Python，N8N 强迫
00:02:22你使用 JavaScript。而 Kestra 根本不在乎每一步是用什么语言写的，而且触发器
00:02:27直接内置在整个系统中。像 Cron 一样定时运行，或者在 Webhook 触发时、
00:02:34文件存入存储桶时启动，亦或是通过 API 调用。我喜欢的另一点是，代码和可视化
00:02:39构建器是同步的。所以编辑其中一个，另一个会自动更新。那么，相比于我们
00:02:46正在使用的工具（比如 Airflow），你为什么要关心它呢？与 Airflow 相比，你的管道
00:02:53变成了一个简洁的配置，即使是不懂 Python 的人也能在拉取请求时阅读和审批。
00:02:59而且开发者声称其引擎处理并行工作的能力优于 Airflow 的
00:03:05调度器。这很棒，但与 Zapier 和 Make 相比，它没有 SaaS 服务，也不会按任务收费。
00:03:12它是为开发者和真实基础设施构建的，你需要自行部署。而与老派的 Cron 相比，
00:03:19你开箱即用就能获得重试、超时、真实的依赖关系图和直观的 UI。目前，
00:03:26Kestra 称其在 2025 年运行了 20 亿次工作流。是前一年的 20 倍。并且拥有
00:03:32苹果、摩根大通、丰田和彭博等大客户。当然，这些增长数字是
00:03:38公司自己提供的，并非第三方审计。所以听听就好。但越来越多的人认为，
00:03:43这种以声明式配置优先的编排方式，正是整个领域发展的方向。
00:03:49好了，还有一些局限性。首先，这是一个 Java 应用。JVM 是个“大胃王”。你至少需要
00:03:584GB 内存和几个核心才能稳定运行服务器。其次，YAML 非常适合
00:04:06清晰的线性管道。但一旦你需要复杂的动态分支逻辑，它就会变得有些棘手，
00:04:11说实话，基于 Python 的工具在这方面处理得更好。最后，Kestra 是开源核心模式。
00:04:18所以引擎本身是真正的开源，但单点登录 (SSO)、基于规则的访问控制 (RBAC) 和审计日志，
00:04:24这些功能都在付费墙之后。所以免费版本只提供一个共享登录账号。就是这样。如果你是
00:04:31独自使用，这完全没问题。但一旦你需要一个真正的多用户控制系统
00:04:36又不想付费，这就成了问题。那么你该使用它吗？最后一点可能决定了一切。
00:04:42如果你想要你的编排是可读的配置，而不是 Python 代码，那么这绝对是一个
00:04:47很酷的工具。而且它可以在 Apple Silicon 上原生运行。在 Mac 上启动它只需要一个
00:04:53Docker 命令，仪表板就会在 localhost 上出现。去试试吧。或者如果你已经
00:04:59试过了，请在下方分享你的看法。如果你喜欢这类编程小技巧，请务必订阅。
00:05:03我们会持续更新这类视频。

핵심 요약

Kestra 通过声明式 YAML 配置实现语言无关的数据编排，在提供重试、日志和可视化能力的同时，解决了传统 Airflow 开发繁琐的痛点。

하이라이트

  • Kestra 采用声明式 YAML 配置替代 Python 代码进行数据管道编排，简化了维护和审查流程。

  • 该工具支持 Python、Node、Bash、SQL 等多种语言的任务混合执行，且不按任务数量收费。

  • 2025 年 Kestra 引擎处理的工作流总量达到 20 亿次，规模是前一年的 20 倍。

  • 运行 Kestra 服务器需要至少 4GB 内存以及多核心 CPU，作为 Java 应用，其资源开销相对较高。

  • Kestra 采用开源核心模式，SSO、RBAC 和审计日志等企业级功能仅在付费版本中提供。

타임라인

传统编排工具的痛点与 Kestra 的切入点

  • 手动实现作业编排缺乏重试和日志记录，故障排查困难。
  • Airflow 将每条管道视为 Python 程序，导致系统笨重且维护成本极高。

传统数据流程通过 Cron 调度时，一旦步骤失败，系统缺乏自动重试和错误日志机制，难以定位问题。Airflow 虽然是行业标准，但其强依赖 Python 的编码方式使得管道的编写和调试过程极其复杂且臃肿。

Kestra 的配置驱动架构

  • Kestra 的工作流本质上是 YAML 配置，无需编写额外的编排代码。
  • 任务执行环境支持 Python、Node、Bash、SQL 和 Docker 容器，实现完全的语言无关性。

用户通过 YAML 定义名为“Flow”的工作流，包含任务序列和触发器。系统内置可视化界面，与代码同步更新，支持定时、Webhook、API 及文件监控等多种触发方式。这种配置优先的方法降低了管道的阅读和审批门槛。

工具对比与市场表现

  • Kestra 提供优于 Airflow 的并行处理能力，且无 SaaS 平台的按任务收费机制。
  • 该工具拥有苹果、摩根大通、丰田等企业客户，2025 年处理工作流达 20 亿次。

Kestra 面向开发者和基础设施，用户需自行部署。相比老派的 Cron，它提供了开箱即用的依赖关系图、重试机制和直观 UI。声明式配置逐渐成为编排领域的新趋势。

系统局限与使用建议

  • JVM 环境需要至少 4GB 内存才能维持服务器稳定运行。
  • YAML 在处理复杂的动态分支逻辑时比 Python 代码更具局限性。
  • 多用户控制系统（如 SSO、RBAC）在开源免费版中受限。

尽管 Kestra 适合作为声明式编排工具，但其 Java 运行环境对资源要求较高。开源核心模式意味着多用户管理功能被置于付费墙后。在 Apple Silicon 上可以通过 Docker 命令快速启动进行本地评估。

커뮤니티 글

아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!

이 영상에 대해 글쓰기