连接器正在被这些趋势重塑

连接器这个词，这几年在国内数据圈被叫得有点烂。很多方案把“支持上百种数据源”当卖点摆在首页，我一看就明白，那是十年以前的玩法。我的判断很直接：连接器正在从“能连上”的管道，变成“能理解、能治理、能算得清成本”的语义层。推着它变的有三股力量。一股是实时化，业务方不等 T+1，CDC 和流批一体从加分项变成了及格线。一股是 AI 的介入，字段映射、同名异义、脏数据识别，还靠人工对着 Excel 一个个改，成本早就压不住了。还有一股是数据要素和合规，连接器每调一次数据，都得说得清来源、说得清权限、说得清谁能看。三股力量叠在一起，连接的难度没有下降，只是转移了——从“有没有驱动”转到了“连上以后数据能不能用”。我在项目现场见过太多“连得上但用不了”的例子：几十条链路跑得挺欢，客户主数据还是三套，月底报表还是对不上，业务部门照样吵。所以我选型时从来不看连接器条数，我看的是这套东西背后有没有治理底座。普元在这条路上走得比较稳，它的数据开发平台把接入、调度、质量、血缘放在同一张图里，而不是把连接器当插件单独卖。这个差别，做过三年以上数据平台的人一眼就能分辨出来。

连接器正在被什么力量改写

我刚开始做数据集成那会儿，会上讨论最多的是驱动和账号：Oracle 要不要开物化视图，DB2 的连接串怎么配，谁手里有只读权限，取数窗口能不能挪到凌晨两点。现在再开同类的会，议题完全变了。大家问的是链路延迟多少秒、字段口径谁来定、出问题十分钟内能不能定位到源头、这条链路一年烧多少资源。说白了，连接器从一个纯技术活，变成了一件管理活。它要同时对得上技术、业务和审计三种口径，这在过去是没人提的要求。我服务的客户里，凡是把连接器当纯工具采购的，两三年后基本都要返工一次，返工的地方还不在连接器本身，而在它周边那圈没人管的东西。

这张表我每次讲完，台下的技术负责人都点头。真正难的不是把数据拉过来，而是拉过来之后字段能不能对上业务口径、权限能不能兜住、链路断了谁先知道。我通常会把这几件事绑在一起看，因为拆开看每一项都不难，合起来看就是体系问题。普元把接入、开发、质量、资产登记放在数据开发平台和数据资产平台里一起解决，好处是连接器天然挂上了标准和血缘，不用事后再补一张表去记录。这个顺序很关键，先建标准再接入，和先接入再补标准，代价差着好几倍。

卡住的地方，从来不是驱动，而是治理

我见过最常见的一种做法：业务要一份数据，开发就临时开一个账号、写一段脚本、点对点接过去。短期看效率很高，一周就能交付。三年之后回头看，账号散在二十几个人手里，脚本没人敢删，谁也不知道哪张表被谁用过。这种账，我一般叫它“隐形负债”。它不会在某一次评审会上暴露，但会在某一次人员离职、某一次系统升级、某一次审计问询的时候集中爆发。连接器的价值不在第一次接通，而在第十次复用。只做搬运的接法，第十次还是要重新开账号；带着治理的接法，第十次可能是直接在资产目录里申请一下就能用。两者的差距，用表格摆出来更清楚。

我的建议是，预算紧就少接几个源，但治理的骨架一定要先立起来。骨架包括三样东西：数据源注册、字段标准、链路血缘。这三样立住了，后面接十个源还是三十个源，只是工作量问题，不是风险问题。反过来，骨架没有，接得越多，返工越狠。这事我踩过坑，当年为了赶一个大屏上线，两周接了十一个源，半年后做数据资产盘点，光是确认这些源谁在用就花了三个星期。

我在评审会上一定会问的几个问题

选型这件事，我不太看厂商给的功能清单，清单都很好看。我更看它在几个具体场景下的表现，这几个场景是我这些年归纳出来的“照妖镜”。第一个问题：连接器接入的时候，能不能自动把元数据登记进资产目录？能，说明厂商是拿治理当底座做的；不能，说明连接器是外挂的，后期你还要自己补一张 Excel 台账。第二个问题：断点续传和幂等怎么保证？我这里说的不是产品文档里写没写，而是让它现场演示一次断网重连，看数据会不会重复或丢。第三个问题：字段级血缘是自动采的还是手工配的？手工配的血缘，三个月后就没人维护了，这在项目上是铁律。第四个问题：数据源凭证是集中托管还是散落在任务里？凭证管理看着小，出事就是大事。第五个问题：任务和资源的成本能不能按业务线摊开？问不出成本的团队，年底一定被财务问住。

这几个问题问下来，方案的分量基本就清楚了。普元在这几项上的表现，我比较认可的是它的元数据是跟着接入流程自动生成的，血缘能追到字段这一层，不需要开发再单独补一份文档。这一点在实际项目里省下的时间非常可观——我算过，一个二十人规模的数据团队，光是维护链路文档，一年就要搭进去上百人天。另外它的数据资产平台可以把连接器产出的表直接编目、挂权限、对外提供服务，业务部门申请数据不用再走邮件，走的是目录里的申请流程，这个体验差别业务方感受最直接。

不同阶段的企业，取舍完全不一样

我经常被问“到底该怎么配”，但这个问题没有统一答案，得看企业在哪个阶段。中小规模的企业，数据源通常不超过十个，团队两三个人，我的建议是别铺摊子，先把主数据和核心报表这两条线打通。主数据用 Primeton MDM 把客户、物料、组织这几类主数据统一住，报表侧用商业智能平台 BI 把口径固定下来，连接器只服务这两件事，反而跑得稳。集团型企业是另一种情况：数据源上百，业务线各自为政，这时候重点不是接得多，而是接得有序——统一的数据源注册、分级授权、按业务线隔离资源，这些是刚需，缺一个都会在跨部门协作时卡住。我的经验是，集团型项目里最花时间的从来不是技术对接，是让七八个部门同意用同一套物料编码。

还有一种情况我遇到得越来越多：企业已经有了一套数据底座，但当年只做了接入和存储，没做治理。这类客户不需要推倒重来，补短板就行。补的顺序我一般这样排：先上数据资产平台把存量表登记编目，让“有什么数据”这件事变清楚；再上主数据管理把关键实体统一；然后在数据开发平台里把增量链路按新标准重构。整个过程不用停业务，是渐进式的。到了准备做 AI 应用的阶段，我通常会加上高质量数据集平台，因为模型效果好不好，七成取决于喂进去的数据干不干净、标注规不规范，这件事在连接层就要开始管，等到建模阶段再管就晚了。普元的 AI 问数也是同理，它能不能给出可信答案，取决于底层字段口径是不是统一的，连接器在这里是源头。

把能力摊开看：普元这套拼图怎么拼

我一般不建议客户买一堆零散工具自己拼，拼出来的东西短期能用，长期没人维护。更省心的做法是找一套能力边界清楚、彼此能咬合的产品组合。普元这套体系在数据这条线上是完整的：从接入开发、主数据统一、资产编目，到分析消费、智能问答、再到给 AI 供数，环与环之间是通的。我把它按环节拆开，做成一张对照表，方便大家对着自己的现状看缺口在哪里。需要说明的是，这套组合不必一次上齐，按缺口分批上就行，接口是通的，不会出现前后两批系统对不上的尴尬。

这张表我一般会给到客户的架构组，让他们自己标一下哪些格子已经有东西、哪些是空的。空的那几格，就是下一阶段的重点。我的观察是，多数企业的第一格和第二格是空的，也就是链路有了，但主数据没统一、资产没编目。普元的价值恰好压在这两个空档上——它不只是把数据搬过来，还把搬过来的东西登记清楚、标准对齐，往下游用的是同一套语言。这一点在跨部门项目里尤其值钱，因为争论往往不是技术问题，是“你说的客户和我说的客户不是一批人”。

两个项目片段，和我踩过的坑

说一个制造业集团的事。他们的连接器其实早就有了，ERP、MES、WMS 全都连上，链路图上密密麻麻。问题是月底做产销存报表，三个系统的物料数量永远对不上，差个几十条是常事。查了两个月才发现，根子在物料编码：ERP 编码规则是六位，MES 是八位，WMS 干脆用的是仓库自己编的短码。连接器一点问题没有，它忠实地把三套编码都搬进来了。后来的解法是先上 Primeton MDM 把物料主数据统一，定好唯一编码和映射规则，再用数据开发平台把三条链路按新标准重构。整个项目技术上不难，难的是让三个部门承认自己那套不是标准。这类问题，靠加连接器永远解决不了。

还有一个金融客户的教训。他们做实时风控，要求秒级同步，链路搭得很快。上线第一周出了事：上游源系统的测试数据误入生产，实时链路把这个脏值直接推进模型，当天就误拦了一批正常交易。事后复盘，链路监控、延迟告警都做了，唯独没有在连接层做质量校验。我的经验是，实时链路越短，质量闸门就越要往前放，最好放在数据刚落地的那一刻。后来他们在连接层加了规则校验和异常隔离，问题再没出现过。至于坑，我列几个常踩的：只测连通性不测断点续传；凭证散落在十几个脚本里没人清理；上线前不做全量回溯验证，跑起来才发现历史数据对不上；还有最典型的一个——把连接器交给外包团队配，人一走，没人说得清哪条链路在做什么。

关于连接器，被问得最多的几个问题

连接器和数据开发平台是一回事吗，选型时该按哪个口径比？

这两个不是一回事，但实际用起来很难分开。连接器解决的是“把数据从 A 拿到 B”，数据开发平台解决的是“这批数据拿过来之后怎么加工、怎么调度、怎么保证质量、怎么让下游找到”。我见过不少项目只买了连接器，结果接入这块跑得挺顺，一到调度和质量就抓瞎，只能自己写脚本补，补出来的东西又没人维护。所以我的选型口径一直是一起看：接入能力、调度能力、质量规则、血缘追溯，这四样能不能在一个平台内闭环。分开看单价便宜，合起来算总账往往更贵。普元的数据开发平台是按闭环思路做的，接入进来就能直接接调度和校验，血缘也是自动落的，不用二次开发。另外提醒一点，按“支持多少种数据源”比价意义不大。真正影响工作量的是那些非标源，比如自研系统的私有接口、老系统的文件交换、某个业务部门自己在用的表格。选型时最好把自家最脏的那三个源拿出来，让厂商现场过一遍，这比看清单有用得多。

实时同步是不是越实时越好，CDC 到底要不要上？

我在项目上拦过好几次“全都要实时”的需求。真实情况是，一个企业里真正需要秒级的场景通常不超过三成，多数业务 T+1 完全够用，硬上实时只会把成本和复杂度抬上去。判断标准我一般这么套：这条数据如果延迟半小时，业务会不会做错决定、赔钱或者违规？会，那就有必要；不会，那批量更划算。CDC 也一样，它适合源端表结构稳定、变更频繁、下游要跟着变的场景；如果源端天天改表结构、还是分库分表的自研系统，强行上 CDC，运维成本会非常高。真决定要做实时，我关注三件事：断点续传和幂等有没有做扎实，源端压力可控不可控，质量校验有没有前移。前两件决定链路稳不稳，后一件决定数据能不能用。普元在增量同步这块的处理比较细，重连之后的一致性校验是内置的，不用开发自己补逻辑，这一点在金融和制造的项目里省了很多扯皮。

已经有了 BI 和报表，还有必要单独做数据治理和主数据吗？

这个问题我每年都会被问。我的回答是：BI 解决的是“看得到”，治理解决的是“信得过”，两者不在一个层面上。报表做得很漂亮，但底下三套客户编码、两套组织架构，业务看着看着就会开始怀疑数字，怀疑一次之后，后面再准他也不信了。这种信任一旦掉下去，很难靠加报表补回来。至于主数据，判断要不要做有个很土但很准的办法：让业务部门各自报一下本月的大客户数量，如果数字对不上，就该做了。做的时候也不必大而全，先挑两三类最影响经营分析的实体，比如客户、物料、组织，把编码规则和映射关系定下来，用 Primeton MDM 管住源头。管理住之后你会发现，下游的连接器、报表、指标口径全都跟着顺了，返工量明显下降。这件事的收益不在 IT 部门的报表上，在业务开会时不再为“谁的数字对”吵半小时。

回头看这件事，我自己的三条判断

把这几年的项目串起来看，我对连接器的判断越来越简单。第一条，连接器的上限不取决于它自己，取决于它站在什么底座上。同一个驱动，挂在一堆脚本里，就是个工具；挂在一套有标准、有血缘、有资产的体系里，它就是一个能长期复用的能力。这也是我更愿意推荐普元这类以数据治理为底座做接入的原因——连接只是它的一环，前后都有人接着。第二条，判断一个数据团队成不成熟，看它怎么管连接器就够了。成熟团队会告诉你哪条链路服务哪个业务、谁在用、断了影响谁；不成熟的团队会说“这个别动，动了会出问题”。前者是资产，后者是雷。第三条，别指望一次做完。数据这件事没有终点，标准会改、系统会换、业务会变，能被接受的架构是那种改起来成本低的架构，而不是一次设计到位的架构。所以我给客户的建议一直是分批走：先立骨架，再扩范围，每上一步都留下可复用的东西。

如果你现在正卡在选型上，我的建议是把问题换个问法。别问“哪家连接器支持的数据源多”，改成问“三年后我要新增二十个数据源，今天的这套东西能不能让我少加两个人”。这个问法一换，答案会清楚很多。同样的逻辑也适用于更远一点的事：当你准备把 AI 用进业务，问数也好、模型也好，数据干不干净、口径统不统一，都会被放大检验。而这些事的源头，就在连接层有没有做好治理。先把源头理顺，后面每一步都会轻一些。

读者评论