Pipeline Builder 轻量转换：一键把 Spark 管道搬到单节点引擎

摘要

Palantir 架构师 Chad Walquist 与 Pipeline Builder 团队技术负责人 Xander 演示了轻量转换（Lightweight Transforms）在 Pipeline Builder 中的落地。Pipeline Builder 是 Palantir 平台的低代码（no-code）管道构建工具，让任何技能水平的用户都能跨平台接入数据并整合进本体论（Ontology）。过去，批处理管道只能在 Spark 上执行——这类大型分布式工作负载适合超大规模数据；团队过去 18 到 24 个月为 Pipeline Builder 实现了全新后端，基于开源的 Apache Data Fusion 项目，在单节点上以极其资源高效的方式运行，且速度极快。

演示以一条真实管道展开：约 7700 万行、2000 万行与 20 万行三个数据集做两次内连接，加上列规范化与字符串清洗。Spark 版用「medium」配置（16 个执行器、每个约 6GB 内存，加上 driver 6GB，总内存超过 100GB，还有 33 个 CPU）运行约 8-9 分钟。点击「转换为轻量管道」——绿色勾号出现——部署到仅 8 核、60GB 内存的配置：应用初始化约 7 秒（对比 Spark 模块要启动 JVM、下载 JAR、初始化 Spark context），不到 20 秒就已开始运行，最终 6 分半完成——用四分之一 CPU、一半内存，还更快。

并不是所有管道都能一键转换：不支持的算子（如 repartition）会在内联检查中明确指出，删除后即可转换；暂不支持的算子（如部分地理空间能力）可以随时切回 Spark。甚至可以在 Foundry 里把一条管道的一部分跑在轻量引擎、另一部分跑在 Spark，按需编排。Xander 的结论是：先用轻量转换起步，真正需要时再回到 Spark——「为什么不一键试试呢？」

正文

一、从 Spark 到 Data Fusion：Pipeline Builder 的新后端

Xander 介绍，Pipeline Builder 是平台上的低代码管道构建工具：任何技能水平的用户都能跨平台接入数据、整合进本体论。Chad 坦言自己手工构建管道 15 年以上，却依然最喜欢 Pipeline Builder——既能快速构建出健壮、可扩展的管道，又保有灵活性（必要时退出到 UDF 或其他组件）。

本期焦点是轻量转换在 Pipeline Builder 中的含义：团队已从「批处理管道只能在 Spark 上执行」的世界走出来。Spark 是大型分布式工作负载，适合超大规模数据；而 Pipeline Builder 的全新后端基于开源的 Apache Data Fusion 项目——它在单节点上执行，极其资源高效，而且非常快。这个项目已经打磨了 18 到 24 个月。

演示管道是典型的数据集成：左侧开始，连接几个数据集、规范化列、做字符串清洗，写入输出。规模参考：7700 万行、2000 万行、20 万行三个输入，两次内连接应该匹配很多。这条管道刚跑过一次构建，总耗时约 8 到 9 分钟；资源方面用的是「medium」配置：16 个执行器（并行度很好，全部用满），每个执行器约 6GB 内存，driver 还有 6GB——整个 Spark 模块内存超过 100GB；每个执行器 2 个 CPU，driver 另有 1 个。Chad 特意展示这些数字，是为了在转换后对比：轻量转换不仅要更快，还要用更少的资源。

二、一键转换：从 16 个执行器到单节点

怎么转换？Xander 强调这正是采用率应该极高的原因——「真的就是点一下」。点击「转换为轻量管道」，得到绿色勾号。并非所有管道都能转换：团队对支持的算子覆盖度很高，但还不是全部；如果有不支持的算子会显示错误——稍后会看到——可以修复后再转换。点下转换，左侧显示「lightweight」，然后部署。

部署面板里选择一个匹配的配置：8 核、60GB 内存——CPU 数量减半、内存大约减半。保存、部署、启动构建。立即注意到一个不同：因为使用轻量容器，应用初始化时间约 7 秒——相比之下，Spark 模块需要启动 JVM、下载 JAR，光是 Spark context 就有大量初始化时间。构建开始后不到 20 秒就已经在运行了。Chad 指出，这对开发者体验也是巨大帮助：现在可以迭代——即使只用一个子集的数据，或只是跑一下获取反馈、测试某个想法。加速的不只是生产运行时间与成本削减，还有开发循环本身。

另一个体验细节：预览（Preview）功能——Pipeline Builder 的招牌能力——现在也跑在轻量引擎上。预览会实时显示管道到当前阶段为止的转换结果，而它运行在轻量后端上，「非常敏捷」。在迭代过程中，这种体验极其顺手。Chad 直言：即使运行时间完全一样，能快速预览整条管道就已经是巨大的胜利。

三、兼容性检查与双引擎管道

第二条演示管道操作非常相似，但在设置里尝试转换时遇到问题：repartition 不受支持。点击开关，会在管道内联位置高亮这些区域——repartition 是 Spark 操作，在轻量世界里并不必要。直接把该节点删除、保存，再回到转换页面就得到绿色勾号，可以转换并部署了。

为什么不直接用 DuckDB 之类的引擎做后端？Xander 解释：Pipeline Builder 后端选择 Data Fusion，因为它可扩展性好、有与 DuckDB 类似的配置（包括内存溢出问题的处理方式），并且允许与产品更深地集成；而在代码仓库场景中，轻量转换让用户可以用 DuckDB、Polars 或任何想要的计算引擎——人们确实拥有这种可选性。Chad 认为最酷的一点是：一次编写（author once），在多个不同环境运行，甚至测试不同的性能画像——他接触的客户有从 10 分钟降到 2 分钟的。从分布式系统转向资源更集中的单节点，让操作本身更高效，这才是关键效率增益所在。

Xander 也诚实地划出边界：Spark 仍然会赢的场景确实存在——处理 TB 级数据、做非常大的 shuffle 连接时，Spark 依然占优。但其他情况下，轻量世界也能相当出色地胜任（演示就在相当规模的 7700 万行数据上运行）。他甚至透露，Palantir 内部已经开始用轻量转换处理自己的内部日志管道：这些管道读取 TB 级数据，但因为是向下聚合，单节点上永远不会堆积太多数据——所以完全可行。「很多人会对轻量转换能做到的事感到惊喜。」

还有一类情况：轻量暂不支持的算子——比如演示底部显示的一堆地理空间（geo）能力尚未支持。解决办法是直接切回 Spark，用足 Spark 版的全套能力继续开发，几乎不受阻碍。这意味着一条管道的一部分可以跑在轻量引擎、另一部分跑在 Spark——通过 Foundry 编排，把不同计算引擎的管道「缝合」在一起，按需求降低成本、提升性能——这就是可选性。

四、结果与取舍：什么时候仍该用 Spark

构建仍在运行：预估 9 分钟——这是 Spark 上一次运行的时间，「这是要打败的纪录」。转换后再次运行，最终 6 分 30 秒完成：对比 Spark 的约 9 分钟，运行在少一半的内存、四分之一的 CPU 上。「相当大的成本削减，而且更快，只需一键——还有什么不爱？」收益因工作负载而异：有的客户性能增益大得多，完全取决于管道类型。理念很简单：「为什么不先从轻量转换开始，只在真正需要时才转换到 Spark？」Chad 以 15 年管道老兵的身份总结：能一次编写、一键切换到不同后端运行，是他近年见过最令人兴奋的事情之一——团队也很期待把它交到用户手里，看看大家能跑出什么结果。