OceanBase CEO 楊冰：2.8萬字總結金融核心系統數據庫升級路徑與場景實踐
金融行業正在面臨前所未有之大變局。近年來，數字化轉型已經逐步從頭部金融機構帶動效應下的“選擇題”，發展成爲幾乎所有金融機構需要面對的“必答題”。隨着全面邁入數字經濟時代，數據量正在從TB級躍升至PB級，甚至ZB級。IT領域“舊瓶”（舊的數據架構）難裝“新酒”（新的數據量級），數字化轉型需要一套現代數據架構的有力支撐。而數據庫相當於“大樹”（數據架構）的“根基”，“根基”決定“果實”（數字化轉型）的優良。立足當下，傳統數據庫已不能滿足現代數據架構需求，金融機構急需徹底重構“根基”。
OceanBase誕生於金融場景，我們從2010年立項，寫下第一行代碼，堅持完全自主研發，到2017年完全承載整個集團的核心繫統數據庫，經歷了7年的金融級場景考驗與打磨。也正好在這一年，因爲我們天然對金融場景的理解與共鳴，贏得了第一批外部金融客戶的信任。伴隨2020年OceanBase商業化的加速，我們已經覆蓋70%資產規模千億銀行、75%頭部證券、65%頭部保險、45%頭部基金（頭部爲Top20）。根據賽迪顧問《2022-2023 年中國平臺軟件市場研究年度報告》顯示，OceanBase在金融行業的國產分佈式數據庫佔有率位列第一。
正是因爲有越來越多金融客戶選擇與OceanBase同行，我們對金融行業的理解不斷加深、對金融場景實踐的沉澱和思考也在不斷深入。深耕金融14載，“根自研”是OceanBase負載關鍵業務系統、爲金融客戶需求兜底的最大底氣，我們與上百家金融客戶攜手並肩沉澱出不少最佳實踐，藉此機會進行抽象、梳理與總結。一方面，以期收到更多金融機構對我們的反饋和建議，讓“根自研”數據庫OceanBase再進一步。另一方面，以期讓更多金融機構少走彎路，在選型階段，結合數據庫技術發展趨勢，選擇更着眼於未來的技術路線；在遷移階段，選擇不同升級路徑，用更低改造成本平滑遷移；在應用階段，貼合創新場景發揮分佈式數據庫的更大效用等。
一、金融數字化轉型，行至關鍵期
談及數字化轉型，如果說過去還只是頭部金融機構帶動效應下的“選擇題”。那麼現在，數字化轉型已經成爲不論大、中、小型金融機構都需要面對的“必答題”。
一方面是來自政策的推動。金融業一直是數字化轉型“排頭兵”。近年來，人民銀行、原銀保監會、證監會不斷出臺金融數字化轉型相關政策，多方位加快推進金融數字化轉型。其中，人民銀行印發的《金融科技發展規劃（2022—2025年）》明確金融數字化轉型的總體思路、發展目標、重點任務和實施保障，到2025年力爭實現整體水平與核心競爭力跨越式提升。
另一方面是整體戰略逐步向“以客戶爲中心”轉變的加速。過去，金融機構側重銷售產品和服務，是典型的“以產品爲中心”，隨着消費者需求的不斷變化，以及內外部競爭加劇，全面轉向“以客戶爲中心”已經逐步成爲金融機構的戰略共識。這也就意味着，金融機構需要具備足夠強大、足夠敏捷的數字化技術，爲客戶打造個性化、精準化、智能化的體驗，這關乎未來可持續發展。
此外，還有數字經濟浪潮的推進。2023年4月，國家互聯網信息辦公室發佈的《數字中國發展報告（2022年）》報告顯示，數字經濟已經成爲穩增長促轉型的重要引擎，2022年我國數字經濟規模達50.2萬億元，佔GDP比重提升至41.5%，這一數字預計在2025年超過50%。當我國全面邁入數字經濟時代，提前打好數字化基礎的金融機構將搶佔新時代的發展先機。
二、走向現代數據架構，數據庫成爲金融數字化轉型關鍵環節
數字化轉型的本質是利用數據重塑傳統業務與組織模式，構建企業的新型競爭力。隨着數字經濟時代的到來，數據量正在從TB級躍升至PB級，甚至ZB級。根據IDC測算，我國數據總量預計2025年將高達48.6ZB，佔全球總量的27.8%。如今數據總量的 “大”已經和過去不是一個級別，而在IT領域“舊瓶”是裝不了“新酒”的，金融機構急需一套現代化的數據架構來作爲數字化轉型的支撐。
站在技術體系的發展角度看數字化轉型，宏觀上，海量數據的爆發來自於互聯網的發展，業務的信息化、線上化爆點先從 SaaS 層開始，很快就觸碰到了IaaS 層計算網絡等基礎設施的瓶頸，從而推動雲計算和大數據平臺的發展。當IaaS層和SaaS層發展起來後，PaaS層這種中間層的技術開始慢慢收斂、標準化，形成雲原生、流/批計算平臺、分佈式數據庫等配套的標準件。隨着第二波AI、WEB3等革命的到來，SaaS 層又往下開始推動IaaS層實現新突破，比如算力、帶寬、存儲，進而促成新的PaaS 層迭代。IaaS、PaaS、SaaS 層的演進關係如圖1所示。
圖1 IaaS、PaaS、SaaS 層的演進關係
從微觀上看，也是更偏技術架構的角度，其演進過程基本都是從最容易的、相對無狀態的SaaS層開始。因爲瓶頸出現後，SaaS層是最容易改造的，面對更多的需求、更多的數據、更快的迭代速度，SaaS層的解題思路就是從單體應用走向服務化拆分，再慢慢向雲原生化演進。由於應用大部分是無狀態的，整個演進的風險相對可控。
隨後，來自業務和架構的壓力很快從SaaS層傳導到IaaS層，這一層雖然是有狀態的，存儲着關鍵數據，但離業務比較遠，與應用間的關係更加弱耦合，基本都是通過標準接口進行交互。而且，雲和新的存儲、芯片以及網絡層的發展並沒有太多標準的改變。所以，在數字化轉型過程中，IaaS層基本能夠相對“透明無感”，在不影響業務的情況下升級爲國產芯片、存儲、服務器等，爲上層提供更強大的彈性算力和更高資源利用率的虛擬化能力。
當SaaS層改變，IaaS層也緊跟着升級，剩下“最難啃的骨頭”就在PaaS層了，這一層既與業務相關又有狀態，往上需要承接SaaS層分拆後的分佈式化的數據通信和運維管控，往下需要向與雲底座相適配的雲原生方向發展。而PaaS層中最難升級的又是數據庫，無論是與應用的耦合度還是狀態數據的重要性，都給數據庫升級帶來了巨大挑戰。例如，金融機構的互聯網業務經常面對脈衝業務的衝擊，應用架構通過服務化架構和容器技術具備了更強大的數據處理能力和彈性伸縮能力，從而間接要求數據庫具備海量數據處理能力和彈性伸縮能力，同時業務的分佈式和垂直拆分要求數據庫也是分佈式的，但分佈式有狀態數據如何保證一致性，又如何應對大量數據庫實例管理的複雜度……
這僅僅是數據庫升級挑戰中的冰山一角，我們已經無法用傳統的數據架構來解決這些新問題。如果還是治標不治本，通過外掛或者各種外部軟件與數據庫軟件拼裝組合的方式來應對，只會讓問題更復雜、風險變得更高。現代SaaS層應用架構和IaaS層基礎架構的演進，都需要數據架構的根本改變，才能解決深層次的矛盾，才能應對現代業務場景的各種挑戰。
數據庫相當於“大樹”（數據架構）的“根基”，“根基”決定了“果實”（數字化轉型）的優良。傳統數據庫已然不能滿足現代數據架構的需求，行穩致遠，金融機構急需徹底重構“根基”。
三、金融行業面臨的數據庫升級挑戰1. 從邊緣到核心，數據庫升級全面提速
金融行業自20世紀70年代開啓信息化建設以來便着手搭建核心系統，其作爲金融機構的交易中樞，經過數十年的發展，在沉澱大量數據資產的同時，更是與周邊系統盤根錯節，可以說是“牽一髮而動全身”。因此，大多數金融機構在開展信息化系統數據庫新技術升級時，通常採取循序漸進、風險可控的策略，即先邊緣系統再核心系統，不僅是爲了逐步掌握新數據庫技術，更是爲了業務的風險可控。
“根自研”OceanBase自2010 年立項以來，已經累計服務了數百家金融機構，覆蓋70%資產規模千億元以上的銀行，在證券、保險、基金行業的Top20資產規模企業中，覆蓋率也分別爲75%、65%、45%。其中大部分涉及核心系統數據庫升級，尤其以頭部銀行、頭部保險公司爲代表的金融機構開始涉足“無人區”，率先進行核心系統數據庫的分佈式升級，並取得了不錯的成績。
以某國有大行爲例，國內首個貸記卡核心系統“大機下移”分佈式已經穩定運行一年有餘，目前已有ECIF、對公網銀等幾十套系統數據庫升級至OceanBase，傳統核心也在基於OceanBase進行大機下移和單元化改造；以中國太平洋保險公司（以下簡稱“中國太保”）爲例，其採取“先難後易”策略，自關聯關係最爲複雜、商業數據庫綁定程度最深、業務影響最多的核心繫統——“P17核心客戶服務系統”（以下簡稱“P17”）投產上線以來，持續平穩運行，廣泛服務於數千名櫃麪人員、百萬業務人員和億級外部客戶，並將升級經驗複製至其他系統，陸續有近80套系統數據庫完成分佈式升級。
從核心系統開始升級，有助於徹底拋棄原有的陳舊數據架構，更快地使用新數據庫技術滿足現代金融業務發展。當然，核心系統數據庫在升級改造的同時，也伴隨着邊緣系統的數據庫升級改造，並且得益於核心系統的經驗積累，部分邊緣系統上線更快。
這些先行者的嘗試，已經驗證了金融核心系統數據庫新技術升級的可行性，並積累了大量的升級方法論。根據我們的經驗，核心系統（含數據庫）的整體升級大概需要持續2～3年。金融信息技術應用創新產業已經從邊緣系統試點驗證階段向核心系統全面提速。加之時間窗口有限，核心系統數據庫的新技術升級已經到了必須提上日程的時期。
2. 不同規模金融機構數據庫升級需求各不相同
我們在服務客戶時發現，不同規模金融機構結合自身IT水平、數字化能力以及人才組織配置等，在數據庫升級時需求各異、各有側重（如圖2所示）。
首先，大型金融機構基礎設施較好，對TPS、響應時間等各方面的要求較高，所以關注點不僅包括分佈式，還包括完整的單元化分佈式整體解決方案以及在分佈式架構下如何構建高可用的技術風險體系。
其次，大型金融機構需要整體升級的系統較多，遷移的數據量也較大，所以重點關注整套遷移方案的安全性和改造成本，數據庫針對原數據庫的高度兼容以及完整的遷移工具是大型金融機構最關心的能力之一。
最後，一般大型金融機構的基礎設施也比較複雜和多樣化，要求數據庫廠商能基本兼容所有主流的國產芯片，同時可以多芯片混部，服務器上也是一樣，可以在不同的雲廠商中部署數據庫服務器，進行跨雲協同。
圖2 大型、中小型金融機構數據庫升級的不同需求
而對於中小型金融機構而言，其首先需要數據庫具備分佈式能力，但在使用上其根本不希望對此有感知，而是希望像集中式數據庫一樣使用數據庫。所以原生的分佈式能力尤爲重要，這種架構避免了分佈式的複雜性侵入應用，避免了分庫分表改造和後期使用及運維上的限制。
其次，中小型金融機構更關注分佈式數據庫與應用廠商的適配，希望有應用廠商的兜底和大量案例，避免爲升級底座而承擔不必要的風險。要求數據庫廠商與神碼、長亮、中電金信等核心系統ISV，以及宇信、天陽、贊同、易誠互動等應用ISV完成適配。
再次，中小型金融機構非常關心服務和培訓，以確保有足夠的服務人員可以保障後續的日常服務。
最後，中小型金融機構期望在硬件條件比較苛刻甚至受限的情況下，提供成本可控的高可用方案。
3.不同用戶數據庫升級關注點各異
我們調研了若干家金融機構的科技總經理/CIO/開發人員/架構師/DBA/運維人員等，對於數據庫產品，大家的關注點也各有側重。總的來說，無論是架構升級還是自身能力迭代演進，首要目標都是確保穩定可靠，數據庫升級過程要平滑，且可分層解耦、風險可控。
同時，作爲基礎軟件的數據庫，對應用系統的影響要儘可能做到最小，除了自身要提供完善的功能，還要對應用系統屏蔽自身的架構複雜度，讓應用簡單地使用數據庫。比較一致的是，數據庫要具備獨立演進能力，保證技術棧的可持續發展和自主掌控。
（1）科技總經理/CIO的主要關注點：數據庫是否成熟穩定，且能否帶來額外效益
作爲數字化轉型的關鍵環節，數據庫要支撐業務系統長期穩定運行，可靠且不丟數據。對於金融業務，尤其是核心業務，穩定性和可靠性是第一位的，做不到穩定可靠的“1”，再多創新的“0”也沒有意義。
因此，數據庫是否做到真正意義的自主掌控，保證供應鏈安全和產品生態基礎的可持續發展，對於關係國計民生的金融業務系統尤爲重要，應確保長期無“斷供”等相關風險，不會因爲停止供應或者服務影響業務連續性。
此外，數據庫作爲數據安全防護的最後屏障，所涉及的組件會不會帶來新的安全問題，這些都是金融機構的IT管理者、科技部門領軍人非常關注的問題。在保證整體架構安全、穩定的同時，如果還能帶來額外的效益，則更佳。比如做到性能不回退且成本不增加、支持業務未來的可持續發展、降低後續開發運維複雜度等。
（2）運維人員/DBA的主要關注點：數據庫維護是否操作簡單，且具備更高的業務連續性
數字經濟時代的到來，金融的數據量持續快速增長，原有集中式共享架構的部署模式，一旦發生故障難以快速自愈則需要大量人工操作，業務連續性將受到影響，因此數據庫需要具備更高階的可用能力和容災能力。
大多數金融機構系統數量多、結構複雜，但大部分系統的業務量、數據量其實並不大。加上創新金融業務的迭代及發展速度遠超預期，分散的集中式集羣運維成本較高，同時容易遇到併發量、擴展性等瓶頸，將導致數據庫的擴展成本、運維成本和管理複雜度的大幅提升。
因此，金融機構的運維人員/DBA會更關注數據庫維護是否簡單易用，數據庫升級後是否能有效提升資源利用率、降低整體運維成本、兼顧複雜度和維護難度、保證業務系統的連續穩定運行。
（3）開發人員/架構師的主要關注點：數據庫升級是否平滑兼容，且滿足未來架構長遠演進要求
作爲金融機構的開發人員或者架構師，數據庫整體架構的可演進性是其首要關注點，而且要確保在滿足業務需求的前提下，數據庫做到平滑遷移。因爲原數據庫的兼容性稍差，就會導致業務改造整體成本非常高，而在此期間業務發展不等人，各類新增業務需求還會層出不窮，開發人員通常需要同時面對以下事項：
因此，數據庫需要具備較高的語法以及用法的兼容性，才能在極大程度上避免以上問題的發生，保證業務平穩上線運行。此外，數據庫升級過程中一旦出現問題，需要支持回退、支持逐步替換升級或者長期並行驗證。
結合金融分佈式架構轉型，越來越多的業務需要數據庫具有在線事務處理和海量數據分析的複雜使用場景，傳統做法是將數據導一份到數據倉庫裡做離線的計算，這對資源本身其實是一種浪費；且對實時分析要求高的場景，這種方案也不具備可落地性。這就要求數據庫在提供高併發交易事務處理能力的同時，還能夠提供海量數據實時分析的能力，以更高效率、更低成本地滿足多元化的金融業務場景需求。
四、 金融行業需要怎樣的數據庫1. 金融行業數據庫技術架構演進
回溯IT技術的發展史，金融行業的IT應用基本走在行業前列。以銀行業爲例，其IT技術應用大致經歷了三個階段的發展：
互聯網催生了電子商務的發展，誕生了網購和第三方支付業務，電子商務借鑑金融行業信息技術的先進應用經驗，“IOE”架構以其穩定性、易用性成爲當時的主流。隨着電子商務業務飛速發展，以及“秒殺”“大促”等業務模式的出現，海量數據、高併發下，集中式數據庫的性能出現瓶頸，而且“IOE”架構的成本越來越高。
爲解決擴展性不足和成本問題，“中間件架構的分佈式”架構誕生，基於國外開源數據庫包一層分庫分表等中間件，使用PC服務器替代小機和高端存儲，並省去了數據庫授權費用。業務模型簡單的互聯網交易場景獲得快速發展。
然而，隨着中間件架構的推廣使用，其諸多缺陷開始顯現。由於分庫分表架構需要按照分片鍵查詢，難以支撐無分片鍵的訪問請求、難以增加不包含分片鍵的二級索引、難以支撐跨分片的分佈式事務等。爲解決這些問題，中間件架構大幅提升了應用層的複雜度，例如，雙寫業務表和索引表這兩張表，而當這兩張表跨越不同數據庫實例時，又需要引入應用事務中間件等。
正是因爲這些中間件架構分佈式的缺陷，互聯網的去“IOE”浪潮沒能推廣到更多的行業，而金融行業的業務模型複雜度以及對數據一致性的要求遠高於互聯網。
到了移動互聯網時代，金融機構紛紛開啓加速數字化轉型。櫃面交易量逐步被替代，由智能手機承載的金融服務方便隨身攜帶。這些金融服務在業務類型上包括銀行、保險、證券、基金、期貨等金融領域，並且在業務範圍上延伸金融行業服務客戶的範圍，開放金融、供應鏈金融、全場景金融等不斷涌現。
傳統的集中式數據庫依賴單機的處理能力，因而存在架構上的單點。隨着摩爾定律的失效，依靠垂直擴展的集中式走到了盡頭，而金融業務的發展要求數據庫具備海量數據下的高併發的事務處理能力。部分金融機構在架構轉型中嘗試中間件架構的分佈式，在國外開源數據庫上做二次開發，並取得一定效果，但隨着深入應用依然出現瓶頸。爲徹底解決海量數據、高併發場景的數據庫的問題，原生分佈式數據庫架構誕生。
中國信息通信研究院在《大數據白皮書（2018年）》中給出了數據庫架構的發展方向，闡述了一致性協議Paxos的誕生爲分佈式數據庫的發展鋪平了道路，是對數據庫發展歷程的高度概括，也爲數據庫的發展指明瞭方向。這包含兩重含義，一方面，分佈式替代集中式是發展的必然，而原生分佈式數據庫是數據庫發展的方向；另一方面，中間件架構的分佈式只是過渡態。數據庫架構演進過程如圖3所示。
圖3 數據庫架構演進過程（注：資料來源於中國信息通信研究院《大數據白皮書（2018年）》）
2. 中國場景驅動數據庫技術創新，新一代數據庫需要具備四大核心能力
自關係模型有了完善的理論支撐後，從Oracle、DB2到SQL Server，商業數據庫迎來第一波高速發展。當關係數據足夠流行，上下游生態軟件和應用軟件的適配足夠完善，以及在全球有足夠廣泛的開發者羣體時。MySQL、PostgreSQL等數據庫以開源、免費版和簡化版的形態推動了數據庫歷史上第二波更加廣泛而影響深遠的發展，但直到1996年後，OLTP領域再也沒有新的主流數據庫出現（如圖4所示）。
圖4 OLTP領域主流數據庫誕生時間點
這是什麼原因呢？因爲在使用場景上並沒有實現代際躍遷，也就無法對現有數據庫的能力和架構產生太大的推動力。直到以中國、美國爲代表的區域迎來第一波PC互聯網到移動互聯網的高速爆發，在這之後，數據庫領域慢慢開始有了新的變化，而比較有意思的是，這波移動互聯網的變革，中國比美國更快、更徹底，也更快地推動了大量技術的發展甚至是變革。
2000年左右，基礎架構還沒有反應過來，從應用層到中間件層開始解決集中式解決不了的問題，以Cobar，MyCAT爲代表的中間件方案的分佈式架構出現。一直到2010年左右，以Google Spanner、OceanBase等爲代表的原生分佈式架構出現，陪伴互聯網高速發展了十餘年，產品逐漸打磨成熟並開始商業化。
Forrester相關報告指出，傳統數據庫在數字經濟時代面臨技術架構複雜、使用成本高以及安全性等嚴峻的挑戰，企業迫切需要採用新一代數據庫來處理海量數據，利用架構升級來消弭高昂的軟硬件成本，並需要加強數據分析能力以推動企業洞察驅動的決策模式，從而進一步加速數字化轉型，進而推動全社會數字經濟的發展。新一代數據庫需要具備低成本的極致性能、全維度的彈性靈活、洞察驅動的融合分析，以及全方位的安全可靠性四大核心能力（如圖5所示）。
圖5 新一代數據庫需要具備的能力（注：資料來源於Forrester《OceanBase總體經濟影響TM (TEI) 研究報告》）
數據庫是用出來的。OceanBase 過去十多年的發展，得益於飛速發展的移動互聯網。這些年，從互聯網支付核心到全場景金融核心，再到政企民生、運營商核心場景，以及新零售、新制造、互聯網海量場景，OceanBase 參與並支持了一次又一次的關鍵業務負載，在千行百業的關鍵業務負載中不斷深度完善、快速迭代。也正是因爲這些，倒逼了分佈式數據庫技術的再次突破、創新和成熟。
對基礎軟件的發展而言，這是一條極爲特殊的成長路徑，也是最好的成長路徑，在全球都很難複製，這是我們的幸運，身上也不由有了一種時代的使命感。
回看14年一路走來的歷程，今天的我們得益於最初的決定——走“根自研”路線；得益於中國獨特的場景——移動互聯網爆發，帶來前所未有的對海量數據、高併發的數據處理需求，以及這幾年大量企業的核心繫統升級，帶來複雜業務場景下處理海量數據的需求。這些獨特的場景使得OceanBase能夠始終堅持創新探索，穿越“無人區”。藉助中國場景，能夠推動分佈式數據庫的四項新標準（如圖6所示）。
圖6 中國場景推動分佈式數據庫的新標準
我們在不斷解決各種場景問題，尤其是關鍵業務的數據存儲、處理、使用過程中，摸索出分佈式架構數據庫的最佳實踐，逐步形成了“一體化”的解決思路。
從2010年至今，OceanBase專注於OLTP場景，開始逐步打造滿足現代數據架構需求的TP&AP一體化、多模、雲上雲下一體化、單機分佈式一體化等核心能力，推出一體化數據庫，支持不同規模金融機構/系統的關鍵業務負載。其中，“一體化”的理念包含以下兩個方面（如圖7所示）。
圖7 OceanBase一體化數據庫
第一，“一體化”的體驗。在實際的應用中，數據庫是解決數據存儲、處理問題的手段，應用系統真正關心的、要解決的是業務需求問題，而不應該花太多精力在關心分佈式帶來的成本複雜度問題、處理各種數據結構帶來的存儲的差異性、不同數據庫操作語法帶來的好處、不同的負載或者基礎設施帶來的差異性等。我們用“一體化”設計來打造產品，讓用戶迴歸到關注業務，讓數據庫使用盡可能簡單。
第二，一個數據庫解決80%的問題。“一體化”不是變成全功能，也不是簡單的拼裝組合。本質上，OceanBase還是一個具備“關鍵業務負載”支撐能力的OLTP數據庫，核心能力還是高可用、高安全、高性能以及高性價比。我們認爲，在企業的絕大部分數據處理場景中，只要成本合理，這些都是必需的能力，我們希望能在這個強勁的底座上，儘可能滿足80%的需求。但在極其專業的場景，還是需要用專門的數據引擎。就像今天的智能手機，可以很好地滿足普通人對電話、聊天、遊戲、聽音樂和看電影的需求，但是針對一些專業用戶，專業的遊戲機是更好的選擇，電影院是更好的選擇。
五、OceanBase如何應對金融行業面臨的數據庫升級挑戰1. 深度強化穩定可靠，保障服務不中斷、數據不丟失
隨着移動互聯網和互聯網金融的進一步普及，金融機構需要爲客戶提供無所不在、觸手可及的全天候金融服務，雙活、多活也成爲金融科技的基本要求。隨身化、實時化的金融服務要求IT系統提供7×24小時不間斷服務，即使面臨天災、地震等自然災害也需要保證業務的連續性。
我們在穩定可靠性方面投入最多，首創的“三地五中心”城市級故障自動無損容災新標準（如圖8所示），在高可靠性上不斷升級，也一直在推動行業的發展。OceanBase 最早提出RPO=0，RTO＜30秒，目前已經是行業標配，這個還是數據庫層面的自動切換時間，爲了給連續性要求更高的業務系統留出更多時間，經過努力，我們將其降到了8秒內。
圖8 OceanBase支持豐富、靈活的容災模式
該架構底層採用Paxos協議實現將Redo日誌在本服務器持久化，同時主副本在確認多數派副本Redo日誌都持久化成功後，確認數據庫事務提交成功，從副本利用Redo日誌的內容實時回放，保證自己的狀態與主副本一致，這種多數派同步機制也保證了少數副本發生不可用或者網絡抖動時，業務系統也能夠平穩運行，影響做到最小。
在金融行業比較常用的“兩地三中心”部署架構中，OceanBase可以通過仲裁副本的機制實現數據一致的真正雙活，在雙機房主備架構下，OceanBase可以支持更細的容災顆粒度，包括租戶級主備庫和備份恢復，實現更靈活的容災部署和容災切換，滿足各個維度的業務容災和業務切換需求。
以深圳農商銀行爲例，基於OceanBase採用“兩地三中心”部署架構。2023年9月，深圳因颱風“海葵”出現超歷史極值的罕見強降水，深圳農商銀行部分系統可用性受到影響，OceanBase順利完成了異地switchover無損切換，支撐業務在異地成功運行，在真實場景中穩定應對危機，服務無中斷，數據零丟失，有力保障了深圳農商銀行的業務連續性與客戶數據安全。
“數據一致性”是數據庫的生命線，面對PC服務器穩定性比大機/小機低、數據庫主備模式解決不了“腦裂”及RPO=0的問題、磁盤固件門及各類靜默錯誤的新挑戰，OceanBase具備數據一致性的五道防線(5+x)：
磁盤靜默錯誤發生的概率並不太高，但其可怕之處在於錯誤發生時沒有任何警告，如果應用程序沒有對數據的正確性做校驗，那就會導致奇怪的應用異常，例如進程崩潰、丟數據等。OceanBase通過多副本校驗、relog校驗、SSTable校驗層層設防，防止類似磁盤靜默錯誤導致的數據一致性、正確性問題。
多副本校驗
OceanBase 數據庫作爲分佈式數據庫，採用了多副本的容災方式。由於磁盤靜默錯誤發生的概率並不高，所以同一個數據塊在多個副本同時出現靜默錯誤的概率微乎其微。只要我們能知道某個副本出現了磁盤靜默錯誤，就可以從剩餘的正常副本中拷貝數據來修復這個錯誤。多副本之間的數據校驗是在LSM-Tree major freeze階段做的。目前 OceanBase 數據庫支持副本粒度的修復，出現磁盤靜默錯誤時，運維同學可以先刪除錯誤副本，再從其他機器補齊正確副本。
relog校驗
在每條 RedoLog 的頭部，我們會記錄這條日誌的校驗和。在做網絡傳輸和日誌回放時，都會強制對每條日誌的校驗和進行校驗。這樣我們保證了三副本同步到的日誌是正確且一致的，如果一條日誌中的數據出現了靜默錯誤，那麼這條日誌一定不會被同步到其他副本。
SSTable校驗
SSTable 的數據存放在一個個宏塊中，宏塊的長度固定爲 2MB，在宏塊的頭部會記錄這個宏塊的校驗和。宏塊內部會拆分多個微塊，微塊長度不固定，通常爲 16KB，在微塊的頭部也會記錄這個微塊的校驗和。SSTable 的讀 IO 以微塊爲基本單位，寫 IO 以宏塊爲基本單位。在讀取微塊時，會強制校驗微塊頭的校驗和，保證用戶讀到的微塊數據是正確的。在遷移、備份等複製宏塊的場景，目的端寫宏塊前，也會強制校驗宏塊的校驗和，保證寫入的數據是正確的，防止磁盤靜默錯誤的擴散。
除了在讀寫時檢查數據塊的正確性，我們還希望儘早發現磁盤靜默錯誤。OceanBase 數據庫可以在後臺開啓巡檢任務，週期性掃描全部宏塊並檢查其校驗和，一旦發現磁盤靜默錯誤便會告警。
2.持續平衡性能與成本，助力性能不下降、成本不增加
性能一直是OceanBase的強項，以前我們更多強調分佈式的擴展性，並且用TPC-C 7.07億tpmC這樣極端的場景，驗證了OceanBase無限的擴展能力。
分佈式的強項是解決擴展性和容災的問題，但冗餘的多副本設計帶來最大的副作用就是成本比較高。在這方面，OceanBase的LSM-Tree存儲架構和高效的SQL優化器，極大地平衡了多副本和併發處理能力，因此可以在性能和成本上達到很好的平衡。
（1）降低成本：降低數據存儲相關的軟硬件成本
當一個數據庫承載的業務量變大、規模變大、系統數變多後，如何高效利用好每一份資源成爲非常重要的目標。數據高壓縮的同時性能無損，在基於傳統B+樹的數據庫中幾乎是不可能的，但在LSM-Tree架構下經過設計使其成爲現實。
憑藉高壓縮比的分佈式存儲引擎，在同一業務的數據存儲量下，OceanBase能顯著節約存儲空間，降低存儲成本。對於數據量大、數據生命週期長的業務場景來說，可以極大地滿足業務需求。比如，某國有特大型保險機構保險公司核心系統上線後，數據庫壓縮比高達8倍，業務數據庫容量瘦身78%，數據庫軟硬件成本縮減75%。
（2）提升性能：提升業務系統的各項性能
金融核心交易系統的特點是事務交易鏈路長，涉及的SQL比較多，一筆交易可能包含上百個SQL，同時核心交易場景對高併發，低延時，數據一致性是基本要求。
OceanBase的分佈式SQL優化器，全面支持HTAP能力，保障業務性能。比如，金華銀行新一代核心系統採用長亮V8核心系統，完成從“小型機+集中式數據庫+高端存儲”到“PC機+OceanBase分佈式數據庫+普通磁盤”的升級，僅使用18臺物理機，而在浙江同規模的某商業銀行使用基於MySQL二次開發的數據庫需要40臺，並且新一代核心系統的性能也得到顯著提升，日終批處理能力提升5倍以上、業務峰值處理能力提升12倍，批量代發時效提升120倍、季度結息效率提升了8倍。
分佈式數據庫的網絡寬帶一直是金融機構關注的問題。金融行業傳統“兩地三中心”架構幾乎均採用同城存儲複製結合異地數據邏輯複製方式，爲降低“兩地三中心”“三地五中心”對高帶寬、低延遲網絡的依賴，我們投入大量資源進行攻關並提出一攬子解決方案。
1. OceanBase 4.X版本對日誌流進一步優化，降低數據庫本身帶寬開銷，配合優化後的日誌流壓縮算法，可有效將多個機房副本間的帶寬下降40%以上；
2. 通過設計合理的數據分佈結合智能 DNS 將流量收斂到同機房，同時利用 OceanBase 獨創的“Table Group”技術將各類相同屬性的數據收斂在相同的 Zone，從底層就避免跨機房訪問數據及跨機房事務，減少應用跨機房訪問數據庫的網絡延遲的同時降低應用對跨城帶寬的依賴；
3. OceanBase 4.X版本仲裁副本技術降低多機房/跨城（省）機房的網絡帶寬，由於仲裁副本本身不存儲任何數據和日誌，因此仲裁副本能夠徹底降低第三中心的帶寬成本，任意機房到仲裁機房的帶寬僅需要原來的千分之二，延時則可以比以往放寬接近數十倍。
通過上述技術創新，四川省農村信用社在新一代分佈式核心方案論證時，使用OceanBase 4.X版本進行了業務模擬壓測，帶寬最高可減少60%，每年預計可節省跨城帶寬費用數千萬元。
3.不斷降低運維複雜度，以集中式體驗享受分佈式性能
OceanBase在數據庫內核、周邊工具層面不斷降低運維複雜度，期望運維人員/DBA能以集中式產品的使用體驗，享受分佈式的性能。
（1）數據庫內核層面：原生多租戶架構，私有云上也可以做到Serverless
隨着金融轉型，應用分佈式/微服務改造等，金融業客戶內部數據庫數量劇增。多個微服務使用的數據庫一般通過schema隔離，多個schema之間無法實現各自所需的資源的隔離，因此，資源碎片化、管理複雜、資源浪費、擴展性差等問題逐漸暴露出來。在這種情況下，數據庫將會成爲微服務體系框架中性能與擴展性的最大制約瓶頸。
加上基於IaaS提供大量數據庫會帶來巨大的運維成本和投資成本，以及難以快速供給等問題，數據庫即服務（DBaaS）成爲剛需。OceanBase通過數據庫內核實現原生多租戶模式，提供數據隔離、資源隔離、故障隔離、彈性資源。
OceanBase中的租戶是一個邏輯概念，是資源分配的單位，是數據庫對象管理和資源管理的基礎，對於系統運維，尤其是對於金融核心分佈式數據庫的運維有着重要的影響，租戶在一定程度上相當於傳統數據庫的“實例”概念。
有些客戶希望通過多租戶把很多單實例合併到一個大集羣；有些客戶希望租戶的隔離性不要那麼強，這樣可以實現超賣；有些客戶則把它用在各個省份的業務單元或者多法人機構，希望在運維上是同一套集羣，但在隔離性上希望和物理機、虛擬機一樣。
如圖9所示，我們將業務系統不同微服務所需的數據庫實例進行資源池化，提供不同規格的實例，在一套分佈式數據庫架構中實現多個數據庫租戶（實例）的資源池化能力，在保證資源隔離性的同時顯著降低資源和管理成本，還依然能夠保持優秀的性能和可運維性，將多個零散的數據庫實例集中統一在OceanBase集羣后，運維管理複雜度大大降低，負載、告警、調優全部統一至集羣級別，常規故障能夠自動恢復。
圖 9 OceanBase多租戶資源池化
多租戶可以應用於金融行業的不同場景，降低運維複雜度。
（2）周邊工具層面：“OCP+OAS”
分佈式數據庫同時運維多個節點，更需要集中式的管理工具統一管理。我們從OceanBase運維管理工具（OceanBase Control Platform,OCP）和OceanBase自治服務工具（OceanBase Autonomy Service,OAS）兩個周邊工具層爲運維/DBA提供可管理的手段，助力用戶真正去解決實踐中遇到的問題。相比於傳統的分佈式數據庫產品，可進一步降低運維複雜度。
與傳統單機數據庫相比，基於分佈式架構的 OceanBase 提供靈活的在線擴展性。在集羣持續可用的前提下，提供在線擴縮容。當集羣的容災需求發生變化時，可通過調整可用區數量（加/減 Zone）的方式提高或降低集羣的容災能力。當集羣的外部負載發生變化時，可通過調整可用區內物理機的數量（加/減 OBServer）的方式改變集羣的負載能力。
從業務視角看用戶操作的數據原子單位是表，用戶通過訪問表來實現業務的增刪改查。當單表的數量級上升到一定數量級時，性能將會急劇下降，此時就需要分而治之。分治的就是將大表拆成小，目前主要有兩種方式，分區表和“中間件+分庫分表”。
OceanBase可以和Oracle一樣通過分區表將數據打散到各個節點。OceanBase的單個分區存儲一張表的部分或者全部數據，當表是普通表的時候，存的就是全部數據，當表是分區表的時候一個分區存的就是一部分數據。
分區表相對“中間件+分庫分表”的優勢有以下幾個方面：
OceanBase分佈式數據庫通過分區表來進行水平拆分，不需要分佈式數據庫中間件產品，也不需要分庫分表，更不需要考慮跨節點分佈式事務一致性問題。通過分區表水平拆分，SQL和事務對業務完全透明，功能上沒有任何限制，且分區表線性擴展性也很好，並且支持在線擴容和縮容，內部數據遷移異步進行，具備高可用能力，不怕擴容和縮容過程中出現故障，可以輕鬆解決分庫分表所帶來的痛點。
4. 完善平滑遷移方案，打造應用基本無感的穩妥升級
大量的數據庫升級是存量替換的過程，如何保證遷移過程的平穩極爲關鍵。OceanBase 經過多年商業化打磨，形成向上向下兼容、向上遊向下遊適配的整套遷移部署方案。
向上兼容方面，我們從0.4版本就開始做SQL語法，確定兼容SQL語法的原則。自2008年集團開啓傳統數據庫升級以來，平滑遷移經驗不斷積累、Oracle/MySQL語法兼容能力不斷增強，Oracle兼容性經過多年打磨，功能兼容覆蓋率在95%以上；MySQL兼容版本也從5.x發展到8.0，兼容MySQL8.0的主流功能。應用只需要很小的改動，甚至無需改動，就可以遷移至OceanBase分佈式數據庫中。今年我們又增加並完善了 DBLink、JSON/XML/GIS/LOB等大顆粒的功能；在OLAP方向常用到的複雜數據類型如 Nchar、Nvarchar 等也有了更好的支持。向下兼容方面，OceanBase完成了基本全部主流芯片和服務器的適配，包括 7 款主流芯片和10多家整機廠商的適配。
向上遊適配方面，具備四大類源端數據庫的對接解析能力，其中包括10多款雲上雲下的數據庫產品；向下遊適配方面，則通過Canal、Flink、DTS等比較常見的數據同步工具打通上下游數據處理軟件，同時支持20多款常見數據處理平臺，可以無縫地跟原有的數據架構進行對接。OceanBase平滑遷移方案如圖10所示。
圖10 OceanBase平滑遷移方案
正是利用這套平滑遷移方案，西安銀行用了3個月時間就完成了互金核心升級至OceanBase。青海銀行的櫃面系統，耗時1個月即從DB2平滑升級至 OceanBase。某國有特大型保險機構全棧核心系統，僅用1年時間即完成整體升級，遷移規模和速度破金融行業紀錄，全程無一例回切。
近年來，金融行業數據庫升級明顯加速，私有云數據庫架構中往往存在多種型號的硬件機型和操作系統版本，而對這些硬件進行批量替換和升級換代是一項高風險、高成本的工作，如何平滑的完成替換升級成爲了一項新的課題。
OceanBase提供“一庫多芯，灰度替換”的解決方案，得益於OceanBase 的多副本異構兼容能力，適配海光、鯤鵬、Intel等多種芯片，兼容麒麟、統信、Linux多種操作系統，且在數據庫層自動適配，用戶無需關注底層的芯片和操作系統形態，並且支持異構芯片副本之間的數據一致性校驗，確保數據一致性和正確性，具備容災切換能力，混部的方式包括以下兩種：
一是主備集羣混部。如在主集羣服務器使用x86芯片+linux操作系統，備集羣服務器使用arm芯片+麒麟操作系統。
在該架構下，生產環境可先保留可靠性更高的x86芯片，利用OMS同步或OceanBase主備庫來驗證ARM架構+麒麟OS的穩定性。待穩定運行一段時間後可在某個時間點進行主備切換，從而在風險可控的前提下完成國產改造。
二是集羣內不同副本混部。如在單集羣內部，Zone1副本和Zone2副本的服務器使用x86芯片+linux操作系統，Zone3副本使用ARM芯片+麒麟操作系統。
將主集羣中的部分副本灰度替換爲ARM架構芯片，配合OceanBase的切主能力，可實現單個分區的Leader切換來驗證國產副本承載流量的能力。如下圖所示，例如將P4分區的主副本從Zone2切換至Zone3。若出現異常可隨時將該分區Leader切換回原有副本，最終可以將主集羣灰度切換爲全ARM芯片的副本且無需停機。
5. OLTP-Based HTAP，實時分析迴歸業務本質需求
在數據庫領域，是否需要“one size fit all”、是否需要HTAP數據庫是業界長期關注的話題。然而一切還要從實際需求溯源，實際情況是無論是傳統金融還是互聯網金融場景，絕大多數業務系統都不可能是純粹的OLTP或OLAP。
即使是銀行核心業務系統，聯機是典型的OLTP，而批量中有大量OLAP形式的負載。隨着24小時實時批量的流行，很難把OLTP/OLAP負載進行非常清晰的切割；隨着微服務化改造，各種數據中臺、業務中臺成爲剛需，而各類中臺本身的業務特點就是典型的HTAP混合負載。
行業內的通用解決方案是使用兩套數據庫引擎，分別提供OLTP和OLAP處理能力，兩種引擎之間通過數據複製/遷移進行數據交換，這種方案能夠解決一些問題，比如兩套引擎各自支持OLTP和OLAP都可以支持得很好，但仍然明顯存在着自身的侷限性：
以常見的金融核心交易類系統爲例，基於核心交易類系統的數據源下進行復雜查詢、報表分析和批處理等是非常普遍的場景，傳統數據庫往往在一定數據量和複雜度的情況下會遇到可擴展性、性能或者併發的瓶頸，因此不得不需要兩套軟件的解決方案。
我們從存儲層、SQL層、事務層乃至鏈路層都進行了整體優化設計，提供“一體化”設計的HTAP混合引擎（如圖11所示），通過一套數據、一套引擎同時支持OLTP和OLAP的負載。這樣可以充分挖掘一份數據價值和一套集羣的能力，數據在一致性、分析實時性和運維效率上取得平衡。交易數據原地分析，無需繁瑣的ETL過程，數據最大程度保鮮，省去了很多業務場景中實時數倉的構建工作，幫助客戶實現業務價值。
圖11 傳統方式VS HTAP方式
中國太保利用OceanBase的HTAP能力，財險核心批處理相比於傳統“IOE”架構，節省了62% 的時間。同時，利用向量化引擎、優化器改寫優化能力和大規模分佈式並行執行技術，顯著提升處理性能，財險分析型的數據加工處理能力提升10倍，監管報送批量場景性能提升3倍，構建起全面的實時數據處理和服務能力。
最新發布的OceanBase 4.3，深入探索TP & AP一體化，基於LSM-Tree架構推出列式存儲引擎，實現可行存、可行列混存和可列存的多種存儲方式，打造近 PB 級實時分析數據庫， 可在一個數據庫、一份數據的前提下，同時實現聯機事務處理和秒級實時分析。
OceanBase的HTAP是在OLTP數據庫的基礎上擴展OLAP能力。經典的 OLTP 數據庫，無論是開源的MySQL，還是商業數據庫 Oracle/SQL Server，都採用集中式架構，底層存儲引擎是面向磁盤設計的 B+ 樹。這種方案是爲小數據量的實時事務處理量身定製的，讀寫性能很好但相比 LSM Tree 等新型數據結構存儲成本更高。以 OceanBase 爲例，底層採用優化過的 LSM Tree 存儲引擎，在支付寶所有業務完全替換 Oracle/MySQL，存儲成本只有原來 B+ 樹方案的 1/3 左右。
爲了讓 OLTP 數據庫具備 OLAP 的能力，尤其是大數據量 OLAP 的能力。
首先，引入原生分佈式架構和基於LSM-Tree的存儲引擎，提升系統的大數據處理能力，從而使得系統不僅能夠處理最新數據的實時交易，也能處理更大規模歷史數據的全量分析。OceanBase 的底層採用了一個基於LSM-Tree 的行列混合式存儲方案，大幅降低存儲成本，並在 OLTP 和 OLAP 二者性能取得很好的平衡。
其次，支持 OLTP 與 OLAP 之間的資源隔離。這裡面既有多個副本之間的物理隔離，也有一個副本內部的CPU/網絡/磁盤/內存的邏輯隔離，將 cgroup 集成到數據庫引擎內部做邏輯資源隔離是一個不錯的方案。
再次，很好地支持複雜查詢和大數據量查詢，涉及到優化器、並行執行、向量執行等核心技術。對於分佈式數據庫，優化器不僅僅要考慮單機上的代價，還需要考慮多機上的代價，優化器的搜索空間大幅增加；另外，如何處理並行執行和服務器故障容錯的問題，如何實現高效的向量引擎，如何設計內存中的數據格式，等等。
最後，更好地支持 OLAP 的數據開發和建模能力。數據倉庫往往會將數據分成多個層次，包括：數據明細層，數據服務層，應用數據層。爲了支持實時分析能力，HTAP 支持高效易用的物化視圖，外部表，快速數據導入，並與各種數據開發工具和 BI 工具完成適配對接。
OceanBase 進化到4.x版本後，可對分析引擎全場景覆蓋，可利用單機的多核心進行並行處理；全新設計的融合日誌緩衝區同時支持聚合提交與共識協議，大幅度提升交易處理能力，分析處理能力再上臺階；全場景向量化能力覆蓋，更豐富的算子下壓，並將完全支持列存。
最新發布的OceanBase 4.3，基於 LSM-Tree 架構推出列存引擎，實現行存、列存數據存儲一體化，同時推出基於 Column 數據格式描述的新版向量化引擎和基於列存的代價模型，支持高效處理大寬表，顯著提升 AP 場景查詢性能，併兼顧 TP 業務場景，適用於複雜分析、實時報表、實時數倉或聯機交易等混合負載場景。該版本新增物化視圖功能，通過預計算存儲視圖的查詢結果提升實時查詢性能，支撐快速報表生成和數據分析場景。新版本內核也擴展了 Online DDL、支持了租戶克隆等功能，優化性能和資源使用，提升了系統易用性。經測試，OceanBase 4.3 在同等硬件環境下，在大寬表場景下的查詢性能達到了業內主流列存大寬表數據庫的水平。
綜上，具備HTAP能力是一個宏大的整體工程，需要完善的頂層設計、長期的技術積累和持續迭代，並不是一個簡單的通過某種“銀彈”技術（如列存）可以解決的。
六、核心系統數據庫升級最佳路徑實踐
金融核心系統更換數據庫，好比飛機在運行過程中更換髮動機。如何在更換髮動機的過程中不影響飛機的正常飛行，甚至讓乘客感受不到這個過程，對於金融機構和數據庫廠商而言都是一場“大考”。
1.八個步驟
目前，金融機構的核心繫統數據庫主要以Oracle、DB2爲主。從應用演進的角度，常見的金融核心系統數據庫升級有平滑遷移和完全新建兩種，平滑遷移側重於應用不改或者僅有少量修改，保持庫表結構基本不變的情況下，將數據庫替換成分佈式數據庫；完全新建指建設一套新的核心繫統，然後將老核心系統的數據與新核心系統的數據結構映射後完成數據的轉換和遷移。
OceanBase在服務衆多金融機構的核心繫統數據庫升級過程中，沉澱出一套升級替換的方法論，供金融機構在覈心繫統數據庫升級時參考（如圖12所示）。
圖12 八個重點步驟
（1）需求分析與戰略規劃。首先金融機構需進行通盤的需求分析和戰略規劃。這包括評估現有系統的性能瓶頸、安全威脅、成本效益等方面，同時考慮國家關於金融信息化的政策導向及未來的業務擴展性、技術發展趨勢。
（2）技術選型與方案設計。在明確需求後，選擇合適的技術路徑和方案至關重要。金融機構往往會考慮選擇具有兜底能力的數據庫，這不僅響應了國家的自主戰略，也有助於降低對外國技術的依賴，增強金融信息系統的安全性。技術選型時會關注數據庫的性能、穩定性、安全性、可擴展性及與現有系統的兼容性。
（3）應用適配、業務測試與評估。在實際升級之前，需要進行應用適配工作、詳盡的業務測試與評估。這包括在測試環境中模擬實際業務場景，驗證新數據庫系統的性能、穩定性及業務兼容性。
（4）系統遷移與優化。系統遷移是升級過程中最爲關鍵的環節。金融機構在遷移過程中，可能會採用漸進式、分階段遷移的策略，確保每一步遷移都是穩妥可靠的。遷移後，需要對系統進行調優，確保其能滿足業務需求並達到最佳性能。
（5）業務驗證與持續監控。系統升級上線（跟賬上線或者灰度上線）後，需要進行業務長期跟蹤驗證，確保所有業務流程在新型數據庫上都能正常運行。此後，還需建立持續監控機制，實時跟蹤系統性能和穩定性，以便快速響應可能出現的問題。
（6）安全與合規。數據安全與合規性是金融機構無法忽視的重要方面。數據庫升級後，需確保滿足國家相關金融信息安全的法律法規要求，加強數據加密、訪問控制、安全審計等措施。
（7）培訓與文檔。爲了確保系統升級後人員能夠熟練操作新系統，金融機構會組織相應的培訓。同時，完善的技術文檔和操作手冊也是必不可少的，以便於日常運維和未來可能的系統迭代。
（8）持續迭代與優化。金融機構的信息技術架構不是一成不變的。在完成核心繫統數據庫升級後，需要根據市場變化和業務發展需求，持續對系統進行優化和迭代，保持系統的先進性和競爭力。
通過以下三點，可幫助金融機構的核心繫統數據庫實現平滑遷移。
一是高兼容與廣適配，即極高的兼容性和廣泛的上下游適配能力，包括國產軟硬件、中間件和大量行業軟件。其中，高兼容不僅體現在原生的支持各種原數據庫的數據類型、SQL功能和數據庫對象，以及數據庫安全、備份恢復、高可用和優化器等高級特性；而且在保持各種原數據庫的開發、運維使用習慣上也在不斷迭代。
二是完善的周邊遷移工具，即一整套成熟的自動化遷移工具，包括兼容性評估、結構遷移、數據遷移、對象遷移等工具。如ODC開發工具儘可能保留原有的Oracle PL開發/調試習慣，通過OMA/OMS實現高度自動化的遷移評估+數據遷移/回遷功能。
三是成熟的遷移方法論，即大量內外部傳統集中式數據庫升級遷移項目所沉澱出來的升級遷移方法論。
2.四條路徑
從最早提出“IOE”以來，我們就已經在集團內部承擔了傳統集中式數據庫的分佈式升級重任。我們從在內部電商、第三方支付、首批民營銀行等內部場景苦練內功，具備了較強的Oracle兼容性，到擁有第一家商業銀行客戶，以及在大型保險機構、運營商等重度使用場景，不斷與客戶共同打磨兼容性，如今已經服務了衆多大中小型金融機構。
得益於完全自研，OceanBase不會有基於PG/MySQL開源版本上與Oracle進行兼容的桎梏。經過長期內外場景打磨，OceanBase的兼容性日趨成熟穩定，主線的GA版本即可滿足升級需求，無需通過定製化版本來支持。在這個過程中，我們也總結出核心系統數據庫升級的四條技術路徑（如圖13所示）。
圖13 核心系統數據庫升級的四條技術路徑
路徑一：Oracle平滑升級遷移
Oracle在金融行業是最常見的集中式數據庫，在金融業務場景的覆蓋上兼具廣度和深度。當分佈式轉型升級到來，銀行、保險、證券、基金等金融行業的客戶需要最短、最快的轉型升級方案，於是產生了該方案。其特點是，在應用代碼少改或者不改的情況下，依靠分佈式數據庫的兼容性實現。OceanBase基於自身的高度兼容（95%以上，若嚴格對標Oracle 12C文檔的功能項，兼容性在85%）及多年積累的體系化的遷移工具與遷移經驗，通過“全面語法兼容”配合客戶實現平滑遷移（如圖14所示）。
圖14 Oracle平滑遷移示意
以某國有特大型保險機構爲例，從2020年9月～2021年9月，僅用時一年即完成包括傳統核心在內的近百個業務系統近800套在線Oracle數據庫的全量搬遷工作，遷移數據規模超400TB、數據量超千億，單庫數據規模超20TB，存儲過程行數總數500萬行以上，整個遷移過程無一例回切。業務改造“Pro*C+Tuxedo”的兼容能力和平滑遷移方案，避免了上千萬行老核心代碼的重寫。
採用此路徑的還有中國太保的“P17”、金華銀行新一代核心系統以及廣發證券的核心估值系統等。
路徑二: “大型主機DB2遷移分佈式數據庫+單元化”方案
因業務規模大、範圍廣、複雜度高等，國有大型商業銀行是分佈式轉型中的難點，同時國有大型商業銀行在新一代核心建設中有單元化等架構方面的建設要求。
以某國有大行爲例，某國有大行的貸記卡、借記卡、ECIF這三大核心繫統均已轉型爲分佈式，其中，貸記卡核心系統採用“阿里雲+SOFA中間件+OceanBase分佈式數據庫”整體技術棧，實現“兩地四中心多地多活+單元化”設計。基於OceanBase多租戶特性，跨多集羣百租戶百庫百表單元化設計，其中5個單元化（Rzone）集羣：每個集羣20個租戶，每個租戶對應一套分片庫/表，總共百租戶/百庫/百表，統一按客戶內部編號分片，實現資源隔離和減少爆炸。OceanBase分佈式數據庫+單元化方案如圖15所示。
圖15 OceanBase分佈式數據庫+單元化方案示意
OceanBase具有超高的寫入性能，支持長亮、天陽分別採用聯機寫入和多表join寫入等不同的數據遷移方式，4小時內即可完成全量數據從大機卸數、數據轉換。從大型主機下移到x86服務器，貸記卡核心交易TPS提升6倍，跑批效率提升7倍以上，達成授權交易端到端耗時80毫秒以內的性能目標，並實現自動化運維、可觀測與安全生產。
路徑三：小型機DB2升級OceanBase
小型機DB2在中小銀行核心系統的數據庫中佔用重要位置，而中小銀行普遍採用新建的方式建設新一代核心系統。其中，一部分選擇OB-Oracle模式，實現一套核心應用分別部署在OB-Oracle和DB2-Oracle兩種數據庫上，實現雙逃生；另一部分選擇OB-MySQL模式，分批切換，一步到位。
以常熟農商銀行爲例，新一代核心系統從方案論證到交付實施，歷時18個月，基於 OceanBase構建起兩地三中心五副本及主備架構，採用OB-Oracle租戶，實現新一代核心系統OB-Oracle和DB2開啓Oracle兼容的雙容災。OceanBase一主拖兩備架構，主集羣和異地備集羣採用 x86 芯片，本地備集羣完全國產，包括ARM芯片、麒麟操作系統，做到“一庫多芯，混合部署”。相比老核心系統，新一代核心系統的每秒交易處理能力提升46倍，日終批量處理能力提升41倍，批量代發代扣處理能力提升651倍。小型機DB2升級OceanBase示意如圖16所示。
圖16 小型機DB2升級OceanBase示意
採用此路徑的還有云南紅塔銀行、深圳農商銀行的新一代核心系統等。
路徑四：MySQL平滑升級遷移
十多年前，爲應對互聯網發展帶來的高併發、海量數據對數據庫的挑戰，電商、第三方支付企業以及民營銀行進行了去傳統集中式數據庫的探索，MySQL或中間件架構的MySQL是主要替代品，在整個金融行業覆蓋度僅次於Oracle和DB2。
誠然，MySQL主要用於互聯網核心或非核心繫統，且大部分情況下爲“完全新建”，“平滑遷移”爲少數。與“Oracle平滑遷移方案”類似，得益於高兼容性，選擇OB-MySQL模式即可在應用基本零改動的情況下，從源數據庫完成平滑遷移。MySQL平滑遷移OceanBase示意如圖17所示。
圖17 MySQL 平滑遷移OceanBase示意
以西安銀行爲例，其快捷支付系統——西銀惠付通過在OMS不停機的情況下實施MySQL向OceanBase的完整遷移。從2019年2月進行數據庫評估分析，到2019年5月正式業務切流，3個月即完成遷移。遷移後，西銀惠付的數據壓縮爲之前的1/2，各項系統性能顯著提升。
3.核心系統數據庫選型建議概述
賽迪顧問2023年2月發表的《核心數據庫升級選型參考》報告顯示，核心數據庫選型因素涵蓋數據、功能、效果三個層面（如圖18所示），爲金融機構的核心繫統數據庫選型提供了清晰的思路。
圖18 核心系統數據庫選型因素（注：資料來源於賽迪顧問《核心系統升級選型參考》）
首先是數據層面，其主要包括數據一致性、數據安全性以及底層代碼安全性。數據一致性不僅侷限於事務發生時，還需要考慮數據庫是否具備多副本數據校驗、主備庫數據校驗、鏈式數據校驗以及數據定時校驗的能力；近年來國家高度重視數據安全性，數據庫需要具備讓數據資產避免未經授權的訪問、損壞或盜竊；底層代碼的安全性涉及軟件產品的本質安全，金融機構核心系統應優先選擇完全自主研發的數據庫，而非基於開源的數據庫。
數據層面的選型考量相當於“1”，數據庫只有在這個層面具備足夠的能力，後續擁有其他的“0”（如更高的性能、更低的成本等）纔有意義。
其次是功能層面，其主要包括兼容與遷移、雙寫及回遷、事務處理、大數據實時分析能力。金融機構的核心繫統如何有效降低數據遷移複雜度和遷移成本，主要依賴數據庫的兼容與遷移能力，尤其是Oracle的兼容能力；一旦出現問題需要異構數據庫切換或回滾，確保業務正常，這與數據庫的雙寫、回遷能力緊密相關；事務處理能力和大數據實時分析能力則是OLTP和HTAP。
最後是效果層面，其主要包括穩定性與可靠性等。穩定性與可靠性跟數據庫的高可用、高容災等特性緊密相關，RTO、RPO等是金融機構在選型時可考慮的可量化指標；在此基礎上，核心系統最好能在數據庫部署成本、使用成本均有所降低的同時，各項性能還有所提升。
七、典型金融場景實踐1.銀行
隨着金融數字化轉型的逐漸深入，銀行業產品百花齊放，不同銀行對於業務經營更多的是拼“軟實力”。從內部來說，銀行需要提升信用風險管控能力、提高優質資產率、滿足監管合規要求等；從外部來說，銀行需要通過設計特色化、差異化的營銷手段提升用戶體驗和用戶忠誠度，同時利用數字化手段通過全渠道爲用戶提供無處不在、觸手可及的全天候、全場景、全生命週期的金融服務。
無論是從內部還是外部，“軟實力”提升都需要藉助數字化能力得以實現。而作爲數字化轉型的關鍵環節，OceanBase在國有大型商業銀行、股份制商業銀行、城市商業銀行、農村商業銀行、省級農信社等經過多年打磨積累了相當豐富的經驗，助力銀行業務系統尤其是核心系統更好地承擔數字化轉型重任。
銀行業務系統按照用途可以分爲存款系統、貸款系統、客戶管理系統、渠道系統、會計系統、風險管理系統、內部支持系統等，典型的銀行系統業務全景架構如圖19所示。
圖19 典型的銀行系統業務全景架構
銀行核心系統是指銀行提供財務服務、進行日常操作的基礎軟件系統，通常包含客戶和機構管理、存款管理、貸款管理、產品管理、交易處理、支付和結算等，是銀行最重要的業務系統。
從銀行業務服務的角度，銀行核心系統主要包含ECIF、貸記核心、借記核心系統三部分，其中ECIF系統提供客戶信息的管理，貸記核心系統如信用卡系統、貸款系統等，借記核心系統即銀行卡核心系統，三大核心繫統按業務實現方式可以分爲跑批類場景和交易類場景。
（1）跑批類場景
跑批類場景天生就是高併發的聯機交易，最重要的是時效。若跑批時間過長，輕則造成客訴，重則導致資損，甚至出現輿情事件。
這類場景對數據庫處理能力的有效檢驗方式之一就是如何快速完成批量交易，因爲需要頻繁地對數據庫進行增刪改查，進行大量的I/O物理讀和邏輯讀計算操作，應用訪問數據庫的吞吐量也尤爲關鍵。集中式數據庫上性能的容量有限，跑批業務需要的時間缺乏彈性，一旦出現突發情況，可能留給跑批的應急處理時間有限。
原生分佈式數據庫利用多臺機器的併發能力，並通過彈性擴縮實現動態的資源調整，因而在跑批場景具備優勢。如避免分佈式事務和遠程訪問，讓所有服務器全部參與批量結息過程，提高處理速度；分散負載到多個節點，減少單一節點的壓力；迅速擴容以應對流量高峰，同時在低峰期自動縮減資源以節約成本；允許讀操作分散到多個副本，而寫操作則在主節點上進行，減少讀寫競爭等，大幅提升批量場景效率。
銀行在覈心繫統分佈式轉型中一般通過新老系統對比、銀行同業對比兩種方式來衡量。老核心（全棧國產分佈式升級前）新核心（全棧國產分佈式升級後）系統的跑批指標對比見表1，同等規模商業銀行日終批量、批量代發實際值對比見表2。
表1 老核心（全棧國產分佈式升級前）新核心（全棧國產分佈式升級後）系統的跑批指標對比
表2 同等規模商業銀行日終批量、批量代發實際值對比
綜上，在跑批場景中原生分佈式數據庫相較傳統集中式數據庫的優勢非常明顯，在銀行同業對比中相較傳統集中式數據庫或者基於MySQL二次開發的數據庫也具備明顯優勢。
（2）交易類場景
在交易類場景中，最重要的是單筆交易耗時和交易吞吐量。若單筆交易耗時過長，則影響用戶體驗；若性能容量的TPS不足，則會造成高併發場景下部分客戶的業務連續性無法保障。
伴隨新一代核心系統的分佈式轉型，分佈式數據庫在交易性能容量方面具有天然優勢。在單筆耗時方面，應用和數據庫同時轉型分佈式時耗時增加有限，業務上完全可接受。例如，某大型商業銀行信用卡核心轉型分佈式雖然從60毫秒增至了80毫秒，在耗時有限增長的情況下，提供了機房級容災能力，爲業務連續性提供更好的保障。
某商業銀行在覈心繫統交易類場景比對上更加精細化，其以一借一貸和混合壓測這兩種場景的壓測結果進行度量，並進行了同規模銀行的同業數據對比。如表3所示，該銀行的新一代核心系統在同規模銀行中處於領先地位，這也進一步印證了原生分佈式數據庫對新一代銀行核心系統的支撐能力。
表3 同等規模商業銀行一借一貸、混合壓測場景數據對比
在金融數字化轉型的浪潮中，銀行新一代核心系統中無論是跑批場景還是交易場景，原生分佈式數據庫都能夠爲業務提供更好的支撐力。某國有大行、常熟農商銀行、雲南紅塔銀行、深圳農商銀行等新一代核心系統，以及某國有大行ECIF系統等均選擇升級至原生分佈式數據庫。
2. 保險
近年來，保險行業出現了非常明顯的行業變革特徵，傳統保險的經營方式，無論壽險還是財險都難以實現大規模增長。數字經濟時代的到來讓這一趨勢更加明顯，倒逼各大保險機構從跑馬圈地式發展升級爲高質量發展。
粗放式地不計成本獲取客戶和保單已經成爲過去，從線下地推到線上獲客、從人海戰術到精英化代理人團隊、從單一化產品到綜合型/定製化產品、從單一保單銷售到客戶長期陪伴乃至發展多維高頻業務。
要做到這些，保險機構必須進行數字化轉型，通過IT戰略和商業戰略的有機結合，靈活響應業務需求、開發優質保險產品、提升服務質量和客戶滿意度、降低服務成本。保險機構的IT系統大致分爲三類，保險系統業務全景架構如圖20所示。
圖20 保險系統業務全景架構
在“互聯網+”的大背景下，保險機構應揚長避短，結合自身特點，借鑑互聯網金融的成功經驗，從傳統的煙囪式的IT架構轉變爲以“雲平臺底座+分佈式數據庫”爲基礎的一體化IT架構，從而完成業務模式的轉型，最終實現彎道超車。
遵循國家自主可控的戰略要求，各大保險機構也開始了新數據庫的升級，近兩年取得了不錯的成績，在不少系統積累了大量數據庫升級遷移的成功案例。但壽險、財險核心業務系統仍然是數據庫最後和最大的“攔路虎”，其難度超出其他系統不止一個數量級，是非常難啃的“硬骨頭”，所謂“行百里者，半於九十”。
（1）壽險核心場景
保險機構的壽險核心業務系統重構頻率比銀行低，很多都有超過10年，甚至20年的歷史，完全推翻、重構這些業務代碼難度和風險極高，可以說既是寶貴財富也是沉重負擔。壽險業務主要具有以下特點。
過去，壽險核心業務系統基本90%以上使用傳統集中式數據庫，面對以上業務特點，隨着數據經濟的加速前行，其在容量、性能、雲化、多模等方面都已經愈發力不從心。
一是複雜SQL、大數據量的性能挑戰。在大多數場景，OceanBase均能獲得和Oracle相似的性能；在某些特定場景，OceanBase可以通過併發獲得比Oracle更佳的性能。值得一提的是，我們在進行優化時可以直接參考Oracle的執行計劃，將之以hint的方式直接應用於OceanBase中，用於固化執行計劃不準的SQL語句，大大降低性能問題帶來的生產運行風險。
二是突發流量的挑戰。如果按流量最高峰來配置集羣資源，顯然是一種極大的資源浪費。我們在支持歷年“雙十一”的過程中，鍛煉出透明擴縮容的能力。在促銷活動前，可以提前將準備好的物理服務器或雲上ECS動態擴容到集羣中；活動結束後，再縮容將機器歸還，從容應對業務流量高峰。
某國有特大型保險機構的壽險核心系統數據庫升級至OceanBase後，最大化利用資源，通過動態彈性調整租戶計算資源，敏捷應對業務負載要求的變化，經受住“開門紅TPS 5萬+”、“QPS 21萬+”的嚴苛考驗，穩妥保障業務連續性和數據準確性。
某國有特大型保險機構核心業務羣的60多套系統，300多套Oracle歷時一年完成向OceanBase的遷移，數據庫存儲容量瘦身78%，數據庫軟硬件成本大幅縮減75%，實現RPO=0的最高級別容災能力，滿足國家級金融基礎設施要求。
（2）客服系統場景
客戶服務系統通常是保險機構關聯關係最爲複雜、商業數據庫綁定程度最深、業務影響最多的核心業務系統之一。秉承“以客戶爲中心”的理念，該系統除了提供7×24小時服務外，還具有以下特點。
一是數據量龐大：隨着互聯網保險業務的開展，客戶服務系統需要支持越來越多互聯網類型的業務，這些業務不僅數據量大，還有瞬時高併發的特點。
二是割接要求高：客戶服務系統上下游對接系統衆多，客戶服務系統停機窗口時間要求極短，對遷移及數據校驗都是挑戰。
以中國太保的“P17”爲例，其是產、壽、健康、長江等所有子公司客戶服務系統的整合，爲公司6地8個客服中心超過2000座席提供系統服務。與一般熱線系統相比，“P17”涵蓋了中國太保幾乎所有子公司業務的服務入口功能，包括車險報案、車險增值服務、非車人意報案、道路救援、壽險保單查詢、壽險保全受理、投保預約等，對接周邊系統超過200個。
“P17”對Oracle兼容性要求高。與其他保險核心系統一樣，挑戰最大的還是“P17”與原數據庫的深度綁定。“P17”對原數據庫特性使用非常深入，包括自定義鎖、自治事務、嵌套表、索引組織表、PLSQL包、物化視圖、DBlink、觸發器、系統視圖。其存儲過程數量龐大，總代碼量近百萬行。
“P17”周邊對接產品多。“P17”集成了大量周邊工具軟件和應用，與很多周邊軟件協同工作，如IBM Datastage、IBM Cognos等，這些軟件都利用了原數據庫很多特有的功能，更換數據庫後需要對這些軟件重新適配。
憑藉OceanBase的高度Oracle兼容性、完善的遷移工具鏈，經過近一年的技術攻堅，“P17”完全遷移到OceanBase，百萬行PL/SQL代碼平遷複用。
在全面升級後，原生分佈式數據庫的優異性能展現出來。中國太保在保持高運行性能、高可用能力的同時，數據庫軟件的運維費用大幅降低，每年可節省設備投入數億元。特別是OceanBase的高級壓縮技術，結合“數據庫瘦身”，將存儲容量節省80%以上。可以說，升級後的應⽤系統彈性擴縮容、處理速度、數據加⼯能⼒均實現⼤幅提升。
3.證券和基金
自券商的主要經營方式由網點營業部模式轉變爲總部集中模式，在集中交易系統的建設背景下，關係型數據庫的重要性愈加突出，以Oracle、DB2爲代表的數據庫產品幾乎佔據證券和基金的各類核心業務系統。
伴隨金融數字化的全面開啓，新形勢下行業規則不斷變化，證券和基金業務的創新爭分奪秒，精細化服務客戶成爲重中之重。傳統煙囪式、系統緊耦、信息分裂的系統架構已經無法適應當前的業務發展。
證券和基金行業的關鍵業務系統包括集中交易系統、理財系統、法人結算系統、第三方存管系統、開放式基金代銷系統、風險監控以及反洗錢系統、網上交易系統等7小類系統，此外，還包括反欺詐引擎、數據平臺、進件系統、催收/貸後系統、呼叫中心等。證券業務全景架構如圖21所示，基金業務全景架構如圖22所示。
圖21 證券業務全景架構
圖22 基金業務全景架構
核心系統整體上可分爲兩類，一類是以股票交易爲中心的在線類業務，另一類是以基金/資管爲中心的“T+1”業務。對於數據庫而言，前者強調極致的低延遲與高可用；後者則通常涉及批處理、大事務、複雜查詢、備份恢復，對數據庫的綜合能力有較高要求。
（1）UF3.0核心交易系統
證券機構的集中交易系統，對外與滬深兩個交易所的系統對接，對內則與其他各種系統對接，具有投資者開戶、證券交易委託和成交、各種維度的查詢等功能。其中“委託”和“成交”是最主要的功能，也稱爲“路由”功能，同時還有資金買空或證券賣空的“監控”功能，以及“查詢”功能。
傳統集中交易系統通常直接引入一體機解決性能問題，但是衆多系統仍以“豎井”的方式建設，配套硬件成本、部署成本等整體成本投入大。由於單體架構的先天限制，在容量和性能遇到瓶頸時無法橫向動態擴容，制約系統的整體處理能力。
恆生電子的UF3.0採用分佈式微服務架構實現交易、清算、管理的三大模塊，整體架構設計與OceanBase相契合，提升業務處理能力，加快交易結算速度，提高證券客戶滿意度。UF3.0業務架構如圖23所示。
圖23 UF3.0業務架構
招商證券、東方證券等券商公司新一代核心交易系統選用基於OceanBase 的UF3.0支持整體IT業務平臺，提供綜合金融服務。
以招商證券爲例，其OceanBase承載了包括 UF3.0、數據中臺服務、Level2 行情數據等共計百套業務系統。用“國產原生分佈式數據庫+國產服務器”替換“中高配x86服務器+傳統集中式數據庫”，節約整體擁有成本約70%。其中，UF3.0將原先分佈在不同數據庫的全量歷史數據集中到OceanBase，數據由原先的50TB壓縮到5TB，自此招商證券的用戶能夠直接查詢自開戶以來的全量歷史交易流水、進行遠期歷史查詢，不再需要臨櫃辦理，使用體驗顯著提升。
（2）ETF_TA系統
TA系統全稱爲開放式基金登記過戶系統，用於記錄投資者買入和賣出的基金份額，是基金公司的核心業務系統之一。TA系統和典型的OLTP業務（如在線聯機交易）不同，清算跑批必須在規定的窗口時間內完成。
同時，TA系統屬於比較複雜的“跑批”業務，涉及的數據量較大，計算邏輯也比較複雜，存在多表關聯和複雜查詢，並且步驟多。比如，清算過程中有串行的、複雜的對賬查詢，也有需要高併發的小事務清算，還涉及大量的文件導入導出。
因此，TA系統對數據庫的綜合要求較高，不僅要高穩定、高可靠，同時也要高性能。
OceanBase通過穩定的SQL引擎保障複雜查詢的執行效率，完全滿足系統的高併發、數據高並行的業務特性，通過多租戶架構（如圖24所示），支撐TA系統的分佈式微服務架構，提升資源利用率。分佈式數據庫的擴展性，讓TA系統跑批效率隨數據庫節點增加而提升，未來基金用戶數、交易數上升時，能在不調整業務架構的前提下，通過數據庫層的橫向擴展支撐業務發展。
圖24 OceanBase多租戶的TA數據分佈
易方達基金通過OceanBase的多租戶與TA分片對應，分別設立了賬戶、清算、匯聚三類租戶。將來如果業務量增長，擴容增加服務器後，可以把其中幾個租戶在線遷移到新的服務器上，這樣每個租戶的可用資源增加，對業務而言則無感。不僅如此，和從一開始就...