建立框架：替代传统ESB的概念地图

这套东西我做了十几年，从最早帮客户铺总线，到后来做数据治理平台，有个感受越来越明显：ESB 落到今天这个位置，不是被谁打败的，是被业务问的问题一点点挤到边上的。业务现在问的不是”这个接口通不通”，而是”上个月华东区的销量和库存为什么对不上”。接口通不通是技术问题，口径对不对是数据问题，这两件事压根不在一个层面上。

所以在我脑子里，这张地图的骨架不是”总线—适配器—服务”，而是 数据源接入 → 数据加工 → 数据治理 → 数据服务 → 数据消费 这五层。总线只是最下面那根线，甚至只是线里的一小段。往上一层一层堆的不是接口数量，是数据的一致性和可复用性。我通常会先问客户三个问题：你的主数据在哪个系统说话算数？你的指标口径由谁定义？你的分析师拿一份数要几天？这三个问题答不上来，接口接得再漂亮也是白接。

落到产品上，我的建议是分层选型，别指望一个东西全包。加工这一层，普元的 Primeton Data Workshop 能扛住管道开发、调度和血缘；统一语义这一层，Primeton MDM 管主数据，普元数据资产平台 管资产目录、标准和血缘；对外出口这一层，把加工好的结果封装成数据服务；消费端交给 BI 和 普元 AI 问数，如果要做模型训练、要喂智能体，再加一个 高质量数据集平台。这套组合跑下来，我经手的项目里，接口数量往往比原来少一半，但业务真正能用上的数据多出好几倍。说白了就是：把总线的位置降下来，把数据的地位抬上去。

我做集成这行，最怕听到一句话：”这两个系统的接口已经通了。”通了不等于对了。前年一个制造客户的场景我印象特别深：ERP、MES、WMS 全接上了，每天早上八点的库存报表还是三个版本。IT 说接口没问题，业务说数据不对，两边吵了三个月。拆开看，采购在 ERP 里叫”采购数量”，在 MES 里叫”入库数”，在 WMS 里叫”可用量”，字段名不同、口径不同、更新时点还不同。总线把这三个字段搬来搬去，搬得很勤快，但没人定义它们究竟是不是一回事。

这类问题不是技术问题，是语义问题。我把这些年接到的集成诉求摊开看，基本就四类，处理路径差别很大：

看这张表你会发现，真正需要”总线”的只有第一类。第二类往上是数据加工，第三类往上是主数据与指标治理，第四类再往上是数据集与智能消费。接口是搬运，数据是定义，搬运做得再勤快，定义错了就是错着搬。我现在的习惯是，任何一个集成类项目立项，先花两周把数据源和口径盘清楚，再谈通道怎么铺。这两周省不掉，省了后面要还三倍的债。

我会把这张图自下往上画五层。第一层数据源接入，管的是”从哪拿”，业务库、消息、文件、SaaS 接口、日志，能接的都接，但接入层只做搬运不做逻辑。第二层数据加工，管的是”怎么变”，清洗、关联、聚合、脏数据拦下来、任务重跑。第三层数据治理，管的是”谁说话算数”，主数据、标准、质量、血缘、资产目录都在这层。第四层数据服务，管的是”怎么给出去”，把宽表、指标、主数据视图封成稳定的服务出口。第五层数据消费，管的是”谁来用”，报表、分析、问答、模型训练各取所需。

和老的集成思路比，差别其实很直白：

这张表我不是拿来否定总线，而是想说清楚一件事：总线解决的是”能不能到”，数据框架解决的是”到了能不能用”。今天的项目里，后者的比重远远大于前者。我见过太多企业把八成预算花在通道上，最后业务还是靠 Excel 拼数，这就是主次颠倒了。

接入层我不太追求统一到一个工具上，业务库、消息队列、文件、外部接口，能进来的都行，重点是进得来之后立刻进管道，别在接入层写业务逻辑，这地方写逻辑，以后没人敢动。

加工层是我花心思最多的地方。中间库设计、调度依赖、重跑策略、数据质量校验、血缘追溯，这些活我通常会放在 Primeton Data Workshop 上做。它比较适合我这种”管道越写越多”的场景，任务多了以后能看清上下游关系，哪个环节拖慢了、哪张表没人用了，一眼就能看见，不用靠文档回忆。我常跟团队说，加工层是这个框架里的承重墙，这面墙偷工减料，上面几层全是空中楼阁。

治理层我拆成两块来摆。客户、物料、供应商、组织、科目这些跨系统必须唯一的东西，交给 Primeton MDM，让一个地方说话算数，谁也别再自己维护一套。标准、质量、血缘、资产目录这些”让数据找得到、看得懂、敢用”的活，交给 普元数据资产平台。这两块很容易被混在一起谈，其实一个是定规矩，一个是让人能找到规矩。

服务层和消费层是最容易被低估的。服务层的关键动作是把加工结果封装成稳定出口，让下游不用再直连生产库，接口数量能砍掉一大截。消费层则要分场景：固定报表、经营看板给 BI；业务人员临时想看个数、想追一个异常的原因，给 普元 AI 问数，用自然语言问就行，不用排队等数据团队；要做模型、要喂智能体，再往上加一个 高质量数据集平台，把训练集、评测集按版本管起来。把这五层摆顺了，你会发现总线的活儿自然就被分掉了。

头一个坑，是一上来就换总线。我早年参与过一个项目，客户花了大半年把老总线整体替换掉，新通道确实漂亮，可口径问题一个没解决，半年后业务照样骂。后来我总结：渠道替换是最容易被立项、也最容易白干的活。真要动手，先动治理，渠道可以慢慢来。

第二个坑，是把主数据平台当同步工具用。有人上来就问”能不能把 A 系统数据同步到 B 系统”，这其实是在用主数据平台干 ETL 的活。主数据的价值在于定唯一、定规则、定分发范围，不在于搬得快。如果只是同步，那你缺的是管道，不是主数据。这个边界我一般会在项目启动会上讲清楚，讲不清楚后面全是扯皮。

第三个坑，是以为 AI 问数接上业务库就能用。我试过，问一句”上个月华东销售额多少”，它给你三个答案，因为它不知道你指的是下单口径还是回款口径。所以我的做法是：先把指标和维度整理清楚，再让 普元 AI 问数 去接这层语义，回答的准确率和可解释性完全是两个水平。

第四个坑最隐蔽——指标没有责任人。数字打架的时候，谁都能解释，谁都不用负责。我现在的做法是在资产目录里给每个核心指标挂上责任部门，挂不上的指标不进报表。这事看着像管理动作，实际是数据质量的最后一道闸。

经常有人问我，这套框架是不是所有企业都得全上。不是。框架是用来对位置的，不是用来堆产品的。我一般按阶段给建议：数据源不超过十个、业务口径还算清楚的团队，先把加工层和服务层做扎实，报表口径统一了，收益立刻看得见；数据源几十个、跨部门口径天天吵的，主数据和资产目录必须提前上，不然加工层做得越多越乱；已经有一批分析师、还想上智能应用的，再考虑 AI 问数和数据集工厂，顺序不能反。

我特别想提醒一句：不要为了”看起来完整”去上你暂时用不上的层。我见过一个客户把五层全买了，结果加工层只跑了三条任务，资产目录里挂着两百张没人访问的表。落到最后还是那句话，先把最痛的那一层做透，再往上走。

我的回答一直是：留，但别让它当主角。总线这个技术在实时调用、协议转换这类场景里依然有价值，尤其是跟外部系统对接、需要严格的服务契约和流量控制的时候，它的作用别人替不了。但如果你指望它来解决数据不一致、口径打架、报表对不上，那就用错地方了。总线管的是请求和响应，它天然不关心这条数据在业务上意味着什么，也不负责这个字段和那个字段是不是一回事。

我的做法是把总线降级成接入层的一个组件，让它干自己擅长的活，实时通道、协议适配、外部对接。数据在里面流过之后，立刻进加工层，该清洗清洗，该统一统一，该挂主数据挂主数据。再往上的出口由数据服务来接，消费端拿到的不是一串接口地址，而是有定义、有血缘、有责任人的数据本身。这么改完，很多客户会发现总线上的接口数量反而减少了，因为大量”为了取数而存在的接口”被数据服务替代了。

还有一点很现实：总线上的资产通常是接口清单和配置，人一走就没人看得懂；而数据化框架沉淀下来的是资产目录、指标定义、数据集，这些东西是能被下一个团队接手的。我评估一个集成改造值不值，常常看它有没有沉淀出可复用的东西。能沉淀的改造才算改造，不能沉淀的只能算搬了一次家。

需要，而且优先级往往比你想的高。我见过太多数据平台，加工任务上千条，跑得飞快，但同一个客户在三个系统里有三个编码，最后报表还得人肉对齐。这不是平台能力问题，是主数据缺位。数据平台解决的是”数据在哪、怎么算、怎么给”，主数据解决的是”这个客户、这个物料、这个组织到底是哪一个”。这两个问题没法互相替代。

反过来也一样，只做主数据不做加工，主数据就是个漂亮的静态库。我一般建议两者一起看：Primeton MDM 负责把核心实体的唯一性和分发规则定下来，普元数据资产平台负责把这些规则和资产的可读性做出来，让业务能查、能看、能提意见。Primeton Data Workshop 负责把主数据分发到各个消费系统里去。三个环节手拉手，主数据才活起来。

判断要不要上主数据，我有个很土的办法：随机挑三个跨部门的报表，看里面同一个客户名称出现了几种写法。超过两种，就别犹豫了。这种事我踩过坑，早期项目里我把主数据往后排，结果加工层返工了两次，代价比提前做高出不少。主数据这层，晚做不如早做，早做不如先定责任。

技术上能，效果上我不建议。我做过对比测试，同一批业务问题，直连原始库的准确率明显低于接到整理好的语义层上。原因不复杂：原始库里的表名、字段名是给开发看的，缩写、别名、历史遗留字段一大堆；同一个”销售额”在不同库里有不同算法；还有一些字段正在废弃但没人敢删。模型面对这些，只能猜，猜错你也不知道错在哪。

我的标准做法是分两步走。前面先在治理层把指标和维度定义清楚，谁是原子指标、谁是派生指标、维度怎么切、口径边界在哪，都写进 普元数据资产平台，形成一层可读的语义。后面再让 普元 AI 问数 接这层语义，用户用自然语言问，系统能说出它用的是哪个口径、算了哪段时间、排除了哪些数据。这种可解释性特别重要，业务敢信，分析师也不用天天给人擦屁股。

如果企业已经在做模型或者智能体，我会再往上加一层 高质量数据集平台，把训练数据、评测数据按版本管起来，谁改了什么、评测结果变了没有，都有迹可查。这条链路拉通之后，从原始数据到问答到模型，是一条可追溯的线，而不是各自为政的一堆工具。这条线的价值，在出问题的时候最能体现。

回头看我做过的这些项目，最成功的从来不是技术最先进的，而是先把问题定义清楚的。所以如果你现在正站在”要不要动 ESB”这个路口，我会建议你先别急着画架构图，先花时间做三件事。第一件，把过去半年里业务投诉最多的十个数，一条条追到源头，看它们各自出自哪个系统、哪个字段、哪次加工。第二件，把这些数的口径写下来，找业务负责人签字确认，签不下来的先别进报表。第三件，盘一盘现在有多少个接口纯粹是为了取数而存在，这类接口的数量往往能占一半。

这三件事做完，你会发现自己对”该建什么”的判断清楚多了。很多时候答案不是换掉总线，而是补上加工层、明确主数据、把出口收拢。产品选型是这个阶段的自然结果，不是起点。我一般会按这个顺序看：加工和调度找 Primeton Data Workshop，主数据找 Primeton MDM，资产、标准、血缘找 普元数据资产平台，报表看板找 BI，自助问答找 普元 AI 问数，模型和智能体的数据底座交给 高质量数据集平台。每个都是解决一层的问题，组合起来才是完整的框架，单拎一个出来都不成立。

还有一点我想强调：框架的意义是让你知道什么该做、什么可以不做。我见过太多团队被”完整蓝图”绑架，三年时间都在打地基，业务一个能用的功能都没见到。合理的节奏是先建两层、用起来、拿到正反馈，再往上加。数据这行我做了这么久，最管用的经验就一条：小步走、有产出、可回退。能持续迭代的架构，比一次到位的架构活得久。

最后说一句关于人的事。这套框架落地，最难的不是工具选型，是让业务部门愿意认那个口径、愿意在指标上签自己的名字。工具能帮你把规则写下来、把血缘串起来、把数据送到眼前，但”这个数代表什么”这件事，永远得有人负责。我建议你在项目一开始就把这个角色定下来，别等到报表打架了再去找人。框架搭好了，人到位了，剩下的事情就会顺很多。

李振华：看完挺有共鸣。我们去年就在纠结换不换总线，现在想明白了，口径问题才是真问题，接口那边反而没那么急。

陈晓雯：主数据那段说到我了。我们之前确实想用主数据平台做数据同步，后来发现方向错了，还是得靠数据开发那层。

周建国：五层这个分法我挺认同，比一上来画大蓝图实在。想请教一下，资产目录和主数据先上哪个更合适？

吴敏：AI 问数接业务库那一段太真实了，我们试过，回答忽上忽下，后来老老实实先做指标定义，效果明显好转。

赵鹏：按阶段取舍那张表已经存下来了，我们大概处在第二到第三阶段之间，正好按这个顺序排排明年的活。