数据平台正在从「存数据」走向「让机器理解业务」。本文沿一条主线梳理：数据仓库 → 批流一体 → 统一语义模型 → Ontology+DDD → AI Data Foundation → Agent Runtime → 人与 Agent 共生，并逐层回答同一件事——每一层，到底解决了什么问题。
一、从数据仓库说起：企业为什么需要数据基础设施
数据仓库诞生的根本原因，并不是「数据库不够强」，而是企业逐渐意识到一件事：
业务系统产生的数据，并不等于企业真正可以使用的数据。
早期企业的数据分散在 ERP、CRM、交易、财务等各自独立的 OLTP 系统里。这些系统的首要职责是完成交易，并不适合复杂分析。于是就有了数据仓库：
它解决了几个核心问题：
数据集中 历史数据保存 统一指标口径 分析与交易系统隔离 为管理层提供统一的事实基础
这一阶段的核心价值，可以概括成一句话：把分散的业务数据，变成统一的分析数据。
二、从离线到实时：批与流的分化
传统数据仓库以 Batch 为主：
离线数据仓库，时效基本都是T+1，即第二天看前一天的分析结果，业务再结合BI报告进行商业分析和决策，如零售的补货，电商的用户漏斗转化分析。随着实时业务的发展，业务想看更加实时的数据分析，如天猫双十一，需要能在大屏实时看到GMV等商品销售数据，于是实时数仓的需求诞生了：
因为实时的数据基本都是要存在内存才能进行实时计算和分析，而这些计算机的内存有限，没法把海量的数据都装进内存，所以只能计算7天内甚至更短的1天内的数据，实时计算的结果最后需要融合到离线数据仓库，不然指标会不准确。所以就要求离线和实时两条并行链路并行存在：
这正是 Lambda / Kappa / 批流一体（Batch-Stream Integration）等技术路线出现的背景。大部分企业没有统一实时和离线的数据模型，设计上就容易出现数据不一致的情况。
这里补充一个很重要的认知：Spark、Flink、Kafka、Iceberg、Hive、StarRocks 并不在同一层。
Kafka：事件流基础设施 Flink/Storm：流 / 批计算引擎 Spark：分布式计算引擎 Hive：SQL / 数据仓库体系 Iceberg：Lakehouse 表格式 StarRocks：OLAP 数据库
所以「批流一体」并不意味着所有东西都要融成一个系统。
三、真正难的不是计算统一，而是模型统一
当前很多所谓的批流一体，实际解决的主要是计算基础设施和数据平台的统一。但双链路模型的架构依然可能同时存在：
于是就出现了这些老问题：
同一指标两套计算逻辑 实时与离线口径不一致 两套任务、两套数据模型 回溯困难 业务语义被重复定义
因此真正值得追求的，不是「Flink/Storm 和 Hive 必须变成一个东西」，而是：
业务语义、逻辑模型、事件、状态、指标和数据契约，应该尽可能统一。
以订单为例：
实时和离线可以使用不同的物理实现，但都应该遵守同一个 Canonical Model「规范数据模型」：
一句话：逻辑统一 > 物理统一。
四、为什么需要 Conceptual Model
如果从业务系统直接跳到物理数据模型，很容易变成一层层堆表：
企业一般的设计就是ODS->DWD->DWS->ADS「DM」，数仓的每一层是否设计合理，有没有跨层应用，每个模型的复用率怎样，模型设计的扩展性这些都是统统需要考虑的，很不幸，技术团队在面向业务，也就是业务驱动的团队基本上很容易就把ADS「DM」层建得很厚，形成了数仓里的一个一个烟囱。更不幸的是如果业务足够强势，他们不想完全依赖数据团队的数据产出，他们就会直接基于ODS去建自己的BI报告，弱势的技术团队拿此基本没有办法。这会导致更严重的问题：数据不一致，不同团队给领导汇报时，同一个指标口径都不一致。
这种困境的一个解决办法就是统一数据模型，尽可能真实的表达业务世界。所以需要一个分层：
模型在数据仓库技术层面无法统一，但在语义层面是可以统一的。
Conceptual Model 回答的是：企业业务世界里有哪些核心实体，它们之间是什么关系？
Order（订单实体）
Product（产品实体）
Customer ── creates ──→ Order（客户创建了订单）
Order ── contains ──→ Product（订单包含产品）
逻辑模型（Logical Model） 进一步定义：Entity（实体）、Attribute（属性）、Relationship（关系）、Primary Key（主键）、Event（事件）、State（状态）、Metric（指标）、Temporal Semantics（时序语义）。
物理模型（Physical Model） 才最终落实到 Kafka、Flink/Storm、Iceberg、Paimon、Warehouse、OLAP、Graph DB、Vector DB。
所以：Conceptual / Logical Model 是连接业务世界和物理数据世界的桥梁。
五、Ontology 出现以后，架构又多了一层
Ontology 和 Conceptual Model 很接近，但不是同一个东西。可以简单理解：
Conceptual Model：我们如何抽象业务世界 Ontology：业务世界中的概念究竟是什么、意味着什么、如何关联、遵循什么规则
Order（订单概念）
Product（产品概念）
Customer ── places ──→ Order（客户和订单的关系是下单）
Order ── contains ──→ Product（订单和产品的关系是包含）
Ontology 还能进一步描述语义：
→ 表示订单已经完成支付
Order.status = CANCELLED
→ 不属于有效交易（订单被取消了）
因此 Ontology 更强调 语义（Semantic）、概念（Concept）、关系（Relationship）、约束（Constraint）、规则（Rule）、含义（Meaning）、推理（Reasoning）；而 Conceptual Model 更偏向 实体（Entity）、属性（Attribute）、关系（Relationship）、结构（Structure）。
所以在 AI Data Foundation 里，我们把 Ontology 放在最上面的语义层。但不能简单理解成「Ontology 在 Conceptual Model 之上」——两者其实是不同维度，可以相互映射：
未来，企业的数据建模，不单单是面向人，还要面向Agent机器。
六、DDD 应该放在哪里？
我一直在思考DDD在数据底座建设过程中，可以做什么（DDD在微服务架构里就是用来拆服务）。引入 DDD 之后，架构进一步完善。DDD 不是一种数据库模型，而是一套领域建模与软件设计方法。它关注 Bounded Context（限界上下文）、Entity（实体）、Value Object（值对象）、Aggregate（聚合）、Domain Service（领域服务）、Domain Event（领域事件）、Command（命令）、Invariant（不变量）、Business Rule（业务规则）。
一句话区分：
Ontology 描述What「业务世界是什么」，DDD 描述How「业务如何运转」，最后生成一套知识图谱。
同一个 Ontology：
Order
Product
Customer → places → Order
到了 DDD 这里，会进一步形成聚合：
└── Order Aggregate（订单聚合根）
├── Order
├── OrderItem
└── OrderStatus
Customer Context（客户限界上下文）
└── Customer Aggregate（客户聚合根）
Product Context（产品限界上下文）
└── Product Aggregate（产品聚合根）
于是新的语义基础可以理解为：
七、从 Data Foundation 走向 AI Data Foundation
把这些拼起来，可以得到这样一张图：
到这里，核心问题已经不再是「如何存储数据」，而是：
如何让机器真正理解企业的业务世界？
八、Agent 不应该只是数据消费者
如果架构只做到 Data → Agent，其实还不够。Agent 需要的不只是数据，还有：
业务语义、业务规则 实时状态、历史数据 知识、Memory Tools、APIs、权限、Policy
因此应该增加一个 Agent Data Runtime：
这样 Agent 才能真正从「聊天机器人」变成「业务执行者」。
九、但 Agent 并不等于实时计算
这是整个架构里非常关键的一点。Agent 调用大模型通常需要 LLM inference、Context assembly、RAG、Tool calling、多轮 reasoning，因此它天然比 Flink、Kafka、规则引擎慢。
所以不应该这样：
更合理的是分层：
也就是说：实时数据 ≠ 实时 Agent。
Flink 负责高频、低延迟、确定性计算；Agent 负责复杂认知、推理和决策；人负责高价值判断与治理。
十、人和 Agent 是「双消费者」，而不是 Agent 替代人
这是整个架构最重要的变化。
传统链路：业务提需求给数据仓库，数据仓库作出BI报告给人看。
未来链路：
所以不是「Agent 替代 BI」，而是：BI 服务人的认知，Agent 服务人的认知与行动。
最终形成：
这就是一种真正的 Human-Agent Coexistence / Collaboration 架构。
十一、人需要什么新能力？
在人机共生体系里，人的技能结构也会变化。
传统企业更强调：业务知识 + 专业技能 + Excel / SQL / BI + 执行能力。
未来会更加重视：
Domain Knowledge（领域知识） Ontology（本体建模） / DDD Thinking（领域建模） Data Literacy（数据思维） Agent Orchestration（智能体编排） Critical Thinking（批判性思维） Decision Making（决策制定） Human-Agent Collaboration（人机协作）
其中最关键的变化是：从「执行」转向「定义、判断和治理」。
Agent 可以：查询、计算、分析、生成报告、调用 API、执行流程。
人则越来越需要：
定义业务目标 定义业务语义 判断结果是否正确 识别异常和因果关系 处理复杂例外 做最终决策 治理 Agent
因此可以下一个判断：SQL 技能的重要性可能下降，但数据思维、业务理解和判断能力的重要性会上升。
十二、技术公司的商业模式也会变化
这套架构最终不仅改变技术架构，也会改变软件公司的商业模式。
传统软件，主要就是提供软件，按照License或者SaaS，提供软件服务给用户，用户为使用这个软件买单：
云计算的商业模式是提供基础架构，计算，存储，API 接口，卖资源给用户，用户可以根据自己消耗了多少资源而买单，也可以周期性的购买，如包月包年，用户不用自己招专业的技术人员去研究技术，不用自己去运维，只专注在自己的业务里：
Agent 时代可能进一步变成：
商业模式变为用户为结果买单，计费单位可能从 $/User（用户），逐渐出现 $/Agent、$/Task、$/Workflow、$/Execution、$/Transaction，甚至进一步向「按完成的业务工作收费」迁移，如画了一张图就付费一张图的钱，帮助用户买了一次商品就收一点佣金，。
因此技术公司的价值链可能演变成提供AI软件给Agent使用（很少给人用了）：
十三、一张完整的 AI 时代企业架构图
综合以上讨论，可以浓缩成这张图：
企业业务经过ontology本体建模，DDD领域建模，形成统一的数据模型，同时提供给离线数据仓库，实时数据仓库，知识图谱使用，这个统一的数据底座同时提供离线，实时，图谱给人和Agent智能体使用，Agent智能体也能进一步去调用业务系统如ERP，CRM，SCM等，最后这些数据又反哺业务，形成一个新的数据链路闭环。
十四、核心结论
整个演进可以浓缩成一条线：
从存储数据，到统一数据计算，再到建立业务知识，搭建 AI 数据底座，部署可自主工作的智能体，形成人机协同模式，最终实现由智能直接驱动业务落地执行。这里又会诞生一大批新的机会。
其本质变化是：
第一代数据基础设施，解决「数据在哪里」； 第二代解决「数据怎么统一、怎么实时」； AI 时代则进一步解决「业务世界是什么、数据意味着什么、Agent 能做什么，以及人和 Agent 如何共同决策和执行」。
最终，企业的数据平台可能不再只是一个 Data Platform，而会逐渐成为企业业务语义、数据、知识、智能和执行能力的共同基础设施。
而 Ontology + DDD + Canonical Model + Data Foundation + Agent Runtime + Human/Agent，构成了这套新基础设施的核心骨架。
朋友们，变革开始了，你准备好了吗？
相关文章
