一、背景說明

券商/基金/銀行等金融機構的數據中心，基本都外購有數十家各類數據，自有業務每天也在產生海量信息。如何有效管理和使用這些數據，通過數據服務，沉淀數據資產，機構研發和運維部門也在不斷嘗試和改進。

傳統數據中臺，是一種中心化應用模式：外購數據直接寫入數據倉庫；湖倉中數據，主從節點部署，對需要數據的下游場景，授權子節點訪問權限。

這種高耦合性的構架，很容易導致死鎖等沖突，從而影響系統整體性能。業內頭部券商，如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。