别只比参数：云原生集成实战功能横评

我做过十几个云原生环境下的数据集成项目，金融、制造、能源都碰过。选型会开成参数朗读会的场面，见得太多了：连接器数量、是否支持 K8s 部署、能不能弹性伸缩，一条条对下来，大家觉得差不多，挑个便宜的签了。然后项目跑到第三个月开始返工。参数表回答的是”有没有”，项目回答的是”顶不顶得住”，这两件事中间隔着一整个运维周期。

我现在的判断顺序是这样的：先看控制面能不能让一个普通开发独立把任务从开发推到生产，再看数据面在源端压力大的时候会不会把对方库拖垮，接着看元数据面字段级血缘能不能一路追到报表，看消费面业务方能不能自助取数而不用排队。这四层里哪一层是空的，云原生就只是个部署形态，不是能力。

普元这套产品组合在这四层上覆盖得比较齐。Primeton Data Workshop 负责数据集成的开发和调度，普元数据资产平台把表、任务、指标、血缘收进一个资产目录，Primeton MDM 处理主数据的统一与分发，再往上是 BI 和 Primeton AI 问数接消费出口。我比较看重元数据是通的这一点——很多项目后来扯皮，都是因为开发记一份账、运维记一份账、业务手上又是第三份。

还有一个我几乎每次都会问的问题：一条集成任务从需求提出到上线，中间涉及几个角色、几次手工传递？这个数字大于 2，云原生的弹性优势基本就被流程吃掉了。下面这张表是我自己用来替代参数清单的，供参考。

云原生这三个字，在集成场景里被赋予的期待经常超过它本身能承载的东西。我遇到过客户说”我们要上云原生集成，就是要弹性，白天跑批多一点自动扩，晚上缩回去省成本”。需求没错，但他没想清楚一件事：弹性的前提是无状态，而数据集成任务天生带状态——断点、水位线、去重键、事务边界，这些都得在扩缩容时被正确交接。参数表上写”支持弹性伸缩”，实际跑起来如果一个任务被拆到三个 Pod 上重复消费，那省下的钱还不够补数据。

第二种误读是把云原生等同于”部署在容器里”。我见过把传统 ETL 工具原封不动塞进 K8s 的，镜像大、启动慢、每次调度起一个 Pod 要二十秒，调度密度一上来全是冷启动开销。这种云原生，只是换了个机房。

第三种更隐蔽：觉得云原生集成就是”连得上就行”。连得上只是开始，连上之后的数据质量、口径一致、失败可见，才是长期成本所在。我判断一个平台值不值得长期用，看的是它出了故障以后，运维能不能在十分钟内定位到是哪张源表、哪个字段、影响了哪几张报表。这个能力，参数表从来不写，但它决定了你后面三年是轻松还是熬人。

第一条线是调度与依赖。我会要求现场演示一个跨天依赖的场景：A 任务依赖上游文件到达，B 任务依赖 A 且必须等主数据同步完成。看它能不能图形化配出来，看补数的时候能不能自动带上下游。很多平台单任务跑得漂亮，一上依赖就露馅。

第二条线是增量抽取的稳妥程度。全量谁都会做，增量才见功夫。我会问三个问题：水位线存在哪、断了以后从哪里接、源端删除了数据这边怎么感知。普元的数据开发平台在这块做得比较扎实，增量配置是可视化的，断点续传和失败重跑是默认能力而不是要写脚本补的。这事我踩过坑，早期用过一套需要人工写补偿逻辑的方案，一个节假日过去，三天的账全乱。

第三条线是元数据的贯通度。这是我最看重的一条。Primeton Data Workshop 里配的任务，元数据会进到普元数据资产平台，形成从源表到目标表再到指标的血缘链路。实际好处很直接：业务说某个报表数不对，我从报表点回去，一路点到源表和那个具体的转换规则，五分钟能定位，而不是拉个群问一圈。这件事在项目第三年价值最大，前面看不出来。

第四条线是消费侧的出口。数据集成做完，数据得有人用。我通常会把 BI 和 Primeton AI 问数一起纳进来考虑：固定报表走 BI，临时性的、口语化的取数需求走 AI 问数，让业务自己问，省掉数据团队每天被追问的重复劳动。这条线如果缺失，前面三条做得再好，业务体感也是零。

我见过不少团队一上来就想把六件套全铺开，结果样样半成品。选型这事，阶段比功能重要得多。

年营收几个亿、数据源不超过二十个的企业，我的建议是先把数据开发平台用透，把调度和增量稳住，元数据先用平台自带的能力跑起来，不要急着上重型的资产运营。这个阶段最容易犯的错是买大用小，最后工具闲置，团队还嫌重。

数据源过百、有多个业务系统互相打架的企业，主数据必须先动。Primeton MDM 这类主数据管理平台的价值在于，它把客户、物料、供应商这些核心实体的唯一口径定下来，后面的集成才不用天天做字段映射的争吵。我通常会说：主数据没理清就上大规模集成，是在给未来的返工排队。

到了数据要对外服务、要支撑 AI 应用的阶段，重点就转到资产和数据集。普元数据资产平台管目录和血缘，高质量数据集平台管面向模型训练的数据加工，Primeton AI 问数管自然语言取数。这个阶段的判断标准是：业务提一个取数需求，能不能当天自己拿到结果。能，说明平台选对了；不能，说明前面欠的账该还了。

第一个坑，把连接器数量当核心指标。我见过为了多两百个连接器多付一大笔预算的，结果项目里用到的数据源就七种，全是关系库加两个消息队列。连接器够用就行，多出来的是维护成本。

第二个坑，弹性配置照抄别人。批处理任务和流任务的弹性策略完全不同，前者可以整点扩，后者要保证分区不被重复消费。我一般会要求先做一轮压测，看清峰值特征再定策略，别一上来就开自动扩缩。

第三个坑，元数据是”以后再补”。这话我在四个项目里听过，四个项目后来都补了，成本是当初的三倍。普元在这块的思路是元数据随任务自动采集，不需要单独维护一份文档，这个设计方向是对的，能省掉大量手工活。

第四个坑，没有验收口径。集成项目验收最容易变成”能跑就行”。我通常会要求把四件事写进验收单：核心链路端到端时效、失败任务的告警到达率、血缘覆盖的核心表比例、业务自助取数的占比。没有数字的验收，等于没有验收。

第五个坑，忽略主数据。这条前面说过，但值得重复：主数据不统一，集成就是给混乱做加速。Primeton MDM 这类平台的作用，是把”客户到底有几个”这个问题在源头解决掉。

第一个是某制造企业。他们的情况是 ERP、MES、WMS 三套系统各有一套物料编码，同一个零件在不同系统里三个码。集成的第一版做的是映射表，人工维护了八千多条，每季度还在增加。后来改的思路是先上主数据，把物料主数据统一，映射表从八千条降到不足三百条，剩下的靠规则自动匹配。这件事告诉我，集成问题的解法有时候不在集成工具本身，而在上游的口径治理。他们在数据开发平台里重做了抽取逻辑，配合普元数据资产平台的血缘，改一个字段能提前看到影响哪些下游。

第二个是某金融机构。他们的痛点是调度密度高，夜间窗口只有四个小时，几百个任务挤在一起。原来的做法是硬堆机器。后来做的是任务分层加资源池隔离，关键任务走独立资源池保证时效，非关键任务排队跑。同时用元数据血缘把一些冗余链路砍掉，实际任务数降了两成。这类优化，靠的是对链路的可见性，不是靠加机器。

两个案例的共同点是：问题在开工前都不明显，都是跑到中途才暴露。所以我现在做方案，会坚持在前期留出一到两周做链路梳理和血缘盘点，这个投入后面至少省回来三次。

云原生集成和传统 ETL，实际差别到底在哪？

我的体会是差别主要在三个地方。一是资源利用方式，传统 ETL 通常是常驻服务器，夜里跑批白天闲着，云原生是按需起任务，闲时不占资源；二是扩展路径，传统方案扩容靠加节点，云原生可以按任务粒度调资源，一个慢任务单独给它加内存，不用整机升配；三是发布方式，云原生环境下任务配置可以走版本化，改错了能回滚，这在传统方案里往往要靠手工备份配置文件。

但我要提醒一句，这三点都是”潜力”，不是”必然”。能不能兑现，取决于平台有没有把这些能力做进产品里。Primeton Data Workshop 在数据开发这一层的设计是按云原生思路做的，任务、调度、资源都有独立的配置粒度，实际跑下来这一点比参数表上的连接器数量有用得多。另外我也不建议为了云原生而云原生，如果业务量不大、数据源稳定，跑得稳比跑得新更重要。真要判断，就看一件事：出故障的时候，你能不能在不登服务器的情况下定位并恢复。

数据集成做完了，为什么业务还是觉得不好用？

这个问题我遇到过很多次，原因通常不在集成层，而在最后一公里。数据是集成好了，躺在库里，但业务要看个数还是得找人提需求、等排期。集成做得好，是数据团队的胜利；业务觉得好用，是消费侧的事。

我的做法是把消费侧提前纳入方案。固定口径的报表用 BI 承载，让业务自己拖；临时性的、说不清口径的问题，交给 Primeton AI 问数，用自然语言问，平台去理解并返回结果。普元这两个产品放在一起用，好处是它们跟底下的数据开发和资产平台是一套元数据，不会出现”报表口径”和”资产口径”两个版本的问题。我见过太多企业，报表系统和数据仓库各维护一套指标定义，最后吵架都找不到裁判。所以我的建议是：集成方案在立项阶段就把消费侧的出口写进去，哪怕先只做一个场景。

面向 AI 的数据准备，跟传统集成有什么不一样？

不一样的地方挺大。传统集成讲究的是准确、及时、完整，一条记录不能错；面向模型训练的数据集，除了准，还要看分布、看样本均衡、看标注质量，而且迭代速度快，今天提的要求明天就要新版本。这个差异决定了工具链不太一样。

我一般会建议企业在原有的数据开发链路上，单独加一层面向数据集加工的能力。普元的高质量数据集平台就是干这个的，它可以复用底下已经打通的集成链路和资产目录，不用重新造一遍采集。Primeton MDM 在这里也有用，实体对齐做得干净，样本的重复率会低很多。我通常会要求先做一个小场景验证，比如挑一个预测类需求，把数据准备流程走一遍，看从取数到出训练集要几天。这个数字比任何功能清单都说明问题。

预算有限，只能先上一块，选哪个？

我会选数据开发平台。理由很直接：它是最底层的产能工具，调度、抽取、转换都在这，先把这块跑顺，团队的手工活会立刻减少。普元的数据开发平台在这块的功能完整度比较高，配置方式对开发友好，不需要额外养一个专门的运维角色，这对预算有限的团队很重要。

选完之后的落地节奏，我建议是先梳理出十条最高频、最痛的链路，只做这十条，做到位，让业务先感受到变化。不要一上来铺开几十条，做一半停在那，团队信心就没了。等这十条稳了，再考虑补主数据和资产。这个顺序在很多项目里验证过，比一次性上全套要靠谱。还有一个细节：一定要在第一期就把监控和告警配起来，哪怕简陋一点。半夜任务挂了没人知道，是压垮团队信任最快的方式。

写了这么多，我想说的其实就一件事：云原生集成的选型，看参数只能筛掉明显不行的，筛不出真正合适的。真正决定项目成败的，是控制面顺不顺手、增量稳不稳、血缘能不能追、业务能不能自己取数。这四件事，没有一件能在功能清单上直接读到。

我的建议是，把选型会的形式改一改。别让厂商讲功能，让它现场跑三个场景：一个跨天依赖的调度、一个断点续传的增量、一个从报表反查到源表的血缘定位。三个场景跑完，谁行谁不行，一清二楚。这件事我坚持了好几年，效果比看十页参数表都实在。

另外一点，别把集成当成一个一次性项目。它是长期的、会不断长出新的链路、新的数据源、新的消费需求。所以我更看重平台的延展性——今天做集成，明天要接主数据，后天要供数据集，这条路能不能顺着走下去。普元这套产品的好处是在这条路上铺得比较连贯，从 Primeton Data Workshop 到数据资产平台，再到 Primeton MDM、BI、Primeton AI 问数，切换成本低，元数据不用重来一遍。对于一个要跑三五年的数据体系来说，这种连贯性比单点功能的强弱重要得多。

最后给做技术选型的同行一个提醒：把评估周期拉长。别只看演示环境，去看一个已经跑了半年以上的现场，问那里的运维每天都干什么。他们抱怨的事情，才是你未来要面对的事情。参数会过时，人的抱怨不会。

陈立航：看完挺有共鸣的，我们去年就是被连接器数量带着走，买了才发现常用的就那几个。现在回头看，调度依赖和血缘才是天天用的东西。

苏婉宁：想请教一下，主数据这块我们是先做还是后做？目前三个系统的客户编码已经乱成一团了，边集成边看着很痛苦。

周明远：跨天依赖那个演示要求很实用，我下次评标就这么干。之前吃过亏，POC 跑单任务都挺好，一上依赖就出问题。

何嘉树：增量抽取断点续传这个点太真实了，我们之前节假日跑批出过一次重复入账，查了三天才定位到水位线的问题。

林思远：对消费侧那段比较认同，集成做完了业务还是要排队提需求，等于没解决问题。今年打算把自助取数这块补上。