轻量数据转换：Chad 与 Matt 谈 Palantir AIP 的下一代计算引擎

摘要

Palantir 架构师 Chad Walquist 与计算引擎团队的前向部署工程师（FDE）Matt Bayer 对话，主题是"轻量转换"（Lightweight Transforms）。计算引擎团队构建 Foundry 平台内所有转换数据的底层基础设施——普通 Spark 转换、Pipeline Builder 转换，以及今天的主角轻量转换。背景是多模态数据平面：加速数据处理、更快通向 AI 与自主性的一系列特性（Databricks 集成、计算下推、虚拟表）。轻量转换的目标是加速中小规模的数据转换：降低成本、提高速度，加速人们通往 AI 与自主性的旅程。

行业趋势已经改变：Spark 曾经是数据工程的经济之选，但单节点计算效率大幅提升，加上 AI 革命让人们在数据上做更有趣的事，Polars、Pandas、Data Fusion 等"单节点、闪电般快"的 Rust/原生查询引擎成为新范式。现场演示把一条近 10 亿行、14GB 压缩的欺诈检测 Spark 管道迁移到 Polars：同样的约两分钟运行时间，内存从数百 GB 降到约 29GB（约十分之一）、CPU 从 16 个执行器降到约 8 核（约四分之一）——而完成迁移只需要在 VS Code 里用 Continue 插件对 Claude 3.7 Sonnet 说一句"翻译成轻量"。

轻量转换远不止表格：支持媒体集成（下载图片与非结构化数据、OCR、交给智能体处理、输出表格）、下推到 Databricks 或 Snowflake、流式模式处理大于内存的数据集。Chad 点出终极目标：让更多数据可计算（computable），为企业自主性（enterprise autonomy）服务。而这一切都发生在 Foundry 的安全、分支、谱系与治理环境内——LLM 能在这里安全地写管道，而不是像"删掉生产数据库"那样翻车。

正文

一、计算引擎与轻量转换的由来

Matt 在计算引擎团队，构建平台内转换数据的海量基础设施：任何涉及表格数据转换的事都由他们负责——普通 Spark 转换、Pipeline Builder 里的转换、以及今天的主题轻量转换（Lightweight Transforms）。Chad 补充框架：多模态数据平面是一大套正在部署的特性，围绕加速数据处理、更快到达 AI 与自主性——Databricks 集成、计算下推、虚拟表等；轻量转换则聚焦加速中小规模的数据转换：降低成本、提高速度，加速人们通往 AI 与自主性的旅程。

为什么是现在？历史上一段时间内，数据工程社区极度聚焦 Spark——它是当时最经济的转换方式：分布式计算、一堆小节点协同完成大转换。但过去几年发生了变化：第一，单节点计算效率大幅提升——随着计算与内存成本下降，理想的形态从分布式 Spark 转向单节点；第二，AI 革命——人们用数据做的事比标准 Spark 管道有趣得多，他们需要高度灵活通用的东西，能在灵活的数据规模上运行任意计算引擎与 AI 工作流。轻量转换正是答案：给不想背大型分布式 Spark 集群开销的人，把 AI 导向的开发与管道部署封装在一种体验里。Chad 补充：真正处于"网络规模"的客户很少，多数企业是几十亿、几百亿行——中小规模数据现在能装进更大的单节点形态；你仍然可以用 Spark 做大规模分布式计算，但现在可以为问题挑选合适的计算——"互操作，不被困在一处"。Matt 强调新计算运行时：Polars、Pandas、Data Fusion——站在 Spark 巨人肩上、引入全新范式的单节点、闪电般快的 Rust 或原生库查询引擎，无论是写新管道还是迁移遗留 Spark 管道，都能带来巨大节省与加速。

二、从 Spark 到 Polars：一次真实迁移

演示：把现有 Spark 转换迁移到轻量，看看能省下什么资源。虚构的店铺销售与交易数据集：约 10 亿行、14GB 压缩（解压后更大），目标是识别疑似欺诈交易。现有 Spark 管道加载全部交易，检查各种特征：近期交易次数、行为异常、网络风险、交易属性、地理关联。有意思的是增量处理：新批次只处理新数据，但数据工程上仍需要全量历史——把新交易放进整段历史里判断它是否像欺诈。语法很简单：一个 transforms 对象拉出 Spark DataFrame 即可。

他们选择用 Polars 翻译。Polars 是最近两年快速被采纳的单节点计算引擎，但关键点在于"不限于 Polars"——你可以把任何计算引擎带进平台并运行。API 是声明式的：拉进任何常见 DataFrame 对象——Spark、Polars、Pandas、DuckDB 或任何顶级查询引擎，开箱即用。迁移过程：在仓库检出分支，用 VS Code 加开源 Continue 插件（AI 编写助手，Claude 3.7 Sonnet），对它说"翻译成轻量"。Chad 说把 VS Code 带进平台的 Palantir 安全环境、与一切集成但仍拥有这些工具，非常棒。Matt 揭秘引擎盖：转换内部有一个"完全工具化的助手智能体"——他们为转换构建了一个 MCP 服务器，可以发现你写过的转换、编辑文件、检查导入的数据，给智能体最大上下文。

对比数据：轻量执行约 2 分钟；Spark 也是约 220 秒，但观察工具显示资源消耗巨大——16 个执行器、每个 16GB 内存，虽然管道只跑 2 分钟，实际是 21 个计算分钟、数百 GB 内存。轻量转换同样 2 分钟，内存约 29GB——几乎是 Spark 的十分之一；CPU 约 8 核，而 Spark 是 16 个执行器各 2 核——CPU 成本约四分之一。而这一切的迁移成本：两年前这是极其昂贵的操作，现在有 LLM 辅助，"挥一挥手"就完成——智能体导入 Polars、应用 lightweight 装饰器（配置内存与 CPU 资源）、把逻辑改写成 Polars，几分钟内完成。Chad 感慨：资深开发者可以把这活交给初级开发者的事，LLM 几分钟搞定——"我有几百条管道，想要速度与成本的价值，现在就是问一句、走人"。

三、LLM 辅助迁移与数据分支

为什么数据分支（branching）对迁移如此重要？你不需要直接把生产从 Spark 滚切到 Polars——可以在仓库检出分支、试新变更、看数据的 diff，两条分支并行跑任意长时间，确认数据一致后再从容切换。Matt 强调数据工程世界通常不会想到的一点：Foundry 里你分支的是数据本身——不是 schema、不是管道代码，而是实际数据，可以做真正的数据 diff。同样的概念适用于版本升级：Polars 等新兴库日新月异，升级时检出分支、升级、确认一切正常、合并进 master——托管 Python 环境让这非常简单。

这也解决了"写管道的人不在了"的经典遗留问题：管理"系统"而不是管理单条管道——AI 工具让迁移与升级容易得多，预览数据再提交生产，是实验升级的完美生态：发现行为变化、在进生产前回滚。LLM 与开发者共享同一套原语：LLM 可以在分支上工作、提交 PR 给你审查——它在编译错误反馈循环上很聪明（改代码、跑编译器、修错、验证），而轻量转换让同样的循环发生在数据上：LLM 可以看它正在构建的数据集的 schema、行数、统计信息，迭代地写管道——比"一次性写完祈祷能用"走得远得多。未来甚至能看到 LLM 自动处理 OOM 错误（调资源请求）、做低效操作的 lint 提示——把人类直觉与洞见加速进管道编写，而这个智能体"看过百万条管道"。

四、超越表格：多模态数据平面

轻量转换不只是表格转换。它有完整的媒体集成：下载图片与非结构化数据、与表格数据一起转换、输出到任何地方。以前你需要一堆管道织成一张网；现在一个地方就能下载图片与文档、用你选的工具或 LLM 做 OCR、输出给函数里写的某个智能体处理、最后输出表格数据。还支持 Polars/Pandas，或下推到 Databricks、Snowflake——在 Python 运行时里做任何事，并与 Foundry 数据集生态完全集成。Chad 的框架："我需要让更多数据可计算——现在我解锁了业务中多得多的上下文与知识，因为我可以跨不同形式与类型计算。这就是我们叫它多模态数据平面（multimodal data plane）的原因。" 而这一切的真正终点是企业自主性（enterprise autonomy）：AI 智能体与自动化需要计算那些困在 PDF、邮件、电话、视频里的东西。

计算谱系从"无主见"到"强主见"：一端是计算模块（compute modules）——你带什么都能跑，本质是平台内运行的 Docker 容器；轻量转换在中间，给一个简单的声明式 API 访问任意形式的数据与计算，然后把接力棒交给你——带着 Python 环境，你想做什么都行。为什么要留在 Foundry？免费获得全套一等公民数据集特性：安全原语、分支、谱系（数据从哪来到哪去）——这些都是极有用的数据工程工具，你在笔记本上跑 Python 得不到；平台根据输入输出自动推断并给你。Chad 强调企业团队协作与安全环境的意义，尤其"vibe coding"翻车故事频出的当下：默认安全、跨一切的分支与谱系，是开发体验与最终落地生产的决定性差异。Matt 补上 LLM 的暗面：LLM 删除过生产数据库、做过各种离谱的事——在错误的环境、没有正确上下文时。而转换这类场景有安全原语（LLM 访问不到未被明确授权的数据）、标准 git 式变更流程（PR、审查、合并，像人类作者一样）——"要让 LLM 写数据管道的好处落地，这些特性不是可选的，它们是关键，是让数据在 LLM 介入时保持安全正确的必要条件"。Chad 总结：这是系统级思维，不是拼凑工具袋——"系统里所有小东西协同工作，这就是为什么人们问：Palantir 怎么这么快？"

五、流式模式与更远的地平线

迁移后的输出：同样的交易集，新增"欺诈风险等级"列，全部为低——"用一次 LLM 调用、一次提交，完整更新了 10 亿行的数据集"（数据集如今接近 23GB 压缩）。这引出"什么算太大"的问题：Polars、DuckDB 等新库正在开发流式模式（streaming mode）——不把整个数据集载入内存，而是分块处理，让你在远大于内存的数据集上操作；并非所有转换都能流式（有时确实需要全量在内存），但像计数行、求平均值这类聚合根本不需要一次载入几百 GB 甚至 TB。于是轻量单节点设置就能覆盖绝大多数日常转换——"几乎我每天看到的每条转换都能用轻量单节点跑；需要大型分布式 Spark 的才是例外：几百 TB、或必须全内存的昂贵转换"。这些库不是 Java 系的，内存管理极其高效，同样的核与内存能挤出更多性能——不只是性能，是巨大的成本削减。

创意用法：入口（ingress）——转换可以直接连接外部系统，比如用 DuckDB 的流式库从外部 S3 桶读取、写 SQL、写 Polars、从源头流入再直接流回 Foundry 数据集——那条转换本身就是一个流式管道。Chad 收束到根本转变："人人都在说'我需要数据湖、把所有数据放进一个巨大的分布式东西里'。但真正的目标是如何让数据被使用、驱动决策与行动、可供 AI 工作流或人类协作——那才是终点，不是把数据堆进一个巨大的分布式容器。" 他现在看到越来越多的客户理解：以低成本门槛处理以前根本无法处理的数据——"让更多数据可计算，为更高阶的工作流提供更好的上下文，这才是终极目标。" Matt 总结：更轻的形态、更小的足迹、更短的运行时间，让你的数据保持最新、正确、管道保持现代，真正驱动那些决策。