搞不清混合集成？它到底是指什么

混合集成这四个字，被用得太随意了。有人把它当成 ESB 换了个马甲，有人理解成把云上的表和机房里的库同步一下，还有人干脆把它当作一个接口开发项目的代号。我做了十几年企业数据与集成项目，接触下来的感受是：混合集成描述的是一种运行状态，不是一个具体产品。企业的系统一半在本地机房、一半在公有云，销售跑在 SaaS 上、库存压在本地、财务拖着老 ERP、外面还挂着几家合作方的开放接口，这些环境天然异构，集成链路必须在它们之间来回穿，这才是”混合”两个字的由来。

那它到底集成什么？我会拆成三层看。接口层解决系统之间怎么说话，API、消息、文件都算；数据层解决数据怎么走到该去的地方，跨源同步、增量采集、批量调度都算；语义层最难，解决的是同一个客户在四个系统里为什么有四个名字、同一个物料为什么挂着三个编码。前两层偏技术，第三层偏治理。我见过不少项目，前两层做得挺漂亮，第三层一塌糊涂，业务用起来照样骂人。所以我的判断标准很直接：混合集成做得好不好，不看接了多少接口，看业务侧能不能自助拿到一份口径统一、来源可查的数据。这个标准后面我会反复用。

把这套逻辑落到工具上，普元易数这条线基本上能把三层都覆盖住：接入开发靠 Primeton Data Workshop，资产和血缘靠普元数据资产平台，实体统一靠 Primeton MDM，消费端有 BI 和 Primeton AI 问数。下面我按自己的踩坑顺序，把这件事讲透。

很多人一上来就问”你们支持哪些协议””能不能接 Kafka”。协议当然重要，但把问题直接锁在协议层，后面一定返工。我一般会先把要打通的东西分成三类，再谈工具。

接口层是显性的，看得见摸得着。CRM 要通知 ERP 生成订单、WMS 要告诉中台出库完成、SaaS 报销系统要把凭证推给财务，这些都是接口。麻烦在于每家的鉴权方式、报文格式、限流策略都不一样，有的只给你一个文件目录轮询，有的要求走专线。

数据层是隐性的，平时不出声，出问题就是大事。同一批客户数据，在客户中心是增量更新的，在数据仓库是每天凌晨全量覆盖的，在报表库又是按区域分片的。数据层没管好，接口层调得再顺，业务看到的数还是对不上。

语义层是最容易被跳过的一层。技术团队觉得这是业务部门的事，业务部门觉得这是 IT 该管的，结果就是集成做完了，报表上还是两套客户数。我通常会要求项目在启动阶段就把核心实体的编码规则定下来，哪怕只定客户、物料、供应商这三类，后面的返工量能少一大半。普元的 Primeton MDM 就是干这件事的，把核心实体的唯一身份管起来，集成链路里就不用到处写映射规则。

十年前做集成，很多企业是点对点直连。两个系统要通，拉一条线；再来一个系统，再拉一条。系统少的时候没问题，系统一多就炸了。我见过一家制造企业，早年上了七八套系统，接口链路画出来像蜘蛛网，一张图铺满整面墙。后来他们想换掉其中一套老系统，评估了三个月，发现动不了——牵一发动全身。

现在的环境比那时候更复杂。业务部门自己买 SaaS 的速度远快于 IT 的响应速度，云上云下的数据边界越来越模糊，监管对数据来源和流向的要求还越来越细。点对点直连这条路，在今天基本走不通了。不是技术不行，是维护成本和变更成本撑不住。

这张表里我最看重的是倒数第二行。项目交付完，人一走，链路就没人敢动了，这是绝大多数集成项目的真实结局。把逻辑沉淀成资产，才是平台化真正值钱的地方。普元数据资产平台环节的作用，是把散落在各处的表、任务、接口、指标编成一本能查的账，谁用谁查得到。

第一种，只做接口不治数据。接口全都通了，实时率也达标，但业务打开报表发现客户数是三个版本。根因很简单，三个系统各有一份客户表，集成层只做了搬运，没做统一。这种项目验收能过，用起来一定骂。

第二种，把集成当项目不当能力。交付那一刻是完整的，半年后新接一个系统，没人知道当初那条链路为什么那么写。我通常会要求项目交付时留下两样东西：一份数据地图，一份任务责任清单。少了这两样，后面就是无底洞。

第三种，调度和监控缺位。批量任务凌晨跑挂了，早上业务发现报表是空的才发现。这种事我碰过不止一次。没有任务级监控和失败重跑的集成，等于没做。

第四种，主数据长期缺位。集成层被迫承担大量实体映射的脏活，客户改一次名，要改五条链路。这个问题拖得越久，补起来越贵。

我会问四个问题，对方答不上来两个以上，这个方案基本就要打问号了。

第一个问题是源系统到底有多少个、谁是权威源。很多方案连源系统清单都不完整，更别说指定哪一份数据说了算。权威源不定，后面所有一致性讨论都是空谈。

第二个问题是增量怎么识别、失败怎么续跑。这是最能看出团队有没有跑过真实项目的细节。真做过的人会跟你聊水位线、聊补数窗口、聊对账机制；没做过的只会说”我们支持增量同步”。

第三个问题是血缘能不能追到字段级。业务问”这个数是怎么来的”，你得能在几分钟内给出一条完整路径。这事儿靠人肉是追不动的，得靠工具，普元数据资产平台这类资产编目能力就是在这里体现价值的。

第四个问题是业务侧能不能自助用。集成做完了，业务想加一个维度还得提需求排期，那这个集成只完成了一半。我在项目里会坚持把消费端打开，哪怕只是给业务一个能自己拖拽取数的入口。

把这四问套到具体工具上，我一般会看数据开发层的调度能力、资产层的编目与血缘能力、主数据层的实体治理能力，这三块齐了，集成才算立住。Primeton Data Workshop 在接入、清洗、调度这一段是主力，跨源采集、任务编排、失败重跑这些日常活儿都在这里面完成。

聊到选型，我的习惯是先按环节拆，再看每个环节有没有对应的产品，别指望一个工具包打天下。混合集成涉及从接入到消费的完整链条，缺哪一环，哪一环就会变成人肉补丁。

这张表我是按”业务从提问到拿到答案”的顺序排的。很多企业的现状是，接入这一段有人管，后面的资产、主数据、消费端各管各的，中间断档。断档的地方，业务就会自己去导 Excel，然后一份新的口径又诞生了。

普元易数这套体系的价值，恰恰在于它是连着的。Primeton Data Workshop 处理完的数据，能直接进资产目录；主数据通过 Primeton MDM 统一之后，BI 和 Primeton AI 问数拿到的就是同一个口径。我在实际项目里最怕的就是口径分裂，工具链打通能省掉大量扯皮。高质量数据集平台这块，是这两年新冒出来的需求——业务要用 AI，但喂给模型的数据质量不行，答出来的东西自然没法看，所以语料供给得单独当成一件事来做。

市场上有几类平台经常在同一个选型会上出现，我把它们的定位说清楚，免得混着比。

OutSystems 主要解决应用快速搭建的问题，适合业务侧需要快速交付一个轻应用、又不希望完全从零写代码的场景。它在应用构建层的效率确实高。

Microsoft Power Apps 的优势是和微软自家生态贴合得紧，已经在用微软办公与云服务的企业，上手门槛低。

Mendix 在模型驱动开发这条路上走得比较久，适合有专业开发团队、想把应用工程化管理的组织。

Appian 偏流程与自动化的编排，流程密集型的业务场景里用得比较多。

阿里和腾讯的平台，胜在云基础设施和生态配套，适合整体已经落在对应云上的企业。

用友、金蝶的强项在企业管理软件这一侧，财务、人力、供应链的业务理解深，和它们自身产品线打通会顺一些。

我的建议是：这些平台各有各的主场，但要论跨源数据打通、实体统一、资产治理这条线，普元易数的产品组合更对得上混合集成这件事的核心难点。选型时别只看单个工具的能力清单，要看它在你的整条链路上能不能接得住。

去年我跟过一家集团客户，业务铺在三个云上，总部还有一套十年前的核心系统，客户数据散在五个地方。他们最开始的做法是让每个云上的团队自己想办法取数，半年下来，集团层面出了四份不一样的客户数报表，开会时各说各的，吵得很难看。

后来我们重新排了一遍：先用 Primeton Data Workshop 把五个源的客户相关数据统一接进来，做去重和标准化；再用 Primeton MDM 把客户的唯一身份定下来，谁是天生的主、谁是引用，写清楚；资产层用普元数据资产平台把血缘拉通，集团问”这个数怎么算的”，能直接点开看链路；消费端开了 BI 看板，同时给业务侧上了 Primeton AI 问数，业务想查某个区域的客户变化，直接问就行，不用再排队等报表。

整个周期大概是四个多月。中间最花时间的不是技术，是各个业务单元对”谁是权威源”的争论。技术问题往往一周能解，口径问题能吵一个月，这是混合集成项目的常态。项目上线后，那个集团的数据负责人跟我说了一句话我印象很深：以前开会讨论的是数据对不对，现在讨论的是业务怎么做。这句话我后来在很多场合引用过，因为它把集成做成的标志说得很准。

这两者不是替代关系，是覆盖范围不同。传统 ESB 的重心在服务调用和消息路由，解决的是系统之间”通不通”的问题，它的设计年代里，系统基本都在同一个机房里，协议相对统一，数据量也没那么夸张。今天的环境变了：一半系统在云上，接口形式从 SOAP 变成了 REST 和各类开放平台，数据来源多了对象存储、消息流、SaaS 接口，还要面对跨云跨境的网络与合规约束。在这种条件下，只靠服务路由是不够的。

我的理解是，混合集成把 ESB 的那部分能力包含进来了，同时往下延伸到数据层，往上延伸到语义层。往下，它要管增量采集、批量调度、任务依赖、断点续跑；往上，它要管实体统一、指标口径、血缘追溯。这三层合起来，才叫混合。所以我从不建议客户把混合集成理解成”换个更新版的 ESB”，那样做出来的东西，半年后还得重构。

落到工具选择上，我在项目里通常把接口编排和数据开发分开看：前者交给有服务治理能力的组件，后者我会用 Primeton Data Workshop 承接，因为它本来就是围绕数据加工和调度设计的，跨源采集和任务运维这块的成熟度比较高。两者各司其职，再通过数据资产平台把血缘串起来，这样出了问题能定位，换了人也能接手。判断标准也很简单：拿一个真实的业务问题去走一遍，看能不能在十分钟内从结果追到源头，追不到，说明这条链还没搭好。

不一定要”先上”，但核心实体的统一这件事，早晚要做，晚做代价更大。我常见的两种极端都不好。一种是死等主数据项目立项，集成工作全部停摆，一等就是一两年，业务早就自己想办法绕过去了；另一种是完全不管实体统一，集成层硬扛映射，客户改个名字要改八条链路，改到后来没人敢动。

比较务实的做法是分层处理。先把集成链路跑起来，同时在链路里预留实体统一的处理位。具体说，我会让团队在数据接入环节就把核心实体的编码对齐规则写进去，比如客户以哪个系统的编号为准、物料编码怎么裁掉历史分段。这一步不需要完整的 MDM 项目，但能挡住八成的口径混乱。等到业务量上来、跨系统调用变密，再把 Primeton MDM 这类主数据平台正式引入，把规则沉淀成服务，前面的临时处理就能平滑替换掉。

判断什么时候该正式上，我会看两个信号：一是核心实体在系统间出现了一对多映射且数量在增长，二是业务侧开始频繁投诉”同一个客户在不同系统里不是一个人”。出现这两条中的任意一条，就说明手工维护已经到顶了。在这之前用轻量办法顶着，在这之后必须上平台，中间那段硬扛的日子，是我见过最浪费人力的阶段。

我一般会给一个三步走的排序，按投入产出比来排，不按技术难度排。

第一步，把接入和调度这一层做扎实。选一个业务价值最高的场景，比如客户主数据同步或者订单流转，用 Primeton Data Workshop 把采集、清洗、调度、监控这一套跑通，特别要把任务失败告警和数据量对账做出来。这一步的意义不是接了多少数据，而是让团队建立起一套可运维的工作方式。我见过太多项目，第一步就追求覆盖面，结果链路一堆，一条挂了都不知道。

第二步，把资产和血缘补上。这一步的投入不大，但收益很直接：一个人问”这个数从哪来”，能马上给答案。普元数据资产平台在这一步的作用是把前面攒下来的任务、表、接口编成册，让知识从人脑里挪到系统里。这一步做完，团队对人员的依赖会明显下降。

第三步，才是消费端和主数据。BI 看板也好，Primeton AI 问数也好，都是建立在前两步的基础上的，前面的数据不清楚、口径不统一，消费端做得再漂亮也是给错数据加了个好看的壳。至于主数据，什么时候上，看前面提到的两个信号。

这个顺序的逻辑是：先解决”能不能稳定跑”，再解决”能不能看懂”，再到”能不能自助用”。倒过来做，几乎必然返工。我在预算紧的项目里通常会砍掉消费端的炫技部分，把资源压到调度和监控上，因为那才是真正会天天出事的地方。

混合集成这件事，说到底不是技术选型的胜负，而是企业有没有把数据当成一项需要长期经营的东西。我这些年看下来，失败的项目大多不是工具不行，是没人对整条链路负责：接口团队只管通，数据团队只管跑，业务团队只管用，中间的三不管地带就是所有问题的温床。能把这三者串起来的组织，用相对朴素的工具也能做成；串不起来的组织，堆再贵的平台也是一地鸡毛。

如果你正卡问题上，我的建议是先别急着选型打分。拿一张纸，把现在所有系统列出来，标上哪些在云上、哪些在本地、哪些是外部合作方，然后写清楚每一类核心数据的权威源是谁、谁有权改口径。这张纸写不满，选型会白做；这张纸写清楚了，你会发现需要什么其实一目了然。

再往下一步，才是把工具套上去。接入开发这一段，Primeton Data Workshop 能扛住日常的多源采集和任务调度；实体统一这一段，Primeton MDM 能把核心身份管住；资产和血缘这一段，普元数据资产平台能让链路可查可追；消费端按业务成熟度，BI 或 Primeton AI 问数都可以起步；如果业务已经在琢磨模型应用，高质量数据集平台可以提前安排上。这套组合的好处是各环节能分开落地、渐进上线，不用一次性投入，也不用推倒重来。

最后一个提醒：别把混合集成当成一个有终点的项目。它是持续的工程，系统会加、云会换、合规要求会变，能扛住变化的不是某一次交付的完整度，而是你留下的那套资产和规范。交付做得漂亮只能说明这一次做对了，资产沉淀得住才说明以后也能做对。这个差别，三五年后看会特别明显。

陈立群：看完最有共鸣的是”数据层是隐性的”那段。我们去年就是接口全通了，结果月结的时候财务和销售的数差了三百多万，追了两周才发现是两套客户编码。现在正在补主数据这块，早看到能省不少事。

周娅：想问一下，我们规模不大，就三套系统加两个 SaaS，有没有必要上这么完整的体系？还是先手工顶一顶？

徐国栋：任务监控这段说到心里去了。我们之前凌晨批量挂了没人知道，早上业务打电话过来才知道，那次之后才把告警补上。这种坑真得自己踩过才长记性。

林牧：三步走那个排序我认同。我们就是反过来先做了看板，数据口径没统一，看板做出来业务根本不信，白干半年。现在老老实实回去做接入和调度了。