这两年数据圈有一个挺明显的变化。以前聊数仓张口就是ODS、DWD、DWS、ADS。现在大家讨论的却越来越多是语义层、指标平台、Data Agent、AI问数、智能分析。于是一个问题也跟着冒出来既然AI已经可以理解数据库、自动写SQL、生成分析结论那企业还有必要一层一层建数仓吗甚至有人觉得以后直接让大模型连接ERP、CRM、MES、WMS就行了。数据在哪Agent自己找。表怎么JoinAgent自己写。指标怎么算也让Agent自己判断。听起来确实省事。但真正放到企业环境里很快就会发现AI解决的是“怎么更方便地使用数据”并没有自动解决“数据本身是否可信”。而这恰恰是数据仓库存在这么多年的根本原因。在正式展开之前我整理了一套《“AI”场景落地实战白皮书》里面包含数据架构、数据治理、数据集成、指标体系等内容。如果你正在做数仓建设或者正在思考AI时代企业的数据底座该怎么搭可以结合这套资料一起看。需要自取https://s.fanruan.com/hti40复制到浏览器一、为什么以前一定要做ODS、DWD、DWS、ADS企业为什么不直接拿ERP数据库做分析因为业务系统从一开始就不是为了分析设计的。ERP负责交易和财务记账。CRM负责客户。这些系统首先解决的是业务怎么跑。而不是以后怎么分析。所以同一个客户在CRM和ERP里可能有不同编码同一个“销售额”销售、财务、经营分析可能各有一套口径退款、取消订单、税额、折扣、跨期确认等规则也散落在不同系统里。如果直接拿这些源数据分析很快就会乱。于是传统数仓做了一件非常重要的事把面向交易的数据重新组织成面向分析的数据。经典四层其实很好理解。ODS负责接数据。ERP、CRM、MES、WMS等业务系统的数据先进入数仓尽可能保留原始状态。DWD负责把业务事实整理清楚。统一编码、字段、状态、业务粒度把订单、客户、产品、库存等基础数据清洗干净。DWS负责沉淀可复用的数据能力。比如客户销售、商品销售、库存周转、生产效率。ADS再面向具体应用。经营分析、销售日报、财务看板、供应链驾驶舱各取所需。所以传统数仓真正解决的从来不只是存储问题。而是把分散、混乱的业务数据加工成可以反复使用的分析资产。二、但现在的问题是很多企业把“分层”做成了规定动作传统四层架构当然有价值。问题是很多企业后来开始机械分层。一张源表进来ODS建一张。DWD复制一张。DWS再汇总一张。ADS继续建一张。业务需求改一下上面几层一起改。最后数仓里几千张表没人说得清哪些还在用、哪些已经废弃。甚至报表下线三年了对应的ADS任务还每天凌晨照常跑。这时候分层本来是为了降低复杂度结果反而制造了新的复杂度。所以现在越来越多团队开始重新思考是不是所有数据都必须机械地走完ODS、DWD、DWS、ADS显然不是。真正应该保留下来的其实是分层背后的能力原始数据可追溯、业务事实统一、公共数据可复用、指标结果可验证。至于最终到底三层、四层还是五层并不是重点。三、AI真正冲击的可能首先是ADS层ADS为什么会越来越多因为过去每出现一个新的分析需求数据开发往往都要重新走一遍写SQL → 建结果表 → 配调度 → 接报表。销售部门要一套。财务部门要一套。供应链再来一套。业务换个分析维度又重新建一张。于是数仓越往上走数据越定制。但AI分析出现之后这套模式正在发生变化。比如业务突然问“为什么最近核心产品毛利一直在掉”过去可能要专门准备产品收入、成本、渠道、客户、折扣、退款等数据再做一套分析。但如果底层已经有稳定的事实数据和统一指标Agent完全可以根据问题动态组织查询毛利下降 → 拆收入和成本 → 定位产品 → 下钻渠道 → 继续追客户和订单。这时候就没必要每出现一个分析问题都提前固化成一张ADS表。所以未来最可能被压缩的不一定是ODS和DWD。而是大量为了固定报表和临时需求反复建设的应用层数据。四、但AI越强底层数据反而越不能乱这是很多人容易忽略的一点。现在让大模型写SQL已经不难了。真正难的是它到底该用哪张表“销售收入”取订单金额还是财务确认收入退款算不算取消订单怎么算客户到底按签约主体还是付款主体统计毛利成本用标准成本还是实际成本这些都不是SQL问题。而是企业内部的业务规则和数据语义问题。如果底层本来就乱让AI直接面对几百张表、几万个字段并不会自动变聪明。很可能只是把过去人找错表升级成AI自动找错表。而且速度还更快。所以AI时代数据仓库里的公共明细层、统一维度、稳定事实数据反而更加重要。因为未来这套数据不只是给报表用。还要给AI用。五、数仓真正的第一关还是先把数据稳定接进来不管上层是传统BI还是Data Agent有一个前提始终没变数据得先到。现实中的企业数据往往散落在Oracle、MySQL、SQL Server、ERP、MES、CRM、WMS以及文件、API和各种异构系统里。而且数仓建设也不是做一次全量迁移就结束了。后面还要持续面对新增订单怎么同步库存变化怎么增量更新源表结构变了怎么办几十个系统的数据怎么长期稳定跑实时数据和离线数据怎么衔接所以数仓建设真正麻烦的第一步往往不是建ODS而是怎么让上游数据持续、稳定地进入数仓。实际落地时这一段通常需要一套数据集成工具来承接。比如用FineDataLink把ERP、CRM、MES、WMS以及不同数据库中的业务数据持续同步到数仓在同步过程中完成全量/增量抽取、字段转换和必要的数据处理对于实时性要求更高的场景还可以通过CDC、实时任务等方式持续获取业务变化。等数据先稳定汇到一起之后再去做DWD清洗、公共模型和上层语义建设整个链路会清晰很多。所以从这个角度看AI并没有绕开传统数据集成。恰恰相反上层越智能对底层数据链路的稳定性要求反而越高。六、四层架构真正会变化的是“语义层”开始变重要传统数仓主要解决数据怎么组织。但到了AI时代还要进一步回答这些数据到底是什么意思。这就是语义层越来越重要的原因。数据库里可能存在order_amtpay_amtsettle_amtincome_amt开发人员看字段还能大概猜一下。但业务真正理解的是订单金额、实付金额、结算金额、确认收入。再往前一步还需要告诉AI销售收入怎么算毛利怎么算客户有哪些层级哪些指标可以按产品、渠道、区域下钻不同角色能够看到哪些数据这些都属于业务语义。所以未来数仓上面很可能会多出一个越来越重要的层次事实数据 → 统一指标与语义 → AI理解与分析。数据仓库负责把事实做好。语义层负责告诉系统这些事实代表什么。AI再负责怎么把它们用起来。七、未来的企业数据架构可能会从“四层”变成“三段”如果不再机械强调ODS、DWD、DWS、ADS我觉得未来更容易理解的方式是把企业数据架构拆成三部分。第一部分数据底座包括数据采集、数据集成、CDC、ETL/ELT、清洗、建模、实时同步、历史数据管理。这一层解决的就是数据有没有、准不准、能不能稳定拿到。像 FineDataLink 这类数据集成平台本质上就是在这一层把分散在不同业务系统中的数据先连接起来。链路可以理解为ERP / CRM / MES / WMS / 数据库 → FineDataLink → 数仓 / 湖仓先把数据流转这件事解决。第二部分业务语义在稳定的数据基础上进一步沉淀指标体系、维度关系、业务实体、指标口径、权限和血缘。解决的是这些数据到底代表什么。第三部分智能消费最上面才是BI、Data Agent、AI问数、异常分析、归因分析、预测和经营决策。解决的是怎么让更多人更低门槛地使用数据。所以未来完整的数据链路更像业务系统 → 数据集成 → 数仓/湖仓 → 业务语义 → BI / Data Agent / AI应用这其实比单纯纠结“到底分几层”更接近企业未来真正的数据架构。八、AI时代最危险的做法是直接让Agent连生产库从技术上来说当然可以。连Oracle。读取Schema。然后问“分析一下最近三个月销量下降的原因。”Agent自动写SQL、执行、生成图表。Demo效果可能非常惊艳。但真正进入企业很快就会遇到问题表太多。字段没人解释。指标口径冲突。历史数据不完整。生产库性能压力。跨系统数据无法直接关联。权限复杂。SQL执行风险。更重要的是没人敢保证答案一定对。所以直接连生产数据库更适合开发辅助、小范围探索和部分实时明细查询。如果要真正支撑企业经营分析数据还是应该先经过稳定的数据集成链路进入数仓或数据平台。比如把ERP订单、CRM客户、MES生产、WMS库存等数据先通过FineDataLink持续同步到统一平台再在这个基础上清洗、建模和统一口径。这样Data Agent面对的就不再是几十套彼此割裂的业务系统。而是一套已经整理过的数据事实。这两种模式的可靠性完全不是一个量级。十、AI时代评价一套数仓的标准也该变了过去大家评价数仓喜欢看有多少层。多少张表。多少主题域。多少TB数据。这些当然重要。但AI时代更应该问的是AI能不能理解这套数据指标有没有统一定义表之间的业务关系是否清晰字段有没有业务含义数据能不能追溯来源结果能不能验证上游数据变化能不能持续同步如果源系统今天产生一笔新订单数据几个小时以后才进入数仓那上面的AI再智能也不可能给出真正实时的判断。所以未来数仓竞争的可能不再只是“建模能力”。还包括数据集成效率、数据质量、语义统一和智能消费能力。写在最后所以回到最开始的问题AI时代还需要分层数仓吗需要。但可能不再需要过去那种机械的ODS → DWD → DWS → ADS每条数据都完整走四层。与此同时数仓上面会越来越重视语义层 Data Agent 智能分析。而数仓下面的数据集成也不会消失。无论最终用的是传统BI还是AI AgentERP、CRM、MES、WMS里的数据都得先稳定流出来。像FineDataLink这样的数据集成平台解决的就是这条链路最基础但也最容易被低估的问题怎么把分散的数据持续、稳定地汇到一起。所以AI时代真正变化的并不是“数仓还要不要建”而是数仓应该怎么建才能既让人用也让AI用。未来企业数据架构真正值得关注的可能不再是“到底四层还是五层”而是底层数据能不能稳定流动中间语义能不能统一上层AI能不能正确理解。这才是从传统分层数仓走向“语义智能”架构真正的变化。