金融行業作為國民經濟的命脈和樞紐，對底層資料庫的能力要求在不斷提高。具有高性能、可擴展、高可用等特性的分散式資料庫是金融行業數字化轉型的重要支撐。 金融企業如何在不同的應用場景下，做好分散式資料庫的選型和落地呢？本文從業務、技術、行業角度出發，從市場發展到落地實踐，全方位全流程為您剖析分散式資料庫在 ...
金融行業作為國民經濟的命脈和樞紐，對底層資料庫的能力要求在不斷提高。具有高性能、可擴展、高可用等特性的分散式資料庫是金融行業數字化轉型的重要支撐。
金融企業如何在不同的應用場景下，做好分散式資料庫的選型和落地呢？本文從業務、技術、行業角度出發，從市場發展到落地實踐，全方位全流程為您剖析分散式資料庫在金融場景中的應用與實踐。本文將會為您解答以下幾個問題：
- 如何在品目繁多的市場中選擇一款合適的資料庫？
- 從哪些維度去考察資料庫？
- 資料庫遷移過程中需要註意哪些要點呢？金融客戶的訴求是什麼？
- 有無實際的案例可供參考呢？
一、金融業資料庫選型之路
資料庫市場會如何發展，在金融領域首先要看政策與監管。《金融科技（FinTech）發展規劃（2019-2021）》中明確指出要加強分散式資料庫的研發應用。做好分散式資料庫金融應用的長期規劃，加大研發與應用投入力度。韓鋒認為，當前分散式資料庫研發應用的成效就是看金融企業內部是否能夠平穩的推進分散式資料庫的使用。
在我國，資料庫市場起步較晚但發展勢頭強勁，基於國產資料庫的金融科技轉型已不再是難題。但是，品目繁多的資料庫市場和複雜的資料庫技術給金融企業帶來了不小的困擾。如何選擇一款合適的資料庫？從哪些維度去考察資料庫？有沒有參考呢？
選型之前先要瞭解市場上有什麼。基於多年深耕資料庫市場的經驗，韓鋒為大家梳理了資料庫行業及技術的背景，提煉出了目前行業和技術的三大特點，並指出了背後的三大痛點。
1. 碎片化嚴重
數字化浪潮下，企業的數據意識越來越強，數據在企業生產經營的應用廣度和深度都在提升，由此也衍生出豐富的業務場景。
面對豐富的業務場景，市場上很難找到一款資料庫去適配所有的場景。現在的普遍現象是企業在不同的場景下，需要對應不同的產品，來解決相應的問題。且不同的產品提供的技術路線又不盡相同，企業當然很迷茫。由此，在多場景、多形態、多技術棧、多元路線的影響下，整個資料庫市場呈現出來的是一種碎片化狀態。
痛點一：在資料庫碎片化嚴重的背景下，企業如何在紛紜複雜的市場中，找到一款適合公司的資料庫產品呢？
2. 開源 or 商業
從近十年來的全球資料庫流行趨勢中我們不難發現，開源資料庫的流行程度逐年上升，甚至在 2021 年已經超過了商業資料庫。在國內，越來越多的國產資料庫廠商紛紛走向開源。開源對國產資料庫來說意義非凡，是實現彎道超車的最佳拐點。因為資料庫作為基礎軟體，技術門檻相對較高，整體的架構設計也較為複雜。開源則能夠大大降低資料庫的使用門檻，使得越來越多的開發者能夠參與到開源生態中去建設，無論是植根資料庫內核技術上，還是打磨資料庫應用場景方面，開源都能夠加速國產資料庫的普及與使用。
痛點二：對企業來說，開源和商業，到底怎麼選？
從早期的架構選型，到中期的開發部署，再到後期的運營維護，開源資料庫和商業資料庫之間都有非常明顯的差異，需要企業基於自身的業務特點、公司實力從各個維度去評估。
3. 廠商分化
據統計，資料庫賽道上已有 200 多家廠商，並且還有越來越多的國內外廠商參與進行。國內的資料庫市場中可以分成四大類資料庫廠商，扎根資料庫領域多年的傳統廠商、深受資本關註的初創廠商、創新資源交付形態的雲廠商、資料庫上下游的跨界廠商。在國外，可以分為資料庫老牌廠商以及活躍的開源廠商。
痛點三：在廠商分化，百花齊放的資料庫市場中，企業該如何選擇？
企業要對業務場景有明確的認識。資料庫在金融行業的應用非常廣泛，場景非常豐富，而分散式資料庫往往需要有明確的適用場景。因此，選型的資料庫產品是不是適用於這些場景呢？韓鋒認為前提是企業要認識到自己的場景到底是什麼。下圖是金融業資料庫使用場景的簡單劃分，主要包括業務、數據規模、一致性要求、負載特點、分析能力等方面。韓鋒強調，客戶在選型的時候，要明晰一款資料庫是很難甚至是不可能適用於所有場景的。
更進一步地，韓鋒提供了更多維度的考察點，如下圖所示包括性能、擴展能力等多個具體的技術細節上。我們可以看到不同場景下的差異是非常明顯的。韓鋒以數據分片為例，從技術角度上為大家詳細闡述瞭如何考察資料庫的能力。
資料庫是非常複雜的系統工程軟體，在選型時要註意的細節其實還有很多。韓鋒總結了幾個觀點，給企業的選型之旅提供方向。
第一，尊重路線之爭，無關乎技術領先性。最好的資料庫產品是適合企業業務的，而不一定是技術最先進的。選型一定要結合業務，不要寄希望於大一統的方案。
第二，成熟度有待完善，但時不我待提前規劃。分散式資料庫確實是一種新興技術，成熟度有待完善。但企業在這個過程中不能“等靠要”，還是得參與進去，不斷打磨，才能越用越好。
第三，國產資料庫百花齊放，機會無限。這一現狀倒逼企業需要具備清晰的考察標準，嚴格考察市場現有產品，才能最終篩選出真正有實力。
第四，謹慎技術選型，不迷信廠商宣傳。真正選型過程離不開測試，要想對產品有非常全面且準確的瞭解，需要在企業自己的環境中測試，這樣的結果才更具有說服力。
第五，選產品選的是標準。很多企業擔心廠商綁定問題，韓鋒認為這個問題有一部份是相容性帶來的。因此，在選擇產品的同時，我們要關註標準，儘量兼用某個通用協議的產品，相對自由度較大，便於後續更換資料庫。
最後，保留技術敏感度，緊跟時代步伐。資料庫技術迭代很快，金融企業客戶要時刻關註技術發展，基於自身的業務進行思考是否升級。在具體措施上，可以選擇架構前置、謹慎選型，局部試點、多線佈局、掌握主動、自建增強等策略。
二、分散式資料庫在金融場景下的實戰
作者｜王東，南雲鵬
在互聯網金融的大背景下，農商銀行面臨著多重挑戰。具體表現在第三方金融、大型金融機構大幅占據市場；客戶在服務體驗上的要求不斷提升；年輕客源流失嚴重；存款理財等負債資金成本越來越高；線下渠道使用率大幅降低等。
農商銀行這類金融機構普遍承擔著發展落實鄉村振興戰略，推動普惠金融的落地重任，又是支持縣域經濟發展與服務三農的金融主力軍。要想做好普惠金融的工作，金谷銀行亟需藉助金融科技力量來解決上述的難題。經過充分調研，金谷銀行立刻啟動了互聯網金融平臺的建設工作。
金谷銀行表示當時的預期就是搭建一套需 IT 人員配置少、技術力量要求不高，穩定的、管理簡單、高可用、高併發且易於擴展的基礎架構。選型期間重點考慮四個方面：首先是大併發與高可用，在面向互聯網的業務在技術架構上，一定要考慮 7 x 24 小時不間斷業務與交易峰值的場景；其次是易於維護與管理，這與農商銀行自身的特點高度相關。農商銀行普遍存在 IT 基礎薄弱，人力資源有限的問題，因此操作簡單，學習成本比較低的平臺更適合。第三，採用分散式存儲。這是因為集中式存儲成本高、管理難度大、技術要求也比較高。最後是技術選型的前瞻性和架構設計的合理性。
南雲鵬自畢業後就一直在金融機構從事 IT 技術相關的工作，基於 15 年的工作經驗，他整理分享了在傳統資料庫運維管理中存在的一些難題。
-
傳統架構下資料庫版本和種類較多，人員學習成本高，掌握知識泛而不精。因為沒有統一平臺，甲方只能跟著乙方走，乙方提供什麼甲方就被動地接受什麼。
-
煙囪式資料庫，運維自動化程度較低，導致工作及時性差，維護成本高。運維人員在維護資料庫的同時，還要維護操作系統，還要兼顧硬體環境等。
-
日常運維的工作比較繁瑣，所有的操作基本都是人工完成，包括用戶、表空間等等。這些人工操作，存在很大的風險，因為出錯率比較高，難以形成統一的標準。
-
集中式的架構橫向擴展能力較差，面對性能不足、容量不足、空間不足等場景，用戶能做的只有增加 CPU、增加記憶體、增加存儲或者換機器的方式。但這些解決方案都無法保證業務的連續性。
-
集中架構下高可用性也難以保障，業務服務能力完全依賴於高性能的主機，一旦主機出現問題，解決方案將十分複雜，對開發人員的要求也比較高。
此外，在數據備份恢復歸檔管理、統一監控管理和運維標準上都存在著困難。這就導致運維工作雜亂、繁瑣，基本上遇到一個事情是一套方法，或者一套臨時性的方案應對。
在運維架構設計的過程中，金谷銀行結合實際的業務需求制定了一套合理合適的運維架構，幫助規範日常工作，同時滿足監管要求。
運維整體架構分成基礎環境層、規範制度層、業務層、工具平臺以及監控層。最底層的工作包括業務如何落地、運維架構如何搭建、如何開展相應的運維工作、如何減少系統的異常場景以及如何保證業務系統的連續性等。基礎環境依托在騰訊雲平臺上，在這個基礎上金谷銀行制定了自己的規範與制度。
在規範制度層，金谷銀行針對操作系統中間件、網路配置、資料庫等日常基礎的標準環境，制定了相應的機械性與規範性的文件。這樣能夠保證所有的業務系統，儘可能地在一個安全、規範的環境下開展運維的工作，也減少運維人員日常的管理難度。在容量管理、問題管理、應急管理等領域，金谷銀行也制定了相應的制度。這些制度一方面保證了資源的合理利用，另一方面也幫助銀行內部進行知識沉澱。
在業務層主要是做一些部署和集成的工作。在此基礎上，金谷銀行構建了工具平臺，包括堡壘機、運維管理平臺以及自動化發佈工具。堡壘機是日常運維操作的一個入口，所有對後端業務系統的操作都是通過堡壘機進行的；運維管理平臺是對資源進行管理，比如資源的增加或減少以及對物理主機的管理等；Jenkins 是自動化開源發佈工具，負責日常系統的變更、生產版本的發佈以及發佈完的結果反饋。
運維監控平臺的構建納管了所有業務的監控，主要建設了系統監控平臺、業務監控平臺以及行為監控平臺。其中，系統監控平臺監控著物理主機 CPU、記憶體等物理信息、基礎信息等，同時監控了一些業務系統的服務埠，比如說開啟 7001、8003 等，保證業務是健康存活的狀態。如果業務埠宕掉了，也會有及時的簡訊告知等；業務監控平臺是偏向於交易類型，比如說熱點事件、大量的訪問行為或攻擊行為等，確保系統不被羊毛黨、黑灰產惡意攻擊；行為監控指的是內部操作行為的監控，以便追溯風險源。
最後，南雲鵬基於日常工作中的實際操作經驗，詳細闡述了數據備份恢復、切換演練、容量管理和巡檢工作中的操作流程、註意事項及優化方案。
三、金融應用場景對分散式資料庫的訴求
銀行業是相對傳統的金融行業，數字化轉型過程中首先追求穩定，金融 IT 側是趨於保守的。從銀行業部署架構趨勢來看，早期通常是將伺服器集中部署在大型機上，為的就是穩定、高效、多併發。隨著應用的發展，銀行業的流行架構開始變成基於伺服器來搭建不同的應用，Oracle 資料庫開始席卷市場。後來，X86 伺服器興起引起應用架構開始發生變化，儘管這時候資料庫市場還離不開 Oracle、DB2，但去 IOE 理念已經萌芽了。如今，在國產化浪潮下，自主可控的必然要求使得國產分散式資料庫的流行。銀行業需要將曾經部署在 Oracle、DB2 等資料庫上的數據遷移至國產資料庫上，這時候資料庫遷移過程中的問題開始顯現了。
基於公司多年的資料庫遷移經驗，孫亮以兩個國產資料庫對接案例為切入口向大家詳細的闡述了遷移過程中的註意事項及優化項。總結來看，首先是分片鍵的配合，一定要帶上 Shardkey。在數據量很大的情況下，能夠保證精準分配；在報表規範、交易介面、數據傳遞過程中，要考慮到分片鍵如何向下傳遞。其次是** SQL 的優化特性，需要註意唯一性的要求**。高唯一性的數據欄位向前放，可以達到更好地索引命中的可能。
接下來是資料庫序列，每個資料庫的序列都不相同，這導致在資料庫遷移過程中需要重新對數據序列做分支方案，做歸攏操作。現在的解決方案是先在技術平臺上做獨立的序列組件，通過序列組件去做整體的序列。最後，日終併發過程當中存在數據分佈不均勻的情況，這也是對數據性能的影響，我們需要重點關註分片鍵是否設置得合理，是否可以達到數據平均化，或者把數據能夠真正離散掉。
結合銀行業的特點，孫亮為大家分享了幾點在金融應用中常見訴求。金融行業的應用軟體最高優先順序關註點就是穩定性，孫亮認為很多不太優雅甚至是不太合理的基礎轉型，其實都是考慮到優先穩定性的要求。目前整個金融行業很關註的一點就是，遷移到國產資料庫下，穩定性是如何保障的？同時容災過程當中 RPO、RTO 真實的情況下能做到什麼樣的情況？包括同城、異地 RPO 也是重點關註的。雖然同城可以做到 RPO 為 0，但如果切到異地，RPO 不能為 0，容災還是有一定的風險，金融行業是一定要考慮的。
在遷移過程中，我們關註遷移的難易程度，簡單說就是 SQL 語法的相容性。我們更期望於國產資料庫這一側，能夠將這些語法儘量做到統一，減少上層大量的適配、改造。資料庫的性能也是關註的重點，容量到底有多大？在金融行業或者在金融軟體用戶側，我們認為資料庫的容量其實更多指的是在指定表寬度下，單表最多能容納多少條記錄，才會產生性能拐點，這就是表容量。而不是一些國內外一些資料庫宣傳時提到的每個數據文件能夠支撐多少 T 的數據。
另外以往缺陷率能否在現有版本當中進行修複也是需要重點關註的。如果大家都認為缺陷修複了，但由於分支的問題而被規避掉了，結果又被重新觸發起來，這樣得不償失。因此這類問題需要國產資料庫在內核構建中就得處理掉。
除此之外，基於公司的實施經驗，孫亮還提出了在問題排查、運維部署以及術語對齊上的訴求。同時，對國產資料庫提出了更高的要求，異地同步能否做到 RPO 為 0？多地多活是否可以在資料庫層面實現？分散式事務是否能在資料庫層面做到 XA 事務，讓分散式事務變得和本地事物一樣簡單容易呢？
最後，孫亮基於行業經驗及市場觀察，對現有的三款分散式資料庫類型進行了對比總結，其維度包括了一致性、性能（響應時間、併發能力、批量性能）、擴展性、生態、自主可控、高可用及部分形態（是否支持雲原生部署等），可作為客戶選型前的參考。
四、金融級分散式資料庫探索實踐
分散式資料庫是基於業務與技術的需求和發展以及監管要求下，解決當下以及未來趨勢發展等問題，更優更穩定地滿足金融銀行業發展的選擇。短期看雖有不足，用長遠和發展的眼光看，對支撐金融需求、滿足監管要求、提升自主可控能力、有效降低風險、合理控制系統建設成本等諸多方面都有助力和支撐作用，是金融銀行業基礎設施、基礎軟體建設的重點之一。
近年來，銀行業在內外部金融環境的快速變化中持續進行轉型和發展，從零售轉型到互金 / 直銷以及多渠道豐富金融產品的興起，從追求業務多元化到追求場景化創新，基於持續不斷的技術發展、業務創新積累下，再到金融數字化轉型深入推進，這些對金融系統的技術架構有了更為嚴格的標準和要求以及訴求。面對此背景和發展的時代，我們首先要滿足高可用及雙中心級以上容災，這是銀行或金融業對技術架構最基本的要求，在此基礎之上要滿足交易高頻高效、低延遲的金融場景處理要求，再衍生到高吞吐能力。在適配和實踐中，需要按照銀行系統的分類進行，每類系統特點對資料庫要求和特性也不一樣。
金融業務系統資料庫的場景維度可簡單劃分成為兩類，第一類是日間交易場景，聚焦到銀行核心就是客戶信息查詢、存貸款業務、支付賬務業務、代繳費批量處理場景等。這類場景的特點就是要求時效性和強一致性，所以必須滿足高併發、高性能。第二類是日終批處理場景，例如計提結息、總分核對、會計科目記賬、借貸平衡檢查這類時效性要求低一點的業務。在批量提交 SQL 時併發量大，單位時間對單表的讀寫量大。這種情況首先要做分散式處理，然後進行分散式聚合處理、查詢，最後按系統測算量和現有數據量的大小分批提交事務。
基於多年的行業架構經驗，賈瓅園從金融資料庫實施角度出發，重點介紹了工作評估中的七個重要維度供參考。在實際應用過程中，企業應結合自身業務特點來評估維度的優先順序。並且，一定要進行測試，以測試結果為準作為最終的評估依據。
-
批量業務場景需求評估。這一點關乎金融資料庫的安全性和數據強一致性，從客戶端來看，直接影響到用戶體驗以及銀行間的清算工作。因此，要重點評估大批量數據操作時，對資料庫的吞吐影響情況。
-
數據有效遷移需求評估。在投產過程中，遷移的時效性也直接影響到體驗以及銀行業行間清算、投產相關的安全平穩度。
-
未來 5 年資料庫容量評估。資料庫建設往往是系統工程，涉及到業務系統的匹配、硬體的匹配、網路匹配，甚至是團隊的技術知識匹配，其投入成本巨大，不可能僅使用一兩年就更換。
-
高峰值 TPS/QPS 需求評估。基於我國的人口紅利，在應用場景中不乏有大量用戶使用，而金融系統應用以穩定性為先，因此併發壓力特點下對資料庫性能的要求非常高。
-
高可用、容災需求評估。兩地三中心，吞吐量要求、IO 要求等都是重點考量點，業務屬性較強的系統，需要與資料庫高可用架構和容災設計相配合，在保障高吞吐量的前提下，同時保持故障切換的靈活性與時效性，對業務影響較低且滿足監管要求。
-
備份需求評估。因為雲化將是未來分散式資料庫的發展方向，所以面對傳統的網路環境、流量限定等也會有一定的要求。存儲方面也從原來的集中式存儲，變為分散式存儲，這些變化不僅僅是每個單項的技術發展，還可能是綜合影響。
-
應用接入需求評估。什麼系統可以直接適配？什麼系統需要轉化改造？這些需求評估在銀行選型期間是考慮的重點。
此外，賈瓅園聚焦資料庫語法維度，在六大使用場景中為開發者提供了適配優化方案。這六大使用場景包括了 SQL 語句、函數 / 關鍵詞、設置 / 語法、索引、數據類型轉換、分片 / 分區優化。
