> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # Databricks 重新定义数据工程师 - URL: https://www.hubwiz.com/blog/databricks-redefines-the-data-engineer/ - Published: 2026-09-13T16:56:06.000Z - Updated: 2026-09-13T16:56:06.000Z - Description: 多年手工构建摄取框架，而今年的发布说明悄悄告诉我，大部分工作已不再是这份工作的核心。 - Author: admin - Tags: JOB MARKET, #Import 2026-10-14 14:41 在我职业生涯的大部分时间里，做好这份工作意味着擅长搬运箱子。 数据存放在一个系统中，而业务需要它在其他地方。你编写中间的东西，调度它，然后在凌晨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](https://medium.com/data-science-collective/how-databricks-just-rewrote-the-data-engineers-job-description-db64d3d6f012?ref=hubwiz.com) 汇智网翻译整理，转载请标明出处