大数据基建如何迈向 AI Infra？（上）

前面我们聊了SQL Boy 怎么可能穷途末路？因为最近聊 AI 对大数据领域的冲击，很多讨论都会自然落到个人身上。

SQL 开发怎么办？ETL 开发怎么办？报表开发怎么办？普通的数据分析同学会不会被替代？

这些问题当然有意义。

因为在日常工作里，AI 已经能做很多过去需要人手工完成的事情：改 SQL、解释 SQL、写调度脚本、生成数据质量规则、补开发规范、读 PRD、出宽表设计草稿、整理数据探源结果。

如果站在个人岗位看，答案大致会落到一个方向：不要只做低语义的执行者，要学会把 AI 变成自己的工作流能力。

但如果视角再往上走一层，站在数据部门负责人、Data Infra 架构师、数据平台 Owner 的位置，这个问题就变了。

关注点会从“某个 SQL 开发怎么升级”，转向一个更靠前的问题：

过去我们花很多年构建的离线数仓、实时数仓、湖仓一体、OLAP 和指标体系，能不能支撑下一阶段基于 AI 的日常经营管理？

这个问题我觉得对管理层而言，应该是更扎心的。

因为它已经超出工具提效，进入基础设施判断。

AI 对数据部门的冲击，表层发生在岗位，深层发生在数据基建的表达能力上。

过去的数据基建，主要服务的是“人如何消费数据”。

人通过报表看数，通过取数分析问题，通过 BI 做下钻，通过 SQL 查明细，通过数仓模型复用口径。系统的核心目标，是让数据能被加工、能被查询、能被复用、能被展示。

但 AI 进入企业经营管理以后，数据基建要面对一个新的使用者：Agent。

Agent 不只是在查一张表，也不只是在生成一段 SQL。它要理解业务问题，要识别对象和事件，要判断指标变化的含义，要沿着业务关系做归因，要知道哪些数据能看，哪些动作能建议，哪些结论必须附带证据。

走到这里，很多企业会发现一个尴尬的问题：

你的数仓可能很完整，指标也很多，但企业业务世界并没有被建模成 AI 能理解、能验证、能治理的形式。

这就是我想写这篇文章的原因。

这篇不讲个人如何从 SQL Boy 升级成 AI 数据工程师。那是另一个层面的话题。

这篇只讲数据部门和 Data Infra 负责人应该如何提前准备结构化数据方向的下一代基建。

我先把范围收窄。

未来企业 AI 数据基建大概会有两条大线。

第一条线，仍然围绕结构化数据展开。企业的经营事实、交易事实、财务事实、用户事实、供应链事实，大量仍然落在数据库、数仓、湖仓和 OLAP 系统里。沿着这条线继续往前走，本体化语义层会成为一个非常关键的补位。

第二条线，会围绕非结构化数据和多模态数据展开。企业文档、会议纪要、合同、图片、语音、视频、页面截图、流程记录，都会进入 AI 引擎。这个方向未来也很大，但它涉及文档理解、多模态检索、多模态推理和企业知识引擎，本文先不展开。

本文只讲第一条线：结构化数据方向，数据部门应该如何为 AI 经营管理提前准备本体化语义层。

一、过去的数据基建，强在数据生产，弱在业务世界表达

过去十多年，数据团队的主线很清晰。

先做离线数仓，把业务系统里的数据抽出来，清洗、建模、分层、汇总，让企业有统一的经营数据。

再做实时数仓，把用户行为、交易事件、风控事件、运营事件更快地接进来，让业务能够在分钟级甚至秒级看到变化。

再往后，湖仓一体、统一指标平台、OLAP 引擎、数据服务、标签体系、数据治理、数据目录、血缘、质量监控逐步补齐。

这些建设当然有价值。

没有这些基础，企业连稳定取数都做不到，更谈不上 AI。

但从 AI 经营管理的角度看，过去的数据基建有一个天然边界：它主要围绕“数据如何生产和被人消费”来设计。

表、字段、分区、任务、指标、宽表、物化视图、血缘、质量规则，这些都是数据生产体系里的核心对象。

可 Agent 进入经营分析时，它面对的问题更接近业务世界：

• • 这个客户处于什么生命周期阶段？
• • 这个订单为什么毛利异常？
• • 这个门店的下滑和库存、活动、人员、区域有没有关系？
• • 这个销售额变化，是价格因素、转化因素、客单因素，还是履约因素造成的？
• • 这个结论能不能给区域负责人看？
• • 这个建议能不能触发任务、审批、提醒或写回？

你会发现，这些问题很少只靠一张宽表就能解释。

宽表可以把字段摊平，指标平台可以把口径统一，OLAP 可以把查询跑快，但 Agent 还需要知道业务对象之间的关系、事件之间的因果线索、指标和对象的归属、权限和动作的边界。

过去的数据基建负责把数据加工成可查询的事实；AI 经营管理还需要把事实组织成可推理的业务世界。

这个缺口，不能简单靠 Prompt 补。

很多团队早期做 AI 数据应用，会先让模型读库表说明、读指标口径、读 SQL 示例，然后直接生成 SQL 或调用 BI 接口。

Demo 阶段可能很好看。

一旦进入真实经营场景，问题就会集中冒出来。

同一个指标在不同部门口径不同，同一个字段在不同表里含义不同，同一个对象在不同系统里 ID 不一致，同一个业务问题要跨订单、客户、商品、门店、履约、财务多条链路。

这时模型如果没有一个受控的业务语义空间，就只能在表名、字段名、历史 SQL 和文本说明之间猜。

猜得准的时候，大家会觉得 AI 很聪明。

猜偏的时候，SQL 也可能正常运行，图表也可能正常展示，风险反而更隐蔽。

因为企业数据分析里最麻烦的错误，往往会避开 SQL 语法层，落在业务含义偏差上。

二、AI 经营管理需要的基座，和传统 BI 基座不完全相同

很多企业会把 AI 数据应用自然理解成 ChatBI。

用户问一句话，系统返回一个数、一张图、一段解释。这当然是一个入口，而且也是非常容易被理解的入口。

但如果数据负责人只用 ChatBI 来理解 AI 数据基建，就会低估后面的复杂度。

BI 时代的核心交互，是人看数据。

人会自己判断问题，人会自己知道上下文，人会自己把图表和业务经验拼起来。系统只要把数算对、图展示出来、权限控制住，就已经完成了相当大一部分职责。

Agent 时代的交互会往前走。

它不仅要回答“是多少”，还要回答“为什么变化”、“影响范围是什么”、“下一步该查哪里”、“需要通知谁”、“有没有历史相似案例”、“这条建议能否进入流程”。

这个变化会把数据基建从查询系统推向经营协作系统。

这里的差别很大。

以销售额下滑为例。

传统 BI 可以展示区域销售额、门店销售额、商品类目销售额、同比环比、TopN 和趋势图。

Agent 如果要参与经营分析，就需要进一步识别：

• • 下滑发生在哪些业务对象上：区域、门店、商品、客户群、渠道。
• • 下滑关联哪些事件：促销结束、缺货、价格调整、竞品活动、履约异常。
• • 下滑影响哪些指标：销售额、毛利、转化率、客单价、复购率、库存周转。
• • 结论适用于哪些权限角色：总部、区域、门店、品类、财务。
• • 建议能不能进入动作：补货、调价、活动复盘、门店巡检、客户触达。

这已经超出传统“指标 + 维度 + 图表”的表达范围。

当然，指标语义层仍然有价值。

它能统一口径，能让自助分析和 BI 报表更稳定，能减少“同名指标不同算法”的混乱。对于大量企业来说，先把指标语义层做好，仍然是非常务实的一步。

但如果目标是让 AI 进入经营管理，指标语义层只能解决一部分问题。

指标语义层主要回答“这个数怎么算”；本体化语义层还要回答“这个数属于哪个业务对象、处于什么业务状态、关联哪些事件、受哪些规则约束、能触发哪些后续动作”。

这个判断对数据部门负责人很关键。

如果你把下一阶段 AI 数据基建理解成“让模型更会写 SQL”，团队很可能会把精力继续投到 Prompt、SQL 样例、表结构说明和 RAG 文档里。

这些工作会有效，但上限明显。

如果你把它理解成“让企业业务世界变成可被 Agent 理解和受控执行的语义模型”，团队建设方向就会发生变化。

你会开始关心业务对象、事件、状态、关系、口径、权限、证据、版本、发布、回归。

这些东西听起来没有“智能体自动干活”那么刺激，但它们决定 AI 能不能进入生产。

三、本体化语义层，适合接住结构化数据方向的下一代基建

我更倾向于把本体化语义层理解成一种更高阶的语义层形态。

它不能被理解为在传统语义层外面随便加一层概念，也不能把几个业务名词写成图谱就算完成。

它的关键在于：把企业经营中的对象、关系、事件、状态、指标、规则、权限和证据，统一沉淀成一套可治理的业务语义模型。

换句话说，本体化语义层要把“表里的数据”翻译成“业务世界里的对象和变化”。

比如一个订单表，在传统数仓里可能是一张事实表。

在本体化语义层里，订单首先是业务对象。它有客户、商品、渠道、门店、支付、履约、退款、发票等关系；它有创建、支付、取消、发货、签收、退款等事件；它有待支付、已支付、履约中、已完成、已退款等状态；它对应销售额、毛利、履约时长、退款率等指标；它还受到租户、角色、区域、敏感字段、审批策略等权限约束。

再比如客户。

客户不能只被看成一串 ID，也不能只被看成会员表里的一行记录。

客户是可以被经营的对象。它有来源、等级、生命周期阶段、最近一次购买、复购行为、投诉记录、权益、风险标签、触达状态，也可能关联订单、商品、活动、门店和客服工单。

当 Agent 问“最近复购下降的高价值客户主要集中在哪里”时，它需要理解的不只是指标和维度。

它要知道什么是高价值客户，复购如何定义，下降和哪个时间窗口相关，客户和订单怎么关联，区域归属按客户归属还是门店归属，高价值客户是否有权限查看，最后输出时能不能给出证据。

这就是本体化语义层的价值。

它让 Agent 进入一个已经被企业定义、审核、发布和约束过的业务语义空间，减少围着字段名猜业务含义。

如果用更工程化的语言表达，这一层至少要承担六类能力。

第一，业务对象建模。

企业要明确哪些对象值得建模：客户、订单、商品、门店、合同、商机、项目、设备、工单、库存、供应商、员工、费用、预算。

第二，关系建模。

对象之间不能只靠临时 join 猜。客户和订单、订单和商品、商品和库存、门店和区域、合同和回款、项目和成本之间，需要有明确的关系定义和路径证据。

第三，事件和状态建模。

经营分析经常关心变化。下单、支付、退款、发货、签收、投诉、审批、调价、补货、逾期，都是事件。对象处在什么状态，会直接影响指标解释和后续动作。

第四，指标和规则建模。

指标仍然关键，但指标要挂到对象、事件和关系上。否则指标只是一个公式，难以参与复杂经营问题的解释。

第五，权限和边界建模。

Agent 不能自由穿透所有数据。哪些字段敏感，哪些对象可见，哪些结论可返回，哪些动作只能建议不能执行，都要进入语义层治理。

第六，证据和版本建模。

AI 给出的答案，要能回到数据事实、语义版本、解释路径和运行证据。否则出了问题，团队无法复盘，也无法改进。

这六类能力组合在一起，才接近结构化数据方向的 AI 经营管理基座。

它不会替代数仓。

数仓仍然负责事实生产、数据加工、性能优化和稳定供给。OLAP 仍然负责快速查询和交互分析。湖仓仍然负责统一存储、开放格式和多类数据管理。

本体化语义层的角色，是在这些基础之上建立业务语义控制面。

数仓是事实底座，OLAP 是执行底座，本体化语义层是 AI 理解企业经营世界的语义底座。

这个分工如果想清楚，团队就不会陷入“有了 AI 还要不要数仓”这种假问题。

更实际的问题是：过去那些已经建好的数仓资产，怎样升级成 Agent 可以安全使用的语义资产。

四、为什么不能只靠 RAG、Prompt 和 SQL Agent

很多团队会先从轻量方案开始。

把库表说明、指标口径、历史 SQL、业务文档放进知识库。用户提问后，系统先召回相关材料，再让模型生成 SQL 或调用工具。

这个方案适合做起步验证。

它成本低，见效快，能让团队快速发现 AI 问数的高频问题，也能帮助业务方建立体验感。

但如果数据部门负责人把它当成长期基建，就会遇到几个绕不过去的问题。

第一个问题是召回材料和业务语义之间存在断层。

RAG 能把相关文档找出来，但文档相关不等于语义正确。一个指标说明可能写得很完整，但它是否适用于当前部门、当前角色、当前时间窗口、当前业务对象，仍然需要受控判断。

第二个问题是 Prompt 很难承担版本责任。

企业指标和模型会变化。表会改，字段会改，口径会改，权限会改，业务组织也会改。如果系统主要依赖 Prompt 拼接说明，就很难清楚回答：这次回答到底基于哪个语义版本？哪个口径？哪个发布记录？哪个审核人？

第三个问题是 SQL Agent 容易把错误藏在执行成功里。

SQL 能跑通，只能说明语法、权限、执行计划没有明显问题。它不能自动证明业务含义正确。

比如“本月活跃客户数”到底按登录、下单、支付、浏览、触达还是有效互动计算？如果没有语义层的定义，模型很可能选择一个看起来合理的字段，然后生成一条可以执行的 SQL。

第四个问题是跨对象分析会迅速放大歧义。

单表查询相对容易，多表 join 已经开始危险。涉及客户、订单、商品、活动、库存、财务、区域多对象路径时，如果没有关系约束和路径证据，模型生成的 SQL 可能在技术上成立，在业务上偏得很远。

第五个问题是企业很难建立回归体系。

AI 数据应用不能只看一次回答漂不漂亮。它要能长期稳定回答同一类经营问题。没有中间语义表示、语义版本、Golden 问题集和 Trace，团队很难判断模型升级、口径调整、表结构变化之后，系统稳定性有没有被破坏。

所以，RAG、Prompt、SQL Agent 都可以用，但最好把它们放在正确位置上。

RAG 可以辅助召回业务说明和案例。

Prompt 可以组织交互和解释。

SQL Agent 可以承担部分工具调用能力。

但生产级 AI 经营管理，需要一个更硬的语义控制面。

越接近经营决策，越不能让模型直接从自然语言跳到 SQL；中间必须有业务语义计划、权限约束、执行证据和回归验证。

如果用元一的产品语言去表达，这条链路会更接近：

自然语言问题 → 候选对象 / 候选指标 / 候选实体 / 候选时间 / 候选关系 → Candidate Graph → 语义组合 → YuanYi Logic Plan（YLP） → Query Guard → Doris SQL → Answer Contract → Trace / Golden / Feedback

当然，本文不展开完整实现。

我只想说明一个方向：数据部门提前准备语义资产时，要为这类受控链路留出空间。

如果一开始所有内容都只是散落在文档、SQL 样例、口头约定和字段注释里，后面再想升级成可治理的 AI 数据基建，会非常吃力。

明天发下篇，给大家一些消化的时间

戛然而止的感觉还是挺难受的……（感觉像酣畅淋漓的一把 LOL 打一半停电了）

主要一不小心写了1w 字，我觉得对大家阅读压力太大了，所以剩下一半如何落地，如何新角度构建数据部门等内容，都放在明天中午发布好了。

如果觉得内容干货，先来个关注吧，免得错过更多干货～

同时看到这里了，来个“点赞”和“转发”吧，这是更新的最大动力了。

我们明天下篇见～