数据工程就是缓存失效问题：专访 Josh Wills

在本期节目中，我们深入探讨模型到底有多重要：它更像是一种偏好，就像你用的是 iPhone 还是 Android，而不是它们的能力。我们聊到运行 Kubernetes 时的裸金属磁盘，然后转向智能体，以及数据工程如何变得像是在飞机上担任紧急飞行员，还有我们如何自动化掉那些无聊的工作，不再有数据库迁移或单元测试。

我们进入了精神领域，他会凭直觉感受一条流水线是否能行得通。最后我们聊到，随着这个领域飞速演变，每个数据工程师或软件工程师最终都想去的地方：一个开满美丽花朵、没有屏幕的农场。这是第 5 期访谈。希望你喜欢。

本文分为四个部分：(1) Kubernetes 和磁盘抽象如何成为他工作的关键，(2) 他如何与模型和智能体协作，以及模型到底有多重要，(3) 他使用什么工具，以及智能体如何减轻他的工作负担，(4) 数据工程是否会被智能体自动化掉。

介绍嘉宾：第 5 期 Josh Wills

Josh Wills 是一位拥有 25 年经验的软件和数据工程师。在 Google，他参与了广告拍卖系统，并领导了 Google+ 背后的分析基础设施。在 Cloudera 担任数据科学负责人期间，他创立了 Apache Crunch 项目，并合著了 O'Reilly 的 Advanced Analytics with Spark，之后他又构建并领导了 Slack 的数据工程团队。他还是 dbt-duckdb 适配器的最初创造者。

自 2024 年以来，Josh 一直是 DatologyAI 的技术人员。DatologyAI 帮助团队更快、更小地训练更好的模型。在那里，他构建自动为深度学习模型训练选择最佳数据的工具，以及以万亿 token 预训练规模处理这些数据的分布式流水线。我们更详细地探讨了处理如此庞大数据集需要什么。

提示：趣闻

他基本上在 2022 年就退休了，而“AI 那些事又把他拉了回来”😉

DuckDB 是的，但还有 Kubernetes 磁盘抽象

你们很多人可能知道，Josh 是 dbt-duckdb 的最初创造者，所以我问他是否还在使用 dbt，更重要的是，他用多少 DuckDB。

他的回答是每个人都在用：“每个人都在某种程度上使用 DuckDB。我觉得任何了解 DuckDB 的人都会用它做点什么。每个人都有自己的特定用例”。他在工作中的特定流水线里用得较少，因为他们有巨大的数据集，是文本数据，不是经典数据集：比如 30 TB 都算小。他用 Spark 或 Ray。他日常处理的大部分是文本和多模态数据（时间序列、图像等），没有太多经典的关系型数据。

他经常使用 DuckDB 的一个用例是读取 S3 上的 Parquet 元数据，因为上述数据流水线“会产生大量 Parquet 元数据，这些元数据仍然很可观，但小得多，大约 100 GB 量级”。这些信息包括运行情况、某个数据集最后一次用于训练模型的时间、他无限期将其存储在 S3 上要花多少钱。他通常让智能体在 EC2 上的开发机上读取这些数据，他在上面运行这些命令，以减少传输时间，纯粹为了速度。

注意：DuckDB 已集成到 dbt v2 中

有趣的是，dbt-duckdb 刚刚获得了更新。DuckDB 的 dbt 适配器于 2021 年 8 月 27 日收到了它的 第一个拉取请求 ，与此同时 在 GitHub 上已获得 1.4k 颗星。自那以后，dbt 用户只需安装一个 Python 包（dbt-duckdb，通过 pip），将其指向一个文件（本地 DuckDB 数据库），就能拥有一个可用的项目（模型构建为表和视图），而无需注册（并付费购买）服务器或数据仓库。在最新版本中，DuckDB 现在通过 dbt Fusion 引擎在 dbt 内部运行。参见 DuckDB 现已随 dbt v2 一同发布。

“我们失去了一整代”数据基础设施人才，2022 年退休，AI 把他拉了回来

当谈到自他在 Google 担任资深工程师（2007–2011 年）并领导 Slack 的数据工程（2015–2019 年）以来发生了什么变化，以及如今数据工程工作负载因 AI 而有何不同时，他说 Snowflake 很棒。尽管如此，我们已经没多少人还知道数据在磁盘上是如何布局的。

但对他这种规模的工作负载来说并非如此。Josh 处理的数据之大，我们普通人几乎难以想象，这就是为什么他使用大量 Kubernetes 作业和工作负载。他喜欢 Apache Celeborn（发音：拼写为 Celeborn，读作“Keleborn”），它抽象了磁盘（无需知道它们物理上来自哪里），因为在 Kubernetes 中你仍然需要手动处理，Kubernetes 并没有真正实现云抽象，他说：

Kubernetes 的绝妙之处在于，理论上它抽象于单个云之外，但实际上并非如此，因为你的磁盘从何而来？如果你在 AWS 或 GCP 上，你可以使用类似 EBS 的服务，但如果你运行的是裸金属，那就不存在同样的东西。

Celeborn 有一种叫做基于推送的 shuffle 写入的机制，映射器节点跳过本地磁盘存储，非常适合云原生架构，这让你能够分离存储和计算，因此

从 shuffle 的角度来看，Spark 作业不再需要担心它们的磁盘来自哪里。有 shuffle 服务，无论你要 shuffle 多少数据。你有本地磁盘，然后你有 shuffle 服务来满足你所有其他磁盘需求。

注意：没人记得如何运行 Spark 集群了

Josh 说最难的事情是：

在需要思考这些东西的地方，这样的人已经相对很少了。整个数据社区在十几年代末期都变得对 Snowflake 趋之若鹜。我在上一家公司使用了 Snowflake，它是一个出色的产品。但我们某种程度上失去了一整代人。已经没多少人还记得如何自己运行一个大型、有效开源、Spark 集群了。

模型对你有多重要？

当被问及模型以及它们有多重要时，Josh 说对他来说就像 iMessage 的蓝色气泡与绿色气泡。Android 手机很棒，但他想要蓝色气泡。而 Josh 的预测是，所有模型都会变得有能力，所以真正的问题变成了：

你喜欢哪一个，并且享受与之相处

来源：Josh 的推文

上面，Josh 解释了他如何不喜欢 Opus 5 模型，并且继续如此。在这次采访中，他补充说，这也与它的沟通方式有关。他说，作为一个整天致力于构建模型的人，这是一个有趣的见解：

Opus 5 如此糟糕，这让我深深意识到，在训练这些模型这件事上，我们根本完全不知道自己在做什么。

好消息是：改变可能比以往任何时候都更容易¹，而且他非常不喜欢之前的 5.0，以至于他改变了工作流程，转投 OpenAI。他评论道：

生产力没有下降，这简直有点疯狂。

提示

我学到的一个技巧：使用穴居人技能，并在开始时加载它。我只用它那一个 MD 文件，然后每个模型听起来都一样，甚至使用更少的 token，也更简洁。阅读它也不需要那么多脑力。

如今如何用智能体编程

接下来，我们谈到了与智能体协作。他开玩笑地回到了一条推文，在推文中他想创办一家强化学习（RL）环境公司，由他来教学：

Josh 说：

[..] 一个玩笑，我想创办自己的 RL 环境公司，那里只有我教模型如何不写出绝对垃圾的数据管道。因为我用智能体来写我所有的代码，极少有例外。然而我仍然发现自己对它所写的数据管道深感不满。

提示：他最喜欢的实用工具仍然是 htop

他在 2022 年就说过他喜欢 htop。当被问及他最喜欢的工具时，他说 htop 非常棒，而且他在做的很多事情中仍然使用 htop。如果你不知道的话，它可以让你一眼看到机器的所有进程和 CPU。参见htop - 一个交互式进程查看器。

如何用智能体获得快速反馈循环？

Josh 说 AI 在有大型训练模型和快速响应的地方会赢，因为如果不在训练数据中，它就会很慢，需要做很多事情。他说：“任何模型拥有高度可靠的训练数据和快速反馈机制的环境，它们都会占据主导地位。绝对会占据主导地位。你在数学中看到这一点，你在前端工程中看到这一点，任何有快速反馈机制的 RL 环境都是如此。”

而这正是当今大规模数据管道所缺失的：

数据管道的棘手之处，至少在大规模情况下，在于你实际上并没有那种快速反馈机制可用，因为运行一个巨大的管道可能需要很长时间和大量计算机。

快速反馈循环也是 Josh 早在将近四年前、在任何 AI 炒作之前就已经提到的。他喜欢快速反馈循环，并引用了 Erik Bernhardsson 的话：

注意

有趣的是，今天Jev 在网上获得了大量赞誉，它基于用于校准决策的强化学习（RLCD），这基本上就是 Josh 想要的。

感受元组在管道中流动，一种直觉

Josh 凭借他多年的经验，建立了一种直觉：

经过年复一年的痛苦和编写庞大的管道，我可以看着一个管道，它对我来说有点像某种感觉。我能感觉到元组在其中流动，因为我对这将如何发展有一个心理模型。

他解释了 SQL 数据库如何拥有一个很棒的快速反馈机制，即查询解释计划。它们会告诉你这是一个好查询还是坏查询。但对于 Spark 作业来说，还不完全是这样。²

Josh 描述了数据管道的一种美学层面：

奇怪的是，我对数据管道有一种审美感受力。一条数据管道对我来说可以是美的。它可以是优雅的、精心设计的、深思熟虑的。这让我想要去观看，就像其他人去参观艺术博物馆，或者因为觉得数学证明很美而去阅读它们一样。

这就是他在智能体所写的内容中仍然看到很多“丑陋”的地方。几周前我们交谈时，它们还不美。Josh 说：“我合作过的一些最优秀的程序员是科班出身的音乐家”。他接着说道：

谷歌有一位杰出工程师，他的硕士学位是小提琴，而我认为他是我见过的最好的程序员，因为他的代码就像音乐一样。它很美。

我对写作也有类似的偏好，好的写作有一种音乐般的品质，某些人能听出来。过一段时间，你就会对好的写作培养出一种听觉。它在你脑海中听起来像某种东西，像诗歌或散文。Josh 说：“这是我们还没弄清楚如何以任何方式用 RL 来训练的东西”。

成本方面，字面意义上的烧钱

谈到成本时，Josh 说：

“模型可能会把时间浪费在最迂腐、最愚蠢的错误检查上，而鉴于我对上游数据源结构的了解，这些错误根本不可能发生。”“字面意义上的烧钱”

他接着说，这些管道非常庞大，计算成本很高。模型可能会为平均规模的数据编写管道，但并不具备关于“巨型管道”的知识或大规模训练数据：“它能运行，是正确的。只是成本效率低得离谱”。

他在那些裁掉数据团队的公司里见过这个问题，因为 LLM 可以在 Databricks 中凭感觉编写一个作业。他是这样说的：“你可以轻松地在 Databricks 中凭感觉编写一个每天运行成本约二十万美元的作业，而一位称职的数据工程师，或者至少一位监督过它的工程师，绝不会写出这样的东西。”

这不是模型的错，而是训练数据的函数，这些数据没有研究或运行过大量“跨数百台机器运行数小时的巨型数据管道”。

目前强化学习环境的构建方式就不是这样的：

它是这种快速反馈循环：小数据，它正确吗？小前端，它正确渲染 CSS 了吗？

Josh 做了一个很棒的类比科学：

人们经常谈论科学也有同样的问题。实验室、生物学、物理学，这些都是真实的东西，你确实必须等待培养物生长。数据工程有一个轻量级的版本。我们现在还不太适合这种反馈风格。

在我们进行采访时，他发现这些模型在 SQL 方面非常出色。“它们真的非常非常棒，”他说。但对他那类工作（原始 Ray 管道、Spark 管道）来说，没有解释计划。正如他所说，你仍然要从头开始构建这个东西。

“紧急异常处理员”的工作

他提到，在他的工作中，因为模型还没有学会所有东西，他基本上就像一个通常靠自动驾驶飞行的飞行员，但在紧急情况下，他要在那里修复或接管。

他使用的是什么工具，以及智能体如何减轻他的工作负担

正如最初指出的那样，他不喜欢 Opus，转而使用 Codex，所以现在他一直用 Codex，但他曾长期使用 Claude。

当被问及他如何工作或审查代码时，他说：主要是提供反馈，就像一名资深工程师那样。他说，作为一名高级技术个人贡献者，他的生活长期以来一直朝着这个方向发展。他主要提供反馈。那是他的主要工作。面试他人、审查设计文档，较少亲自动手，极少有例外。

他喜欢处理高要求、高紧急性的工作，这迫使他去创造。这又回到了“紧急异常处理器”：

如果有一个烂透了的数据管道，而且必须立刻运行，因为客户有一个训练任务即将开始，数据必须为它准备好。那就是我提供的主要价值。

Josh 喜欢智能体的地方：没有感情，以及咖啡因调节旋钮

Josh 还透露，他喜欢与智能体合作，因为智能体没有感情。他说，他可以随时给智能体反馈，强制创造东西：

我不必对智能体非常友好。

他可以直接说：

我不必关心它们的感受或职业发展，因为当我结束这次编码会话时，它们就不存在了。我可以这样说：这很糟糕，你应该感到糟糕。Ctrl-C，你死了，我要换别人重新开始。

作为一个自称“相当平庸的管理者，因为我通常不喜欢关心这些事情”的人，这对他很有效 🙂³。

他说的另一件有趣的事：

我可以根据需要调高或调低工作量。如果我需要五个智能体同时运行，我可以做到。如果太多了，我就调低。就像我试图在一天中的任何时刻维持一定水平的咖啡因一样，我可以维持一定的节奏来匹配我的精力，匹配我当下的状态。我是超级兴奋，还是有点无聊？这是这个新世界的一个优点，以前并非如此。

就像咖啡因剂量一样。

不再有单元测试！

他还喜欢将大部分无聊的工作自动化。谁想再做一次数据库迁移？或者修复“不稳定的单元测试”？他说，他喜欢做更高层次的战略性工作，这就是人们最终成为投资者或产品经理的方式。

更进一步：

我有一个智能体，它的全部工作就是监视不稳定的测试并修复它们。就这样，它只做这个。数据库迁移？绝对不行。我有一个智能体负责数据库迁移。我已经把我生活中最糟糕、价值最低、最不愉快的部分自动化掉了，我对此非常欢迎。

对他来说，这是巨大的质量提升。而且他可以非常专注于他喜欢的事情，以及杠杆效应高的地方，去做出艰难的决定。

留下的就是所做的决定，而沟通原因至关重要

关于代码审查，在智能体包办一切的世界里，他试图坚决做到的一件事是：

对于每个项目，我都非常专注于我正在做出的决定。

他提到了 Datology 的一个具体例子，他正在构建一个数据集索引，以确定数据集的哪些部分可以在其他地方整体或部分重用：

• 选项 A：在读取时查询元数据目录，找出有用的资产。
• 选项 B：预先编写一个显式索引：“此资产存在于该索引中，并且可用于此目的”

他说：

两种选择都有效，各有利弊。我在这里做了一个明确的权衡，而这些是我需要传达的决策。索引如何工作的细节则远没有那么重要。

他提出了一个很好的观点：

真正需要传达的是决策。决策构建了共同的理解，我们做出的选择，权衡取舍。这仍然是工程工作的核心。

我也认为这一点最为重要，如果不小心的话，它可能会演变成恶性循环，正如有人在这条推文中吐槽的那样。此外，在我看来，智能体迫使你专注于架构，这就是为什么它们对资深人士来说更顺手。

数据工程会被智能体自动化掉吗？

Josh 明确表示数据工程不会消失。原因和它长期以来没有消失一样：根本问题不会消失。我们仍然在解决物化视图和缓存的问题！

我看不出数据工程会以任何方式、任何形态消失，即使在这个世界里也是如此。除了强化学习环境问题使得智能体异常难以擅长运行这些超长流水线之外，数据工程的根本问题与我整个职业生涯中一直面对的问题相同，也与我开始工作前 25 年的问题相同。这就是物化视图问题。

问题是：“我现在应该预处理和创建哪些数据，以便以后让查询更快，哪些东西不值得做，哪些应该即时处理？”这些就是根本问题。

他说这将是“超级智能的问题”，因为：

这不是一个固定不变的东西，它会持续变化，正确的权衡也会不断改变。

Josh 说，除了强化学习之外：

这是计算机科学中的两个难题，对吧？缓存失效和命名。而智能体仍然不擅长它们，因为它们确实很难。

“数据工程从根本上就是缓存失效问题，”他继续说道，“只是在批处理环境中完成”。

注意：连 Hannes 也开始使用 Claude Code 了

Hannes Mühleisen 在DuckDB、DuckLabs 的过去、现在和未来中表示，自 2026 年 5 月左右 Quack Protocol 发布以来，他现在使用 Claude Code 来开发 DuckDB。所以自那以后他没有写很多代码，但他仍然会查看一些东西。

谦逊与倦怠

最后，我们谈到了谦逊以及如何避免倦怠。

保持谦逊有帮助，他说他很擅长这一点，并告诉家人：

我同时是一个白痴，也是我所做领域的世界顶尖之一。

我说我们可能都感受到某种矛盾心理，因为 AI 能完成我们的一部分工作，我们感到自己不被需要。这正是谦逊能帮助我们之处。Josh 还补充说，他有点感激自己仍然能坐在键盘前编程。这对他来说“极其有趣”，他热爱能身处这个时代。

我问他，当智能体不以他的方式生成代码时，他是否会倦怠。或者他是否将其分为“我不介意的代码”和“我想要完美的代码”？他说他的优势在于已经做了“非常非常长的时间”：

现在的我能容忍年轻时的我绝对不会、绝对不会、绝对不会容忍的事情。我已经习惯了与有些“固执”的人进行反馈循环。

他说，有一次，agent 找不到他正在向它描述的一个问题：“而且我无论如何都没法让 agent 按照能实现这一点的写法来编写 pipeline。”他当时在告诉 agent“你不能这样使用缓存”，但 agent 就是控制不住自己。他不得不亲自接手。

这又是一个异常处理场景的完美例子。Josh 说，“找出这些情况——无论出于什么原因，模型确实无法完成我要求它做的事——算是如今我的工作之一”。但他说，模型每天都在变得更好：

现实情况是，我不再遇到那么多这类问题了。

结论

这次对话的一个主要收获是：数据工程就是缓存失效问题，只不过是在批处理场景下进行的。这一点很重要：做对了的话，agent 会占据主导，因为反馈循环很快，就像带执行计划的 SQL 或数学一样。而运行数小时、横跨数百台机器的庞大 Spark 和 Ray pipeline 还没有这样的循环。这就是为什么 Josh 最终仍然要充当紧急异常处理者，也是为什么其他人可以凭感觉写出一个每天花费 20 万美元的 Databricks 作业。

有意思的是，模型本身对他来说并不那么重要。更重要的是设计和感觉，比如蓝色气泡与绿色气泡：选一个你乐意与之相处的，不喜欢了就换掉，或者把不稳定的测试和数据库迁移交给 agent。剩下的就是数据工程一直以来最难的部分：做决策并沟通权衡取舍。

我们聊得有点玄乎，Josh 能感受到元组在 pipeline 中流动，而话题最终落到我们许多人在这个领域飞速发展时都会去的地方：梦想着一座开满美丽花朵、没有屏幕的农场 🙂。Josh 承认他也时不时会心动：“也许我就再退休一次，去下下棋。我可不是铁打的。”

希望你喜欢这期访谈系列节目。也去看看其他几期，从 Mark Freeman、Chris Riccomini、Wes McKinney 和 Maxime Beauchemin 开始。

如果你读到了这里并且喜欢，也去看看与 Mehdi 关于“数据工程中的耦合问题”的对话，或者看看 Josh 最近在 Pebblebed 的演讲 Josh Wills on the End of Coding。

1.当模型变化时，他也毫不介意再跳回去。用最新的模型时，他又回到了 Opus 5.5。

2.有人在 Reddit 上也有同样的印象：“agent 在优化 Spark 作业（或任何高度复杂的 pipeline）方面绝对是狗屎 AI。以我的经验，它们差得可笑。”

3.我没有在他手下工作过，但我相信他仍然是一位出色的管理者！