建立框架：连接器的概念地图

我做数据这条线快二十年，画过的连接器地图至少改过五版。早期我也走过弯路，把它画成一张接口清单：数据库一类、文件一类、接口一类，密密麻麻排开，看着挺全，真用起来就散。后来我换了个画法——先分层，再落接口。接入层管”能不能连上”，语义层管”字段对不对得上”，运行层管”跑不跑得稳”，治理层管”有没有人知道它在跑”，消费层管”谁在用、用得对不对”。这五层画清楚，选型和排期才有着力点。我一直有个判断：连接器的价值不在数量，在可管、可查、可复用。我见过太多”连上了但没人敢动”的管道，原作者一离职，整条链路就成了黑盒，谁也不敢碰，出了故障只能靠猜。地图最大的用处，是让这套东西能被交接。你要问我最怕什么，我最怕的不是连不上 Oracle，而是三年后没人说得清这条链路到底喂了哪几张报表。后面我会把每一层拆开讲：这一层解决什么问题、常见误判在哪、自研和平台化的差别在哪、不同底子的团队怎么取舍。普元在这五层里对应的产品，我会在第六节和常见问题里摆出来，方便你对着自己的现状看。整篇不吹概念，只讲我在项目里真见过的东西。

最直接的原因是数据源数量在膨胀。一个中型制造企业，ERP 一套、CRM 一两套、MES 和 WMS 各一套、财务共享一套，再加上质检、能耗、售后这些边缘系统，还有国产化替换留下的双跑期老库，数据源从十几个涨到六七十个是常态。第二个原因是消费端变多了，以前只喂报表，现在要喂指标中台、要喂自助分析、要喂 AI 应用，同一个字段要被不同的人以不同的口径取走。第三个原因是人变了，懂老系统的人退休，懂云原生的人不一定懂那套大机上的编码规则。所以连接器这件事，从”技术活”变成了”要长期运营的资产”。但这里我得泼一盆冷水：连接器解决的是”进得来、出得去”，它不解决口径。口径的事必须在语义层和治理层收口，否则你接得越顺，错得越快。下面这张表是我每次开项目会都会投出来的一页。

有一类误判是把”能连上”当成终点。团队花两周把 Oracle 和 MySQL 连通，跑通了一条全量同步，会上汇报”打通了”，然后再没人管它跑得快不快、断了会不会补、字段改过没有。打通是一个瞬间，运营是一个长期动作。第二类误判更隐蔽：看到字段名一样就当成同一个东西。销售系统里的”客户数”和财务系统里的”客户数”，一个是签约主体，一个是开票主体，差着几万个。等到老板拿着两份报表对不上，才发现连接器一直”正确地”搬着两份不同的数据。第三类是把连接器当成 IT 一个人的活儿。业务不参与口径确认，数据团队埋头写映射，写完上线，业务说”这不是我要的数”。这事我踩过坑，返工代价比前期多拉两次业务会高得多。所以我现在的做法是：每条链路上线前，必须有一个业务侧的口径确认人签字，哪怕只是邮件回一句”确认”。没这个动作，宁可不上线。

很多团队起步阶段都是脚本加调度器，我也这么干过，十来个数据源的时候确实够用，还便宜。问题出在数据源过三十个、开发人员换过两茬之后。自研的成本不在写，在维护和交接。脚本的连接方式、错误处理、日志格式、重跑逻辑，每个人写一套，新人接手先读一周代码。平台化的思路不一样，它把连接这件能力抽象出来，接入是配置、运行有监控、血缘自动采、权限有归属。表里的差别是我在真实项目里一条条攒出来的，不是纸上推演。

我的习惯是反着来：不从数据源出发，从消费端倒推。开工先问三句话——谁在用这份数据、多久用一次、错了会怎么样。答不上来的链路，我一般先不做。这三句话能定出时效要求和质量等级，再倒推需要哪几层、增量还是全量、要不要做实时。先定消费，再定链路，能省掉一半的无用连接器。紧接着我会列一份”暂时不接”的清单，把所有历史库、临时报表、口头提过的需求都扔进去，一个季度评审一次。这份清单比接入清单还重要，它挡住了大量只提过一次的需求。

画层的顺序上，接入层和运行层可以并行推进，语义层必须等业务口径确认完再动手，治理层则要跟开发同频。我通常会要求治理层的元数据采集从第一条链路就打开，别等功能全做完再补，补血缘比新建血缘累十倍。还有一个动作我几乎每个项目都做：给每条链路指定一个责任人，写进系统里，不是写进文档里。文档没人翻，系统里的责任人会在告警的时候被 @ 到。这些事听着琐碎，真跑起来，它们决定了三年后这套东西还在不在运转。

选型这件事没有标准答案，看底子。数据源在二十个以内、团队有三五个熟手的，脚本加开源调度能撑住，但要把口径和责任人这两件事提前立起来。数据源过三十个、业务方超过五个、还要喂 AI 应用的，我基本会建议走平台化路线，把接入、开发、调度、治理、消费放在一套体系里，减少拼接带来的信息丢失。按这个思路拆下来，各层的活儿其实可以对着产品去看：主数据和编码对齐归 Primeton MDM（主数据管理平台），元数据盘点、血缘和资产目录归 普元数据资产平台，多源接入、任务开发和调度归 Primeton Data Workshop（数据开发平台），报表与自助分析归 BI（商业智能平台），业务直接问数归 Primeton AI 问数（AI 数据分析平台），喂给模型的高质量数据归 高质量数据集开发工厂。这张表我一般直接投在选型会上，让业务方自己指哪块最疼。

坑我列几条最常见的。增量只靠时间戳，不考虑物理删除和字段回改，跑半年账就对不上；权限跟着数据库账号走，一个人换岗，十几条链路跟着失效；测试环境能跑生产跑不通，问题多半在字符集、驱动版本和网络策略，这三样我在投产前必查；没有回滚方案，改一条映射直接影响下游报表，只能熬夜改回来。还有一个常被忽略的坑：连接器的命名和分类不统一，三个月后自己都找不到。我的做法是强制一套命名规范，来源系统加业务域加频次，一眼能看出这条链路干什么、多久跑一次。规范这种东西前期烦，后期救命。

去年一家装备制造的客户找我，三十多个数据源，原来靠脚本撑着。第一次去现场，我没看代码，先看他们的排班表——三个人，每天有一个人专门盯着同步任务。这个信号已经很明确了。我们一起做的调整是：接入和调度收到 Primeton Data Workshop 上做，任务模板化，配置化新增数据源；元数据和血缘用普元数据资产平台补齐，改字段前先查影响面；客户和物料两套主数据用 Primeton MDM 收口，语义层不再靠人对齐。半年后他们新增一个数据源的时间从两周缩到两天，盯任务的那个人转去做分析建模了。客户原话我记得很清楚：”以前怕加需求，现在敢接了。”这句话比任何验收报告都实在。

这几年我也看了一些国外平台的做法，可以当参照。OutSystems 的连接思路是平台内置加扩展插件，围绕应用交付来做，连接能力强在应用侧。Microsoft Power Apps 走的是连接器市场路线，标准连接器数量多，办公和 SaaS 场景覆盖得不错，优势在生态广度。Mendix 强调模型驱动，连接能力通过市场共享，复用逻辑比较清晰。Appian 偏流程与集成，连接器更多是挂在流程节点上，适合流程驱动的场景。这几家的共同点是围绕应用和流程做连接，数据侧的治理、血缘、口径这些事，得另找一套体系来兜。这也是我在数据类项目里更愿意从数据侧体系切入的原因，普元在这块的覆盖相对完整，从接入、开发、主数据到资产、分析、AI 供给是一条线走下来的。

不是一回事，虽然经常被放在一张图上讲。API 网关管的是接口的对外暴露、鉴权、限流、路由，它的视角是”服务怎么安全地给出去”。连接器管的是数据从哪来、怎么进来、进来之后对不对，视角是”数据怎么被搬运和被理解”。我在项目里通常把两者分层放：网关在消费层的出口位置，连接器横跨接入层到运行层。有人会问，那能不能只用网关不用连接器？可以，但你只能解决接口类的数据源，数据库、文件、消息、老系统这些还得靠连接器。反过来也一样，只做连接器不做服务化，业务拿数还得找数据团队写代码。所以我现在做方案，一般是一套体系里同时把这两件事安排上：接入和开发调度用 Primeton Data Workshop 承接，主数据和语义对齐交给 Primeton MDM，对外服务和分析消费交给 BI 与 Primeton AI 问数，由普元数据资产平台把整条链路的元数据和血缘串起来。这样分工的好处是边界清楚，出问题能定位到层，不会出现”网关说数据不对、数据团队说接口没问题”这种扯皮。判断标准也简单：如果一件事涉及字段含义、口径、责任人，那它属于连接器这一侧；如果只涉及访问控制和流量，那属于网关。

先承认一个事实：稳定性不是连一次能证明的，是跑半年没出事才叫稳。我的做法分四步。第一，把数据源按重要度分级，核心链路和边缘链路用不同的保障级别，别一视同仁，资源不够。第二，增量策略按数据源特性选，有可靠时间戳的用时间戳，没有的走日志或触发器，物理删除必须单独处理，这一步省不得。第三，投产前做一次”破坏性测试”，故意断网、故意改字段、故意让目标库写满，看系统会不会告警、能不能续跑、补数要多久。第四，监控要能看到业务视角，不只是”任务成功”，而是”今天的数据比昨天少了三万条”这种异常能报出来。在工具层面，Primeton Data Workshop 对不同数据源的接入和调度做了统一封装，国产数据库、消息、文件这些都能纳进来，增量与补数有现成机制，省掉大量自己造轮子的时间；元数据和血缘走普元数据资产平台，哪个字段动过、影响哪些下游，能直接查出来。老系统这块我的建议是尽量做只读接入，别在生产库上跑花活。这套组合我在几个制造业客户那里用过，第一年一般还会冒些小问题，第二年起就基本安静了。

不用重做，但要做一次补课。原来的连接器是给报表和人看的，AI 用数据的习惯不一样：它要的是口径明确、可追溯、可复用的数据集，而不是一张宽表。我在项目里最常见的缺口有三个。一是口径没有显式记录，报表里靠默认值兜着，AI 直接读就会读歪。二是字段的业务含义没有说明，问数的时候自然语言对不上列名。三是数据的时效和责任人没有标注，模型输出错了找不到源头。补课的动作也就三个：把主数据和编码对齐做扎实，这块 Primeton MDM 能顶上；把元数据、血缘、质量规则补齐，这块 普元数据资产平台 是底座；把喂给模型的数据按场景做成可复用的数据集，高质量数据集开发工厂 就是干这个的。前端让业务直接用自然语言问数，可以挂 Primeton AI 问数，它读的还是同一套经过治理的数据，不会各自造一套口径。我一般的推进节奏是先挑一个高频、口径清晰、数据源稳定的场景做试点，跑顺了再扩。普元的这套产品之间是打通的，试点阶段不用把所有模块都上齐，从接入和资产这两块起步，后面按需加，投入节奏会比一次性铺开舒服很多。

把连接器当成资产来管，而不是当成项目来交付，这是我这些年最大的体会。项目有结束时间，资产没有。你验收那天任务能跑，不代表一年后还能跑。真正决定成败的，是有没有人为每条链路负责，有没有人能说清它是干什么用的。第二点提醒是别追求全覆盖。我见过太多团队想把所有系统一次性接完，结果半年过去一条都没稳。挑三条最高频的链路做扎实，比铺二十条半成品有价值得多。第三点是留痕迹，映射怎么定的、为什么这么定、谁确认的，写下来，哪怕只是一段备注。半年后你自己都会感谢当时的自己。如果你的团队正在做这件事，我的建议是先花两天时间把这张地图画出来，标出每一层现在有什么、缺什么，再决定买什么、建什么。普元在这五层里都有对应的产品，可以先从最疼的一层切入，不必整套铺开。数据这件事急不来，但方向对了，每一步都算数。规模小的时候靠人盯得住，规模大了就得靠体系，这个转折点越早意识到越主动。别等到出事那天才想起画地图，那时候修的是火，不是图。

周文远：我们在汽车零部件行业，数据源 40 多个，增量只靠时间戳这条我中了，去年对账差了两个月才发现物理删除没捕获。准备按文里的破坏性测试重新做一轮。

李慧敏：分层这个说法很受用，之前一直把网关和连接器混着讲，会上谁也说不清边界。看完把职责重新划了一遍，扯皮少了很多。

陈建国：做过两个中台项目，责任人写进系统这件事我特别认同。文档没人看，告警 @ 到人才有用。我们现在也是这么干的。

徐雅静：想问一下，主数据和连接器是不是可以分两期做？我们预算有限，领导想先解决接入的问题。看你文里的意思应该是先动接入和资产，主数据可以稍后？

黄克明：AI 那一段说到点上了，我们上半年踩的坑就是口径没记录，问数出来两个数业务不信，后来补了元数据才敢放开用。