数据服务：冗灾容错，质量保障

一、UTS工作原理

1、日志模式缺陷：

UTS（统一数据传输系统）之前的数据库同步和ETL转档，大多都是基于操作日志进行的：由数据更新方，或者使用数据库触发器，填写详细操作记录日志，下载程序和ETL读取这些记录来处理相关的数据。这种方式有较大不足：

逻辑缺陷：网络/数据库异常等各种意外发生时，如果不做人工干预，继续处理下条日志，则本条信息将丢失，最终将导致目标数据与预期的不一致；

抗风险程度低：如果目标数据发生误操作（比如误删除），则整个数据体系存在崩溃风险，目标缺失的数据将很难补回来。

2、UTS工作原理：

UTS是基于时间戳技术设计的，通过对比源和目标数据库的时间戳差异，来判断出具体发生了何种操作。具体的判断逻辑和优势如下：

源时间戳	目标时间戳	操作判断
有	无	新增
无	有	删除
有	有，但主键不一致	更新

冗灾冗错，抗风险程度极高：每轮都在比对源和目标的时间戳差异，多删少补，本轮操作失败下轮继续，不怕事故，确保永远不会丢失数据；

简单易维护：不管是同步还是ETL，无需触发器，无需人工维护，无需写代码，一次配置永久有效；

普适性：广泛应用于证券金融行业，尤其一线数据商，常规和个性化需求已经集大成，该踩的雷都有人踩过了。

UTS的常见应用场景有：

二、应用场景一：数据库镜像传输

1、数据库异地传输：

数据商销售数据库给机构客户；

机构购买的数据库，自由多地部署；

机构和数据商，内部的数据库分钟级热备。

传输中，只有UTS的服务器接口暴露给客户端访问，起到了“中间件”的保护作用，源和目标的数据库都安全隐藏在后端；

时间戳冗灾容错的传输理念，确保了目标数据库与源数据库的完全镜像一致：即使目标数据库遭到了毁灭性破坏，也一样会尝试补齐缺失数据；

性能：日线行情表级别全表传输，1小时可以下载2000万条记录以上；日常增量同步检查，秒级完成。

2、数据库异构传输：

UTS通过各种底层的数据库访问技术（OLEDB/OCI/ODBC/MYSQL直连），将各数据库的变更数据整合成统一的中间集格式，再传输到客户端向目标数据写入。标准化的处理方式，兼容了mssql/mysql/oracle/db2等主流数据库交互传输：

异构传输，可以让数据商无视其客户的数据库类型，确保源数据在目标数据最大兼容；也可以让机构采购的数据库，有更多更复杂的应用场景；

异构传输，不以牺牲性能为代价，不同数据库间的传输，照样支持每小时数千万条记录级别的同步；

3、数据库集采与分发：

只要有时间戳，UTS就能将数据线路全部串接起来，数据可以一路传输下去。以机构为例，通过UTS，可以整合各数据源，生产自己的数据中心；生成好的数据，可以热备同步或分发到下个应用场景：

三、应用场景二：ETL数据转档

常见的ETL数据加工，有两个痛点：

工作量大，需要有开发团队支持，才能将各种复杂的多库合一/多表合一/一表拆多等等应用需求进行编码表述；

维护复杂，不仅需要维护需要的日志体系，还需要有专人职守监测ETL运行状态；如果出故障，如何补齐丢失数据将是一件非常头痛的工作。

UTS就不用那么麻烦，其支持的视图同步简单粗暴的可以替代绝大多数ETL工作：

不用关心数据的具体处理步骤，只需要在源库写成视图，将各种多对一/一对多逻辑写清楚，UTS传输一次，在目标数据库就成为真正的表；

无需触发器，无需代码编写，极大的简化了维护和设计工作。也让ETL的实施成本和运维至少下降一大半，传统开发人员才能干的ETL工作，将主要由数据库dba承担。

最关键的，能分享到UTS绝对不丢失数据的优势，极大的提高了ETL转档的稳定性；

四、应用场景三：数据稽核

通过对比源和目标数据库时间戳的差异来进行同步，无形之中正好满足了机构的监测刚需：不用触发器和日志便可发现数据的所有变化，能广泛适应各种数据库环境，能普遍支持各大数据厂商的数据库。

所以新版UTS在较老版UTS同步速度提升6~100倍的基础上，加入了数据稽核的功能，为机构数据质量监测提供强有力的底层支持：

1、数据质量判断标准：

没有权威的信源作对比，如何判断数据的质量高低？UTS的思路是，将数据的修改和删除统计作为数据故障的参考：作为数据商，必然有着大量的客户在广泛使用，如果数据有差错，总归会有人反馈和投诉，倒逼数据商修正数据。如果数据商发布过来的数据，经常性的反复修改和删除，说明其生产流程有待提高，而机构使用这些经常出故障的数据，也要做好防雷的心理准备；如果故障率极低，说明其数据质量的过硬；

通过监测和统计修改/删除的数据故障率，就可以得出比较直观的结论：该数据商的数据质量到底高低如何。在选择使用同类型数据商数据的时候，也能做到扬长避短，最大可能的提高机构自身数据中心的质量；

精确到每条记录每个字段的变化明细，也给机构提供了扯皮的底气：）有理有据的数据质量报告，倒逼数据商将数据质量作为自己的生命；对于一些直接涉及投资的关键核心数据，下份合同签订时，也能有更多的数据做参考依据。

2、质量监测实现机制：UTS传一遍

UTS通过对比源和目标数据的时间戳差异来判断具体的数据变化：源头有目标没有的数据，说明发生了新增操作；源头没有目标有的，说明发生了删除操作；两边都有但时间戳不一致，说明发生了修改操作；

如果数据厂商本来就是用的UTS下载，那在下载的时候就可以直接生成数据更新明细；如果数据厂商使用其他工具或者老版UTS下载，那就再传一遍，将下载下来的数据，同步一次到镜像库，照样可以判断出发生了什么操作；

汇总统计所有表的故障率，即可得出相应的结论；详细分析每次修改和删除是对哪些数据和字段做的修改，直接解剖数据（商），想不知道数据商的质量都难了：（如下图，首次入库，16：18分的数值是2086.0250，到20：28分修改为2086.0247，以前可知？）

五、信创支持

基于安全的考虑，操作系统和数据库平台，国产化在未来将成为机构必选甚至是唯一的选择。UTS也做了相应的准备：

支持windows和linux跨平台，协议统一；

支持统信麒麟等国产操作系统；

支持达梦/巨杉等国产数据库。

安全上，支持反调试和反注入等防黑功能。

六、硬件需求

UTS采用C++开发（windows的vs2022，linux的gcc，一套代码跨平台自适应），数据库引擎均采用最底层但最高效的接口，所以对机器性能无特殊要求：

内存8G起，建议16G；磁盘空间取决于数据库需要的存储空间；双核CPU足够UTS运行：总而言之，即使最低配置的服务器甚至台式机，都不会影响UTS的稳定同步传输；

上述配置，单机可以支持100个数据库客户的同步下载；

每小时能同步2000条日线级数据。只要索引有效，UTS在分钟级别能检查完毕1000张表的常规数据更新。