过去二十年，企业数据平台的发展经历了数据库、数据仓库、BI、大数据平台、数据治理等多个阶段。虽然底层技术不断演进，从传统数据库到Hadoop生态，再到今天的湖仓一体，但对于大多数企业而言，数据开发的基本范式却始终没有发生根本性的变化。
业务系统产生数据，数据通过ETL或ELT同步到数据平台，经过清洗、转换、建模、汇总之后，再提供给BI系统、报表平台或者业务应用使用。几乎所有的数据平台，无论采用的是Oracle、Hive、Spark还是Lakehouse，本质上都遵循着这一套流程。
然而，大模型的出现，第一次开始对这一范式提出挑战。
最近一年，无论是各大数据平台厂商，还是AI创业公司，都在推出面向数据开发的AI能力。从自然语言生成SQL，到自动编写ETL脚本，从AI辅助建模，到自动生成数据文档，再到能够理解业务语义的Data Agent，AI已经不再只是帮助数据分析人员提高效率，而是开始进入数据开发本身。
于是，一个问题开始被频繁讨论：
数据开发工程师会不会被AI取代？
我的观点是，AI确实会改变数据开发，但它改变的并不是数据开发这个职业，而是传统的数据开发方式。
ETL为什么能够成为企业数据平台的核心
在讨论AI之前，我们首先需要理解，为什么ETL能够在企业数据平台中占据如此重要的位置。
ETL（Extract、Transform、Load）从来都不是一个简单的数据同步过程，它承担的是连接业务系统与数据平台之间的桥梁作用。
一家中大型企业通常拥有ERP、CRM、MES、WMS、SRM、OA等多个业务系统。每个系统的数据模型、编码规则、业务口径都存在差异。如果直接将这些数据用于分析，不仅难以关联，而且很容易产生大量口径不一致的问题。
例如，一个看似简单的”组织架构”概念，在不同系统中的定义就可能完全不同。OA中的组织架构可能是人力的组织架构，ERP中的组织架构可能是财务的组织架构。如果没有统一的数据转换和建模过程，即使拥有再先进的分析工具，也无法得到可信的分析结果。
因此，ETL真正承担的，并不是”搬运数据”的工作，而是帮助企业完成数据标准化、业务规则沉淀以及统一数据口径。这也是为什么数据仓库建设过程中，大量时间实际上花费在数据清洗、字段映射和业务规则确认上，而真正编写SQL代码只是整个过程中的最后一步。
过去二十年，无数企业的数据平台正是依靠这样的方式逐步建立起来的。
AI首先改变的，是ETL的开发方式
如果观察最近一年AI在数据开发领域的应用，可以发现一个非常明显的特点：AI最先进入的，并不是数据架构设计，而是开发过程。
过去，一个新的ETL任务通常需要经历需求分析、表结构阅读、字段理解、SQL开发、测试验证、上线部署等多个步骤。整个过程中，大量工作实际上属于重复性的编码劳动。
例如，当需要将订单表与客户表进行关联统计时，开发人员往往需要先了解两个表之间的关联关系，再编写SQL完成数据转换。如果需要增加一个新的统计维度，又需要重新修改SQL并进行测试。
而今天，这部分工作已经开始发生变化。
越来越多的AI开发工具能够根据自然语言描述自动生成SQL，也能够解释已有SQL的逻辑，甚至能够根据数据血缘关系推荐关联字段，帮助开发人员快速完成初稿。对于一些结构相对固定的数据同步任务，AI已经能够生成相当高质量的ETL代码。
换句话说，AI首先替代的是重复性的编码过程，而不是数据开发本身。
这一点，与软件开发领域正在发生的变化高度相似。GitHub Copilot、Codex 等工具能够帮助程序员编写代码，却并没有减少系统设计的重要性。数据开发同样如此，SQL生成越来越容易，但真正困难的问题依然存在。
数据开发真正困难的，从来不是SQL
很多企业第一次接触AI生成SQL时，都会产生一种错觉：既然AI能够写SQL，那么数据开发工程师是不是就没有价值了？
事实上，这是将数据开发简单理解为”写SQL”所产生的误解。
真正的数据开发工作，远远不止SQL。
举一个非常常见的例子。
业务部门提出一个需求：”统计新增客户数量。”
对于AI来说，这句话可以很容易转换成SQL语句。
但真正的问题在于，什么叫”新增客户”？
是第一次注册的客户？
还是第一次下单的客户？
是否需要剔除测试账号？
历史客户重新激活是否算新增？
这些问题，没有任何一个能够通过大模型自动推理出来。
因为它们不是技术问题，而是业务规则。
类似的问题几乎存在于企业所有核心指标之中。
销售额是否包含退货订单？
利润是否包含税费？
库存是否按照自然日统计？
客户生命周期如何划分？
这些定义往往需要经过业务部门、财务部门和数据团队长期讨论之后才能形成统一标准。
SQL只是业务规则的一种表达方式，而不是业务规则本身。
因此，即使未来AI能够自动完成SQL开发，也无法替代企业对于业务知识的理解和沉淀。
AI时代，数据工程师需要重新定义自己的价值
如果说过去的数据开发工程师，更像是一名代码生产者，那么未来的数据工程师，更应该成为企业数据体系的设计者。
这种变化已经开始出现。
越来越多企业开始关注数据语义层（Semantic Layer）、统一指标体系、元数据管理、数据质量管理以及知识图谱建设。这些工作的共同特点是，它们关注的不再是代码本身，而是企业数据如何被理解、如何被组织以及如何被复用。
对于未来的Data Agent而言，它是否能够正确回答业务问题，并不取决于SQL写得是否优雅，而取决于企业是否已经建立起统一的数据语言。
因此，未来数据工程师需要投入更多精力思考的问题可能是：
- 企业的数据模型是否能够准确表达业务？
- 不同部门之间的数据口径是否一致？
- 元数据是否完整？
- 指标体系是否统一？
- 数据质量是否能够支撑AI分析？
这些问题，才是真正决定AI应用效果的关键因素。
AI不会削弱数据质量的重要性，反而会放大它的价值
过去，在BI时代，一份错误的数据通常意味着一张错误的报表。
虽然会影响业务分析，但由于报表具有固定格式和固定使用者，问题往往能够较快发现并修正。
而AI时代的情况完全不同。
越来越多企业开始建设知识库、智能问数平台和Data Agent。AI不再只是展示数据，而是直接参与分析、解释甚至决策建议。
如果底层数据存在错误，那么错误将不仅出现在某一张报表中，而可能通过Agent快速传播到更多业务场景。
错误的数据口径可能导致AI持续输出错误答案。
缺失的元数据可能导致AI生成错误SQL。
低质量的数据可能导致模型形成错误推理。
换句话说，AI并不会自动提高数据质量，它只会更高效地消费数据，并更快速地放大数据质量问题。
这也是为什么我越来越认为，未来企业数据团队最重要的竞争力，不是开发速度，而是数据质量。
作为《数据质量管理实践手册》中文版联合译者，在翻译这本书的过程中，我其中一个最大的感受是：数据质量不单单是一个技术问题，更是企业管理能力的体现。 当AI开始成为企业的重要生产工具之后，这句话的重要性将进一步凸显。未来，我也会用专门几篇文章，结合企业实践，系统讨论AI时代的数据质量体系应该如何建设。
写在最后
回顾过去二十年的企业数据平台建设，我们会发现，每一次技术变革都没有消灭上一代技术，而是在重新定义它的价值。
数据库没有因为数据仓库而消失。
数据仓库没有因为BI而消失。
BI也不会因为ChatBI而消失。
同样，ETL不会因为AI而消失。
真正发生变化的是，数据开发正在从以代码为中心，逐渐走向以知识为中心；数据工程师的核心竞争力，也将从编写SQL，逐渐转向理解业务、组织数据和管理知识。
未来的数据平台，不再只是数据流转的平台，更是企业知识不断沉淀和持续演进的平台。
而Data Agent，正是建立在这一基础之上的下一代数据消费模式。