实时数据基础设施重塑：从事务处理到智能体时代

执行摘要：广告平台等企业常需运维多套数据库以回答单一业务问题，暴露数据架构碎片化痛点。随着智能体应用兴起，流式数据库、上下文图谱、MCP协议、操作型数据网格等新架构涌现，实时数据平面正从事务处理、增量计算向服务智能体演进。本报告梳理该领域现状格局、产业链结构、技术竞争要素，并研判架构融合与标准化趋势。

现状与格局：多库并存之痛

一、一个问题的六套系统

在广告平台等高并发业务场景中，一个看似简单的业务问题——例如“某广告位在最近一小时针对当前用户的实时竞价表现如何”——往往需要并行运行六类不同的数据库才能完整回答：OLTP 数据库负责账户与计费事务，OLAP 数仓负责历史报表分析，缓存系统提供毫秒级热点读，搜索引擎支撑召回与过滤，KV 存储管理特征数据，流处理引擎补足实时增量计算。每一类系统都在自己的最优点上工作，但业务需要的却是同一个问题的一致答案。

这种分工并非设计失误，而是各系统沿自身技术演进路径自然扩张的结果：OLTP 系统为保证事务正确性牺牲了分析吞吐；OLAP 系统为保证扫描效率牺牲了点查延迟；缓存为保证速度牺牲了持久性与一致性。当业务复杂度跨越这些边界时，企业只能通过增加系统数量来弥补能力缺口。

二、割裂架构的隐性成本

多库并存带来的成本远超许可与硬件支出，主要体现为三个层面：

链路成本。 数据需要在六类系统之间反复抽取、转换、加载（ETL/ELT），同一份数据以不同格式、不同延迟、不同一致性保证存在于多个副本。数据在系统间流动的每一跳都是延迟、错误和不一致的产生点。

一致性成本。 由于各系统同步周期不同，同一指标在不同入口可能给出不同数值。在广告计费、风控决策等场景中，这种不一致直接转化为业务纠纷与对账成本。

运维成本。 六类系统意味着六套部署、扩缩容、备份、安全加固、版本升级与故障演练流程，也意味着六类专业技能的人才需求。对多数企业而言，数据基础设施团队的主要精力并非投入在业务创新，而是消耗在维护系统之间的“胶水层”。

三、收敛诉求为何在当下爆发

架构收敛并非新话题，一体化的尝试在过去十年从未停止，但真正推动产业拐点的因素在近年集中出现：

其一，流式物化视图技术的成熟。以增量计算为核心的流数据库（如基于 Timely Dataflow 演进的 Materialize）将原本需要“OLTP 写入 + 流处理 + OLAP 查询”三段式架构承载的实时分析能力，收敛到单一系统中，且增量计算性能的大幅优化使其实用性显著提升。

其二，事务处理向数据平面的下沉。事务语义正在从传统集中式数据库向分布式数据平面迁移，使写入侧与读取侧可以在统一架构内各自优化——写者高效写入，读者高效查询，不再需要以系统拆分换取两端性能。

其三，智能体（Agent）时代的新需求。AI 智能体需要低延迟、强一致、可实时的上下文数据，这正是传统割裂架构最难提供的组合。面向智能体的 MCP（Model Context Protocol）标准化接入、企业级上下文工程等实践，本质上都要求一个统一、实时、语义清晰的操作性数据层。实时操作数据网格（Live Operational Data Mesh）等新架构思路，正是在这一背景下被提出。

四、小结

多库并存是上一代技术约束下的理性选择，其成本随数据规模与业务复杂度线性乃至超线性增长。当流式计算、增量物化、统一事务等技术逐渐消除“拆分换性能”的必然性，而智能体应用又对数据的实时性、一致性与语义统一提出更高要求时，架构收敛便从可选优化变为产业趋势。下一章将讨论支撑这一收敛的核心技术路径。

上游：存储与计算底座

实时数据基础设施的重塑，首先发生在产业链最上游——存储与计算底座。这一层的竞争逻辑正在发生根本转变：传统上以离线批处理和事后查询为中心的架构，正让位于以事务处理数据平面、增量计算与流式引擎为核心的新型底座。谁掌握了上游的实时化能力，谁就掌握了向下游应用层和智能体层持续供给新鲜数据的话语权。

从事务处理到数据平面的重构

理解这一轮底座变革，需要回到事务处理（Transaction Processing）这一最基础的问题。传统数据栈的典型困境是：为了回答同一个业务问题，企业往往需要同时运行六套以上的数据库系统——OLTP 库负责交易、数据仓库负责分析、缓存层负责加速、搜索索引负责检索、消息队列负责解耦、CDC 管道负责搬运。每一套系统都是为某类负载单独优化，通过繁复的同步链路拼接在一起。这种“多库并用”模式带来的是高昂的运维成本、不可避免的数分钟到数小时级数据延迟，以及跨系统一致性的持续博弈风险。

新一代底座技术的思路，是将事务处理能力下沉为统一的数据平面（Data Plane）。其核心主张是：事务处理不应当只属于交易库，而应当成为整个数据基础设施的公共能力——分析、查询、流式计算共享同一份具备事务一致性的数据底座。这使得“写入即生效、查询即最新”成为架构默认值，而非需要额外工程堆叠的特性。

Timely Dataflow：性能百倍优化的信号意义

在计算侧，增量计算与流式引擎成为上游的核心竞争力，标志性事件是 Timely Dataflow 框架实现的 100 倍性能优化。Timely Dataflow 最早由 Frank McSherry 等人提出，是 Materialize 等增量计算系统的理论基础。此轮优化通过通信路径简化、数据结构压缩等手段，将计算性能提升了两个数量级。这不仅是单点技术突破，更具有产业信号意义：增量计算在性能上已经跨过“可用”门槛，进入“可大规模替代批处理”的商业化区间。

增量计算的核心优势在于数学层面的确定性：当上游数据发生变化时，系统只需计算变化的部分，而非全量重算。相比传统的“数据入仓—调度批任务—刷新物化视图”链路，增量计算将结果更新延迟从小时级压缩到毫秒级，同时大幅降低重复计算的算力成本。这使得维护实时视图的总成本（TCO）首次具备与传统批处理竞争的条件，是流式引擎成为上游核心竞争力的经济学基础。

底座架构全景

新的上游底座可以概括为一条从写入到服务的实时链路：

这条链路的技术要点在于：事务处理数据平面承担写入侧的强一致保障；CDC 与增量计算引擎承担计算侧的实时化；物化视图成为面向读写两侧的统一服务层。

面向智能体时代的读写博弈

智能体的规模化接入，对底座提出了新的结构性要求，可以概括为“Happy Writers, Happy Readers”——写侧与读侧同时获得良好体验。智能体场景的特点是：读请求呈现高并发、低延迟、上下文密集的特征，且读写负载在短时间内可能剧烈波动。传统读写分离架构在代理规模下出现新的失衡，产业界因此提出 Context Graphs（上下文图）等方案，在底层存储结构上针对智能体的读写模式重新设计索引与分区策略。

与此同时，数据平面的开放接口成为上游厂商博弈的新焦点。Materialize 等厂商内置 MCP（Model Context Protocol）服务器，使智能体能够以标准化协议直接访问实时数据平面，而无需经过中间ETL层。这一动作的战略含义在于：MCP 正在成为智能体与数据底座之间的连接层标准，率先拥抱该标准的上游厂商，有机会在智能体经济中占据“数据入口”位置。企业侧的 Context Engineering（上下文工程）实践，也进一步强化了对底座实时性、一致性与语义结构的要求。

在行业与监管层面，数据基础设施领域长期存在的开源生态与商业发行之争、以及围绕数据主权与合规的监管要求，同样作用于上游格局。开源计算框架与商业产品之间的竞合、不同司法辖区对数据存储与流转的合规约束，均构成上游厂商必须纳入考量的产业变量。

小结

上游底座的竞争，本质是三重能力的叠加：事务一致性带来的正确性、增量计算带来的性能与成本优势、标准化接口带来的智能体可连接性。Timely Dataflow 百倍优化等技术突破，正在将增量计算从理论优势转化为商业现实。可以预见，未来数年内，“一套具备事务处理能力的实时数据平面”将逐步侵蚀“六库并用”的传统架构，上游的产业集中度与技术壁垒也将随之重构。

中游：实时数据库与数据平台

从“管道”到“数据库”：中游的定位

在实时数据基础设施的分层结构中，上游是数据源与流式传输系统（Kafka 类消息队列、CDC 工具），下游是应用、仪表盘与智能体。夹在中间的，长期是一条由 Flink 作业、ETL 调度、OLAP 引擎和缓存组成的复杂管道。这条管道的问题在于：逻辑分散、状态难管理、一致性难以端到端保证。

流式数据库（Streaming Database）正是为填补这一结构性空缺而出现的品类。以 Materialize 为代表，它将流处理引擎封装为标准数据库接口：用户声明式地定义物化视图（Materialized Views），系统持续增量维护视图结果，并在毫秒级延迟下直接对外提供查询服务。换言之，中游不再是若干胶水系统的组合，而是一个具备承上启下能力的独立层。

三项核心能力

物化视图与增量计算。 Materialize 底层基于 Timely Dataflow 与 differential dataflow 框架实现增量视图维护——当上游数据变更时，只计算受影响的部分，而非全量重算。社区与厂商披露的性能工程工作（如对 Timely Dataflow 的多轮优化）使这一计算模型的吞吐与延迟达到可生产部署的水平。对用户而言，写一条 SQL 即可获得一个永远“最新”的结果集，运维心智显著简化。

一致性保证。 流式管道中最大的痛点之一是上游故障后的状态一致性与 Exactly-Once 语义。Materialize 采用内部事务处理机制（Transaction Processing in the Data Plane）管理计算状态，使得中间结果与源数据的最终一致成为系统能力而非用户负担。这与企业数据平台对审计与合规的要求直接相关。

查询服务。 物化视图天然可服务下游查询：高并发的点查、聚合与 JOIN 都命中预计算结果，省去额外缓存层的引入。

统一平台的演进逻辑

参考素材中“广告平台为何要跑六个数据库回答一个问题”揭示了现状的碎片化：事务库、缓存、搜索索引、OLAP、特征库、键值存储各司其职，数据在它们之间反复搬运、建模、同步。实时数据平台的演进目标，正是用一个统一层替代其中的大部分搬运工作——让“写入一次，多处即时可用”成为默认。

智能体时代的放大效应

智能体（Agent）的兴起使中游的地位进一步凸显。智能体对数据的需求有三个特征：低延迟、强一致性、可导航的上下文。

• 内置 MCP 服务器。 Materialize 提供对模型上下文协议（MCP）的内置支持，使智能体可以以标准化方式连接实时数据，而不必为每个数据系统编写定制连接器。
• 上下文图。 面向智能体规模的 Context Graphs 被提出用于平衡写入方与读取方的需求——写入侧保持高吞吐，读取侧获得低延迟、结构化的上下文检索。
• 活的操作型数据网格。 新的智能体数据架构主张将操作型数据以“live”形式暴露给智能体，数据不再是批量快照，而是持续更新的运行时事实。

这构成了一条清晰的产业逻辑：智能体越多、越实时，对中游一致性与查询能力的要求越高，中游的价值密度越大。

竞争格局与挑战

中游赛道的参与者可分为三类：以 Materialize 为代表的流式数据库新势力；由流处理引擎（Flink 及其商业化发行版）向上延伸的平台；以及云厂商自有方案。竞争焦点在于增量计算引擎的技术深度、SQL 兼容性与生态连接器覆盖。此外，企业落地还面临三类现实约束：流式语义与既有批处理体系的认知与组织迁移成本；实时平台的成本控制（持续计算意味着持续计费）；以及与既有治理框架的衔接——实时数据同样需要分类分级与权限控制，产业界亦在讨论数据标签与表示层面的公平性问题。

总体判断：中游正在完成从“管道胶水”到“平台化数据库”的身份转变。谁能把物化视图、一致性与智能体接入打包为标准能力，谁就有机会定义下一代实时数据平台的形态。

下游：智能体与应用集成

数据消费主体的历史性切换

过去三十年，数据基础设施的下游一直是“人”：分析师写 SQL，BI 工具出报表，业务人员看仪表盘。这一消费模式决定了整个工具链的形态——查询需要低频但交互式响应，缓存和物化围绕报表刷新周期设计，权限体系围绕部门和组织架构构建。

智能体的普及正在改变这一前提。当自动化智能体成为数据的主要消费者时，消费模式呈现出与人类用户截然不同的特征：查询频率大幅提升、调用模式从探索式转向任务驱动、单次会话内需要多轮连续访问、且对延迟和一致性的敏感度远高于人类分析师。产业界将这一转变概括为“数据消费端从人转向自动化智能体”——它不是现有 BI 链路的延伸，而是对数据平面（data plane）能力的新要求。

MCP：智能体与数据层之间的标准接口

在这一背景下，Model Context Protocol（MCP）正在成为智能体连接企业数据层的通用协议。2025 年以来，数据基础设施厂商开始将 MCP 服务器作为产品的内置组件而非外挂集成。以流式数据库 Materialize 为例，其内置 MCP 服务器允许智能体直接以自然语言或工具调用方式访问物化视图和流式查询结果，无需为每个智能体框架单独编写连接器。

MCP 内置化的产业意义在于连接成本的结构性下降。在此之前，智能体访问企业数据需要经历“框架适配器—数据库驱动—权限网关—Schema 文档”的多层定制开发；MCP 将这一过程标准化为单一协议接口，使得任何一个兼容 MCP 的智能体理论上可以接入任何提供 MCP 服务器的数据系统。对数据厂商而言，提供 MCP 服务器从差异化功能变成了准入门槛。

上下文工程的爆发

接口标准化解决的是“连得上”的问题，而“用得好”则催生了企业上下文工程（Enterprise Context Engineering）需求的爆发。与提示词工程聚焦单次交互不同，上下文工程关注的是：企业如何系统性地组织、治理和供给智能体完成任务所需的全部背景信息——包括结构化数据、非结构化文档、业务规则、历史决策记录等。

这一需求的规模效应体现在“上下文图谱”（Context Graph）这类新架构的出现：将企业知识组织为图谱结构，使写入端（业务系统持续产生数据）与读取端（大量智能体并发消费）能够同时保持高效。其设计目标可概括为“写者与读者都满意”——写入吞吐不受读取压力影响，读取延迟在智能体规模的并发下依然可控。这与传统数据仓库面向人类分析师的低并发、批量读取模式形成鲜明对比。

新型智能体数据架构

参考素材中描述的“新型智能体数据架构：活的运营数据网格”（Live Operational Data Mesh）描绘了下游重构的完整图景：数据不再经历“抽取—清洗—入库—报表”的离线管道，而是以运营级新鲜度直接供给智能体消费。支撑这一架构的技术底座包括流式物化、增量计算引擎（如 Timely Dataflow 在性能优化后实现数量级提升）以及事务处理能力向数据平面的下沉——即“事务处理即数据平面”的理念，让智能体读写操作直接建立在具备事务保证的实时数据之上。

值得关注的张力与不确定性

下游智能化也带来新的产业张力。其一是权限与治理：当消费主体从少数分析师变为成百上千个智能体，传统的“按人授权”模型难以直接迁移，围绕智能体身份、最小权限和审计的治理框架仍在早期探索阶段。其二是分类与话语权问题：素材中提出的“无分类即无代表权”（No Classification without Representation）反映出数据被自动化消费后，数据分类和语义标准由谁制定、如何让数据生产方参与的博弈正在浮现。其三是经济模型：MCP 标准化降低了切换成本，可能加剧数据层的同质化竞争，也可能使掌握上下文资产的企业获得新的议价能力。

总体来看，下游正从“人读报表”演进为“智能体读数据平面”。MCP 内置服务器打通了连接层，上下文工程解决供给层，而治理与商业模式的重塑将是决定这一转型能否规模化落地的关键变量。

数据与竞争：上下文成核心资产

从“存数据”到“供上下文”的竞争转向

过去十年，数据基础设施的竞争焦点集中在存储层：谁能以更低的成本存储更大规模的数据、谁的数据湖格式成为事实标准、谁的查询引擎扫描更快。这一阶段的典型形态是“一个问题的六套数据库”——广告平台为回答一个业务问题，往往要同时运行事务库、分析库、缓存、搜索索引等多套系统，数据在它们之间反复搬运与对齐。存储的边际成本持续下降，使得“把数据存下来”不再是差异化能力。

智能体时代的到来改变了这一格局。当 AI 智能体成为数据的主要消费方，负载特征从“人类定期查询”转向“机器高频请求”，竞争的关键资源变为上下文供给能力——即在正确的时刻，以正确的形态、正确的延迟，向智能体提供其决策所需的全部相关数据。存储是供给侧的原材料，上下文才是可被消费的产品。

上下文图谱：兼顾读写性能的架构尝试

支撑智能体规模负载的核心挑战在于读写矛盾的统一。传统架构中，写入侧（事务处理）与读取侧（分析查询）由不同系统承担，中间依赖 ETL/流式管道同步，带来延迟与一致性代价。

新兴的“上下文图谱”架构试图在单一数据面上同时满足两类需求：

• 写入侧：事务处理能力下沉到数据面，保证高并发的实时写入与更新（Happy Writers）；
• 读取侧：以图谱化的上下文模型组织数据，使智能体的检索、推理请求能够低延迟命中（Happy Readers）。

流式增量计算引擎是这一架构的关键底座。Materialize 基于 Timely Dataflow 的增量视图维护技术，通过对该计算框架的持续性能优化（有报道称性能提升达百倍量级），使物化视图能够在数据变更时以毫秒级增量更新，而非全量重算。配合内置的 MCP（Model Context Protocol）服务器，数据平台可以直接向智能体暴露标准化的上下文接口——这意味着上下文供给正在成为数据平台的原生能力，而非外挂组件。

产业层面，“活体运维数据网格”的概念也在兴起：数据不再沉淀为静态的湖仓快照，而是以持续在线、持续更新的运营形态存在，智能体直接订阅和消费这一活体数据面。

分类与表示：数据质量的上游变量

上下文质量的上游是数据的组织方式。“无分类即无代表”这一命题指出了一个常被忽视的机制：数据被如何分类、以何种表示方法建模，直接决定了下游 AI 系统的表现。

分类不只是目录管理。当企业将数据划分为实体、事件、关系等语义类别，并选择合适的表示（向量、图谱、结构化表）时，本质上是在为智能体构建可检索的知识结构。分类不当的后果是隐性的：向量检索召回语义漂移、实体消歧错误、上下文窗口被低相关性内容占满——这些问题在人类驱动的 BI 时代影响有限，在智能体自主决策的场景下会被放大为直接的决策错误。

因此，领先企业开始将“企业级上下文工程”作为系统性工程推进：统一本体与语义层、建立数据分类的治理规范、将上下文质量纳入数据质量度量体系。上下文工程正在与提示工程、模型工程并列，成为 AI 落地的第三根支柱。

竞争格局的三点判断

1. 差异化从容量转向时延与语义。存储成本趋同后，竞争焦点转移到增量更新时延、上下文一致性、语义检索精度等能力维度。

2. 接口标准成为新战场。MCP 等智能体—数据交互协议的普及，使“谁能被智能体更便捷地连接”成为选型因素，数据平台正围绕该协议构建生态位。

3. 上下文工程能力构成进入壁垒。分类体系与表示方法的选择需要领域知识与长期治理积累，难以通过短期采购获得，这使上下文供给能力比算力更接近企业的护城河。

小结

智能体规模负载要求基础设施同时满足“写得快”与“读得准”，上下文图谱与增量流式计算代表了这一方向的当前实践。分类与表示方法决定了上下文质量的上限，而上下文供给能力正在取代存储规模，成为数据基础设施竞争的核心变量。对企业而言，评估数据平台的标尺，正从“存了多少”转向“能在多快的时间内，向智能体提供多准确的上下文”。

趋势判断：架构融合与网格化

从分离到融合的架构演进逻辑

回顾数据基础设施的历史，操作型与分析型系统的分离是一条主线：OLTP 数据库保障事务一致性，数据仓库与湖仓承接分析负载，两者之间依赖 ETL/ELT 管道进行数据搬运。这套架构在过去十年支撑了分析型应用的高速发展，但在智能体时代正面临结构性挑战。

一个典型的信号来自广告平台等复杂业务场景：为回答一个跨渠道的实时业务问题，企业最终运行了六套以上不同类型的数据库，分别覆盖事务、缓存、搜索、时序、分析与归档需求。系统数量随业务复杂度线性增长，而数据一致性、运维成本与团队协作成本呈指数级上升。这种「一问多库」的碎片化，正是架构融合需求的最直接来源。

操作型数据网格：智能体时代的新范式

行业正在出现一种新的架构范式，可以概括为操作型数据网格。其核心思想是：不再按事务与分析的边界切分系统，而是按业务域组织数据产品，每个域对外提供统一、实时、可治理的读写接口。

这一范式的三个支柱正在快速成熟：

第一，事务能力下沉到数据面。 传统上事务处理被视为数据库的专属能力，而新一代流式数据引擎正将事务语义嵌入统一数据平面，使读写路径在同一平台上具备 ACID 保障。这消除了「先落库、再同步、后分析」的三段式延迟。

第二，增量计算的性能拐点已现。 基于及时数据流模型的增量计算框架在近期的工程优化中实现了数量级的性能提升，使得在持续更新负载上维持低延迟一致视图的成本大幅下降。这意味着「实时」不再是大客户的专利，而成为平台默认属性。

第三，上下文成为一等公民。 智能体消费数据的单位不是报表，而是上下文。面向智能体规模的上下文图技术，需要在高频写入与高频读取之间保持平衡，让写入方顺畅、读取方（智能体）快速获得结构化、可追溯的背景信息。企业级的上下文工程正在成为与数据工程并列的新学科。

标准化协议加速边界消融

连接层的标准化是本次融合的加速器。以 MCP 为代表的模型上下文协议，正在让智能体以统一方式接入不同数据平台——部分实时数据引擎已推出内置的 MCP 服务端，智能体可以直接对操作型数据发起查询与订阅，无需经过独立的 API 网关或中间同步层。

与此同时，数据分类与治理的社区化讨论（如围绕数据语义分类的代表性议题）表明，行业开始将「如何描述和归类数据」视为公共基础设施问题，而非各家私有实现。标准化协议 + 统一语义层的组合，将显著降低跨平台迁移与整合的成本。

边界模糊后的产业影响

事务、分析、服务三类负载在同一数据面上共存，将带来三方面产业结构变化：

对供应商而言，统一数据面意味着产品边界的重新划定：数据库、流处理、数据仓库、向量检索等品类的区分度下降，取而代之的是「谁能提供更完整的操作型数据网格能力」。这将加速行业整合——具备实时事务、增量计算与智能体连接三重能力的平台将获得溢价，而单点工具面临被平台内化或被淘汰的压力。

对用户企业而言，网格化架构降低了多系统运维负担，但也提高了平台锁定的风险。在统一数据面上，「换掉一个组件」与「换掉整个数据面」的成本差异显著扩大。企业需要在架构红利与议价能力之间做出权衡，多数据面并行、以标准化协议保持互操作性，可能成为中大型企业的务实选择。

演进路径判断

综合技术成熟度与市场需求，本章对本轮架构融合的演进路径作如下概括：

未来两到三年，操作型数据网格能否成为主流范式，取决于两个关键变量：一是增量计算引擎在通用负载上的稳定性与成本表现能否持续兑现性能红利；二是 MCP 类协议能否在治理、权限、审计等企业级要求上形成事实标准。若两者同时成立，数据基础设施行业将迎来一次类似湖仓之于数仓的范式更替——而这一次，智能体将成为推动替代进程的主要需求侧力量。