Databricks 重新定义数据工程师
在我职业生涯的大部分时间里，做好这份工作意味着擅长搬运箱子。
数据存放在一个系统中，而业务需要它在其他地方。你编写中间的东西，调度它，然后在凌晨3点醒来，因为它出了问题，而原因对任何人来说都没有意义，包括编写它的人。通常那个人就是我。
我们称之为工程。其中很多是物流。
我曾经花了一个整个季度构建一个摄取框架，该框架读取配置文件并从中生成Spark作业，它很干净。我为此感到自豪。十八个月后，一个功能发布，从下拉菜单中完成了大致相同的事情，我的框架变成了没有人想要继承的东西。
这种情况一直在发生。现在发生得更快了。
如果你阅读并仔细研究Databricks过去一年实际发布的内容——我指的是发布说明而不是主题演讲亮点——你会发现一个我认为我们大多数人都没有 properly sit with 的模式。
该平台不再试图让数据工程更快。
但它开始试图让大部分数据工程变得不必要。
1、没有人放在幻灯片上的转变
每隔几年，我们的领域就会获得一个新的重心。
- ETL工具。
- Hadoop。
- Spark。
- 云原生。
- Lakehouse。
每一个都改变了我们的工作方式。但它们都没有改变这份工作的本质。你仍然设计数据的流动，并且当它失败时你仍然拥有它。
现在发生的任何事情在本质上都是不同的，而不是程度上的不同。
Agent Bricks、Lakeflow、AI Gateway、ABAC、MCP。单独阅读，它们是五个产品线，有五个不同的路线图。一起阅读，它们描述了一个平台，在这个平台上数据工程师停止编写流动，开始治理编写流动的智能。
我一直在反复思考这是否是夸大其词。
我不再这么认为了。
2、结果而非指令
当大多数工程师听到"平台中的AI"时，他们想象的是代码生成和具有更大上下文窗口的自动完成。
这种框架已经过时了。
Agent Bricks最有趣的版本不是你要求Spark作业的那个。而是你描述结果的那个。摄取这个源，根据这些期望验证它，标记看起来错误的内容，将其落地到分析师可以使用的地方。你不是在指定实现；你是在指定目标，让系统选择路径。
Databricks在四月份进一步推动了这一点，当时Supervisor Agent开始接受自定义MCP服务器和Databricks Apps上的自定义代理作为协调系统内的子代理。
再慢慢读一遍。
你不再管理一个作业。你管理的是一个作业团队。
任何入职过初级工程师的人都知道"编写这个函数"和"这是目标，带计划回来"之间的区别。一个是打字的委派。另一个是思考的委派。
但问题是：这会在下个季度取代工程师吗？不会。
它会删除目前填充我们冲刺的大量工作类别吗？如果不会，我会感到惊讶。
老实说，我不会怀念编写下一个几乎相同的摄取框架。
3、我们构建的框架从来不是产品
在谈论Lakeflow时，它被描述为Delta Live Tables的演变，这低估了正在发生的事情。
Lakeflow Designer让人们可以可视化地组装管道。Lakeflow Connect处理来自那些曾经占用整个季度的系统的摄取：Oracle、SQL Server、Teradata，以及总是带有一个未记录怪癖的企业源家族。
生产力故事是显而易见的。架构故事是值得思考的那个。
十年来，认真的数据团队构建了内部平台。摄取框架、编排包装器、配置驱动的作业生成器、自定义血缘。我帮助构建了其中几个。有些确实很好。
它们几乎都不是竞争优势。
它们是做生意的成本，伪装成工程文化。我们告诉自己自定义层给了我们控制权。它主要给了我们维护负担和单点故障。
问题从来不是强大的团队是否能构建这些东西。
问题是他们是否应该。
4、无聊但支付一切的那个
大多数组织仍然处于AI采用的混乱阶段。
一个团队使用GPT。另一个使用Claude。有人在GPU集群上启动了一个开源模型用于概念验证，悄悄变成了生产。而在某个地方，财务总监盯着一张没有明显所有者却翻了三倍的账单。
这就是AI Gateway不再无聊的地方。
它现在为工作区内运行的编码代理和MCP服务器提供集中访问控制、使用监控和审计日志。模型和代理活动落在一个受治理的遥测层中，而不是五个供应商仪表板中。
没有人写关于审计日志的会议演讲。
但它回答的问题决定了AI是否能在大公司真正推出。哪些模型被批准。谁被允许调用它们。哪些数据离开了大楼。这花了多少钱。其中是否有任何能经得起监管者的审查。
企业采用不会因能力而停滞。它会因无法回答这五个问题而停滞。
5、我实际上会押注的那个
基于属性的访问控制今年全面可用，为团队迁移现有策略提供了宽限期。
该公告获得的注意力只有Agent Bricks的一小部分。我认为它可能更重要。
任何管理过大规模权限的人都知道这个弧线。基于角色的访问控制在五十人时感觉合理。然后团队成倍增加，法规到来，数据分类堆叠，你正在维护一个看起来像是由从未见面的委员会设计的权限矩阵。
ABAC颠倒了模型。策略附加到数据的属性而不是人的身份。
这听起来像是一个小区别。
它不是。
规则不再跟随用户在组织图表中移动，而是开始与数据本身共存。将一列标记为包含患者标识符一次，策略就会随它进入下游触及它的每个表、笔记本和代理。对于医疗保健、金融、保险以及任何涉及监管者的内容，这是完全不同的治理姿态。
在一个代理正在读取你的表的世界中，跟随数据的治理是唯一可扩展的那种。
从来没有人对访问控制感到兴奋。
每个人都在审计期间对它感到兴奋。
6、推理从来不是瓶颈
Agent Bricks将获得头条新闻。MCP可能会有更长的尾部。
原因是，
模型很久以前就在推理方面变得很好。那从来不是约束。一个聪明的新员工如果无法访问Jira、代码库、维基或工单系统，就不是一个高效的新员工。他们是一个昂贵的对话伙伴。
代理正好有那个问题。每个集成都是定制的。每个连接都增加了维护。团队花费更多精力将代理连接到系统，而不是改进代理连接后所做的工作。
标准协议改变了这种成本的形状。构建一次连接器，每个说该协议的代理都可以使用它。
这将代理从答案业务转移到工作业务。
从"告诉我这个管道有什么问题"到"修复它，打开拉取请求，并标记我。"
第二个是穿着相同界面的不同产品类别。
7、我没有好答案的部分
在所有这些中，有一些我一直在反复思考但没有解决的事情。
一个特定类别的工作正在被自动化，而它恰好是我们传统上用来培训人员的类别。
- 样板转换。
- 简单的摄取作业。
- 初步故障排除。
- 不光彩的清理工单。
这些工作本身从来不是有价值的。它之所以有价值，是因为它是你学习的方式。你搞砸了一个作业，你阅读了日志，你更好地理解了系统，最终你有了判断力。
如果一个平台吸收了所有这些，梯子就失去了底部的横档。
高级工程师会没事的。可能比没事更好，因为幸存下来的工作始终是最困难的部分。设计系统。设置架构。理解治理。知道来自业务的十一个需求中哪个才是真正重要的。
如果没有人先在战壕里待两年，我不知道我们如何培养下一代这样的人。
我问过一些工程领导这个问题。他们中也没有人有答案。
8、我们以前看过这部电影
几年前，每个人都在迁移到微服务。论点是拆分单体将消除复杂性。
它没有。它将复杂性从代码库内部重新定位到服务之间，在那里它更难看到也更难调试。
教训是通用的。
技术很少消除复杂性。它将复杂性移动到你不看的地方。
减少编写管道的时间，更多时间治理自我编写的系统。减少构建集成的时间，更多时间定义代理被允许触及的内容。减少移动数据的时间，更多时间决定应该对数据做什么以及谁必须为该决定负责。
工作不会缩小。
它只是看起来不再像管道。
你认为这些在未来三年中哪个对工作的重塑最大？
- Agent Bricks
- Lakeflow
- AI Gateway
- ABAC
- MCP
我很好奇其他人对此的看法，特别是那些已经在生产环境中运行过其中一些的人。
原文链接: How Databricks Just Rewrote the Data Engineer's Job Description
汇智网翻译整理，转载请标明出处