FDE-Wiki

主题

#数据工程#应用架构#MLOps#中国市场#Agent

数据中台与 AI 中台不是两个独立产物,而是一根价值链条的两段:前者负责把企业的原始数据沉淀为可信、可复用的数据资产(数据湖/湖仓/指标/标签/主数据),后者负责把这些资产转化为可决策、可执行的智能能力(模型/Agent/知识/评估)。过去五年,大多数中国企业的真实路径是先建数据中台(2018—2022 年那一轮"中台热"),再在 2023 年大模型爆发后被迫叠加 AI 中台。两套中台割裂运行,是当下最普遍也最致命的反模式。本专题拆解二者融合的必要性与落地架构。

一、两个中台的真实边界与重叠 ​

先澄清概念,避免陷入"中台到底是什么"的口水战。

数据中台的内核是四件套:数据湖/湖仓(原始与加工数据的统一存储)、指标体系(把"GMV""日活""周转率"定义成机器可算、跨口径一致的实体)、标签中心(对"人/货/场"等主体打可复用画像)、主数据管理(客户、商品、组织等核心实体的唯一真相)。它解决的是"数据在哪里、是什么意思、能不能信"。

AI 中台的内核同样是四件套:模型仓库与生命周期管理(训练-评估-上线-监控-下线)、Agent 编排(把模型、工具、知识组装成可执行任务的工作流)、知识中心(向量库 + 图谱 + 文档,供 RAG 与推理使用)、评估中心(离线指标 + 在线 A/B + 回归测试)。它解决的是"模型怎么生产、怎么用、好不好"。

重叠区是关键:数据中台的标签中心,在 AI 中台看来就是一类结构化特征;指标体系既是 BI 看板的数据源,也是模型监控的基准;主数据是知识图谱的骨架。反过来,AI 中台产出的预测分数、Embedding 向量、Agent 调用日志,回流到数据中台又成为新的数据资产。融合不是物理合并,而是把这条"数据→特征→模型→Agent→回流"的链路打通,消除三道墙:口径墙(同一字段在数仓、特征库、模型里三个定义)、时延墙(离线 T+1 指标喂不进实时 Agent)、治理墙(模型上线没人知道它用了哪张表)。

二、为什么必须融合:数据是 AI 的燃料,割裂则 AI 无源 ​

大模型时代把这条铁律放大了十倍。传统机器学习时代,一个模型几十个特征,数据断点影响有限;今天一个面向客户的 Agent,可能同时需要:实时订单状态(秒级)、用户 30 天行为画像(分钟级)、商品知识图谱(小时级)、企业制度文档(向量检索,毫秒级)。任何一环断流,Agent 就会"一本正经地胡说"。

割裂带来的三类硬伤已经在一线反复出现:

第一,训练-服务偏差(Training-Serving Skew)。模型训练用数据科学家从数仓拉的离线特征,线上推理却由 AI 中台现拼一套逻辑,两次计算结果不一致。金融风控领域这类偏差直接导致策略失效,且极难排查。特征平台(Feast/Tecton)存在的首要意义就是用同一套特征定义同时服务训练和推理,从根上消除这堵墙。

第二,数据漂移无人兜底。模型上线时数据质量合格,三个月后上游业务系统改了字段含义或截断规则,模型静默劣化。如果数据中台的数据质量监控与 AI 中台的模型效果监控是两套人马两套面板,问题往往要到客户投诉才暴露。融合后的评估中心必须把"数据质量指标"和"模型效果指标"对齐到同一张时间轴上。

第三,Agent 上下文无法拼装。Agent 调用一个工具,本质是去数据中台取数;调用知识库,本质是去 AI 中台取向量。两套网关、两套鉴权、两套目录,Agent 编排层就要写大量胶水代码。融合架构的核心动作,是把数据网关与模型网关统一在一层。

三、融合架构:一条贯通的链路 ​

把融合拆成五层,自下而上看清这条链路。

第一层:湖仓一体作为统一底座。 这是 2025 年已是事实标准的部分。Iceberg、Paimon、Delta Lake、Hudi 四种开放表格式(Open Table Format)取代了过去"数据湖一份、数仓一份"的双副本结构。小米用 Apache Paimon 作统一存储格式,实现流批一体、湖仓一体,达成 6 倍性能提升;Google Cloud 把托管式 Iceberg 作为新一代湖仓的默认选项;阿里云 AnalyticDB 同时支持 Paimon/Iceberg/Delta/Hudi,主打"数据不用搬,AI 直接炼"。Databricks 与 Snowflake 则把湖仓、特征、模型、向量检索打包进同一平台(Unity Catalog 统一治理 Delta 表、模型、向量索引)。选型上,国内倾向 Paimon(流式原生、与 Flink 贴合),国际化团队倾向 Iceberg(生态最广、AWS/GCP/Snowflake 都已托管)。底座统一的硬指标只有一条:模型训练读的特征表和 Agent 推理读的特征表,必须是同一张物理表,不再做"离线导出 + 在线灌库"的双写。

第二层:特征平台打通数据与模型。 Feast(开源)和 Tecton(商业托管)是两个标杆。Feast 的定位很克制——不接管你的特征计算逻辑,只解决存储与服务:你用 Spark/Flink/SQL 把特征算出来写入 Feast,Feast 同时对外提供离线 SDK(给训练用,批量取历史时间点特征,保证时间穿越正确)和在线服务(给推理用,毫秒级点查)。Tecton 走更重的路子,把流式特征计算、特征物化、血缘追溯全做成托管能力,适合没有自研特征管线工程能力的团队。选型经验:团队小于 10 人且已有数仓基础,先上 Feast + Iceberg 的组合,把 5—10 个核心模型复用的高价值特征管起来;团队到了平台型规模,再评估 Tecton 或自研。这里的中国现实是:大多数数据中台已经有"标签中心",它本质就是结构化特征库,融合的第一步往往是把标签中心升级成兼容 Feast API 的特征平台,而不是推倒重来。

第三层:知识中心(向量库 + 图谱 + 主数据)。 大模型让"知识"第一次成为独立的基础设施层。融合架构里,知识中心是一个三件套:向量库(Milvus/Qdrant/Pinecone/PGVector,存 Embedding 供语义检索)、知识图谱(基于主数据搭建实体-关系网络,支撑多跳推理)、文档库(企业制度、合同、SOP 的原文,供 RAG 引用)。三者必须共享主数据 ID 体系:向量库里某条客户 Embedding 的主键,要能 join 回图谱里的客户节点,也要能映射回数据中台里的客户主数据表。否则 Agent 检索到的"张三"和数仓里的"张三"对不上号,是另一种口径墙。Databricks 的 Vector Search、Snowflake 的 Cortex Search 已经把向量检索做进湖仓,本质就是让向量与结构化数据共用同一份治理与权限。

第四层:模型网关与数据网关统一。 这一层最容易被忽视,却是融合能否工程化的关键。传统 AI 中台有模型网关(统一推理路由、限流、鉴权、计费),数据中台有数据网关(统一取数、脱敏、审计)。融合架构要求两个网关在协议层对齐:Agent 调用模型网关取一个推荐分数,同一调用里能附带从数据网关拉到的用户画像,且两次取数用的是同一份权限策略。实现路径有两种:一是物理合并为一个"智能网关",统一编排模型调用与数据查询(如 Databricks 的 AI Functions、Snowflake 的 SQL 模型调用);二是协议统一但物理分离,两个网关都暴露统一的 OpenAPI/Function Call 规范,Agent 编排层(LangGraph/Dify/Coze/自研)按需组合。第二种在国内更现实,因为数据中台往往已是上百个系统的中枢,推倒迁移成本不可承受。

第五层:评估中心对齐数据与模型。 评估中心不是只跑离线指标。融合视角下,它要同时盯三类信号:数据质量(完整性、新鲜度、分布漂移,来自数据中台的数据质量监控)、模型效果(准确率/AUC/业务转化率,来自 AI 中台的模型监控)、业务结果(GMV、流失率、客诉率,来自指标体系)。三者按同一时间轴对齐,才能回答"模型效果掉了,是因为数据漂移还是模型本身过拟合"。成熟的评估中心会建立回归测试集,每次数据中台上游变更或模型版本更新,自动跑一遍,出红绿灯报告。这是融合架构里"运营"重于"建设"的典型环节,也是中国企业最容易欠账的地方。

四、湖仓一体选型的真实权衡 ​

把底座层展开,因为这是技术决策最密集的一环。

四种表格式各有性格。Iceberg 生态最成熟,Schema 演进与时间旅行能力强,AWS、GCP、Snowflake 都已原生托管,国际化或多云团队首选。Paimon 流式原生,与 Flink 深度绑定,主键表支持高更新频率,小米、字节等国内大厂规模验证,实时场景(分钟级入湖)优势明显,2024 年进入 Apache 顶级项目后采用率快速上升。Delta Lake 与 Databricks 强绑定,治理与 ACID 最完善,但开放性近年才追上。Hudi 起步最早,upsert 能力强,但社区活跃度已被前两者反超。

实际选型很少单选,常是"主格式 + 兼容多读"。比如以 Paimon 为写入格式,用 Trino/Doris/StarRocks 多引擎读 Iceberg/Delta 的混合湖仓越来越多。阿里云 AnalyticDB、Doris 3.x、StarRocks 都主打"一个引擎读所有格式"。这里的 FDE 选型原则很朴素:以最大写入负载场景定主格式,以查询引擎覆盖度定读路径,而不是追求某种"最优格式"。

Databricks 与 Snowflake 走的是另一条路——把湖仓、特征、模型、向量、评估做成一体的平台(Databricks 用 MosaicML + Unity Catalog + Vector Search + MLflow,Snowflake 用 Cortex 全家桶)。这条路对没有历史包袱的新业务最友好,代价是锁vendor。国内对应的是阿里云 MaxCompute + PAI、腾讯云 Wedata + TI、华为云 DataArts + ModelArts 的全家桶,优劣一致。

五、特征平台的落地现实 ​

Feast 在国内落地的常见坑值得单独说。

Feast 设计上假设你已有特征计算管线,它只做物化与服务。这意味着团队要先有能力用 Spark/Flink 把特征算出来,再决定哪些进 Feast。很多团队误以为装上 Feast 就有特征平台,结果发现上游算特征的活儿没人干,Feast 成了空壳。

Feast 的在线服务默认用 Redis 做低延迟点查,离线存储用对象存储或 Iceberg/Delta 表。点查延迟可做到个位数毫秒,但要撑住高峰流量,Redis 集群规模不能小,这是一笔持续成本。Tecton 把这部分托管掉,代价是按特征量计费。

对已有数据中台的团队,融合的第一步通常是:先识别出 5—10 个被多个模型复用的高价值特征(用户 LTV、商品热度、设备风险分等),把它们从"每个模型自己算"升级为"统一进特征平台"。这一步投入小、收益快,也是说服业务方买单的最佳切入点。切忌一上来就想把全公司特征都搬进平台。

六、中国企业的中台现实:叠加,而非重建 ​

这一点对 FDE 驻场至关重要。中国大中型企业的现状是:数据中台已建(可能建了两三轮),指标体系跑了三五年,标签中心上有几百个标签;AI 中台是大模型之后才仓促上马,通常是个 LangChain/Dify 试点加几个微调模型。两套班子、两套预算、两套汇报线。

强行"统一中台"是政治自杀加技术灾难。可执行的融合路径是分层叠加:

第一步,数据底座不动,加一层湖仓。 把数仓里高频更新的表迁移到 Paimon/Iceberg,让 AI 中台能直接读这份"活的"数据,而不是从 T+1 的数仓快照取。这一步往往由数据中台团队主导,AI 中台提出 SLA 需求。

第二步,标签中心升级为特征平台。 标签中心的结构化数据本来就在那里,给它套一层 Feast API,同时供训练和推理。这一步是融合的最低成本入口,通常 2—3 个月能见效。

第三步,新建知识中心。 主数据 + 向量库 + 图谱是新东西,数据中台没有现成组件。建议由 AI 中台团队牵头建设,但主数据必须从数据中台的 MDM 系统取,不要重建主数据。

第四步,评估中心对齐。 把数据中台的数据质量监控和 AI 中台的模型监控接进同一个面板,建立回归测试机制。这一步是运营层面的融合,投入主要是组织协同而非系统建设。

第五步,网关统一。 在两个网关之上抽象一层统一协议,Agent 编排层只面对一个接口。这是融合的最高级形态,也是最难的一步,建议放在前面四步跑通后再做。

七、反模式清单 ​

把一线见过的反面案例列出来,避免重复踩坑。

反模式一:数据中台与 AI 中台两个团队各立山头。 数据团队觉得 AI 团队"乱取数搞乱口径",AI 团队觉得数据团队"响应慢不支持实时"。结果两套口径、两套数据副本、两套治理,模型上线后反复出问题,最后 CEO 来问"为什么中台投了这么多钱还做不出东西"。这是组织问题,不是技术问题,解药是共同 KPI——让两个团队对同一个业务指标(GMV 提升、流失率下降)负责,而不是对各自平台成熟度负责。

反模式二:重建设轻运营。 投千万建平台,上线后没有数据质量监控、没有模型回归测试、没有特征血缘维护。三个月后平台烂掉,变成又一个"僵尸中台"。融合架构 70% 的价值在运营,30% 在建设。FDE 在交付时必须把运营 SOP、监控面板、回归测试集作为交付物,而不是只交付一套能跑的代码。

反模式三:向量库与主数据脱节。 大模型一来,业务方急着上线 RAG,工程团队随手建个 Milvus 把文档灌进去,完全没有和企业主数据对齐。三个月后 Agent 回答"张三的订单"对不上数仓里的张三,排查无解。正确做法:向量库的每条记录必须带主数据外键,索引建立时就和主数据 ID 绑定。

反模式四:把特征平台做成数仓的复刻。 有些团队把数仓里的几百张表原样灌进特征平台,美其名曰"统一特征"。特征平台的价值在于"被模型复用的高价值特征的单一真相",不是另一个数据副本。灌几百张表只会增加维护成本,不会提升模型效果。

反模式五:模型网关与数据网关各做各的鉴权。 Agent 一次调用里要鉴权三次(调模型一次、取数据一次、查向量一次),策略不一致导致越权或漏权。融合架构要求三者共享同一份权限策略,从主数据粒度对齐。

反模式六:迷信"一个中台"的物理合并。 物理合并数据与 AI 中台代码仓库、共用一套数据库,听起来干净,实际是把两个高负载系统耦合在一起,任何一边的故障都会拖垮另一边。融合是协议与治理的统一,不是物理堆栈的合并。

本专题小结 ​

数据中台与 AI 中台的融合,本质是把"数据→特征→模型→Agent→回流"这条价值链打通成一条河,而不是在两岸各修一座漂亮的码头。融合的硬指标只有四条:湖仓统一底座(模型读的特征表与推理读的是同一张表)、特征平台消除训练-服务偏差、知识中心与主数据共享 ID 体系、评估中心把数据质量与模型效果对齐到同一时间轴。中国企业已普遍建成数据中台,正确路径是分层叠加(Paimon/Iceberg 湖仓 → 标签中心升级为 Feast 特征平台 → 新建主数据对齐的知识中心 → 评估中心统一 → 网关协议统一),而非推倒重建。70% 的价值在运营,建设投入再多,没有数据质量监控与模型回归测试兜底,就是下一个僵尸中台。组织上,两个团队必须对同一个业务指标负责,否则技术融合做得再漂亮也会被山头主义拆掉。

本专题来源 ​

本站由原始 Markdown 调研报告自动构建 · 原文未改动

FDE 调研报告 (2026)