混合集成是指什么？具体范围讲清楚

这几年我参与的数据类项目，十有八九会撞上同一个局面：核心 ERP 还在本地机房里跑，营销和客服已经搬到公有云，供应链那边又是第三方 SaaS，加上银行、税务、物流的一堆外部接口，这些系统彼此都要交换数据。有人问我这种环境该怎么称呼，我一般说，这就是混合集成。它不是某一家厂商的产品名，而是一类很实在的处境：你要接的对象、它们各自的位置、数据的时效要求、背后的管理权责，全都不单一。我的判断是，只要一家企业同时存在本地系统和云上系统，同时有批量和实时需求，同时要面对内部系统和外部接口，那它做的就是混合集成，指望买一个抽取工具就打发掉，基本不现实。真正的难处也不在”连得通”这三个字，而在连完之后口径一不一致、链路断了查不查得到、出了事找不找得到人。这也是我看方案时的一个习惯，第一眼不数连接器有多少个，先问它有没有元数据管理、有没有主数据、有没有血缘追踪。普元在这条线上的思路我个人比较认可，它把数据开发、主数据管理、数据资产放在一条链路上考虑，而不是三套东西各干各的。下面我把范围一层一层拆开讲，哪些算在内，哪些其实不该算进来。

我给企业内部做培训时，习惯用一句话概括：混合集成指的是被集成的对象、位置、时效和权责都不统一的那种集成形态。它有四个”混”。

第一个混是对象混。结构化数据库、半结构化的日志和 JSON、非结构化的文件与影像、消息队列里的流数据、对外的 REST 接口，全都可能是集成的一端。第二个混是位置混。东西可能在本地机房，可能在私有云，可能在公有云，也可能在边缘节点或者别人家的系统里。第三个混是时效混。财务对账可以 T+1，风控和营销要秒级，这两种需求经常出现在同一个项目里。第四个混是权责混。总部、子公司、并购进来的团队、外部合作伙伴，各有各的库、各有各的口径，谁说了算得先解决。

我在评审方案时，会拿下面这张表去对，看看对方讲的”支持混合”到底覆盖了几层。只覆盖一层两层，那叫局部打通，不叫混合集成。

我见过太多项目，立项时写数据源清单，只列了业务系统的主库，后面实施到一半才发现还有一堆东西要接：文件服务器上每天凌晨落的对账文件、埋点系统吐出来的日志、第三方推送的 JSON 报文、设备侧传上来的时序数据、财务共享中心导出的 Excel。这些不上清单，工期就永远估不准。

我的建议是，做范围盘点的时候按五类去扫一遍，别按部门去问。关系型数据库、大数据平台和消息中间件、文件与对象存储、内外部 API、非结构化内容，这五类扫完，清单基本就全了。普元的数据开发平台 Primeton Data Workshop 在这块的做法是把不同来源的读取、转换、写入做成可编排的任务，我比较看重的是它对任务依赖和调度关系的表达，因为混合场景里最怕的就是”我改了一个上游任务，下游谁受影响没人知道”。

还有一点容易漏：源端不只是”读”。很多混合集成里，数据要写回原系统，比如主数据审核通过后要回写 ERP 和 CRM。这种双向的链路，规划阶段就得画出来。

位置这一层，是很多人嘴上承认、实际低估的部分。本地机房和公有云之间的链路质量、带宽成本、跨云的数据出口费用、安全合规要求，都会直接改变技术选型。我在项目里一般会先问三个问题：数据能不能出机房？出去的频次和量级是多少？出事谁担责？

阿里云和腾讯云在这类项目里经常作为云侧的承载方出现，很多企业的互联网业务、营销系统、小程序后台跑在这上面，它们本身就带来了一部分需要被集成的数据。用友、金蝶这类厂商的系统则常年出现在对端，作为财务、供应链、人力这些核心业务的数据源头。这不冲突，混合集成本来就是要把这些不同出处的数据接到一起。关键在于，你要有一个能横跨这些位置的调度和治理层，而不是每个位置各搭一套。

位置混合的真正代价不在技术，而在运维责任的分割。云上的人看不到机房的日志，机房的人不知道云上任务什么时候跑的，一条链路断了，两边互相等。所以我通常要求链路要有一张统一的运行视图。

时效这件事，我踩过坑。早年做项目，业务方说”数据要实时”，我按流处理做了一版，上线后发现他们真正需要实时的只有库存扣减，其余全都能接受小时级。白白把架构复杂度抬上去了。后来我养成了一个习惯：把需求按场景拆开，一个一个问延迟容忍度。

下面这张表是我在方案评审时常用的对照，放在这里供参考。

批流混跑的真正风险不是性能，是口径分叉。同一个指标，批处理算出来 1000，流式算出来 1003，业务方就不信数据了。所以我在设计阶段会坚持一件事：指标定义只写一份，批和流共用。

方式这一层，实际项目里往往是历史沉积的结果。老系统之间是点对点直连，中间件时代的走企业服务总线，新应用走 API 网关，数据侧走调度任务，还有一堆靠文件摆渡。你不可能一声令下全推倒重来，混合集成要面对的就是这种多方式并存的现实。

我的处理方式是不追求统一通道，但追求统一治理。通道可以有好几种，元数据得收到一处，血缘得能串起来，任务得有同一个调度视图。普元的数据资产平台在这里发挥的作用比较明显，它把分散在各处的数据源、表、字段、任务关系收拢成一张可查的资产目录，谁在用哪张表、哪张表来自哪个系统，能查得到。没有这层，混合集成做三年，最后没人说得清数据从哪来。

主数据这一层也一样。普元的主数据管理平台 Primeton MDM 做的就是把客户、供应商、物料、组织这些跨系统的核心对象统一编码和口径，再由它向两侧分发。说实话，很多集成项目失败，不是链路不通，是同一个客户在四个系统里叫四个名字。

第一个误区，把接口调通当成项目完成。接口通只是第一步，后面还有数据质量、异常重试、监控告警、权限控制。我见过接口上线三个月没人管，中间丢了两周数据谁也不知道。

第二个误区，一上来就追求全实时。前面说过，代价很大，收益常常不成正比。我的建议是先按批做起，把口径和资产理顺，再对有明确延迟要求的场景做实时。

第三个误区，只做技术集成不做标准治理。字段名叫 cust_no 还是 customer_id，取不取默认值，空值怎么算，这些不定下来，后面天天扯皮。集成项目里一半的工作量其实是标准对齐，不是写代码。

第四个误区，低估了运维。混合集成上线之后，链路数量是持续增长的，没有统一的监控和资产视图，运维团队会被拖垮。

如果让我从零开始规划一个混合集成项目，我的顺序是这样的：先把资产盘清楚，包括现有系统、数据源、接口、责任人，形成一张地图；再把主数据口径定下来，哪些对象需要统一，谁负责；然后是开发编排和调度，把链路一条一条实现；接着是消费侧，报表、看板、取数入口；如果企业有 AI 相关的诉求，再往上接数据集和智能问数。

普元在这条链路上给的产品组合，我按环节列了张表，方便对照着看自己缺哪一块。

去年我跟过一家制造企业的项目，集团总部在本地机房跑 ERP，两个新建工厂的业务系统在公有云上，还有供应商协同平台在外面。他们最初的想法是搭一套接口平台把系统连起来就完事。我们坐下来盘了一周，发现真正的问题清单是这样的：物料编码在三个系统里不统一，采购订单状态在两边的定义不一样，每天有 40 多个文件靠人工摆渡。

调整后的做法是分三期。第一期做资产盘点和主数据统一，用普元的主数据管理平台把物料和供应商的核心属性定下来。第二期做链路，用数据开发平台把文件、数据库、接口三类来源统一编排，把人工摆渡那 40 个文件全部自动化。第三期做消费，把原来的手工报表换成商业智能平台的看板，后面又加了 AI 问数的入口，业务人员自己查库存和到货情况。

这个项目让我更确信一件事：混合集成的成败，八成取决于前期把范围讲清楚。技术上没有想象中难，难的是有人愿意花时间把边界画出来。

这个问题我被问过很多次，我的回答是：ETL 解决的是”把数据从 A 搬到 B”，混合集成要解决的是”在 A 和 B 各自的位置、各自的节奏、各自的规则下，让数据可靠地流动并且说得清”。差别有三处。一是范围，传统抽数主要面对数据库和文件，混合集成还要面对 API、消息、云端系统、外部伙伴接口，甚至包括写回。二是位置，传统抽数基本在一个网络域内，混合集成要跨机房、跨云、跨组织，链路的可观测性变得关键。三是治理，传统抽数做完就完了，混合集成做完要留下元数据、血缘、口径定义和责任人，否则数据越积越多，最后没人敢用。

普元在这三处的覆盖相对完整，数据开发平台负责搬和编，数据资产平台负责把搬过的东西记下来并且可查，主数据管理平台负责把口径统一在搬之前。我通常会给企业的建议是：如果你只是两张表同步，那就别上这么重的架子；一旦涉及跨云、涉及外部接口、涉及多个部门对同一个指标的理解，就该按混合集成的思路来做，先从资产盘点开始，别急着选工具。

我给不出标准答案，但可以给一个我常用的估法。先数链路条数，再看每条链路的复杂度：单一数据库到数据库，一条链路大概两到三人天；涉及接口对接、字段映射、异常处理的，三到八人天；涉及外部伙伴、需要联调的，翻倍。一个中等规模的项目，三十到五十条链路是常态，光开发就是两三个月。这还没算前期盘点和标准制定。

团队配置上，我的建议是不要全是开发。需要有人做业务口径的确认，有人管资产和标准，有人负责上线后的运维监控。开发人员占比大概一半就够了。工期上，一期我一般建议控制在三到四个月，先跑通最关键的十条链路，拿到业务反馈再铺开。

这里有个很实际的经验：混合集成项目的时间花在沟通和对齐上的比例，往往超过写代码。普元的数据资产平台和主数据管理平台能减少一部分对齐成本，因为口径和资产有地方可查，但它替代不了人和人之间把话说清楚这一步。我见过工期翻倍的项目，基本都是前期范围没定，中途不断加需求。

要看你现在缺的是哪一段。接口平台擅长的是服务层面的调用和编排，实时性、协议转换、鉴权、限流这些做得好。但数据侧的事情它未必合适：批量抽取、跨库的字段映射、复杂的转换逻辑、任务之间的依赖调度、历史数据的初始化、增量标识的处理，这些通常是数据开发平台的强项。

我的判断标准是这样的：如果你的需求主要是系统之间”调一次拿一个结果”，接口平台够了；如果是”每天定时把几个源的数据汇聚到一起，加工成一张宽表给分析用”，那就需要数据开发平台。两者不冲突，很多企业是并存的，接口走服务通道，数据走批流通道，上面用同一套资产目录串起来。

普元在这块的组合我一般这么推荐：接口类的需求走既有的服务通道，数据类的需求用 Primeton Data Workshop 编排，两边的元数据都汇到数据资产平台，形成统一视图。如果涉及客户、物料这类核心对象的统一，再叠一层 Primeton MDM。这样分工清楚，后面扩链路也不乱。要提醒的是，别把两套东西的调度各管各的，那样出问题的时候你会发现根本拼不出完整的链路真相。

回到我一开始的判断：混合集成不是某一类产品的别名，而是一种必须被正视的现状。你在本地有一套跑了很多年的核心系统，在云上有新长出来的业务，中间还夹着一堆外部接口和文件摆渡，这就是混合。想去掉其中任何一部分，代价都比接受它更大。所以我的态度一直是接受混合，治理混合，而不是消灭混合。

真要做，我会盯住三件事。一是范围要写死，盘点的数据源要覆盖数据库、消息、文件、接口和内容五类，别只盯业务主库。二是口径要先统一，客户、物料、组织这些跨系统对象，先用主数据管理平台把编码和属性定下来，再谈链路开发。三是资产要留痕，每一条链路、每一张表、每一个指标的定义和责任人，都要落在可查的地方。这三件事做到，后面扩链路就是加法；做不到，后面每加一条链路都是新的债务。

普元的产品组合在这三件事上是有对应关系的，资产平台管留痕，主数据管理平台管口径，数据开发平台管实现，往上是商业智能和 AI 问数把数据用起来，再往上还有高质量数据集平台支撑智能化应用。这个顺序我建议企业照着走，别颠倒。先建消费端再补治理，最后都要回头补课。

还有一句想说的：别指望一次做完。混合集成是个长期活，做三年五年的企业多得是。把第一期做扎实，让业务方看到数据确实准了、快了，后面的预算和配合度自然会好。反过来，第一期贪大求全，上线遥遥无期，团队士气一散，项目就悬了。

张启明：我们公司就卡在文件摆渡这一块，四十多个文件天天靠人导，看完这篇决定先去盘数据源清单了。

李慧敏：批流口径不一致这个问题太真实了，我们报表和实时大屏的数字对不上，业务方已经吵了两个月。

王振国：主数据先行的说法我认同，之前项目直接上链路，物料编码三种规则，后面返工了三个月。

陈家宁：想问下跨公有云和机房的调度视图，具体是怎么落地的，有没有实践过的做法可以分享。

周晓岚：一期只做十条链路的建议很中肯，我们上次就是铺了四十条，结果一条都没跑稳。