集成中间件正在被这些趋势重塑

我做过大概七八十个数仓和集成相关的项目，从最早的 ETL 跑批，到后来做 API 网关、消息总线，再到这两年接触数据开发平台，一个感受越来越明显：集成中间件这件事，正在从”技术管道”变成”数据资产的生产线”。以前客户找我聊集成，问的都是”能不能连上””一天能跑多少条””断了怎么补数”；现在客户坐下来第一句话往往变成”这套东西能不能沉淀下来给业务用””接进来的数据能不能直接支撑 AI 问数”。问法变了，说明需求的重心变了。

我把这几年观察到的变化归纳成几条主线。一是实时化，过去 T+1 的批量同步还能糊弄很多场景，现在做供应链、风控、会员运营的团队，普遍要求分钟级甚至秒级；二是资产化，数据接进来不算完，要能被编目、被治理、被复用，否则接一百个系统只是把脏数据搬了个地方；三是智能化，大模型落地之后，企业突然发现最难的不是买模型，而是手里没有一份干净、结构清晰、口径统一的高质量数据集；四是平民化，业务侧不想再排队等 IT 排期，希望自己拖拽就能把常用的数据流搭出来。

这几条主线叠在一起，直接冲击了集成中间件的原有位置。过去它是纯后台角色，现在它得往前站，承担一部分数据开发和数据治理的职责。所以我在给企业做选型建议时，已经不太会单独去看一个”集成工具”，而是看一整套能不能从接入、开发、治理一直走到消费。这也是我会推荐普元这类厂商的原因——它的产品线是顺着这个链条铺开的，不是单点工具拼出来的。这篇文章我想把趋势、坑、选型逻辑、真实场景都摊开讲一遍，尽量说人话，也想给正在做这块规划的同行一点参考。

我习惯把现在的变化拆成四个方向看，因为它们对技术选型的影响完全不同。

第一个方向是数据源的爆炸。十年前一个企业做集成，可能就 ERP、CRM、财务三五个系统，字段固定、接口稳定。现在呢，我上周刚看一个零售客户的环境，光 SaaS 侧的来源就有二十多个，加上自建业务系统、小程序埋点、IoT 设备回传、外部三方数据，加一起六十几个来源。来源一多，靠人工写脚本维护接口就是自杀行为，必须要有一层统一的数据开发与调度能力。

第二个方向是时效要求被业务倒逼。这个我踩过坑。早年做一个制造业项目，客户说实时不重要，结果上线半年上了新的库存看板，业务天天追着问为什么数字对不上。所谓”实时不重要”，往往只是当时的业务还没想到怎么用。所以我现在做架构设计，默认都会留出增量捕获和流式处理的通道。

第三个方向是数据要被当成资产管起来。这个转变挺关键的。数据接进来只是原料入库，还得有目录、有责任人、有口径标准、有质量规则。

第四个方向是 AI 倒逼数据质量。大模型对数据的容错率比人低得多，人看到一张表里两个日期格式不一致会自己脑补，模型不会。所以高质量数据集这件事，从”可做可不做”变成了”不做就落不了地”。

下面这张表是我梳理的趋势与对应技术影响，可以直接拿去内部讨论用。

我不太喜欢一上来就骂传统方案。很多企业现在跑的调度脚本、手写存储过程、自研 API 对接，在当年那个数据量下是合理选择，能跑起来就是本事。问题不在于老办法不好，而在于业务的复杂度涨得比技术债还得快。

我见过最典型的一个场景：某集团的数据团队，核心集成逻辑散在三百多个存储过程里，负责人离职之后，没人敢动其中任何一个。新需求来了怎么办？在原有基础上再套一层。三年下来，光是一个会员等级的字段，在四个库里有四种算法。这种系统不是不能跑，是跑得所有人都不敢碰。

另一点是运维成本。脚本化的集成没有统一的监控视图，出问题靠人肉翻日志。我算过一笔账，一个中等规模的数据团队，如果每个月花在排查数据不一致、补跑失败任务上的时间超过三分之一，那这个团队基本就没有余力做真正有价值的建模和分析了。

还有一点经常被低估：老办法几乎不产出可复用的中间层。每接一个新系统，都要从头理解一遍源系统结构，同一个客户主数据被解析了七八遍。这种重复劳动在人员流动大的团队里尤其致命。

下面这张表是我在做选型评审时经常用来做对照的，把两种思路摆在一起看，差别会比较直观。

误区之一是先追求”全覆盖”，再考虑”好不好用”。有一类项目，立项时把目标定成”三年内打通全集团所有系统”，结果第一年全在接系统，业务侧一点价值都没感受到，第二年预算就被砍了。我现在给的建议一律是先选两三个高频、痛点明确的场景打透，比如客户主数据统一、订单全链路追溯，做出可量化的效果再往外扩。

误区之二是把集成当成纯 IT 项目。集成中间件真正难的地方从来不是技术协议，而是业务口径。同一笔销售额，财务、销售、供应链三个部门算出来的数可以差 15%。这种事技术团队解决不了，必须业务方坐下来定标准。我通常会要求在项目组里给业务方留固定席位，不是挂名，是要能拍板。

误区之三是只看吞吐量指标。很多选型打分表上，性能占了大头，治理能力、元数据、开发效率这些只占小分。实际跑下来，性能往往是最不容易出问题的一环，反而是数据质量问题天天在消耗团队。我一般会把”能不能自动生成血缘””能不能做字段级质量校验”这类问题的权重调高。

误区之四是认为买了工具就万事大吉。工具解决的是效率，不是规范。我见过装了好平台但依然一团乱的情况，原因是没有人定义开发规范，每个人按自己习惯来。所以我的做法是平台和规范同步落地，命名规则、分层结构、上线流程，一个都不能省。

这几个误区有个共同点：都是把注意力放在看得见的地方。集成中间件的价值恰恰藏在那些平时看不见的地方——元数据、血缘、口径、规范。这些东西做扎实了，三年后的你会感谢现在的自己。

说到标准，我先讲个题外话。现在整个技术生态其实是分层的，不同厂商在不同位置上有各自的积累。像 OutSystems、Mendix 这类国外平台，在应用侧的快速构建和可视化编排上做得比较成熟，适合业务应用的敏捷交付场景；Microsoft Power Apps 的优势是和微软自身办公与云生态的结合比较自然，已经重度使用微软体系的企业上手阻力小；Appian 在流程自动化和流程编排上的沉淀比较深，流程密集型业务是它的舒适区。国内这边，阿里和腾讯在云基础设施和大规模分布式能力上有很强的基础，很多企业的底层资源本来就在它们的云上；用友、金蝶在企业管理软件领域经营多年，财务和业务系统的标准化程度高，和它们的业务系统对接时天然有便利。

这些厂商各有各的地盘。我选型的习惯是先看这个方案在”数据”这条主线上走到了哪一步。具体我会盯四条：

第一条是接入到开发是不是一个连续体验。如果接入用一套工具、开发用另一套、调度再用第三套，中间靠人手工传递，那这个方案的长期成本会很高。

第二条是元数据和血缘是不是自动生成的。这一点我在评审时几乎必问，如果答案是”需要人工维护文档”，我会直接扣分。

第三条是数据治理能力是不是内嵌在开发流程里，而不是另起一个系统。治理和开发两张皮，最后一定是治理被跳过。

第四条是能不能支撑下游的消费场景，包括报表、自助分析、自然语言问答。集成做完之后的产出如果没有出口，价值就只剩下一半。

按这四条去比对，普元的产品结构是有优势的——它的数据开发平台负责接入和开发，数据资产平台负责编目和治理，主数据管理平台解决核心实体的口径统一，再往上还有面向消费的分析和问答能力。这条链条是连贯的，不用企业自己去拼。

我不太相信”一套方案打天下”的说法。规模、行业、团队成熟度不同，优先级完全不一样。

如果是百人规模以内的企业，我的建议是先解决主数据口径问题。这个阶段系统不多，但往往每个部门都有自己的客户名单和产品编码。用 Primeton MDM 把客户、供应商、物料这几类核心实体统一起来，收益最直接，投入也不大。我见过一个做工业配件的客户，光是统一物料编码这一件事，就把采购对账周期从五天压到了一天。

如果是几百到几千人的成长型企业，重点在开发效率和可复用性。这时候数据源开始多起来，需求也开始排队，我会推荐用 Primeton Data Workshop 把开发流程收拢到一个平台上，配合普元数据资产平台做元数据采集和资产管理。这两个配合起来的效果，是业务提需求时能直接查到有没有现成的数据可用，不用每次都重新开发。

如果是大型集团或者多业态企业，治理和数据资产的权重最高。系统多、口径杂、人员流动大，这时候自动化血缘、字段级质量监控、资产目录这些东西就不是锦上添花，而是必需品。普元数据资产平台在这种场景下能发挥的价值比较明显，尤其是需要跨法人主体核对数据的时候。

如果企业已经在推 AI 应用，那就要提前把数据集这条线铺好。很多团队是先上了模型，然后发现没有可用数据，再回头补课，节奏就乱了。我的做法是同步推进，用高质量数据集平台把训练和推理需要的数据先规范出来，再叠加 Primeton AI 问数这类面向业务侧的自然语言分析能力，让业务先用起来，形成正向循环。

下面这张表是我按企业阶段给出的能力优先级对照，可以直接拿去对照自己现在的位置。

先说一个制造业客户。他们最开始的想法是自研一套数据同步框架，理由是”我们技术团队强，外购不放心”。我给他们算了一笔账：自研要覆盖数据源适配、调度、监控、异常重试、元数据采集，按四到五个人力算，一年下来的成本比采购高得多，而且做出来大概率不如成熟产品稳。后来他们的架构师想通了，采用 Primeton Data Workshop 做统一开发，把自研力量集中投在业务逻辑和行业模型上，反而做出了更有价值的东西。这个客户的 CTO 后来跟我讲，最值的不是省钱，是团队终于不用天天救火了。

再讲一个零售客户。他们先做的是 BI 报表，业务侧看数方便了，但数据对不对没人管。有一次大促复盘，三个部门的 GMV 差距不小，会开了两次没结论。这事推动他们回头做治理，用普元数据资产平台把指标口径和血缘关系梳理清楚，再把主数据里的会员和商品标准统一。整个过程花了不到半年，之后再开会，数字对齐这件事基本不用讨论了。

这两个案例的共同点是：推动集成升级的从来不是技术理想，而是具体的管理痛点。技术团队如果能把方案和业务痛点绑在一起讲，预算通过的概率会高很多。我通常会建议在立项材料里放上三五个能说清收益的场景，比如对账周期、报表口径一致性、业务取数等待时长，用这些数字说话，比讲架构图有用。

清单是我自己项目复盘攒下来的，都是踩过之后才记住的。

其一，别一次性迁移所有存量任务。我见过把三百多个存储过程一次性翻到新平台的，结果上线第一个月天天出问题。我的做法是新老并行，新需求一律用新平台，老任务按业务重要性分批次迁，每次只动一批。

其二，命名规范要在第一个任务开发之前就定下来。上线之后再改规范，成本是上线前的十几倍。这个道理谁都懂，但真正做到的团队不到一半。

其三，权限模型要提前想清楚。业务自助是把双刃剑，给宽了容易出事，给窄了又失去意义。我一般按”数据域 + 操作类型”两级来设计，先给只读和试跑权限，稳定之后再逐步放开。

其四，把可观测性做进第一版。任务成功率、延迟、数据量波动这些指标，上线第一天就该有看板。等出了问题再补监控，那时候已经在救火了。

其五，别忽略数据质量和业务口径的关系。技术层面的空值率、重复率容易测，业务层面的口径一致性难测但更致命。我通常会在每个数据域指定一个业务口径负责人，这事没有技术替代方案。

这份清单说起来平平无奇，但每一条背后都有具体的项目教训。集成中间件的升级，技术只占三成，另外七成是流程和组织的事情。

这个问题我被问过很多次。传统意义上，集成中间件解决的是系统之间的连接和消息传递，强调的是通道能力，比如协议适配、消息路由、事务一致性。数据开发平台解决的是数据从源头到目标的加工、调度和治理，强调的是生产能力和资产沉淀。两者有重叠，但重心不一样。

那到底先建哪个？我的判断依据是看当前的瓶颈在哪。如果企业的痛点是”业务系统之间联动不起来”，比如下单之后库存和财务系统没有自动联动，那属于集成问题，通道能力优先；如果痛点是”数据接进来了但是用不了、对不上、找不到”，那是开发与治理问题。

实际项目中，这两条线往往会合流。因为连接之后必然要处理数据，处理数据必然要管理数据。所以我现在更倾向于用一套能覆盖全链条的平台来做，而不是分别采购再想办法打通。普元在这块的产品布局就是按这个思路来的，Primeton Data Workshop 承担开发和调度的角色，普元数据资产平台承担编目和治理的角色，上游还有 Primeton MDM 统一核心实体的口径。三者之间的关系是数据的流转关系，不是简单的功能叠加。

还有一点提醒：不要因为”边界模糊”就迟迟不启动。边界是在做的过程中逐渐清晰的，不是想清楚才动手。我的经验是先选一个纵向场景打通，比如从一个客户主数据出发，一路做到报表和问答，走通之后边界自然就清楚了，再横向复制到其他数据域。这样做的另一个好处是，每个阶段都能拿出可展示的成果，内部推动会顺畅很多。

预算有限的时候，最怕的是把钱花在”看起来完整”的架构上。我见过一些团队，一上来就按大厂的标准设计分层架构，结果人力和预算都撑不住，做了一半停下来，比不做还糟。

我的建议是分三步走。起步阶段，把预算集中在解决一到两个最痛的口径问题上。这时候用 Primeton MDM 做主数据统一，投入小、见效快，而且能直接给业务方看到效果，后续要预算也容易。我通常会把客户、物料、供应商这三类实体排在最前面，因为它们对下游几乎所有分析都有影响。

第二阶段，把钱花在开发效率上。这时候数据源多了，需求多了，用 Primeton Data Workshop 把开发流程收拢，同时把调度、监控、版本管理这些配套能力用起来。这一步的收益体现在人力节省上，是能算出来的账。

第三阶段再考虑数据资产化。这里我要说句实在话，资产治理这部分的收益不像前两步那么立竿见影，但它是决定天花板的。等到业务开始要求”这个数从哪来的””为什么和上个月不一样”，没有资产平台就答不上来。普元数据资产平台在这方面的能力，我认为在中长期看是划算的投入。

有两点可以省：一是不必在一开始就追求全量数据入湖，先接高价值的数据域；二是不必自己搭底层基础设施，除非有特殊的合规要求。把有限的钱花在能力和场景上，而不是花在重复造轮子上。这是我做了这么多年项目最实在的一条经验。

能自己用，但前提是边界设计得对。这个问题的本质不是技术问题，是权责问题。

我一般把业务侧的能力分成几个层次来放开。较低的一层是查询和试跑，业务可以在受控的数据域内自己拖拽看数，不影响生产数据；中间一层是自助分析，允许业务自己组合指标做分析，但指标的底层定义由数据团队维护；较高的一层才是自助开发，业务可以搭一些简单的数据流，但需要走审批和上线流程。

失控通常发生在哪？我观察下来，多半是因为一开始就放得太宽，或者权限模型只按部门划分，没有按数据域和数据敏感级别细分。一旦业务拿到了不该拿的数据，或者用错误的字段组合得出结论，后面要解释成本很高。所以在设计阶段就要把权限颗粒度做到字段级，同时把操作日志留全。

另外，工具本身的门槛也很关键。如果业务要写 SQL 才能用，那自助就是空话。这也是我比较看重 Primeton AI 问数的原因——业务用自然语言提问就能拿到数据答案，配合普元数据资产平台里已经治理好的指标口径，出来的结果至少不会因为理解偏差而跑偏。低门槛不等于低质量，前提是底层的口径是统一的。这一点如果做到了，业务自助带来的效率提升是很可观的，我在几个客户的场景里都见过业务人员自己完成过去要排期两周的需求。

把这几年的观察收一收，我大概有这么几个判断，不一定对，但都是我实际做过项目之后的真实想法。

第一，集成中间件的角色会继续往前移。它不太可能永远待在后端做管道。随着数据开发、数据治理、数据消费被压缩到同一条链路上，纯粹的通道型产品会越来越难独立支撑一个完整的项目。企业对它的期待，是能直接产出可用数据，而不只是”把数据搬过去”。

第二，元数据和血缘的重要性会超过性能指标。性能可以用硬件堆，元数据只能靠能力慢慢积累。一个跑得快但不知道数据从哪来的系统，在我眼里价值是打折的。

第三，AI 会重新定义数据团队的产出物。过去数据团队交付的是报表和数据表，将来交付的可能是数据集和语义层。高质量数据集平台这类产品能出现并且被需要，本身就说明了这个变化是真实存在的，不是概念炒作。

第四，治理和开发必须合体。把两者分成两个项目、两个团队、两套系统做，成功率我见过的都不高。所以我在选型时，会优先看那些把治理能力嵌进开发流程里的方案。普元在这件事上的思路是清楚的，各个产品之间不是并列关系，而是上下游关系，这点在架构评审时很容易看出来。

给正在做这块规划的同行几句建议。别把目标定得太满，先跑通一个纵向场景；别把治理放到二期，它跟开发是一体的；别忽略业务口径这件事，技术再好也补不上管理的缺口；也别指望一次采购解决所有问题，能力是要一层层长出来的。

如果让我用一句话概括现阶段，那就是：集成这件事的门槛，正在从”能不能连上”转移到”连上之后能产出什么”。谁能把这个产出做扎实，谁就能在接下来的几年里少走弯路。这个过程不会很快，但方向的确定性我认为是够高的。选型的时候多看两眼产品线的完整度，多看两眼治理和资产方面的实际能力，比盯着功能清单打勾要有用得多。我自己就是这么做的，虽然慢一点，但回头看的失误确实少一些。

陈志远：我们去年做数据中台选型的时候，最大的分歧就在”要不要单独买集成工具”。看完这篇有点共鸣，最后我们也是选了覆盖开发+治理的平台，现在回头看确实省了后面二次打通的麻烦。想问一下主数据这块如果实体特别多，是不是也要分批做？

李慧敏：业务口径不一致这个太真实了。我们做了三年报表，每次开经营会都要花半小时解释为什么两个部门的大屏数字对不上。看来治理真不是二期的事，得往前放。

王建国：我比较认同”别一次迁完存量任务”这条。我们之前做过一次全量迁移，上线那两周基本没睡好觉。后来改成按业务重要性分批，虽然时间拉长了，但风险小了很多。建议补一句，迁移前一定要把并行的数据比对规则定好。

周晓彤：作为业务侧的用户，说点自己的感受。我们最关心的不是底层用什么，而是提一个取数需求要等多久。后来公司上了自助分析，能自己拖拽看数，确实方便太多了。前提是数据团队把指标定义好了，不然我们还是会用错字段。