一、背景说明

券商/基金/银行等金融机构的数据中心，基本都外购有数十家各类数据，自有业务每天也在产生海量信息。如何有效管理和使用这些数据，通过数据服务，沉淀数据资产，机构研发和运维部门也在不断尝试和改进。

传统数据中台，是一种中心化应用模式：外购数据直接写入数据仓库；湖仓中数据，主从节点部署，对需要数据的下游场景，授权子节点访问权限。

这种高耦合性的构架，很容易导致死锁等冲突，从而影响系统整体性能。业内头部券商，如G信/海T等，借着信创改造契机，做了较大的结构调整，让数据服务更加稳定可靠：

外购数据不能直接写中心数据，做一层隔离：

• 保护中心数据，尽可能规避库表结构变更/死锁等行径，减少源端数据清洗影响；

• 加强管理，增加机构标准化字段，如更新时间、统一时间戳等；数据清洗，格式转换，满足要求再融合。

• 数据留痕，尤其对已采信数据的再次更新和删除，需要做一些必要的记录，以便在纠纷发生时，能有据可依。

下游具体应用场景，也不能直接访问中心服务器，只能使用分发后的数据：

• 降低耦合，规避单一任务故障所导致的系统整体性能下降甚至崩溃风险；

• 广泛兼容，不管目标应用部署何种数据库（SqlServer、Mysql、Oracle、DB2、GaussDB、TIDB、TDSQL、OceanBase、达梦等等），均可从中心数据同步过去；

• 定制化服务，按需同步：源端多库拆分合并，单表部分字段或记录等。

UTS（统一数据传输系统）作为金融行业被广泛使用的系统工具，在帮助相关机构进行信创改造和构架升级中，积攒了大量经验，能对数据服务提供更好的支持。

二、数据库服务：冗灾容错，高效兼容

1、最大特色：绝对不丢数据。

• 数据强一致性对齐：

实际传输中，多种原因导致更新失败：网络故障、数据库异常、数据冲突等等，甚至事务或异步模式下，结果返回成功但实际更新失败更是屡见不鲜。在异地和异库同步中，单轮同步必定存在数据丢失！这种丢失，不会因为客户的不检查就能否认存在，也不会因为失败时多重复几次操作就可以解决。

系统构架和管理者还需要考虑更多的异常：数据误删除如何补救。

UTS基于时间戳强制对比的同步模式，即使目标数据本次写入丢失，即使目标数据人为破坏，也能在下轮同步时，自动发现目标库与源库的差异，并增量补齐缺失数据。

• 数据留痕：

UTS通过同步镜像库的方式进行数据留痕：对比源库和镜像库的差异，可以记录数据DML明细。这种镜像+留痕模式，可以确保即使源库发生了删除，也能将误删除数据很快补救回来。

UTS支持源库物理删除映射成目标库的逻辑删除。这让机构对外购数据的操作能一目了然，更是纠纷时的关键证据。

2、极限同步速度：

信创版UTS是批量传输模式，多线程并行同步，抢占式任务处理。一小时能同步日线行情级别表5000万~1亿条，速度是历史版本的10倍以上。可以满足机构灾备、迁移等多种应用场景。

UTS优先增量同步，可以完成机构即时性要求高的，要求在10秒内的数据热备同步需求。

3、兼容所有关系型数据库，包括国产信创：

所有数据库无需逐一版本适配，统一驱动，统一配置方法。

所有数据库之间可以交互同步，最大兼容目标数据库，包括字符集、编码映射、字段类型、字段宽度等等。

4、丰富的行业经验，避免少踩雷：

作为金融行业的老牌同步系统，已经支持各种数据商和机构的更多需求：高可用集群部署、数据库附件字段与附件文件同步保持一致性，内容替换，名称映射，编码映射，脚本执行。。。

冗灾容错是UTS的核心思想，让机构运维对数据同步高枕无忧是UTS的方向，让数据服务更高效更便捷是UTS的一贯目标。

三、数据服务：数据可用不可见

国务院在2021年提出数据服务的一个指导思想：“数据不出域，数据可用不可见”。用API服务（接口服务）替换直接数据库分发，就是其中的一种使用方式。

传统的API接口，都是由开发人员完成的，用Java/Python/C#等语言，外包或者自建团队。UTS的API可以由数据运维人员自己完成：

1、SQL=API

• SQL语法+变量替换，即可完成API的数据接口定义。参数请求和结果返回，都是标准Json格式。

• 记录缓存时间、API版本号、数据分页等，由配置或者请求指定。

• 支持防范SQL注入攻击。

2、碎片化开发

UTS也支持如上图的高级语言（子函数、变量、条件、循环、函数库等）开发API。编码者无需拥有复杂的编程经验，无需精通数据库和网络底层接口，依葫芦画瓢，即可批量提供海量的API。