9 月 21—23 日，第一屆“金融現代化 IT 基礎架構轉型論壇（FinTech Infrastructure Wave 2022）”成功舉辦。該論壇由中國資訊通訊研究院雲端計算與大資料研究所、《中國金融電腦》雜誌社主辦，北京志凌海納科技有限公司（SmartX）與北京鯤鵬聯合創新中心協辦。論壇分為三大專場，覆蓋銀行、保險、證券、基金、期貨、信託六大金融細分行業，內容涵蓋多雲平臺建設、核心業務系統自主創新轉型、超融合關鍵場景落地、核心業務 K8s 改造、資料中心零信任安全、基礎設施即程式碼等前沿話題。

資料庫領域資深專家韓鋒發表了《金融行業資料庫自主創新之路》的主題演講。

文丨韓鋒

本文圍繞資料庫技術發展趨勢，結合金融行業特點闡述金融行業資料庫自主創新之路。

一、資料庫創新驅動因素

金融行業資料庫自主創新的驅動因素既有外部因素影響，也與自身發展有著密不可分的關係。總的來說，驅動金融機構進行資料庫自主創新的關鍵因素主要包括以下幾個方面。

一是供應鏈安全。金融行業關係國計民生，其基礎軟體的安全性至關重要。那麼什麼是真正的安全？如果專案中使用的是開源產品，又該如何保證供應鏈安全？筆者認為，保證安全的一個要點就是自主創新，無論是選用商業產品還是開源產品，都必須將核心技術掌握在自己手中，這樣才能做到真正的安全。

二是滿足金融合規要求。金融業是資料密集型行業，大量業務依賴於資料的產生與流轉，對資料的敏感度非常高，同時，金融業的資料通常也具有很高的價值，這些都對資料本身的安全性、穩定性和可靠性提出了非常高的要求。作為國家重點監管的行業，金融業必須滿足金融合規要求。

三是業務創新需求。近年來，金融業務正在悄然發生著變化，以銀行為例，過去傳統的網點人工放貸形式正逐漸被線上銀行、手機銀行、數字銀行等多種線上放貸形式取代，這些新興業態都對底層的資料基礎設施提出了更高要求。

作為基礎軟體的重要組成部分，資料庫被要求承載更多能力，包括分散式、混合負載、多模、智慧應用等，這些都是金融業務在金融創新的大背景下對底層資料庫提出的新能力要求。

二、資料庫的創新改造

筆者認為，資料庫的創新改造可分為四個階段：一是架構選型評估階段，主要是完成技術棧選型，並開展技術棧培訓，完成資源評估。二是研發測試階段，主要是完成業務系統的改造及測試，也是整個階段中耗費成本資源較多的一個階段。三是驗證並行階段，主要是在完成業務系統改造後，對新平臺的功能、穩定性、可用性等進行驗證，保證後面的替換順利進行。四是上線支援階段，主要是在系統經過充分驗證後，將業務系統從原技術棧完全遷移至新技術棧，這一階段的重點工作是提供遷移能力及運維保障。

1.架構選型評估的痛點及其解決方案

（1）技術棧分散

痛點

技術棧分散，尚未形成選型標準，使用者選型困難。在生態相容性上，有相容 MySQL、PG、Oracle、自有標準等；在架構上，有單機、集中式、分散式等，包括以 NewSQL 為代表的產品；在部署平臺上，有私有部署及雲端部署（含私有云、公有云）等。

解決方案

解決上述問題的思路是，首先需統一企業內部的資料庫生態，明確採用如 MySQL、PG 等為代表的事實標準生態。針對同生態產品（如 MySQL 生態的 TDSQL、GoldenDB、TiDB 等）提供標準能力相容支援；針對異構生態產品（如 Oracle、DB2）及 MySQL 或 PG 生態，提供等價改寫、異常處理（前提是收斂異構間資料庫差異，規範標準寫法）。

其次需統一企業內部的資料庫協議，可透過標準的 MySQL 或 PG 協議訪問多種異構資料庫。例如透過標準 MySQL 協議接入，底層可對接不同資料來源（如 Oracle、DB2）。這種統一接入管理方式，對企業內部資料庫管理帶來極大便利。

面對企業內部多資料庫產品並存的情況，需從全域性視角出發擬定資料管理策略。傳統豎井式的管理方式在現有碎片化現狀下將更加困難，可考慮建立資料標準管理層，將常用的資料管理職能（如訪問安全、資料加密）等統一處理。

（2）產品能力層次不齊

痛點

當前，自主創新的資料庫產品能力層次不齊，不同產品間功能差異明顯，包括核心層面、周邊生態層面及管理維護層面等，這使得使用者無法使用統一的服務介面。此外，在雲產品選擇上，使用者的自主權不高，存在與原有方式的管理差異。

解決方案

針對以上問題，企業可以增強資料庫及周邊生態的能力，如針對單機資料庫短板，透過引入中間層解決分散式能力，在不改變底層技術棧的情況下，提升資料庫的上限能力；加強雲適配能力，遮蔽底層變化和管理方式的差異。

2.研發測試的痛點及其解決方案

（1）原系統遷移評估難

痛點

在實際工作中經常會面臨一類問題，就是當舊有系統已無人瞭解或乾脆由第三方開發的時候，將會缺乏有效的手段去收集、評估存量業務改造的工作量。

解決方案

這類問題可利用源系統評估工具解決。它不僅能提供資料庫評估工具，實現抓取資料庫的語句、負載，支援回放能力，同時針對資料庫特有的方言、函式等個性化需求改造內容，可生成報告方便工作量評估及改造工作。當然，如果沒有工具，透過調研表的方式也可以進行對之前情況的評估。

（2）遷移過程成本高

痛點

很多應用系統嚴重依賴原有技術棧，如以 Oracle、DB2 為代表大型商業資料庫，應用端對商業資料庫方言、庫內計算（儲存過程、觸發器、函式等）、生態工具（SQL 最佳化、資料整合、管控維護）等都存在較重依賴情況，而新技術棧產品差異明顯，透過應用研發改造，工作量極大。同時，大量基於商業資料庫的開發邏輯需改造遷移，一部分需改造適應新架構資料庫，一部分需考慮在異構平臺（如大資料平臺、快取平臺）或應用層解決。此外，部分改造內容不等價實現，提高了改造難度。

解決方案

為滿足在新技術棧下的開發需求，需秉承在架構選型階段談到的資料庫訪問標準層的理念，簡化對資料庫的使用。對於重度依賴原有系統的，需提供一種方式將舊邏輯向新邏輯轉換，這點是比較難的，通常很難做到完全的等價轉換。目前，有些工具已經能夠實現將複雜的庫內計算（如儲存過程、觸發器等）轉化為業務語言（如 Java），可大大加速轉化程式。當然，更為重要的還是將兩者的差異充分暴露給開發者，讓技術人員有的放矢地去改造，明確知道潛在的工作量。此外，可提供一些諸如資料整合、資料管理、SQL 診斷最佳化的工具，在改造過程中提高開發效率。

還可透過以下兩種手段進一步減少改造工作量，一是提升目標平臺對源平臺的相容效能力，二是透過中間層實現必要的改寫，自動完成不相容改造。針對第二個方面的訴求，可以透過第三方平臺實現，它可相容新舊平臺的語法，同時完成等價轉化；針對不能轉化的部分，給出異常提示，配合前面的改造改寫工具完成內容的修改，不斷收斂兩者的差異。

（3）遷移結果評估難

痛點

很多新架構產品提供的相容效能力存疑，僅透過語法層面的相容或少量改造，很難保證語義上的一致性，這種不確定性會增加系統上線後的風險；同時，缺乏有效的評測手段評估遷移結果，難以有效評估應用遷移前後的語義等價（資料一致性）及效能等。

解決方案

針對上述痛點，可利用遷移結果評估工具，該工具能提供一種驗證執行結果的機制，包括但不限於對執行結果一致性的檢查、執行效率的檢查等，可有效降低系統上線後的風險。

3.驗證並行的痛點及其解決方案

系統驗證階段是很多重要系統正式上線前必須經歷的階段。透過上線前的驗證，可以大幅降低系統可能存在的技術風險，提高上線成功率。系統驗證階段的痛點主要包括以下幾點。

（1）遷移風險高，無法回退

痛點

為了驗證系統是否工作正常，一般需要開發大量驗證類的程式碼。這部分工作主要是為了滿足系統對新舊技術棧及必要的對比等工作的支援，工作量往往很大，如很多應用常見的資料雙發邏輯，透過資料雙寫同步驗證兩邊執行結果，為滿足這一訴求，不得不在原有業務邏輯上開發兩套適應不同技術棧的程式碼。

解決方案

可利用資料雙寫平臺解決上述問題。資料雙寫平臺提供基於中間層的輕量級實現方法，在應用側無需改動或少量改動程式碼，即可完成資料的雙發寫入，滿足資料同步寫入到異構平臺中。為保證資料的一致性，還需提供必要的事務性保證，保證異構資料庫間資料的一致性。當一方平臺出現異常時，應可自動回退，不影響另一套平臺正常使用，能從前端業務自動感知這一變化，可自動適應這一過程，使業務無感，但系統修復後，又可以手工新增回雙髮狀態（需提供異常期間的資料補償能力）。這一思路的難點在於如何實現在應用程式碼邏輯不變的情況下支援寫入異構庫。常見的思路是將資料庫的互動語言 SQL 從一種方言翻譯成另一種方言，前提是語義等價。此時，就可以參考之前在架構選型階段談到的資料庫訪問標準層，收斂企業內資料庫的訪問，儘量簡化、標準化對資料庫的使用，這也是雙發驗證階段可執行對比的前提。

（2）遷移驗證，無從下手

痛點

在系統驗證階段，還有一個比較難的地方在於如何驗證。最好的驗證方式是帶著真實流量進行驗證，但同時還需考慮風險問題，以及如何對業務訪問做好精準的控制，按需求進行業務驗證，且還需提供必要的回退能力保證安全，如常用的基於讀寫的分配、基於流量的分發（甚至基於業務特徵的分發能力）。

解決方案

可利用流量分發平臺解決上述痛點。流量分發平臺滿足在多平臺線上情況下根據策略分配業務訪問，可精準地控制其流向，如痛點中提到的讀寫流量、比例流量抑或是帶有業務特徵的流量，可感知下方物理拓撲變化（甚至是異構平臺間的變化），可對應做流量重分發，不影響業務正常執行。這種方式會為上層應用帶來很大的靈活度，可根據需要隨時調整驗證策略，降低驗證期間的風險。

4.上線支援的痛點及其解決方案

（1）遷移視窗短，遷移困難

痛點

在系統上線階段，遷移視窗期普遍很短，這就需要在較短的時間內完成資料庫間（一般是異構）的資料遷移工作，同時還需針對遷移後的資料進行質量對比，以保證遷移資料是正確的。

解決方案

可採用離線上遷移工具解決這一問題。該工具支援異構資料來源間的資料離線上遷移，可充分利用物理資源，採用並行處理技術提升遷移效率，滿足時間視窗要求。海量資料的遷移通常採用離線與線上相結合的方式，即將靜態資料透過離線方式遷移，動態（活躍）資料採取線上方式遷移。此外，還需提供資料對比能力，可根據使用者需要進行比對。這存在兩個難點：一是如何提升對比效率，滿足海量資料對比需求；二是如何實現動態變化的資料對比。針對前者，通常的解決思路是可以讓使用者選擇對比方法（演算法），如簡單計數、部分取樣、統計報表或複雜演算法；針對後者，可透過流式視窗比較的方法不斷擬合趨近於實時結果。

（2）新上系統不穩定

痛點

新產品、新架構上線後很難保證一定不出問題。雖然可透過充分的測試、並行驗證等多種手段儘量減少出現問題的風險，但顯然無法完全避免。

解決方案

比較好的方式是提供一種能力，針對可能出現的執行問題，透過一些手段儘量縮小問題的影響範圍，恢復業務。可用流量治理平臺和系統逃生平臺（方案）解決上述問題。

流量治理平臺支援資料庫流量的統一接入，可透過多種手段（基於標籤、SQL 文字、使用者名稱、來源 IP 等）實現對 SQL 流量的精準控制。例如針對低效 SQL，可實現熔斷、限流；針對特定 SQL，提供黑白名單；為滿足問題排查提供全量 SQL 的審計能力，做到事後追蹤等。

系統逃生平臺（方案）可提供一種異構“逃生”方案，防止出現系統性風險或全域性邏輯性錯誤。所謂異構，一定是一種有別於現有技術棧的平臺或方案，兩套平臺間的資料是需要做到可控同步的，即可根據需要選擇實時同步、延遲同步和人工同步。同時在資料之上，還需提供切換的能力，可滿足在異常情況下短時切換需求。

三、資料庫改造建議

從過去實踐來看，很多業務系統的創新改造比較順利，但對於資料庫的創新改造就比較難。對此，筆者提出以下幾點建議。

一是進行前瞻性佈局。雖然資料庫的技術路線還沒有完全成熟定型，但在技術層面要有前瞻性的佈局，去選擇主流的技術發展路線，採用一些跟隨策略，不斷在企業內部嘗試使用，技術路線都是在企業內部場景中逐步打磨出來的，所以前瞻式的佈局很關鍵。

二是儘量選擇和企業內部建立的生態相相容的標準，這會為企業在後續的調整保留餘地。

三是加強自主創新能力建設，要構建自己的核心能力，且保證這種能力自主可控，這樣無論下面的資料庫如何變化，上層能力都會讓企業在做選擇時更加從容。

四是廣泛合作，無論是引入廠商還是開源專案，透過展開合作，都能快速提升企業的技術能力。

五是做好風險評估，要有預案，能夠在整個過程的各個階段提前預測問題，並提前部署解決方案。

韓鋒，dbaplus社群聯合發起人，CCIA（中國計算機協會）常務理事、Oracle ACE，曾擔任多家公司首席 DBA、資料庫架構師等職務。具有豐富的一線資料庫架構、設計、開發經驗，精通多種關係型資料庫，包括 Oracle、MySQL、GreenPlum、Informix 等，對 NoSQL 及大資料相關技術也有實踐經驗。著有《SQL 最佳化最佳實踐》《資料庫高效最佳化》等書籍。