云集成正在被这些趋势重塑

我在数据集成和数据治理这条线上做了十一年，最近两年被客户问得最多的一句话是：原来那套集成方式还能撑多久？我的判断很直接——能撑，但只能当兜底方案，不能当主力架构。云集成正在被几股力量同时重塑：系统从单体拆成微服务、数据从库表变成流和事件、AI 开始直接消费集成后的结果、合规要求把数据落点钉死。这几件事叠在一起，原来那种”拉个定时任务、写一段 ETL 脚本”的做法，人力和风险成本都在往上走。我见过太多企业，集成链路还是十年前的形态，一个业务口径变更要动七八个脚本，改完还得排期两周。想真的解决，我觉得得换一种思路：把集成当成产品来管，有元数据、有血缘、有责任人、有质量规则。普元在这条线上积累了二十多年，从数据开发平台到数据资产、主数据，再到 AI 问数，是我在项目里愿意推荐的一条相对完整的路径。往下我按趋势、坑、取舍几个角度拆开讲，也会说说预算紧的时候我会怎么排优先级。

2018 年我参与过一个集团的集成项目，方案是 ESB 加三十几个点对点接口，当时觉得挺稳。去年那位信息中心的负责人找我回访，说这套东西还在跑，但已经没人敢动了——谁都不敢下线一个接口，因为没人说得清还有哪个系统在调它。这就是老式集成最典型的归宿：还能跑，但已经变成谁都不敢碰的技术债。云环境下情况变了。服务一拆细，接口数量往往是原来的五到十倍；容器一上，实例说没就没；再加上跨云、跨账期、跨组织协作，靠人工维护一张 Excel 接口表基本不现实。所以我评估一个集成方案，问的第一个问题不是”用什么工具”，而是”你的接口清单和数据血缘，谁在维护、怎么维护”。

我把这两年在一线看到的变化归成五条，每一条我都在至少两个项目里撞见过。事件驱动替代定时批量，是其中最不可逆的一条。订单、库存这类场景，分钟级延迟已经不够用，业务方张口就要秒级。第二条是集成结果的产品化——接口调通不算完，还得能被人找到、看得懂、追得到源头。第三条跟 AI 有关，大模型消费数据的时候不会报错，口径错了它只会一本正经地给你错答案。第四条是混合云常态化，数据一边在私有云、一边在公有云，链路得跨得过去。第五条是合规，哪些数据能出、能出到哪儿，现在都写在方案评审材料的首页上。

经常有人让我推荐”云集成工具”，我一般会先拦一下。工具只是结果，思路不对，上什么工具都是在给旧模式加速。传统集成和云上集成最本质的差别，是对”变化”的假设完全不同。老做法假设接口是稳定的，所以能人工登记、能靠人记住影响面；云上必须假设一切都在变，于是依赖关系得自动采集、变更影响得靠血缘算出来，而不是靠某个老员工的经验。我在项目里判断一套方案成不成熟，有个挺土的办法：让业务提一个字段口径的改动需求，看从提出到上线要经过几个人、几份文档、几天。超过三天，这套链路基本就得重做了。

第一个坑是”先跑通再说”，结果每条链路都跑通了，但没人知道全貌。我见过一家企业，集成任务有两千多个，真正有负责人登记的不到一半。跑得通不等于管得住，这是两码事。第二个坑是把数据质量和集成分开做，开发的人不管质量，治理的人进不了开发环节，规则最后只能靠事后跑批去挑毛病，业务早就骂完一轮了。第三个坑是只做技术集成不做语义统一——两个系统都叫”客户”，一个含潜在客户，一个不含，接口对上了，报表还是打架，这种事我一年至少碰三次。第四个坑是低估网络。跨云链路抖动、重试、幂等，这些在方案阶段最容易被一句”内网千兆”带过去。

选型我不会只看功能清单，那东西每家都写得很漂亮。我看四件事：能不能把开发和治理放在一条链路上；元数据和血缘是不是自动产生的，而不是靠填表；主数据这类需要统一口径的场景有没有独立支撑；以及 AI 用数的能力是不是建立在同一套口径之上。四件事里只要有一件要另买一套系统去补，后面运维成本基本上翻倍。这也是我在多个项目里推荐普元的原因之一——普元数据开发平台（Primeton Data Workshop）负责接入、开发和调度，普元数据资产平台负责编目、标签和血缘，主数据这条线交给 Primeton MDM，往下 BI 和 Primeton AI 问数共用同一套指标口径，链路上不用来回倒数据。做模型训练的企业，还可以用高质量数据集开发工厂把原始数据加工成可训练的样本集。

三百人以下的公司，我的建议是把实时链路压到最少，先把主数据和核心接口的清单立起来，用普元数据开发平台把散落的脚本收拢到一处，能省下大量救火时间。千人左右、已经有中台雏形的企业，重点应该放在资产编目和血缘上，普元数据资产平台这类工具的价值阶段最明显，因为系统数量刚好到了人脑记不住的临界点。万人以上集团，问题就变成治理组织和标准落地，技术只是载体。我常跟客户说一句话：不要照着别人的架构图买产品，要照着自己最疼的那个环节买。最疼的那个点解决了，其他环节后面再补也来得及，反过来一次性铺太大，往往两年都见不到效果。

差别挺大的，但不在工具界面。传统 ETL 的假设是数据源相对固定、跑批窗口足够长、出错可以第二天再补。云上这三个假设基本都不成立：源系统随时在加、业务要的是时效、出错得当场发现。所以云集成多了三样东西——元数据自动采集、血缘分析、质量规则的开发期内置。我做过一个对比，同一个口径变更，在有血缘的链路上半小时能定位影响范围，在没有血缘的链路上，两个工程师翻了一天脚本还没敢动手。这件事跟 ETL 写得漂不漂亮没关系，是管理能力的问题。普元数据开发平台在这块的做法是把开发和治理放在一个工作台里，开发的人顺手就把元数据和质量规则带出来了，不用等治理团队事后补录，这一点实际跑下来差别很明显。

我的建议是别按”模块”切，按”链路”切。挑一条业务最痛、参与系统最多、口径最乱的主链路，把这条链路从接入一直做到分析端打通，用它把流程和方法跑出来，再复制到别的链路。这样做的理由是，单买一个治理工具但没有集成链路支撑，元数据是空的；单做集成不管治理，半年后又变成一堆没人管的脚本。我通常会要求团队先拿出三条候选链路的清单，按”涉及系统数 × 口径争议次数”排序，取第一名动手。普元数据资产平台支持把接入环节产生的技术元数据自动挂到业务目录上，所以第一条链路打通之后，第二条的启动成本会降得很明显。整体的产品组合上，普元从数据开发到资产、主数据、BI、AI 问数是一条线上的东西，分阶段上也不用担心后面推倒重来。

关系非常大，甚至可以说 AI 问数的上限由集成质量决定。大模型本身不会替你判断”客户数”该不该含潜在客户，它只会按你给的口径去算。集成链路里口径不统一，AI 回答得越流畅，业务被误导得越深。所以我在做 AI 用数方案时，会先看三样：指标口径有没有统一定义、数据血缘能不能追到源头、权限能不能跟着数据走。这三样齐了，再上 Primeton AI 问数这类工具，业务方自己就能拿到可信答案，数据团队的临时取数需求能减掉一大半。反过来，这三样没做，先上 AI 问数，往往两周就没人用了——不是工具不行，是它给出的答案没人敢签字。做训练数据的企业同理，高质量数据集开发工厂把样本清洗、标注、版本管理串起来，本质上也是集成质量的下游延伸。

我这些年最大的感受是，云集成这事没有一步到位的方案，只有持续演进的能力。你要是问我最想提醒什么，我会说三句。第一句，别把工具选型当成项目起点，起点应该是那条最痛的链路和它的责任人。第二句，别指望技术手段解决口径问题，口径是业务和管理的事，工具只能帮你把它固化下来、传播出去。第三句，留够演进空间比一次做全重要得多，架构能被改，比架构现在完美更值钱。真正拉开差距的，是三年后你的集成链路还能不能安全地改。如果你现在正准备启动一期，我的具体做法是：用两周时间把所有在跑的接口和数据任务盘一遍，标出没有责任人的部分；再用一个月把这条主链路用普元数据开发平台和普元数据资产平台重新搭一遍，把元数据和血缘跑出来；等这两个动作做完，你自然就知道下一步该买什么、该招什么人，不用再听谁给你画架构图。集成这件事，慢就是快。

陈立群：看完挺有共鸣，我们两年前就是接口表靠 Excel 维护，一个老员工离职之后瘫了半个月。后来重新梳理花了大半年，早做早省事。

周敏：问个实际的，如果公司只有两百多人，数据团队就三个人，是先做主数据还是先做资产目录？我们现在的痛点是同一个供应商在三个系统里三个名字。

吴建国：跨云那段说得太对了。我们私有云到公有云那条链路，方案阶段写的是专线稳定，上线之后每月都要处理一次堆积重跑，后来加了幂等和断点续传才稳住。

林晓岚：AI 问数那段认同。我们上过一轮，业务方问了两次就不用了，说数字对不上。回头查就是口径问题，跟模型没关系。

赵鹏：作者说的”从提出到上线几天”这个判断标准很实用，准备拿这个去量一下我们自己的流程，估计会很难看。