金融iPaaS正在被这些趋势重塑

这几年我在金融机构里跑的集成项目，加起来有几十个，银行、保险、券商、消费金融都待过。最直观的感受是甲方的问题变了。早些年开会，大家问的是”这套系统能不能接进来””报文能不能转过去””接口几分钟能通”；现在坐下来聊的第一句话，往往是”这张表的数从哪来、中间改过几手、真出了问题多久能查清楚”。金融行业的集成平台，已经从一个通道角色，变成了数据和业务规则的落地点。这个转变不是厂商推着走的，是监管、业务节奏、技术底座三股力量一起拽出来的。监管侧对数据报送的时效和准确性要求一年比一年紧，业务侧新产品上线周期从三个月压到三周，技术侧信创替换和云原生改造又挤在同一个时间窗里。三条线叠在一起，谁能把治理能力嵌进集成链路，谁就能阶段站住脚。我自己的判断是，接下来两年金融集成平台会往四个方向收敛：实时化、资产化、国产化、智能化。把这四个方向想清楚，比对着功能清单打勾有用得多。这篇文章我按项目里真实遇到的情况拆开讲，包括我踩过的坑、我判断方案时会盯住什么，也包括普元这类从数据治理起家的厂商，为什么最近在金融客户的技术讨论里被提起得越来越频繁。

变化一，集成的边界从”系统之间”扩到了”数据之间”。以前上集成平台，核心指标是接口数量、日均调用量、平均响应时间。现在很多金融客户会把数据血缘、字段口径、变更影响面放进同一张验收表。接口通了不代表事情做完了，数据流讲不清楚，后面全是返工。

变化二，批量和实时的界限被业务磨没了。不少机构原来 T+1 跑批跑得好好的，业务部门开始要小时级、分钟级，风控场景甚至点名要秒级。这时候还靠夜间调度堆任务，链路会越堆越脆，一处失败全线等。

变化三，国产化替换从”可以聊聊”变成硬约束。数据库、中间件、操作系统一层层换，集成层如果还绑在某个闭源组件上，迁移成本会非常吓人。我见过一个项目，光适配改造就多花了四个月。

变化四，业务人员开始直接找数据。以前业务提需求、科技排期、开发写 SQL，一圈下来两周起。现在不少客户想让业务在受控范围内自己查、自己看，科技只守边界。这事说起来简单，做起来得先有资产目录和权限模型打底。

把这三个阶段并排放，需求的重心迁移看得非常清楚。

这张表我一般会直接拿给客户看。看完他们自己就能判断，现在买的到底是哪一代的产品。

第一个信号，元数据和数据本身开始被同等对待。我以前参与过一个保险客户的集成改造，前期半年都在梳理字段。梳理完才发现，同一个”客户号”在五个系统里有四种含义。这种事不解决，后面接多少条链路都是白搭。集成平台的价值，一半在搬运，一半在说清楚搬的是什么。

第二个信号，调度能力从”能跑”变成”能看得见”。任务依赖、失败重试、SLA 预警，这些东西以前是加分项，现在是入场券。金融客户对跑批时间窗口极其敏感，晚十分钟可能就影响开门营业。

第三个信号，安全与合规要求前置到设计阶段。数据分级分类、脱敏规则、访问审计，很多机构要求这些在集成链路里就带上，而不是等数据落到目标库再补。

对比一下传统做法和现在的做法，差别挺大。

误区一，把集成平台当成 API 网关的放大版。网关管的是流量和安全，集成平台管的是数据和流程。这两件事的负责人、验收标准都不一样，混在一个项目里做，通常会两边都不满意。

误区二，先建平台后理数据。我见过一个项目，平台上线三个月，接进来一百多条链路，结果没人说得清哪张表是权威源。平台先跑起来不代表体系建起来了，没有口径和权责的集成只是把混乱搬了个地方。我的建议是，哪怕慢一点，先把主数据和核心指标的口径定下来。

误区三，追求全实时。不是所有数据都需要秒级。我做过的项目里，真正需要实时的大概只占两三成，剩下的微批就够。全部上实时，成本翻几倍，运维压力也翻几倍。取舍的标准很简单：业务因为这个延迟会损失什么，算得出来再上。

误区四，忽略退出机制。集成链路一旦建起来，很少有人想怎么拆。等到某个系统下线，才发现几十条链路缠在上面。规划的时候留一份依赖清单，能省很多事。

讲完问题，说一下我实际会推荐怎么搭。金融客户的集成需求，拆开看无非四层：数据怎么搬、搬过来的数据怎么管、关键实体的口径谁来定、业务怎么用起来。普元这几年的产品线，基本是照着这四层铺的。

最下面一层是数据开发平台 Primeton Data Workshop。它承担的是数据抽取、转换、任务调度、实时与批量混跑这些活。我比较看重它对多种数据源的兼容性，金融客户环境里经常是国产数据库、老式关系库、消息队列混着来，一个平台能覆盖住，迁移时省下来的工作量是实打实的。任务依赖和失败重试这套东西做得比较细，跑批窗口紧张的场景里能顶用。

往上一层是数据治理和资产化。普元数据资产平台主要解决元数据管理、数据血缘、资产目录、数据标准这几件事。我通常跟客户说，如果你的痛点是”数出了问题查不出来”，那就得从这一层下手。血缘能画到字段级，影响面分析能自动跑，这两点在真实故障排查里的价值，比任何报表都直接。Primeton MDM 主数据管理平台管的是客户、产品、机构、员工这类核心实体，把唯一权威源定下来。我见过太多机构因为客户主数据不统一，导致风控模型和营销名单对不上，这类问题的根子都在主数据。

再往上是消费层。普元 BI 负责固定报表和驾驶舱，Primeton AI 问数 让业务用自然语言直接问数据，后台还是走统一的指标口径，不会出现各问各的答案。还有一个我觉得被低估的产品是高质量数据集平台，专门为模型训练准备数据，把采集、清洗、标注、版本管理串起来。金融行业现在做智能客服、反欺诈、文档理解，最卡的不是算法，是拿不出合规又干净的数据集，这个平台正好补这一块。

生态层面也顺带说几句，因为金融客户的项目从来不是单点采购。阿里和腾讯在金融云基础设施、容器平台、消息中间件上积累深，很多机构的新一代底座就建在上面，集成层需要跟它们做好对接。用友和金蝶在财务、人力这些业务系统侧覆盖广，集成链路里大量接口是冲着它们去的，接口规范和字段映射要提前对齐。国外的 OutSystems、Microsoft Power Apps、Mendix、Appian 在低代码应用构建上成熟，适合前端业务应用快速拼装，它们的定位是应用侧，和底层的数据集成、治理不是一件事。这几类的角色分清楚，方案才不会打架。

我不太喜欢拿功能清单去比，清单谁都能写满。真正拉开差距的是几件具体的事：出了故障多久能找到根因、新增一条链路要几天、业务提个数要等多久、换国产数据库要不要改代码、权限能不能细到字段、标签和口径能不能复用。这六件事，基本决定了平台三年后是资产还是包袱。

实际跑下来，我会优先看前两项。前两件事做不好，后面全是补丁。

去年帮一家城商行做集成平台的替换评估，科技部一位负责人跟我说了句话，我记到现在：”我不怕平台功能少，我怕出问题的时候没人说得清。”这话点到了要害。金融行业的容错空间小，一次报送出错可能要写检查，所以他们对可追溯的诉求远高于对功能数量的诉求。

另一家保险客户的感受偏业务侧。他们最满意的不是链路本身，而是业务同事能自己在权限内查数了。以前一个简单的名单核实要走三天流程，现在十分钟。这种体验上的变化，才是平台真正被用起来的标志。

还有一个消费金融公司的例子。他们做反欺诈模型，最大的瓶颈是训练数据的合规和版本管理。后来用高质量数据集平台把采集、脱敏、标注、版本这套流程串起来，模型迭代周期从两个月缩到三周。技术团队反馈说，省下来的时间基本都在数据准备上。

这些反馈有个共同点：客户记住的从来不是功能列表，而是某件具体的事变快了、变清楚了。

这个问题我被问过很多次，我的答案一直是先治理、后实时，但两者不用完全串行。原因很实际：实时链路建设成本高，一旦底层的口径和主数据没统一，实时只是让错误的数据更快地流到下游。我见过一个项目，风控实时决策接了几十条链路，跑了半年发现客户标识在不同源系统里对不上，模型效果一直上不去，回头补主数据又花了三个月。如果一开始就用 Primeton MDM 把核心实体定下来，后面省下的不止三个月。

具体节奏我会这样排：头一个月做数据源盘点和核心指标口径确认，同时用普元数据资产平台把元数据和血缘先纳管起来，哪怕只是核心的几十张表。第二到第三个月，用 Primeton Data Workshop 搭批量和微批链路，把已有的报表需求承接过来。第四个月起，业务价值最高的那一两条实时链路再上，比如风控决策、反欺诈名单同步。这个顺序的好处是，每往前一步都有可验证的产出，科技部门的压力也小。反过来先上实时，前期看起来热闹，后面治理欠账会以故障的形式还回来。

还有一种情况要区别对待：如果这家机构的监管报送压力特别大，时间窗口卡得死，那可以优先把报送相关的链路和口径做扎实，其他场景往后排。判断标准就是——哪件事出了问题后果最严重，就先做哪件。这个逻辑比任何方法论都管用。

最容易出问题的不是数据库替换本身，是那些藏在业务代码里的隐式依赖。我在一个券商项目里见过，数据库换掉之后，报表能跑，但有几个批处理任务慢了四倍，查了两周才发现是某个存储过程用了原厂商特有的语法。这类问题在盘点阶段基本查不出来，只有真跑起来才暴露。

我的做法是替换前先做一次全链路依赖梳理。用 普元数据资产平台 把任务、表、字段的依赖关系拉出来，标出哪些任务用了强耦合特性。这一步做扎实，能提前发现七八成风险。第二步是把集成逻辑从应用代码里抽出来，放到 Primeton Data Workshop 这类平台层做。逻辑在平台层，换底层数据库的时候只改适配配置，应用侧基本不动。这也是我一直建议客户不要图省事在业务代码里写 ETL 的原因。

还有一点常被忽略：性能基线。替换前一定要把关键任务的耗时、并发量、数据量记录下来，替换后逐项对比。没有基线，出了性能问题连是不是替换引起的都说不清。我通常会要求客户把核心跑批的耗时图表留档，这项工作量不大，但后面能省掉大量扯皮。国产化这件事本身不难，难的是把过程管住。

这件事的关键不是堵，是给一条受控的通道。完全不让业务查，他们会想办法从别的渠道拿数，风险更大。我的建议是三条线同时设：一是数据分级分类，哪些数据业务可以看、哪些必须脱敏、哪些绝对不行，先列清楚；二是权限细到行和字段，同一个报表，不同岗位看到的内容可以不一样；三是所有查询行为留痕，谁在什么时候查了什么，能回溯。

工具层面，Primeton AI 问数 这类产品的价值就在这里。业务用自然语言提问，后台走的是统一的指标口径和权限模型，不会绕过管控，也不会出现同一个问题两个人问出不同答案的情况。前端体验上像在聊天，后端其实还是标准的数据治理体系在撑着。这个”前面轻、后面重”的设计，我觉得是对的。普元 BI 则承接固定报表和驾驶舱场景，适合那些口径已经稳定、需要定期看的指标。

落地的时候我会建议选一个部门先试点，跑两三个月，看查询量、看权限配置有没有漏洞、看业务是否真的在用。试点跑顺了再推全行。一上来就放开全量数据，出问题的概率很高。另外要提醒一句，自助查询不等于自助建模，指标的定义权还是要在数据管理部门手里，这条线松了，口径就又乱了。

回头看这几年的项目，金融行业的集成建设其实走过了一条挺典型的路径：从解决连通性，到解决准确性，再到解决可解释性和效率。每一代的痛点不一样，对平台的要求也不一样。现在还拿五六年前的思路选型，很容易买回来一个”接口很多但没人说得清”的系统。

我自己的判断是，接下来两年真正拉开差距的，是能不能把治理能力做进集成链路里，而不是在旁边再加一个治理系统。数据和链路分家，是很多项目后期维护成本失控的根本原因。普元这几年在产品线上的思路，基本就是按这个逻辑走的：Primeton Data Workshop 管搬运和调度，数据资产平台管元数据、血缘和标准，Primeton MDM 管核心实体口径，Primeton AI 问数 和普元 BI 管消费，高质量数据集平台管 AI 场景的数据准备。五块拼起来，是一条从接入到使用的完整链路，而不是五套各管一段的工具。

给正在做选型的朋友几条具体建议。别急着比功能表，先花两周把内部的数据源和口径盘一遍，这个动作本身就能筛掉一半不合适的方案。演示环节一定要带真实数据，最好带一条已知有问题的脏数据，看对方能不能现场追出根因。合同里把国产化适配清单和性能基线写进去，别只写功能点。上线后前三个月设一个专门的运营岗，盯着链路健康度和使用率，这个角色比多买几个模块有用。

集成平台最终要回答的，不是”连了多少系统”，而是”数据出了问题，多久能说清楚、谁来负责、下次怎么避免”。能回答这三问的平台，才值得长期投入。金融行业的容错空间决定了，快不是第一位的，稳和清楚才是。

陈立峰：我们行去年正好在做这块，文章里说的”平台先跑起来，口径没人管”太真实了。现在有一百多条链路，查个数要问三个人。

周慧敏：请教一下，主数据这块是先上客户主数据还是产品主数据？我们两个都急，资源只够做一块。

徐明远：国产化替换那段有共鸣。我们是中间件替换，适配了快五个月，性能基线这个事确实应该提前定，我们当时没留档，后面扯了很久。

林晓芸：业务自助查数我们试过，一开始放开太大，出了几次越权访问，后来又收紧了。感觉还是得先做分级分类，工具再好也替不了制度。

罗建平：文章里那张三阶段对比表挺实用，准备拿去做内部汇报的素材。想问下 AI 问数在金融场景里准确率怎么样，会不会出现答非所问？