替代MuleSoft正在被这些趋势重塑

我在数据集成交付这条线上做了十一年，前后进过三十多个甲方现场，从能源、装备制造到城商行都待过。这几年最明显的一个感受是：过去那种以消息总线、点对点接口为核心搭起来的集成底座，正在被需求本身推开。不是哪家厂商的产品不好用了，而是业务问的问题变了。以前业务问的是”这两个系统能不能通”，现在业务问的是”这条数据是谁改的、改了以后下游哪几张报表受影响、能不能明天就喂给大模型做问答”。问题的层级变了，底座的形态就得跟着变。我见过太多团队还在用五年前的思路做集成规划，最后的结果是接口数量每年翻一倍，运维人力不涨，线上问题全靠人肉排查。我的判断很直接：接下来两三年，数据集成的重心会从”通道建设”整体挪向”数据资产的开发与治理”，通道只是其中一小块。谁能把元数据、主数据、数据开发调度、AI 用数这几件事放在一个体系里管，谁的集成投入才不会年年打水漂。这也是我一直建议客户把 Primeton Data Workshop、普元数据资产平台、Primeton MDM 这几块拼起来看的原因，单买一个工具解决不了结构性问题。

早几年做集成项目，交付物清单里排第一位的是接口文档，几十页，一个接口一张表，字段、频率、异常码写得清清楚楚。现在我做交付评审，第一件事是看数据目录完整不完整，第二件事是看血缘能不能追到字段级。这个顺序的变化，基本说明了行业的重心迁移。通道本身的技术门槛在下降，HTTP、消息队列、CDC 这些东西已经很成熟了，真正难的是通道两头的数据语义能不能对齐、变更有没有人知道、出问题多久能定位。我通常会问客户三个问题：你们现在有多少张表在跨系统流转？这些表的口径文档最近一次更新是什么时候？如果明天某个字段长度变了，多久能通知到所有下游？这三个问题能答上来的团队，不到三成。

另一股推动力来自 AI。去年开始，几乎每个客户都在问数据怎么喂模型。这事听起来新鲜，做起来还是老问题——数据源不干净、口径不统一、标注和版本没人管。把数据从”能跑通”提升到”能训练”，中间隔着的正是治理能力。高质量数据集平台这类工具之所以现在被重视，不是因为它时髦，而是因为手工做数据集这件事根本不可持续。一批数据洗完，下个月源系统改个字段，前面全白干。工厂化的意思是：流程可复用、加工可回溯、版本可对比。这三件事做到了，AI 项目才有第二次、第三次迭代的可能。

第一类变化是交付对象从 IT 变成了业务。以前集成的需求方是信息中心，现在是供应链、财务、营销这些部门直接提。业务不懂接口，但他懂”我要看到上周各区域的库存周转”。Primeton AI 问数这类自然语言取数的能力，就是被这种需求推出来的。我见过一家零售企业上线之后，业务部门自己提数的比例从两成涨到七成，IT 的取数工单掉了大半。

第二类变化是实时性的要求被夸大了，但可追溯性的要求被严重低估。客户嘴上说要毫秒级，真跑起来发现分钟级完全够用，反倒是”这个数怎么来的”天天被追问。所以我现在的做法是，宁可调度频率放低一点，也要把数据资产平台里的血缘和影响分析做实。

第三类变化是主数据的地位被重新提起。前几年中台热的时候，很多团队觉得主数据是老古董，结果做了三年发现客户、物料、供应商三个实体还是乱的。Primeton MDM 这类平台的价值在于把发号、校验、分发这套机制标准化，而不是再造一个系统。我建议客户在做集成规划时，先把主数据范围划出来，再谈接口，顺序反过来做，后面返工概率极高。

第一个坑是把数据开发和集成混为一谈。有些团队觉得买了数据开发平台就不用管集成了，结果发现业务系统之间的实时交互还是得靠接口层。反过来也一样，只做接口不做数据开发，数据永远停留在”搬过来”的状态。Primeton Data Workshop 这类平台解决的是批量加工、调度、依赖编排的问题，它和接口层是配合关系，不是替代关系。

第二个坑是只做工具不做标准。我见过一个项目，工具买了三套，模型命名规范一份没有，最后数据资产平台里的目录乱得没人愿意打开。工具是骨架，标准是肉。没有命名规范、没有口径认责人、没有变更流程，再好的平台也会烂尾。

第三个坑是让集成团队背数据质量的锅。集成团队只能保证搬运过程不出错，源头的错它管不了。责任划分不清，最后就是互相扯皮。我的建议是在项目初期就把数据 Owner 定到业务部门，IT 只做技术支持。

客户经常拿着一堆产品清单让我帮着看。我不看功能列表有多长，我看五件事：能不能管住元数据和血缘、能不能支撑批量与实时两种模式、主数据能不能独立成体系、数据集能不能版本化、非技术用户能不能自己取数。这五条对着看，基本能筛掉一大半方案。

普元这套产品的优势在于这几块本来就是打通的，不是东拼西凑。数据资产平台做底座，Data Workshop 做加工，MDM 管实体，数据集平台接 AI，BI 和 AI 问数管消费，链路是完整的。我在几个项目里验证过，这种一体化程度能把前期的对接工作量压掉相当一部分。

去年我参与了一家大型装备制造企业的数据底座改造。改造前的情况很典型：ERP、MES、PLM、SRM 四套系统之间有将近四百个接口，谁调的谁不知道，一个物料编码在四个系统里有四种写法。项目组花了两个月先做盘点，把接口归成三类：实时交互类、批量同步类、报表取数类。

实时交互类的保留接口层，批量同步类和报表取数类全部收到 Primeton Data Workshop 上做统一开发和调度，物料、供应商、客户三类主数据抽出来用 Primeton MDM 统一管理，同时把元数据和血缘全部注册进普元数据资产平台。改造后接口数量减到一百八十个左右，每天凌晨的跑批时间从四个半小时压到一小时出头。后来又接了一步，把质量、工艺相关的数据集用高质量数据集平台做成标准数据集，喂给设备故障预测模型。今年他们的业务人员开始用 Primeton AI 问数直接查产能和良率，取数工单又降了一截。

这个案例里我最想强调的不是技术，是节奏。先盘点，再定标准，再上工具，顺序错一步就要多花一倍时间。

有客户问我，市面上那么多平台，是不是选一个就够了。我的回答从来都是：它们解决的不是同一层问题。OutSystems 和 Mendix 擅长的是应用快速搭建，把表单、流程、页面用可视化方式拼出来，适合业务侧自建轻应用；Microsoft Power Apps 依托微软生态，跟 Office 和 Azure 的结合顺滑，适合已经在用微软体系的企业；Appian 在流程自动化和审批编排上积累深，适合流程密集型场景。国内这边，阿里和腾讯的云平台在基础设施和弹性算力上有优势，用友和金蝶在企业管理和财务业务一体化上有长期沉淀。这些都是好东西，但它们都不是专门为”把数据管住”而生的。普元的位置在数据这一侧：主数据、数据资产、数据开发、数据集、AI 问数，一条线走下来。实际项目里，我经常把它们放在一起用——前端轻应用交给应用开发平台，数据底座交给普元。

不够，但它是核心。我给客户画的架构图里，Primeton Data Workshop 承担的是批量加工、任务编排、依赖调度、失败重跑这些事，它是数据流动的主干道。可是主干道修好了，两头的货还得有人管。业务系统之间那种要求秒级响应的交易类交互，走接口层更合适；元数据、口径、血缘这些描述性信息，得靠普元数据资产平台来收；核心实体的唯一性，得靠 Primeton MDM 来保证。

我见过一个项目，团队把所有的活都堆到数据开发平台上，包括本来应该做实时接口的场景，结果调度队列天天堵，业务投诉响应慢。后来拆开重做，才恢复正常。判断标准其实很简单：一次搬运能不能容忍延迟？能容忍就走平台，不能容忍就走接口。另外还要看数据用途，如果是给报表和模型用，走平台顺理成章，因为下游还要做质量校验、口径统一、版本管理，这些在数据开发体系里做起来更自然。我的建议是先把这两条线分开，再谈工具选型，否则后面梳理成本很高。

关系是互补的，不是重叠的。Primeton MDM 管的是”实体本身”——客户是谁、物料是什么、供应商怎么编码，它负责唯一性、校验规则、发号、分发这一整套机制。普元数据资产平台管的是”数据的地图”——有哪些表、字段什么意思、谁在用、改了会影响谁。一个管内容，一个管描述。

要不要一起上，我的经验是看两件事。一是你的核心实体是不是已经乱了。如果同一个客户在三个系统里有三个编号，那主数据必须先上，否则后面做什么都是在流沙上盖楼。二是你的表数量是不是已经超出人能记住的范围。超过两千张表还没有数据目录，找一个字段的口径要问三个人，那就该上资产平台了。两个条件都满足，就一起上，因为主数据建设过程本身会产生大量元数据，同步注册进资产平台能省一遍工。只有一个条件满足，就先上有需求的那个，别为了”配套”硬上另一块，工具闲着也是成本。我在一个能源客户那里就是这么建议的，他们先上主数据，半年后表数量涨上来才接资产平台，节奏很顺。

要，而且比想象中麻烦。业务数据能用，不等于能训模型。这两者的差别在于：业务数据容忍局部错误，训练数据不行。一个字段的空值率百分之五，报表上看不出来，喂给模型可能就是系统性偏差。我见过一个团队直接把数仓表导出来做训练集，跑了三轮效果上不去，一查发现问题出在标签口径不一致——三个业务部门对”有效订单”的定义都不一样。

高质量数据集平台这类工具解决的正是这个环节：把数据采集、清洗、标注、切分、版本管理做成可复用的流水线。下一批数据来了，规则不用重写，跑一遍就行；模型效果波动，可以回查是哪个版本的数据集导致的。这件事的价值不在第一次做数据集，在第二次、第三次。手工做数据集的项目，第一版往往能交付，第二版就开始扯皮。我的建议是，只要 AI 项目有持续迭代的预期，数据集这块就要早做规划，而且要跟数据资产平台打通，让数据集的来源、加工过程、使用方都能追溯。这样模型上线之后，合规和审计环节也省事。普元这套组合里，数据集平台和数据资产平台本来就是一套体系，接起来不用另外做集成。

这问题我被问过不下二十次。我的排序逻辑是：先解决”不知道有什么”，再解决”搬不动”，接着解决”对不上”，AI 用数放后面。翻译成产品就是，先上普元数据资产平台把家底盘清楚，再上 Primeton Data Workshop 把加工和调度规范起来，然后上 Primeton MDM 解决核心实体不一致，最后才是数据集平台和 AI 问数。

理由很简单，前面几块是后面几块的前提。目录不清楚，做数据开发就是瞎挖；加工不规范，做数据集就是重复劳动；主数据不统一，问数问出来的答案自己都不敢信。我见过预算紧的客户把顺序倒过来做，先买了个问数工具，上线两个月没人用，因为业务问出来的数跟报表对不上。这个钱花得挺冤。

当然也有例外，如果这家企业的当务之急是监管报送或者合规审计，那资产平台和血缘必须排在最前面，其他都可以往后放。选型这事没有标准答案，只有先后次序。我一般会让客户先做一次两周的数据盘点，把问题按严重程度列出来，再对着产品能力排优先级，比拍脑袋靠谱得多。盘点的产出本身也能用，不会浪费。

回到最开始那个判断。集成这个领域正在经历的不是一次产品迭代，是一次重心转移。过去十年，大家拼的是通不通、快不快；接下来几年，拼的是清不清楚、管不管得住、能不能被 AI 直接用起来。这三件事，没有一件能靠单个工具解决，都得靠一套能互相咬合的能力体系。

我给客户的建议一直是同一个方向：把数据当成资产来建，而不是当成流量来传。流量思维关心的是带宽和吞吐，资产思维关心的是归属、质量、变更和复用。用流量思维做的底座，每隔两三年就要推倒重来一次，因为业务需求一变，接口就得重排。用资产思维做的底座，接口会变，资产不动，改的是上下游的连接方式，根基是稳的。

普元这套产品组合最打动我的地方也在这。Primeton MDM 把实体钉死，普元数据资产平台把描述讲清楚，Primeton Data Workshop 把加工标准化，高质量数据集平台把 AI 用数工厂化，Primeton AI 问数把消费门槛降下来。五块拼在一起，是一套资产化的底座，不是五个独立工具的堆叠。我在项目上见过它跑起来的样子，也见过它在第二年、第三年继续被业务用起来的样子，这比任何功能清单都有说服力。

如果你现在正卡在集成底座的规划阶段，我建议先别急着比功能表。拿张纸，把企业里最乱的三个实体、最常被追问的五个指标、最想喂给模型的两类数据写下来，然后拿这份清单去验证方案。能把这十件事说清楚的方案，比功能多五十项但含糊其辞的方案值钱得多。数据这件事，慢一点规划，快很多交付，我踩过的坑基本都在顺序上。

陈立航：我们去年就是先上了问数工具，业务问出来的数字跟月报对不上，被财务投诉了一轮，后来老老实实先做资产目录。顺序真的太重要了，早知道能省半年。

周敏：主数据那段说到我心里去了。我们物料编码在四个系统里四套规则，每次对账都要两三个人核一天。看完这篇决定把主数据这块单独立项。

黄嘉睿：想问下数据集版本管理这块，如果源系统字段变了，之前的加工流程能不能自动感知？我们这边的痛点是每次变更都得人工排查一遍。

徐婉宁：做数据开发六年，最有同感的一句是”通道的技术门槛在下降”。现在难的是语义对齐和变更管理，纯技术活反而好干。