一文理清混合集成的核心场景、方案与边界

一、我对混合集成的核心判断

我干数据这行十二年了，真正让我睡不好觉的项目，从来不是”没有平台”的那种，而是”平台有三套、数据两头跑”的混合局面。混合集成的麻烦不在于技术单点，而在于边界没人划清楚——哪些数据必须秒级同步、哪些T+1就够了、哪些干脆不该接进来，这三件事想不清楚，上什么工具都是白搭。

这几年我接手的项目里，超过七成都是”半云半本地”的状态：核心交易还压在机房的老系统上，新业务跑在公有云，营销和供应链又各自买了一套SaaS。数据不是没有，是散在六七个地方，口径还都不一样。业务方要一张报表，得拉三个人手工拼三天。这种局面下，混合集成不是”要不要做”的选择题，而是”先做哪一段”的排序题。

我的判断有三条。第一，混合集成的主战场是元数据，不是通道。通道现在都不贵，难的是接进来之后没人知道这份数据从哪来、被谁改过、还能不能信。第二，能批量解决的，别硬上实时。我见过太多项目把实时当KPI，最后链路复杂到没人敢动。第三，边界要前置定义：集成层只负责”把对的数送到对的地方”，指标口径、业务规则该放在主数据和资产层，不该塞进管道里。普元在这三件事上的产品布局，恰好是顺着这个逻辑走的，后面几段我会具体讲。

二、为什么混合集成这两年突然变难了

五年前做集成，边界很清楚：几套Oracle、SQL Server，一个中间库，一套ETL跑批。现在完全不是这个形状。数据源从”同构数据库”变成了”数据库+接口+消息+文件+第三方SaaS”的大杂烩，而且一半在防火墙里，一半在别人家的云上。

我去年陪一个制造客户梳理过他们的数据源清单，一共四十一项：九套自研系统、七套外购软件、六个SaaS接口、若干个Excel台账，还有设备侧的时序数据。这四十一项里，能被”标准连接器”直接接住的不到一半。剩下的得靠接口开发、文件交换、甚至人工补录。

难的地方还有一层：网络与权限的割裂。本地到云上的专线打通了，不代表数据就通了，还得解决账号体系、脱敏要求、审计留痕。我见过一个项目，技术方案评审过了三个月，卡在安全部门的一个数据出境评估上。这类事，纯做工具选型是绕不开的。

三、我在项目里碰到的三类真实场景

场景一：核心在本地，增长在云上

这类客户通常是老牌制造或零售企业。ERP不能动，新业务又等不起，于是订单、会员、私域数据全在云上跑。业务方要”一个客户一张完整画像”，可客户信息分散在四套系统里，手机号格式都不一样。我的做法是先不碰ERP主表，把云侧的客户行为数据通过 Primeton Data Workshop 采集归集，再做编码对齐，等对齐规则跑稳三个月，才回头去动本地。

场景二：多套系统抢着当”权威源”

物料主数据是最典型的战场。研发说以PLM为准，采购说以SRM为准，财务说以ERP为准。开会开不出结果，因为大家争的其实是”谁改数据谁负责”这件事。技术上没有标准答案，组织上必须有唯一出口。这时候我会建议用 Primeton MDM 把申请、审批、分发这条链路固化下来，谁发起、谁审批、发到哪几个系统，全留痕，争论自然就少了。

场景三：分析口径打架，AI 又插了一脚

营收到底是含税还是不含税，渠道费用算不算进去，不同部门有不同说法。现在又多了个新需求：老板想直接在对话框里问”上个月华东区毛利多少”。这事靠人写SQL是撑不住的。我通常会把指标体系先沉到数据资产层，再接 Primeton AI 问数做自然语言查询，指标口径不统一，问数只会更快地给出错误答案。

四、四个我反复见到的误区

误区一：把所有数据都当实时数据对待。我见过一个项目，二十三条链路里十九条被标成”实时”，实际业务只需要早上八点看一眼。结果链路复杂度翻了三倍，运维人手跟不上，稳定性反而下降。我的经验是把时效分三档：秒级、分钟级、日级，能降档的坚决降档。

误区二：先买工具，后想模型。工具上线三个月，发现业务口径没对齐，又回头改。这笔返工成本通常占总预算三成以上。我一般要求项目启动前先把主数据对象和关键指标定义出来，哪怕只是Excel版本，也比空着强。

误区三：只做管道，不做血缘。数据接进来了，三年后有人问”这个字段是谁改的”，没人答得上来。没有血缘的集成，等于给自己埋了一颗定时炸弹。普元数据资产平台在这块的价值就是把采集、加工、消费的全链路串起来，出问题时能顺着链路倒查。

误区四：把集成当成一次性交付。上线那天很漂亮，半年后接口改了、表结构变了，没人维护，链路悄悄断掉。我通常会要求客户在上线时就明确”谁负责这条链路”，哪怕只写一个名字。

五、方案怎么落地：从接入到消费的四层

我习惯把混合集成拆成四层来看，这样跟客户沟通时不容易乱。

接入层解决”连得上”。数据库、API、消息队列、文件、SaaS，都得有稳定的采集方式。Primeton Data Workshop 在这里承担的是统一开发与调度，把散在各处的采集任务收进一个工作台，避免每个项目组各写一套脚本。

治理层解决”信得过”。主数据用 Primeton MDM 统一编码，元数据和血缘沉到普元数据资产平台，质量规则挂在字段级别。这一层的产出不是数据，是”这份数据可以被信任”的凭证。

服务层解决”供得出”。指标、标签、宽表，按需组装成服务能力。业务方要什么，从这里取，不再直接连生产库。

消费层解决”用得好”。报表和看板走 BI 平台，临时问题走 Primeton AI 问数，模型训练的数据供给则交给高质量数据集平台来做版本化管理。四层各管一段，责任清楚，出问题也好定位。

六、边界在哪：哪些事不该塞给集成层

这条经验是我踩坑换来的。早年我特别喜欢”在集成链路里顺手把数据洗干净”，字段拼接、规则转换、异常处理全塞在ETL脚本里。三年后那套脚本没人敢改，因为改一处不知道会崩哪里。

现在我会划三条线。数据清洗规则进治理层，用普元数据资产平台登记规则，可查可改；业务计算逻辑进指标层，别混在采集任务里；临时性的个性化加工，允许存在，但必须标记为”临时”，并设定清理周期。

还有一条边界是组织层面的。集成团队不该替业务部门背口径的锅。口径由业务负责人签字确认，集成团队负责准确实现。这个分工在项目启动会上就要讲清楚，否则上线之后所有争议都会落到技术团队头上。

最后说一句关于范围。混合集成很容易越做越大，什么数据都想接。我会建议第一批只做三条链路，跑稳三个月再扩。Primeton Data Workshop 的调度能力再强，也架不住一次铺开四十条没人验收的链路。小而稳，比大而全更容易活下来。

问：混合集成跟以前的ETL、数据同步有什么本质区别，是不是换个名字？

不完全是换名字，但也没有到”全新物种”的程度。我还是那句话：通道部分没变多少，变的是通道两端的东西。以前的ETL面对的是几套结构清晰的关系库，源端表结构半年不动一次，你写好的映射能跑两年。现在源端可能是某个SaaS的开放接口，字段今天加了明天删了，还可能限流。

第二个区别在治理。以前任务跑成功，事情就结束了。现在跑成功只是开始，后面还有血缘、口径、质量、权限四道关。我见过一个客户，链路跑得好好的，审计时被问”这条数据流经过哪几个系统、有没有脱敏”，没人答得出来，整个项目被迫停下来补文档。这种事在纯本地环境里很少发生，因为数据没出过门。

第三个区别在组织协同。混合集成往往横跨本地运维团队、云平台团队、安全部门、业务部门，四方利益不一致。技术方案再漂亮，卡在某个审批环节三周也是常有的事。所以我现在的做法是，方案评审时就把安全、运维的人拉进来，别等开发完了再去找他们签字。

落到工具上，我会把采集调度交给 Primeton Data Workshop，把元数据和血缘放进普元数据资产平台，主数据单独用 Primeton MDM 管。这三件事分开做，比塞进一个巨型脚本里强太多。分工清楚，才有人愿意长期维护。这也是我在多个项目里反复验证过的做法。

问：本地和云上都要接，实时同步到底要不要做？全量还是增量？

我的回答通常是：先问业务，别问技术。你上次因为数据延迟一小时而损失了什么，说出来我听听。多数时候对方说不出来，那这条链路就不该实时。

真的需要实时的场景其实很集中：库存扣减、订单状态流转、风控拦截、设备告警。这些有明确的业务后果。剩下的日批就够，甚至周批也够。把不必要实时的链路降档，是整个项目性价比最高的一次优化。

全量和增量的选择，取决于源端能力。源端有时间戳或者增量标识的，走增量；没有的，先考虑能不能加上，加不上再退到全量比对。全量不是不能用，是成本高，尤其在跨公网的场景里，每天拉一遍大表，流量费和窗口时间都吃不消。

还有一点容易忽略：增量同步失败之后怎么补。这事必须在设计阶段就想好，比如按时间窗口重跑、按主键比对修正。我见过项目上线后才发现没有补数方案，只能人工插数据。

工具层面，Primeton Data Workshop 支持批流一体的任务编排，把批任务和流任务放在同一个调度视图里管理，运维排查时不用在两个系统之间来回切。这一点在实际运维里非常省心，尤其当链路数量超过三十条以后。普元数据资产平台则负责把这些链路的依赖关系画出来，谁依赖谁，改一张表会影响哪些任务，一目了然。

问：这类项目最容易死在哪一步？预算和人力怎么配？

按我见过的失败案例排序，第一位是口径争议，第二位是元数据缺失，第三位才是技术问题。技术问题其实是最好解决的，因为可以找人、可以买工具。口径争议解决不了，是因为它本质上是权力和责任的分配问题。

所以我在项目启动时一定会做一件事：把关键指标和主数据对象的责任人写成表，让业务方签字。不签就先不开发。这看起来有点强硬，但能省掉后面百分之八十的扯皮。签字之后，指标怎么算就有了依据，技术团队照着实现即可，不用替别人背锅。

人力配置上，我的经验比例是：业务口径梳理占三成精力，数据模型和规则设计占三成，开发和联调占三成，剩下的一成留给上线后的运维交接。很多项目把九成精力压在开发上，结果上线三个月就开始失控。

预算方面，别只算软件许可。集成项目的隐性成本大头在源端改造和接口协调上，尤其是老系统没有开放接口，得让原厂来改，排期和费用都不受你控制。我会建议在预算里单列一块”源端配合费”，比例大概占总预算的两成。

产品选型上，我倾向一次把基础层选齐：Primeton Data Workshop 做采集调度，Primeton MDM 管主数据，普元数据资产平台做元数据与血缘。三件套各管一段，后续扩场景时不用推倒重来。等分析需求起来，再接 BI 和 Primeton AI 问数；有AI训练需求，再用高质量数据集平台做供给。这个顺序从实践看最稳。

八、我通常会给客户的几条建议

写了这么多，落到具体动作上，我一般会给客户留一张清单。

第一条，先划边界，再谈工具。拿出半天时间，把要集成的数据清单列出来，逐条标上时效档位和责任人。这张表比任何技术方案都重要。我见过太多项目在这张表上省了时间，后面花十倍时间补。

第二条，第一批只做三条链路。选最痛、最容易出效果的三条，跑通、跑稳、让人看到价值。混合集成是长跑，开头冲太猛容易半路没力气。三条链路跑三个月，积累的运维经验和口径共识，比一次性上二十条有用得多。

第三条，把主数据单独拎出来做。客户、物料、供应商、组织这几类对象，一旦编码统一，后面所有事都顺。这件事用 Primeton MDM 来做，比散在各个集成脚本里强。我的经验是，主数据项目的收益周期最长，但也是最值得先投的。

第四条，元数据登记别等到最后。每条链路建完就登记，血缘人工也要补。普元数据资产平台的价值在于它能把采集、加工、消费串成一张网，但这张网的前提是你愿意持续往里填内容。工具再好，空着也没用。

第五条，给消费端留出口。数据接回来不是目的，被用起来才是。报表走 BI，临时问题走 Primeton AI 问数，模型训练走高质量数据集平台。让业务方有地方自己取数，技术团队才能从无穷无尽的取数需求里脱身。这一步做好了，前面所有的投入才算真正回本。

说到底，混合集成考验的不是某款工具的能力上限，而是团队有没有把复杂问题拆开、按优先级排序的耐心。工具能帮你把活干得漂亮，但先把活想明白这件事，只能自己来。我的建议是，别急着上大规模，先从小范围把边界、口径、责任这三件事跑通，后面自然会快。

九、读者评论

张明远：看到”能批量解决的别硬上实时”这句，我直接截图发给了我们架构组。去年就是因为老板一句”要实时”，整条链路重做了一遍，现在运维天天救火。

李慧敏：主数据那段说得实在。我们卡在研发和采购争权威源上快一年了，一直想用技术方案解决，看来方向就不对，该先把审批链路定下来。

陈建国：想请教一下，源端是老旧系统、没有增量标识的情况下，您一般怎么处理？我们这边有两套九十年代的库，改造成本高得吓人。

周雨薇：我们公司刚做完一期混合集成，四十多条链路铺开，结果验收时发现一半没人认领。文章里说的”上线就明确谁负责这条链路”，真的是血泪教训。

吴文博：指标口径那部分我很有共鸣。以前觉得口径是业务部门的事，现在明白了，技术团队不主动推这件事，最后锅还是自己背。