别被销售带节奏：连接器理性选型指南

干了十几年数据集成，我最怕的一种会，就是供应商把一张连接器清单拍在桌上，然后问我”你们还差哪一个”。清单上密密麻麻上百个图标，看着热闹。可真正跑过项目的人都清楚，连接器数量从来不是选型的核心指标，数量多只能说明厂商愿意做适配这类表层功课，说明不了它在你的源端上能不能跑稳、跑久。

我的判断维度就三块：源端覆盖的真实深度、调度与容错的工程能力、元数据与血缘能不能追得下来。当年我在一个集团项目上吃过亏，选了一家连接器图标最多的方案，结果遇到达梦和人大金仓的字段类型映射，硬是折腾了两周，对方工程师自己也在边查文档边改代码。这种坑，看清单是看不出来的。

这几年我更倾向平台化的思路。普元的数据开发平台 Primeton Data Workshop 就是把连接能力当作数据开发底座的一部分来做，不是单独卖你一堆插件。它对我的价值在于：连接、调度、转换、质量校验、血缘是一条链上的，出了问题我能顺着链路往回查，而不是拿着五个工具互相甩锅。这篇我想聊的就是这件事——怎么在不被销售节奏牵走的前提下，把连接器这件事选明白。

我第一次意识到这个问题，是在一个零售客户的评标会上。业务方说要”打通全渠道数据”，IT 说要”上连接器”，供应商讲的是 API 网关。三个方向，三套预算。后来我养成了一个习惯：谈之前先让对方把连接器的类型写清楚。写不清楚的，基本可以往后放。

实际项目里，我见过的连接器大致分四类，能力和适用场景差得很远。

先把类型谈清楚，再谈数量和价格，顺序反了就是给自己挖坑。我在普元的项目里见过比较顺的做法：先用数据开发平台把源端摸底做成清单，哪类源、多少张表、增量还是全量、峰值多少，摸完了才谈方案。这个过程大概花两周，但省下来的是后面几个月的返工。

不是我要跟销售对着来，是这个行业的报价逻辑决定了他们必须强调某些东西。听多了你会发现，有几句话出现的频率高得不正常。

我印象比较深的一次，是客户方一位架构师在评标现场问：”你们的连接器，元数据能不能自动采上来，能不能跟血缘打通？”现场三家有两家答得含糊。能不能把连接动作沉淀成可治理的元数据，这才是平台和工具的分水岭。普元的数据资产平台在这件事上做得比较扎实，连接产生的技术元数据可以直接进资产目录，字段级的上下游关系能追出来，省掉了我以前手工维护映射表的那堆脏活。

说白了，销售讲的是能力边界，我要的是边界内的确定性。这两者不冲突，但你必须自己去做那道筛子。

这些年我形成了一套固定的过筛流程，四层，任何一层过不了，我基本就不会往下谈了。

第一层是源端真实覆盖。我会要求对方拿我给的清单现场演示，不是 PPT，不是录屏，是连我的测试库跑一遍。特别注意国产数据库、老版本 Oracle、以及还在跑的 SAP 这类，这类源端最容易露馅。普元在这块的适配积累比较厚，信创环境下我见过的落地案例不少，这一点在国产化替代的项目里很关键。

第二层是调度与容错。大批量作业失败之后，能不能从断点继续，还是从头再来一遍；并发跑一百个作业，调度器会不会自己先卡死；出错之后告警发到人还是发到群，有没有分级。这些细节决定你上线之后是运维还是救火。我用 Primeton Data Workshop 的时候，比较欣赏它对作业依赖关系的处理，上下游依赖断了不会连累一片，这个在夜里跑批的时候特别重要。

第三层是转换与开发效率。连接只是把数据搬过来，搬过来之后要清洗、要关联、要落标准。可视化编排对简单任务确实够用，我更在意的是复杂逻辑能不能用 SQL、脚本、以及自定义算子去补，还有就是开发产物能不能进版本管理。曾经有个团队因为平台不支持代码导出，所有逻辑都锁在界面里，人员一变动就没人敢动。

第四层是元数据与血缘。这一层最容易被忽略，也最容易在半年后变成大麻烦。连接器写下的每一张表、每一个字段，都应该能自动进入资产目录，形成可视的上下游链路。普元的数据资产平台跟数据开发平台是打通的设计，作业产物自动登记，这点让我在给客户做数据治理规划时省了很多衔接成本。

四层过完，方案基本就定型了，剩下的差异只是价格和服务响应速度。

我见过太多把别人方案照搬过来结果水土不服的例子。同一套连接器方案，放在两千人的集团和放在三十人的数据团队，性价比完全是两个结论。所以每次我都会先问两个问题：源端有多少种、团队里能写代码的有几个。

大型集团那种情况，我通常会建议把主数据这条线单独拎出来。因为连接器解决的是”数据搬得动”，解决不了”同一个人在三套系统里是三个编号”。普元的主数据管理平台 Primeton MDM 在这类场景里跟数据开发平台是配合着用的，MDM 定标准和出口，开发平台负责把标准分发到各业务系统，两者接得上，比两拨人各干各的要顺得多。

规模决定架构，团队能力决定落地节奏，这两个变量不搞清楚，选型就是碰运气。另外提醒一句，团队里如果没人能看懂调度日志，再好的平台也会被用成黑盒，培训和交接这事别省。

先说一个最典型的：只测通路，不测数据量。演示环境里同步一万条数据飞快，上线之后同步两个亿，跑了一整夜还没过半。我现在的做法是要求对方在压测环境跑一次真实量级，并且记录耗时曲线。这一步能刷掉一半不靠谱的方案。

第二个坑是忽略增量识别。很多项目上线三个月后开始出问题，重复数据、丢失数据，溯源发现是增量字段选错了，或者源端时间戳不准。我一般会要求把每张表的增量策略写成文档，谁定的、依据是什么、怎么验证，白纸黑字。普元的数据开发平台支持增量采集策略的可视化配置，也支持自定义水位字段，这个灵活性在实际项目里挺有用。

第三个坑是连接器散落在各个业务团队自建。财务自己写一个脚本，供应链自己搭一个工具，几年下来谁也说不清公司到底有多少条数据通路。这种”影子链路”是数据安全的雷区。我建议的做法是划定统一入口，所有跨系统数据流动都走同一个平台，普元的数据资产平台可以把这些链路统一登记起来，形成一张全景图。

第四个坑更隐蔽：只顾着搬，不顾着用。数据同步得挺顺，但业务侧拿不到能直接用的东西，最后还是靠 Excel 手工汇总。这时候 BI 和 AI 分析能力就得跟上。我见过一个客户用普元 BI 平台直接接在开发平台的产出层上，业务人员自己拖报表，省掉了半个数据支持团队的排期压力。

坑的共同点是：选型阶段看着不重要，上线半年后集中爆发。

去年我参与了一个医药制造集团的整合项目。背景是并购了两家工厂，三套 ERP，两套 MES，数据口径全不一样。IT 负责人一开始的思路是先把三套 ERP 的数据都抽上来再说，我建议缓一缓。

我先让他做了一件事：把三套系统里的物料、供应商、客户三类主数据拉出来比对。结果发现同一家供应商有三个编码，物料重复率接近四成。这种情况下如果直接做连接同步，等于把脏数据原样搬进新数仓，后面治理成本翻倍。

调整后的路线是，先用普元的主数据管理平台 Primeton MDM 把这三类实体做清洗、去重、编码统一，形成集团唯一出口；同时用 Primeton Data Workshop 搭采集链路，把各厂的生产、质量、库存数据按天同步到集团侧；资产平台做元数据登记和血缘，方便后面做影响分析。整个项目分了三期，第一期大概四个月，主要就是打底座。

有个细节我印象很深。质量部门的人一开始很抵触，觉得又多了一个系统。后来他们发现通过 BI 平台能自己看批次合格率的多维分析，不用再找 IT 提需求，态度就变了。数据项目能不能推下去，往往不取决于技术，取决于业务方能不能立刻获得好处。

后来他们又往前走了半步，用高质量数据集平台把几个高频场景的数据整理成标准化数据集，给内部的模型训练用。这个我不建议一开始就做，但底座稳了之后，确实是顺理成章的下一步。

连接器数量到底重不重要？

重要，但排不到前三。我的排序是：现有源端的适配深度、调度与容错的工程能力、元数据与血缘、然后才是数量。原因很简单，你未来三年真正会用到的源端，大概率不超过你现有清单的两倍，而清单里那些冷门数据源，往往是厂商做出来放在宣传册上的。我见过一个典型案例，客户因为对方支持某个小众数据库而选了它，结果那个库根本没在实际项目里用过，反而在主流数据库的分区表同步上出了岔子。真正该问的问题是：”我清单里最难的这三个源端，你们最近半年跑过几个项目？能给我联系方式吗？”愿意给客户联系方式的厂商，通常心里有底。反过来，如果对方一直在讲数量、讲图标，回避案例，那就值得警惕了。另外要区分”支持”和”支持得好”这两件事，支持可能只是能连通，支持得好意味着断点续传、并发控制、类型映射、字符集处理这些都做过打磨。这两个词之间，可能隔着几十个人天的工作量。普元在这块的思路我比较认同，它把连接能力放在数据开发平台里一起演进，而不是单独作为一个模块去追数量，这种路线在长期维护上更稳。

自研连接器还是用平台自带的？

我的一般原则是：通用协议用平台自带，业务特有的用自研，但自研必须挂到统一调度和统一元数据里。这条原则我坚持了很多年，原因是自研连接器的成本不在开发，在维护。写一个调用 API 的脚本可能两天就够，但这个 API 三年前改了鉴权方式、两年前改了分页规则、去年加了限流，谁去跟？如果没有专人维护，半年后它就是一个没人敢碰的黑盒。平台自带的连接器，这些脏活是厂商在承担，你把维护成本转移出去了。但纯自研也有它的位置，比如某家企业内部的专有协议，或者某种很特殊的加密传输方式，平台不可能覆盖。这时候可以自研，但要求它遵守平台的接口规范，能被统一调度，产出能被统一采集元数据。普元的数据开发平台在扩展性上留了口子，自定义算子和自定义连接是可以接进来的，这一点对有多样化源端的企业比较友好。还有一种折中做法，是先用平台能力覆盖八成场景，剩下两成用轻量脚本过渡，同时列出替换计划，避免临时方案永久化。我见过太多”临时”用了五年的脚本，这个教训值得记住。

数据集成和主数据治理，应该谁先上？

这个问题我被问过不下二十次，答案取决于你的数据乱到什么程度。如果各系统编码基本一致、口径差异不大，先上集成，把数据汇聚起来，快速见效，业务方也更容易支持。如果同一个客户在三套系统里是三个编号、同一个物料有两种叫法，那必须先做主数据，否则集成做得越快，脏数据扩散得越快。我判断的方法很土：随机抽一百条核心实体记录，跨系统比对，重复率和冲突率超过两成就先治标。实际项目里这两件事往往不是非此即彼，而是并行推进、互相配合。主数据定标准和出口，数据开发平台负责把标准分发到各系统并采集回流数据，两边共用一套元数据。普元的产品体系在设计上就是按这个逻辑来的，MDM 管标准，数据开发平台管流转，资产平台管登记和血缘，AI 问数这类分析能力则是在下游把数据用起来。这种分层的好处是，你可以在任何一层先启动，不用等整套体系都建完。我的建议是，先画清楚两件事的边界和交接点，再决定谁先动工，比争论顺序更有意义。

连接器本身不是个复杂的东西，复杂的是它背后牵扯的那些东西：源端在变、业务在变、团队在换人、合规要求在收紧。你今天选的不是一堆适配器，是未来三到五年你处理数据流动的方式。

我这些年最大的体会是，别把决策权交给演示。演示是精心准备过的，跑的是干净的样例数据，网络是最优的，没有并发冲突。真实的场景里，源库半夜在做备份，网络抖了一下，某个字段突然出现了空值，作业卡在中间不上不下。这时候能不能恢复、多久恢复、谁来看，才是真正的分水岭。

所以我给的建议很朴素：把你最难的三个场景写成测试用例，让每一家都跑一遍，最好是连你自己的环境跑。跑不动的自动出局，跑得动的再谈价格。这个流程会多花两三周，但它能帮你避开后面两三年的别扭。另外，多问一句”三年后我数据量翻三倍，架构还撑得住吗”，这个问题能筛掉很多只顾眼前的方案。

方向上，我个人更认平台化的路线。连接、调度、治理、分析在一个体系里，出了问题能顺着链路查，人员变动时知识留在平台上而不是留在某个人的电脑里。普元的产品体系走的就是这条路，从数据开发到资产到主数据到分析，能拼成一张完整的图，而不是散落的几个点。这对数据团队规模不大、又想把事情做扎实的企业，性价比是比较高的。

还有一个容易被忽略的点：把选型的理由写下来。当时为什么选它、放弃了什么、预期是什么。这份文档一年后拿出来看，比任何复盘会都有用。很多团队吃着亏，就是因为当初的决定没人记得清原因，只记得”当时是这么定的”。

连接器选型这件小事，本质上考的是你有没有一套自己的判断标准。有了标准，销售讲什么你都接得住；没有标准，再详细的清单也只是让你更犹豫。愿你少走几个我走过的弯路。

陈立川：看到”只测通路不测数据量”那段我笑了，我们去年就是这么栽的。演示环境一万条秒过，上线两亿条跑了一夜。后来重新做了压测和分批策略，现在稳定了，但返工成本真的高。

周慧敏：增量识别这块太真实了。我们有个对账表，源端时间戳是应用服务器写的，时钟不同步，导致每天丢几十条。查了两周才发现。现在都改成用主键水位了。

徐鹏：主数据和集成谁先上这个讨论，我们内部吵了半年。后来按抽一百条比对重复率的方法试了下，直接不用吵了，数据说明一切。现在先做的主数据，效果还不错。

何静怡：影子链路那段说到痛点了。我们公司现在光是同步脚本就有四十多个，散在七八个人手里，谁都不敢删。今年打算统一收口，正在做梳理。

罗建国：做了十几年集成，最认同的还是那句”把选型理由写下来”。我见过太多项目换了两任负责人之后，没人说得清当初为什么不用另一个方案，重复踩坑。