華為“高斯”戰記

做資料庫核心開發如在刀尖上跳舞，壓力很大，但凡在核心架構與機制制定上有一絲一毫沒考慮清楚，那麼，上線就一定會出問題，後果嚴重。因為，一旦確定的方向進行不下去，就會導致推倒重來。一位核心研發工程師對筆者說。

2007年，因為電信實時計費專案困境，華為開始組織人手研發記憶體資料庫，專案代號GMDB，這是可追溯華為最早的資料庫研發記錄。

當時，華為決定自研記憶體資料庫的想法並不高大上，而是很單純，完全不是外界所猜想的搞個資料庫去售賣並幹掉誰，純粹只是因為在電信計費領域，華為解決方案找不到能與之很好契合的資料庫，僅此而已。

眾所周知，電信行業對資料庫要求較高，尤其是可用性，定製化需求較多，涉及改動工作量大，而採用國外資料庫，讓原廠來配合改動，人家未必會配合。因此，無奈下，華為被迫走上了自研資料庫的道路，以此來提升自身解決方案的競爭力。

不過，2007年的GMDB並沒有取得大規模商用，只在小範圍內進行試用，但這個版本卻鍛鍊了一大批人。當時，國內對資料庫核心開發知之甚少，有經驗者寥寥，都是摸著石頭過河。

但有苗不愁長，到了2010年，華為資料庫研發團隊開始對2007年版本進行全面重構，並寫下了重構版本的第一行程式碼：

“typedef struct st_database{...}database_t;”

資料庫物件的定義。

從這個版本開始，華為資料庫的定位已經不再僅侷限於記憶體資料庫，而是在向通用關係型資料庫逐漸轉變，重構過程中，開始融入大量非記憶體資料庫的特性，這就是Gauss OLTP資料庫的前身。

重構後的版本，質量上取得了顯著提升，2012年，GMDB開始大規模商用，主要應用於電信計費領域，同時，在華為內部，眾多配套的解決方案也開始使用GMDB。

對於每一個剛誕生的新產品，華為都不會先讓客戶當“小白鼠”，“狗糧” 華為一定是自己先吃，一位核心研發工程師對筆者說。

GaussDB對外輸出之前，華為也是從服務內部開始。但在華為，內部客戶遠比外部客戶更苛刻更殘酷。“往往只要有一點不滿意，內部客戶就會直接一個郵件捅到總裁或副總裁那裡，連個喘息的機會都不給你，那是真的要命啊！”，一位核心研發工程師心有餘悸的回憶說。因此，在服務內部客戶的過程中，GaussDB研發團隊總是膽戰心驚。

為了讓Gauss OLTP資料庫的核心變得更穩定，研發團隊創造了最暴力的測試方法，並立下規矩，誰發現的問題，用例就用誰的名字來命名。在暴力測試方法及命名規則的雙重刺激下，從剛開始幾乎每半天就能測出問題，到之後一個周甚至一個月才能發現一個問題。正是這樣一步步的積累下來，讓Gauss OLTP資料庫的核心變得越來越強壯和穩健。因此，從2013年規模上線到2019年，6年的時間裡，Gauss OLTP資料庫沒出過任何問題，這一點讓團隊成員極為自豪。

華為強大的研發平臺一直是外界所公認的，而正是基於強大的研發平臺為Gauss OLTP資料庫的產品質量提供了強有力的保障。在軟硬體基礎設施方面，華為過去幾十年的積累非常深厚，有著整套完整的標準流程和研發支撐體系。Gauss OLTP資料庫首席架構師告訴筆者，高手畢竟是少數，一個產品的開發不能完全依賴編碼高手，在團隊作戰的時候，一個大的研發平臺至關重要，這就是華為資料庫的最大優勢。

2017年，華為與招商銀行開始就GaussDB進行聯合創新；2018年3月，Gauss OLTP資料庫開始在招商銀行綜合支付交易系統成功上線投產，順利承接招商銀行 “手機銀行”和“掌上生活”兩大App交易流水流量，日均請求量高達8500萬，峰值TPS達到3500，截至目前，系統穩定執行。

如今招商銀行的信用卡風警系統、零售實時風險警示系統、手機銀行收支賬單系統、一網通使用者日誌系統、客戶經理平臺系統、供應鏈金融服務平臺系統、分散式交易鏈路追蹤系統等多套業務系統已進入對接開發階段，預計2019年底前將有17套系統採用GaussDB並投產上線。

華為真正想做資料庫，把資料庫作為一個完整的產品來做，其實是始於2011年底。當時，華為成立了2012實驗室，也有了高斯實驗室和Gauss DB。

就在這年，華為同時啟動了面向OLAP資料庫的研發預演，並足足用了3年的時間來預演程式碼和驗證架構的可行性。研發團隊分析了業界資料庫相關理論和技術，在基於傳統關係型資料庫的SQL引擎和事務強一致性等基礎上，進行了分散式、平行計算的改造。2014年，孵化出Gauss OLAP資料庫第一個產品版本。

2015年，華為與工商銀行一起聯合創新，Gauss OLAP資料庫也開始在工商銀行內上線，並逐漸取代某國外品牌資料倉儲。從一開始的十幾個節點到現在的單個叢集超過二百個節點，這大概是目前國內資料倉儲中最大的。事實上Gauss OLAP資料庫的產品交付過程也並非一帆風順，也是經歷了諸多磨難，尤其是在MPP大規模通訊上踩過不少坑。

“最初，Gauss  OLAP資料庫採用的是SCTP通訊協議。當時，工商銀行的EDW資料倉儲已經有上百個節點，再往上擴容，通訊就面臨很大的挑戰”，Gauss OLAP資料庫的一位核心研發工程師說。

因為，研發團隊在實驗室測試發現，隨著叢集的擴大，SCTP協議存在BUG，問題嚴重，一方面是穩定性，通訊變得很不穩定，丟包嚴重，其次是效能，在大壓力下，效能變得非常不穩定，而且儲存空間已經達到70%了，照這樣下去， 再有幾個月叢集空間肯定就不夠用了，業務就會停擺責任之大，誰也承擔不起。怎麼辦？

經過與客戶溝通，工行要求華為Gauss OLAP資料庫團隊必須儘快擴容一倍以上的節點。

此時，整個研發團隊的壓力可想而知，團隊內部經過了無數次激烈的討論後，最終決定採用自研的多流代理通訊技術重構解決該問題。而這一重構，前後就花了半年多時間，最終擴容成功，確保了工行業務的穩定執行。

這樣的故事，在Gauss  OLAP資料庫產品化的過程中不勝列舉。“沒有以客戶為中心的理念，沒有像工行這樣優質客戶的積極反饋與配合，就不會有今天成熟可靠的Gauss OLAP資料庫”，這位工程師說。

而在核心研發過程中，對研發團隊而言，最大的痛苦莫過於完全無法預知外部客戶會怎樣去使用GaussDB，客戶並不會像內部客戶嚴格按照規範來，因此，當出現問題時，定位問題復現問題就顯得尤為重要，因為，只有定位到問題才能對症下藥，如果連故障原因都找不到，解決問題也就無從談起。

華為在資料庫核心構建中，有著非常嚴格的要求，一旦發現的問題被解決後，一定要覆盤，解決問題一定是經過嚴格推匯出來的，如果問題解決過程含糊不清，或稀裡糊塗的把問題解決了，這在華為是絕對不行的。

在所有測試中發現的問題，規範要求都必須要放入CI（資料庫用例全集）裡，這樣CI就會被不斷補充。“CI就像一道‘門禁’，資料庫每一個版本的釋出，必須要透過十年所積累的所有用例，只要一個沒透過，就甭想釋出。”

讓工程師們印象最為深刻的是一次定位分散式事務一致性問題， 各種DDL, DML 高併發執行， 每隔幾分鐘，隨機Kill 資料節點程式，驗證實時校驗資料的一致性長期穩定執行。

開始一切正常，但就在第17天的時候，測試發現有瞬間資料不一致問題，Log裡並沒有足夠定位資訊，也無法復現，定位了好幾天沒有進展，儲存引擎團隊的核心開發人員都很沮喪。

於是團隊自行封閉會議，開始對MVCC機制，CSN可見性判斷邏輯, Prune清理記錄歷史版本的邏輯做了逐行程式碼排查分析，結合log, 模擬並行執行的時序，最終找到了根因，Prune記錄的歷史版本過早導致的問題。 

也正是基於此，促使Gauss OLAP資料庫團隊開始思考併發場景測試方法如何才能更有效，因為是併發時序問題，出問題的時間視窗是很難卡到的，要在程式碼裡模擬觸發隨機異常且控制其他執行緒的時序，才能讓測試覆蓋更全面，而這種測試方法幫助研發團隊發現和解決了很多問題。

2017年，華為又啟動了面向事務和分析混合處理的資料庫研發。2018年，華為第一個Gauss  HATP資料庫問世，併成功落地中國民生銀行。據悉，民生銀行採用了GaussDB分散式資料庫+ARM伺服器的全棧解決方案，從資料庫層面解決了可擴充套件性問題，降低了應用分散式改造的難度，已應用於一卡通、貴金屬模擬交易等交易類系統，是國產資料庫在銀行交易類系統的首次商用。

GaussDB有一個特性，叫邏輯叢集，可以實現多個業務系統的統一管理，計算彈性共享。這是個對客戶非常有價值的特性，也符合客戶雲化多租戶的業務演進趨勢。但就是這樣一個非常有價值的特性，前期的規劃也是一路坎坷。

這一個特性最初由某個核心工程師提出，起初並不為團隊一些成員所認可，認為這個特性並沒有什麼價值。

後來，GaussDB產品管理團隊經過大量客戶的走訪，對客戶業務系統的痛點、需求、以及未來發展趨勢進行了詳細的梳理，發現隨著海量資料的爆炸式增長，資料分析的訴求越來越旺盛，客戶分析系統也越來越多，面臨的運維管理複雜性也就越來越高。同時，雲化也是一個趨勢，很多客戶希望能夠基於雲化模式建設資料分析系統，能夠實現資源彈性共享，而邏輯叢集的特性恰好可以完美的解決客戶的業務訴求。

最終，產品管理團隊內部達成一致。如今，這個特性已經成為GaussDB的一個非常有差異化競爭力的特性。

不過，華為將GaussDB定位於AI-Native資料庫而非Cloud-Native資料庫，這不僅是一種升維，更是源於GaussDB實現的兩大革命性突破：其一，AI in DB，首次將 AI 技術引入了GaussDB全系列產品核心中，實現自運維、自管理、自調優、故障自診斷和自愈，調優效能比業界提升60%以上。其二，DB for AI，GaussDB資料庫適配AI的執行。使用者可以透過資料庫語言來方便地使用AI，降低AI使用門檻，實現普惠AI。同時，GaussDB 透過異構計算創新框架，充分發揮了x86、ARM、GPU、NPU多種算力優勢，在權威標準測試集TPC-DS上，效能比業界提升50%。

華為GaussDB希望透過智慧、異構、融合這三個方面，重新定義資料處理平臺。

華為以硬體聞名，因此，很多人會質疑華為的軟體研發能力，事實上，在華為8萬多研發工程師中，有70%是從事軟體研發人員。這是汪濤在釋出會上，接受媒體採訪時給出的資料。

華為在資料庫領域已經投入了千人左右的研發工程師，這一規模是很多資料庫廠商難忘項背的。不過，華為做資料庫並不是為替代誰，目前華為內部也在使用其他的資料庫，比如Oracle，SQL Server，MySQL等，以後也依然會繼續用。華為做GaussDB資料庫的目的，一方面是對華為AI戰略的承接，一方面是為了構築硬體+軟體+生態的戰略佈局。

截止目前，華為GaussDB資料庫和FusionInsight大資料平臺已經應用於全球60個國家及地區，服務於1500多個客戶，擁有500多家商業合作伙伴，並廣泛應用於金融、運營商、政府、能源、醫療、製造、交通等多個行業。

GaussDB也具有云上的版本。目前華為雲已經發布了13款資料庫服務，其中DWS資料倉儲服務就是GaussDB OLAP資料庫的雲化版本，為行業客戶提供雲上資料倉儲服務。華為還將繼續培養基於GaussDB資料庫的生態環境，讓更多的IT公司可以基於新資料庫開發相應的產品，讓GaussDB資料庫在更大範圍內得到應用。

還記得華為GaussDB釋出影片中的一行文字：向數學致敬、向科學家致敬。GaussDB，不僅蘊含著華為對數學和科學的敬畏，也承載著華為對基礎軟體的堅持和夢想。

從GaussDB工程師身上，我看到了一種“軸”，這是對技術的精益求精和偏執。這正是這種“軸”，才能讓這群工程師們堅持12年，歷經坎坷，最終在被譽為基礎軟體“皇冠上明珠”的資料庫領域中一舉突圍，破繭成蝶。