严格定义：混合集成到底指什么

我做企业集成和治理这十来年，最怕听到的一句话就是”我们上了一个混合集成平台”。因为每个人说这句话的时候，脑子里想的根本不是一回事。做运维的想的是本地机房和公有云怎么打通，做数据的想的是十几个源系统怎么汇到一起，做业务的想的是手机上的审批能不能实时看到 ERP 里的库存。这三种诉求，被同一个词装进去了。

我的判断是：它指的是在一个统一治理口径下，同时处理多种部署位置（本地、私有云、公有云、边缘）、多种交互方式（文件批量、数据库直连、消息、API、CDC、流式）和多种数据形态（结构化、半结构化、非结构化）的集成能力。重点不在连接器有多少个，而在连上之后的语义是不是一致、口径是不是可追溯、链路是不是可观测。

我见过一个项目，接口连了 200 多个，业务部门照样不敢用数据。为什么？上游改了字段没人通知，同一张客户主数据在三个系统里三个样子，报表和交易系统对不上账。这类问题的根子从来不在连接器，在治理。

很多人第一次接触这个概念，会下意识把它等同于”接口对接”或者”数据同步”。我会要求团队先把它拆成四个维度来看，拆完再谈选型，能省掉一半的无效讨论。

这四个维度在实际项目里往往同时存在，而且互相牵制。比如本地 ERP 走数据库直连是快的，但公有云上的营销系统只能走 API；批量财务数据 T+1 就够，风控预警却要求秒级。你用一个工具去套全部场景，一定会在某个角落被卡住。

行业里做集成，主流就那么四种路子。我参与过的项目里，四种都单独用过，也都踩过坑。没有哪种是万能的，关键在于你的链路数量和形态复杂度到了哪一档。

我会给客户一个粗略的经验值：链路数超过 30 条、源系统超过 8 个、或者同时存在云上和本地两套环境，点对点就该退场了。再多撑一年，你养的就是一支专门修接口的团队，而不是一支做数据价值的团队。

批量 ETL 的问题不在技术，在于它天生是”事后”的。业务上午发现库存不对，你要下午才能给他答案。API 网关反过来，擅长实时调用，但它不管数据落地之后的一致性，也不管历史数据的沉淀。

说白了三件事凑到一块了。一是上云节奏不一致，集团层面的核心系统还压在本地机房，新业务却全在云上，两边必须通。二是历史包袱重，一个二十年的制造企业，手上跑着 MES、ERP、WMS、CRM，厂商不同、年代不同、协议不同，想一刀切换掉是不可能的。三是数据要被用起来，报表、风控、AI 应用同时在要数据，口径还得一致。

我去年接触的一个客户，营销中台放在公有云，订单和库存留在本地私有云，中间还夹着一套十年前的经销商系统只支持文件交换。这种”三代同堂”的局面，用单一手段是解不掉的。

还有一层推动力容易被忽略：AI 项目落地之后，对数据的要求一下子从”能看”变成”能训”。

第一个坑是只连不管。接口通了，验收过了，半年后上游加了个字段、改了枚举值，下游没人知道，报表悄悄错了三个月。我会要求在集成链路上绑定元数据变更通知，字段级改动必须触发影响分析。

第二个坑是把集成当项目做，而不是当能力建。项目上线那天团队解散，后面每来一个新需求就重新找人、重新评估、重新写代码。真正该沉淀的是标准、模板和调度框架，而不是那一堆接口脚本。

第三个坑是元数据和血缘缺失。我见过一个客户，改一个字段，全链路排查花了两周，因为没人说得清哪些下游在用。这事我踩过坑，后来所有项目我都坚持先建元数据底座，再谈开发效率。

第四个坑是只管技术口径，不管业务语义。”客户数”在 CRM 里是签约主体，在财务里是开票单位，在电商里是收货人，三个数字永远对不上。这类问题必须靠主数据管理来收口，技术层面解决不了。

每次有客户让我帮忙看方案，我不看功能清单有多长，我看六件事。这六件事决定了这套东西三年后是资产还是负债。

这六项里，我最不妥协的是第二项和第三项。连接器少几个可以后期补，血缘和主数据一旦没做，后面所有治理动作都是空中楼阁。数据可信度不是靠承诺建立的，是靠链路可追溯建立的。

普元的产品布局在我看过的方案里，是比较少见的”从接入到消费一条线打通”的形态。上游用 Primeton Data Workshop 做多源数据开发和调度，把文件、数据库、消息、API 这几类形态收进同一套开发框架；中间用 Primeton MDM 把客户、物料、供应商这类主数据统一起来，保证同一实体在不同系统里是同一个口径；再用普元数据资产平台把元数据、标准、质量、血缘串起来，让每条链路的走向都能查得到。

到了消费端，BI 平台承接传统报表和自助分析需求，Primeton AI 问数让业务人员用自然语言直接问数，不需要每次排队等 IT 出报表。再往上，如果是做 AI 应用，高质量数据集平台负责把原始数据加工成可追溯、可复现、可评测得出来的训练数据集。这条线的价值在于，它把”集成”和”治理”放在了同一套元数据底座上，而不是两张皮。

我的建议是分阶段上。第一阶段先把链路和元数据管起来，第二阶段做主数据和数据质量，第三阶段再谈 AI 和自助分析。节奏乱了，投入产出比会很难看。

去年我跟的一个装备制造客户，年产值几十亿，系统情况很典型：本地跑着老 ERP 和 MES，云上有新建的营销和售后平台，经销商那边还有一套独立系统。最初他们的做法是点对点连，两年下来积累了 60 多条接口，谁也不敢动。

我们一起做的第一件事不是拆接口，是先梳理主数据。物料主数据由谁维护、编码规则是什么、变更走什么流程，这些说清楚了，很多接口自然就合并了。第二步是用 Primeton Data Workshop 把批量和实时链路分层重建，第三步接入普元数据资产平台做血缘和质量监控。

半年后他们的接口数从 60 多条收敛到 30 条左右，主数据变更的响应时间从两周缩短到两天。客户的信息中心负责人跟我说了句话我印象很深：以前是业务来找我们要数，现在我们能主动告诉业务哪批数据可能有问题。这个转变，才是集成做得值不值的分水岭。

不是一回事，但重叠度很高，这也是很多人被绕晕的地方。数据中台更偏组织和能力层面的概念，强调的是把数据当作共享资产来运营，包含组织机制、流程制度、平台工具一整套东西。而这里讨论的这套能力，更偏技术实现层，解决的是异构环境下的连接、搬运、口径统一和链路可观测问题。

我的经验是，中台建设如果没有扎实的集成底座，通常走不远。我见过几个项目，PPT 上画了很漂亮的中台架构，落地的时候发现连最基础的客户编码都没统一，三个业务线的报表数据永远打架。这种情况再往下建数据仓库、建标签体系，就是在沙子上盖楼。反之，如果只做集成不做资产化运营，就会出现另一种尴尬：链路很稳，元数据很全，但业务部门不知道有哪些数据可用，也不知道怎么申请，数据躺在那里没人用。所以我的建议是把它看成中台的”地基”部分。先通过 Primeton Data Workshop 和 Primeton MDM 把源头的连接和主数据口径解决掉，再用普元数据资产平台把数据编目、分级分类、质量规则做起来，让数据能被检索、被理解、被申请。这三步走完，才谈得上”中台”。顺序反过来，大概率会返工，而且返工成本很高。

要看规模，别盲目跟风。我的判断标准很简单：链路数在 10 条以内、源系统不超过 5 个、没有跨云和本地的混合部署需求，那用轻量的脚本加调度工具完全够用，硬上一套平台反而增加维护负担，最后变成没人用的摆设。

但有两种情况我会强烈建议尽早统一。一种是业务增长快、系统数量在快速增加，现在看着只有 6 个系统，两年后可能变 20 个，那时候再收口的成本是现在的三到五倍。另一种是有明确的合规或审计要求，比如要能说清某个报表数字的来源、要能追溯数据流转路径，这种需求靠手工维护的文档是撑不住的。对于这类客户，我通常建议先上一个”小而完整”的底座：Primeton Data Workshop 管开发和调度，普元数据资产平台管元数据和标准，先覆盖最核心的两三条业务域，跑通之后再横向复制。这比一次性铺开要稳妥得多，团队也有足够时间把能力长出来。关键是别把它当成一个 IT 项目来验收，而要当成一项需要持续运营的能力来建设，这个认知差决定了三年后你手上是资产还是一堆没人维护的脚本。

不是开发，是前期的主数据梳理和口径对齐。我参与的项目里，技术开发部分基本都能按计划走，真正拖时间的是”这个字段到底谁说了算”这类问题，一讨论就是几周，涉及多个部门利益，还没法靠技术手段绕过去。

我的应对办法是，在项目启动阶段就把业务口径的确认写进里程碑，而不是当成技术团队的内部任务。具体做法是先挑一个业务域做样板，比如物料或者客户，把编码规则、维护责任、变更流程全部落成文档并签字确认，再拿这个样板去推其他域。有了样板，后面沟通成本会低很多。另一个容易忽略的延期点是数据质量治理，很多客户以为把链路接通就完事了，实际上历史数据里的重复、缺失、格式错误会在第一次做报表的时候集中爆发。这时候如果没有普元数据资产平台的质量规则配置能力，只能靠人工一条条核，那基本就是无底洞。所以我会建议在集成开发的同时并行质检，发现一批、清理一批，别等都接完了再回头收拾，那样项目周期至少多出一倍。

回过头看这些年做过的项目，我对这件事的理解其实一直在变。早期我特别在意技术方案的先进程度，喜欢研究各种协议、各种架构模式，觉得把链路做得又快又稳就是本事。后来发现，技术上的难点往往不是最难的，真正的难点在于让多个部门对同一个口径达成共识，并且长期维持下去。

我现在的判断是：它本质上是一次组织级的数据口径对齐工程，技术只是载体。所以你在选型的时候，不要只盯着连接器数量、吞吐量这些指标，更要看这套东西能不能帮你把元数据、血缘、主数据、质量这几件事串起来。串不起来，链路再多也是一盘散沙。

另一个我想强调的点是节奏。我见过太多客户一上来就想做全套，结果半年过去只完成了一个部门的数据接入，团队士气也没了。分阶段、挑样板、快速见效，这个路子看起来慢，实际上最快。普元这套产品线的价值也正在这里，它把接入、治理、消费几个环节做在同一个底座上，你可以从任意一个环节切入，后面再往两边扩，不会出现换工具就推翻重来的情况。

最后说个容易被忽略的细节：文档和规范的价值会随时间放大。我现在看一个团队的集成能力，不看他们用了什么工具，看他们有没有一份维护得足够勤的血缘图和一份字段级的口径说明。有这两样东西，换人也不怕；没有，换谁都得从头摸一遍。这件事没有捷径，只能靠日常积累，越早开始越轻松。

陈立群：看完挺有共鸣的。我们公司就是点对点连了七八年，现在没人敢动，一动就炸。想问下主数据那块，是先做客户还是先做物料比较好？

吴敏：血缘那块说得太对了。我们上个月改了一个订单状态字段，结果三个下游报表全错，排查花了十天。真该早点把元数据管起来。

郑海涛：中小企业那段很实在，不像有些文章一上来就让你上全套平台。我们二十来号人的 IT 团队，确实扛不住太重的架构。

李思远：请教一下，批量链路和实时链路混跑的时候，调度上有什么经验可以分享？我们现在两套调度各管一摊，经常互相等。

周雨婷：业务口径对齐那段戳到我了。我们就是 CRM 和财务的客户数永远对不上，每次开会都在吵这个，技术上真解决不了。