作為資料基礎設施的重要組成部分，資料庫在其中扮演著重要的角色。近些年來，資料庫整體發展也呈現出較之以往很大的不同。其一、是開源資料庫受到更為廣泛的關注，從多家機構的最新報告來看，開源資料庫無論從產品數量還是受關注程度都超過商業資料庫。開源這一新模式，正成為未來資料庫發展的主流。其二、是雲端計算成為未來主要資源供給方式得到普遍共識。已經有越來越多的企業選擇在雲上構建基礎環境，包括雲上資料庫的發展速度也遠高於非雲環境。據樂觀估計，在未來5~10年雲資料庫將佔據整體資料庫市場的七成以上。此外，對遷移到公有云、使用多雲環境等問題，也普遍被企業所接受。其三、是資料融合趨勢，針對資料多場景應用，使用融合技術簡化訪問，提升效率。作為資料使用高地，金融行業一方面對資料庫有著極高的要求，一方面又面臨很多來自資料新的挑戰，諸如海量規模、高併發、資料安全、實時分析等訴求亟待解決。分散式資料庫的出現，迎合這一發展趨勢，對於金融企業解決上述問題帶來新的解決思路。本文從金融使用者角度入手，對如何選擇分散式資料庫及選型後的最優實踐進行闡述。

1. 金融業資料庫選型背景

隨著企業數字化轉型深入，對於資料使用場景也呈現多元化趨勢，正有越來越多資料被企業利用起來。金融行業作為資料庫應用“高地”，這一趨勢表現更為明顯。同時我們也看到，近些年來資料庫領域也發展迅速，有分散式資料庫、多模資料庫、雲資料庫為代表的產品不斷湧現。這些新興資料庫在特定場景有很好的使用前景。基於上面兩種趨勢，金融行業很多企業都在面臨選擇資料庫的問題。

1).選型技術層面要素分析

從技術角度來看，在資料庫選型中有哪些要素需要考慮呢？下面以近期比較關注的分散式資料庫的選型為例，說明下重點考量的技術要素。

分散式事務

分散式架構，自然會帶來分散式事務的問題。由於需要跨節點的網路互動，因此較單機事務會有很多損耗。隨之帶來的是事務處理時間較長、事務期間的鎖持有時間也會增加，資料庫的併發性和擴充套件性也會受到影響。針對單筆事務來說，分散式事務執行效率是肯定會有降低的，分散式帶來的更多是整體處理能力的提升。

效能

由於分散式資料庫通常使用的二階段提交和各節點之間的網路互動會有效能損耗，分散式資料庫優勢不是單個簡單SQL的效能，而是大資料量的SQL查詢，每個節點會將過濾之後的資料集進行返回，會提升效能，並且分散式資料庫的優勢是併發，大量的SQL併發也會比單機資料庫強大，應用需要做分散式架構的適配，將序列執行機制儘量都改造成併發處理。對於含有需要節點間資料流動的SQL語句的事務，OLTP類的分散式資料庫處理效率一般較差，事務處理時間會較長，事務期間的鎖持有時間也會增加，資料庫的併發性和擴充套件性也會受到影響。建議儘量改造存在跨節點資料流動的SQL語句（主要是多表關聯）的事務。

資料備份

分散式資料庫的一致性保證通過內部時鐘機制所提供的全域性時間戳，所有節點都會遵循該機制，所以備份恢復的增量也是基於全域性時間戳，但是分散式資料庫的備份解決方案最重要的標誌為是否支援物理級的備份，物理級的備份會比邏輯的備份效能吞吐大很多，還有就是是否支援一些分散式備份方案，比如S3協議介面，是否支援壓縮等功能。分散式資料庫基本都具備備份和恢復方案，通常從備節點進行連續備份（全量+日誌），恢復的時候指定節點進行恢復到指定時間點，整個過程可配置自動任務、自動執行。

高可用

分散式資料庫大多都是基於多數派協議，同城雙中心不適合多數派的要求，同城資料級多活建議採用三中心部署。如果同城主備可以採用叢集級的非同步複製，異地建議採用叢集級的binlog非同步複製，建議例項的主備節點設定在同城兩個雙活資料中心，仲裁節點三機房部署；異地災備單獨啟例項與本地例項進行資料庫間同步，也可以將本地備份檔案T+1恢復到異地災備。

資料一致性

分散式資料庫大多都是通過獲取全域性時鐘時間戳，採用二階段提交，可以實現一致性的保證，分庫分表架構對於事務的一致性，需要應用層考慮，比如通過合理的分割槽鍵設計來規避。部分分散式資料庫對於跨節點事務目前還是實現的最終一致，對於全域性一致性讀，一般通過引入類似全域性時間戳的元件統一管理全域性事務，在資料庫選型時可以重點關注廠商對這一塊的實現。如果目前暫時無法提供全域性一致性讀的分散式資料庫，對於要依賴分散式事務“中間狀態”的業務，優先進行業務改造進行規避，其次通過合理的資料分片設計讓其在單節點內完成。

資料分析

分散式資料庫，多采用存算分離架構。針對資料分析場景，需要對資料從下層儲存節點上移到計算節點，這對分散式資料庫提出了更高的要求。一方面可通過運算元下推等技術，減少需傳輸到計算節點的數量；一方面針對匯聚後的結果需要通過流式處理等方式，規避諸如OOM的問題；此外也可採用如MPP等並行處理技術，加速資料分析過程。

2).選型過程問題痛點分析

在選型過程中，會遇到來自以下幾方面的痛點。

一是由於分散式資料庫整體架構還比較新，也是近十年來逐步發展完善的。針對新型架構的諸多特點，包括廠商和使用者還都在不斷摸索積累之中，還需要有個長期實踐的過程。此外，新架構也需要有個逐步成熟完善的過程。
二是大量產品來自國內資料庫廠商，其發展週期相對較短，還需要在產品成熟度、穩定性、周邊生態等方面不斷完善。對於使用者來說，一方面需面臨產品多、技術棧多的現狀；另一方面還需面對成熟度不足等問題，存在較多痛點。
三是近些年金融行業發展迅速，各種新的業態產品不斷湧現，這些對作為底層資料基礎的資料庫也提出了更高的要求。
四是隨著內外部環境的變化，自主可控等問題受到更多的關注。金融行業首當其衝，針對上述問題也需要引起足夠的重視。在資料庫選型問題上，也需要考慮這一因素。這無疑對使用者選擇帶來一定困難。

2. 資料庫選型技術架構

1).分散式路線分析

針對分散式資料庫的發展路線，大體可分為兩種：

分散式中介軟體

這種架構是從中介軟體路線演進而來。其採用儲存與計算分離架構，底層採用標準單機資料庫，副本間基於資料庫主從複製機制。上層承擔計算，並可將部分計算下推到儲存節點執行。這種架構在分散式事務、全域性MVCC等方面，往往存在一定難點，各廠商也有各自解決之道。

原生分散式

這種架構正是受到Google論文影響演進而來。其採用儲存與計算分離架構，底層採用單機庫(不一定是關係型)，副本間採用分散式一致性協議完成複製，支援多數派提交。上層承擔計算，並可將部分計算下推到儲存節點執行。

2).重點需求滿足情況

針對上述遇到的痛點，兩類產品實現邏輯也所有不同。

3). 路線場景分析

從資料使用場景來講，可大致按下面進行劃分：

針對不同的場景，不同分散式資料庫路線產品各有所長。

針對事務類場景下，強調高併發聯機交易、對分析能力要求不高的場景比較適合分散式中介軟體路線產品。
針對事務類及事務/分析混合類場景，既要滿足常規聯機交易場景的同時，還需滿足分析類的一部分能力，這種情況比較適合原生分散式產品。基於原生分散式的 HTAP 資料庫，用一個資料平臺應對規模化交易和實時分析，提升業務決策的時效性，降低資料技術棧的複雜性，越來越多的混合負載需求推動了 HTAP 在金融場景的落地。

3. 金融業 HTAP 應用場景實踐

1). 金融場景下 HTAP 的分析

在金融企業數字化轉型的過程中，各類業務對“海量、實時、線上”的資料需求變得愈發迫切。在金融企業運營場景中，實時推薦、精準營銷是企業提升競爭力的一大因素。在企業風險控制場景中，實時風控、反欺詐等業務開展可以更早地識別和阻斷風險可以讓企業減少損失，HTAP正是基於上述背景誕生出的需求，為各類實時資料處理需求提供瞭解決方案。

2).某金融使用者 HTAP 的架構設計和實踐

隨著金融市場同業業務的蓬勃發展，業務部門對於交易資料的實時統計分析和展現有了急切的需求。基於大資料技術棧的 T+1 報表模式，已無法滿足業務部門通過實時分析交易發生情況來防範風險以及提供決策的需求，迫切的需要找到一種能讓資料實時變現的解決方案。結合金融行業特點，在技術選型過程中，重點考察待選產品如下能力：包括承載業務複雜查詢處理、海量資料容量儲存、應用透明無侵入、開發協議可適配及混合負載下的表現等。經過測試，選擇 TiDB 作為基礎資料庫平臺。通過一段時間上線使用，滿足業務場景，基於其 HTAP 的特性，打造金融市場實時資料平臺，目前已投產了靈活報表和交易對手分析等功能。整個處理流程包括：

·Flink 消費交易系統產生的實時增量資料，對部分事實表進行拉寬處理並寫入TiDB
·維表和其他明細表直接寫入 TiDB
·BI 工具直接連線 TiDB，提供秒級的實時計算和分析能力

這一案例中，構建千萬及以上資料規模、超過五張表的複雜關聯實時查詢能力，讓業務人員在極短的時間內（大部分報表執行時間為幾十到幾百毫秒、個別報表秒級別）獲得實時交易的詳情。

3).未來 HTAP 的場景發展

實時資料處理技術還以某些具體的應用場景為主，從現狀來看以事件驅動類、流式管道資料計算類為代表的場景，已經開始使用 HTAP 場景的。未來隨著 HTAP 計算能力進一步的提升，實時全量資料的計算將帶來更多場景。

4. 面向未來的架構趨勢

1).雲原生

從未來的發展趨勢來看，雲方向是一個大的趨勢。

從上圖可見，雲資料庫的發展經歷了幾個階段，從雲託管、雲服務、雲原生之路。

雲託管，是最接近傳統資料庫系統的部署模式。本質是將原本部署於IDC機房內物理伺服器上的傳統資料庫軟體部署在了雲主機上。這種模式下，雲平臺提供諸如高可用、異地災備、備份恢復、資料安全、SQL審計、效能優化和狀態監測等企業級資料庫管理能力，使用者可減少運維投入即可享受之前同等的服務水平。
雲服務，之前的託管架構中，受限於傳統資料庫架構的侷限，未能完全發揮雲端計算的優勢。在諸如彈性擴充套件、高效能、高可用等方面，均有不足。到了雲服務時代，充分利用雲基礎設施的底層能力，提供定製化的資料庫產品。
雲原生，與之前的雲服務架構不同，這一階段產品將更為充分地利用雲基礎設施的能力，通過多層資源解耦，可享受雲帶來的彈性擴充套件、按需供給、超大規模能力。真正做到了資料庫與雲的深度結合。從長期來看，金融機構逐漸把業務和技術向雲原生演進，實現傳統應用遷移上雲和雲原生改造是重要的方向。在這個過程中需要考慮分散式資料庫對 K8s、微服務應用的支援，提供高效、彈性排程能力，同時需要兼顧開發運維和敏捷度。

2).多雲方向

雲作為未來主流的資源供給方式，多雲必然是企業不得不考慮的問題。多雲通常指金融機構同時採用多種不同的雲環境組合來滿足業務需求的多樣性和金融業監管的要求。如何圍繞資料打造面向未來的多雲 IT 架構，滿足在多雲之間提供資料服務能力，擺脫單一供應商的弊端，是必須考慮的問題。多雲架構對分散式資料庫的考察重點聚焦於跨地域、跨公有私有云、跨本地 IDC 和 K8S 的部署、服務提供與統一運維能力等。

金融業分散式資料庫選型及HTAP場景實踐

相關文章