5月15日，華為常務董事、ICT戰略與MarketingQuattroporte汪濤在眾多國內外媒體見證下，正式面向全球推出了GaussDB資料庫。
歷時9年的研發和打磨，終於掀開了GaussDB資料庫的神秘面紗，讓之走到了臺前。
華為做GaussDB的真正原因是什麼？
GaussDB是個怎樣的資料庫？
又是怎樣煉成的？
近日，GaussDB研發團隊的多位骨幹成員與筆者展開了深入交流，介紹了GaussDB的來龍去脈，以及背後艱辛的研發故事。
其實，GaussDB並非是一個產品，而是系列產品的統稱，目前GaussDB至少包含有3款產品，有面向OLTP的資料庫，面向OLAP的資料倉庫，還有面向事務和分析混合處理的HTAP資料庫。
做資料庫核心開發如在刀尖上跳舞
做資料庫核心開發如在刀尖上跳舞，壓力很大，但凡在核心架構與機制制定上有一絲沒有考慮清楚，那麼上線就一定會出問題，這會導致嚴重後果，因為一旦確定的方向進行不下去，就會導致推倒重來。一位核心研發工程師對筆者說。
2007年，因為電信實時計費專案困境，華為開始組織人手研發記憶體資料庫，專案代號GMDB，這是可追溯到的華為最早的資料庫研發記錄。
當時，華為決定研發記憶體資料庫的想法並不高大上，而是很單純，完全不是外界所猜想的搞個數據庫去售賣並幹掉誰，純粹只是因為在電信計費領域，華為解決方案找不到能與之較好契合的資料庫，僅此而已。
眾所周知，電信行業對資料庫要求較高，尤其是可用性，定製化需求較多，涉及改動工作量大，而採用國外資料庫，讓原廠來配合改動，人家未必會配合。因此，無奈下，華為被迫走上了開發資料庫的道路，以此來提升解決方案的競爭力。
不過，2007年的GMDB並沒有取得大規模商用，只在小範圍內進行試用，但這個版本卻鍛鍊了一大批人。當時，國內對資料庫核心開發知之甚少，有經驗者寥寥，都是摸著石頭過河。
但有苗不愁長，到了2010年，華為資料庫研發團隊開始對2007年版本進行全面重構，並寫下了重構版本的第一行程式碼：“typedef struct st_database{...}database_t;”，資料庫物件的定義。
從這個版本開始，華為資料庫的定位已經不再侷限於記憶體資料庫，而是在向通用關係型資料庫逐漸轉變，重構過程中，開始融入大量非記憶體資料庫的特性，這就是GaussDB OLTP的前身。
重構後的版本，質量上取得了顯著提升，2012年，GMDB開始大規模商用，主要應用於電信計費領域，同時，在華為內部，眾多配套的解決方案也開始使用GMDB。
對於每一個剛誕生的新產品，降落傘自己先跳，“狗糧”一定是華為自己先吃。一位核心研發工程師對筆者說。
GaussDB對外輸出之前，華為也是從服務內部客戶開始。但在華為，內部客戶遠比外部客戶更苛刻更殘酷。“往往只要有一點不滿意，內部客戶就會直接一個郵件捅到Quattroporte或副Quattroporte那裡，連個喘息的機會都不給你，那是真的要命啊！”一位核心研發工程師心有餘悸地回憶說。在服務內部客戶的過程中，GaussDB研發團隊總是膽戰心驚。
因此，從2013年規模上線到2019年，6年的時間裡，GaussOLTP資料庫沒出過任何問題，這一點讓團隊成員極為自豪。
華為強大的研發平臺為Gauss OLTP資料庫的產品質量提供了強有力的保障。在軟硬體基礎設施方面，華為過去幾十年的積累非常深厚，有著整套完整的標準流程和研發支撐體系。Gauss OLTP資料庫首席架構師告訴筆者，高手畢竟是少數，一個產品的開發不能完全依賴編碼高手，在團隊作戰的時候，一個大的研發平臺至關重要，這就是華為資料庫的最大優勢。
2017年，華為與招商銀行開始就GaussDB進行聯合創新；2018年3月，Gauss OLTP資料庫開始在招商銀行綜合支付交易系統成功上線投產，順利承接招商銀行 “手機銀行”和“掌上生活”兩大App交易流水流量，日均請求量高達8500萬，峰值TPS達到3500，截至目前，系統穩定執行。
如今招商銀行的信用卡風警系統、零售實時風險警示系統、手機銀行收支賬單系統、一網通使用者日誌系統、客戶經理平臺系統、供應鏈金融服務平臺系統、分散式交易鏈路追蹤系統等多套業務系統已進入對接開發階段，預計2019年底前將有17套系統採用GaussDB並投產上線。
MPP 分散式並行踩過的坑
華為真正想做資料庫，把資料庫作為一個完整的產品來做，其實是始於2011年底。當時，華為成立了2012實驗室，也有了高斯實驗室和Gauss DB。
就在這年，華為同時啟動了面向OLAP資料庫的研發預演，並足足用了3年的時間來預演程式碼和驗證架構的可行性。研發團隊分析了業界資料庫相關理論和技術，在基於傳統關係型資料庫的SQL引擎和事務強一致性等基礎上，進行了分散式、平行計算的改造。2014年，孵化出GaussOLAP資料庫第一個產品版本。
2015年，華為與工商銀行一起聯合創新，Gauss OLAP資料庫也開始在工商銀行內上線，並逐漸取代某國外品牌資料倉庫。從一開始的十幾個節點到現在的單個叢集超過二百個節點，這大概是目前國內資料倉庫中最大的。事實上GaussOLAP資料庫的產品交付過程也並非一帆風順，也是經歷了諸多磨難，尤其是在MPP大規模通訊上踩過不少坑。
Gauss OLAP資料庫的一位核心研發工程師說：
“
最初，Gauss OLAP資料庫採用的是SCTP通訊協議。當時，工商銀行的EDW資料倉庫已經有上百個節點，再往上擴容，通訊就面臨很大的挑戰。
”
因為，研發團隊在實驗室測試發現，隨著叢集的擴大，SCTP協議存在BUG，問題嚴重，一方面是穩定性，通訊變得很不穩定，丟包嚴重；其次是效能，在大壓力下，效能變得非常不穩定，而且儲存空間已經達到70%了，照這樣下去， 再有幾個月叢集空間肯定就不夠用了，業務就會停擺責任之大，誰也承擔不起。怎麼辦？
經過與客戶溝通，工商銀行要求華為GaussOLAP資料庫團隊必須儘快擴容一倍以上的節點。
這樣的故事，在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的一個非常有差異化競爭力的特性。
搞資料庫，華為是認真的
不過，華為將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%是從事軟體研發人員。這是汪濤在釋出會上，接受媒體採訪時給出的資料。
華為在資料庫領域已經投入了千人左右的研發工程師，這一規模是很多資料庫廠商難忘項背的。不過，華為做資料庫並不是為替代誰，目前華為內部也在使用其他的資料庫，以後也依然會繼續用。華為做GaussDB資料庫的目的，一方面是對華為AI戰略的承接，一方面是為了構築硬體+軟體+生態的戰略佈局。
截止目前，華為GaussDB資料庫和FusionInsight大資料平臺已經應用於全球60個國家及地區，服務於1500多個客戶，擁有500多家商業合作伙伴，並廣泛應用於金融、運營商、政府、能源、醫療、製造、交通等多個行業。
GaussDB也具有云上的版本。目前華為雲已經發布了13款資料庫服務，其中DWS資料倉庫服務就是GaussDB OLAP資料庫的雲化版本，為行業客戶提供雲上資料倉庫服務。華為還將繼續培養基於GaussDB資料庫的生態環境，讓更多的IT公司可以基於新資料庫開發相應的產品，讓GaussDB資料庫在更大範圍內得到應用。
還記得華為GaussDB釋出影片中的一行文字：向數學致敬、向科學家致敬。GaussDB，不僅蘊含著華為對數學和科學的敬畏，也承載著華為對基礎軟體的堅持和夢想。從GaussDB工程師身上，我們看到了一種“軸”，這是對技術的精益求精和偏執。正是這種“軸”，才能讓這群工程師們堅持12年，歷經坎坷，最終在被譽為基礎軟體“CROWN上明珠”的資料庫領域中一舉突圍，破繭成蝶。
華為智慧資料和儲存。
5月15日，華為常務董事、ICT戰略與MarketingQuattroporte汪濤在眾多國內外媒體見證下，正式面向全球推出了GaussDB資料庫。
歷時9年的研發和打磨，終於掀開了GaussDB資料庫的神秘面紗，讓之走到了臺前。
華為做GaussDB的真正原因是什麼？
GaussDB是個怎樣的資料庫？
又是怎樣煉成的？
近日，GaussDB研發團隊的多位骨幹成員與筆者展開了深入交流，介紹了GaussDB的來龍去脈，以及背後艱辛的研發故事。
其實，GaussDB並非是一個產品，而是系列產品的統稱，目前GaussDB至少包含有3款產品，有面向OLTP的資料庫，面向OLAP的資料倉庫，還有面向事務和分析混合處理的HTAP資料庫。
做資料庫核心開發如在刀尖上跳舞
做資料庫核心開發如在刀尖上跳舞，壓力很大，但凡在核心架構與機制制定上有一絲沒有考慮清楚，那麼上線就一定會出問題，這會導致嚴重後果，因為一旦確定的方向進行不下去，就會導致推倒重來。一位核心研發工程師對筆者說。
2007年，因為電信實時計費專案困境，華為開始組織人手研發記憶體資料庫，專案代號GMDB，這是可追溯到的華為最早的資料庫研發記錄。
當時，華為決定研發記憶體資料庫的想法並不高大上，而是很單純，完全不是外界所猜想的搞個數據庫去售賣並幹掉誰，純粹只是因為在電信計費領域，華為解決方案找不到能與之較好契合的資料庫，僅此而已。
眾所周知，電信行業對資料庫要求較高，尤其是可用性，定製化需求較多，涉及改動工作量大，而採用國外資料庫，讓原廠來配合改動，人家未必會配合。因此，無奈下，華為被迫走上了開發資料庫的道路，以此來提升解決方案的競爭力。
不過，2007年的GMDB並沒有取得大規模商用，只在小範圍內進行試用，但這個版本卻鍛鍊了一大批人。當時，國內對資料庫核心開發知之甚少，有經驗者寥寥，都是摸著石頭過河。
但有苗不愁長，到了2010年，華為資料庫研發團隊開始對2007年版本進行全面重構，並寫下了重構版本的第一行程式碼：“typedef struct st_database{...}database_t;”，資料庫物件的定義。
從這個版本開始，華為資料庫的定位已經不再侷限於記憶體資料庫，而是在向通用關係型資料庫逐漸轉變，重構過程中，開始融入大量非記憶體資料庫的特性，這就是GaussDB OLTP的前身。
重構後的版本，質量上取得了顯著提升，2012年，GMDB開始大規模商用，主要應用於電信計費領域，同時，在華為內部，眾多配套的解決方案也開始使用GMDB。
對於每一個剛誕生的新產品，降落傘自己先跳，“狗糧”一定是華為自己先吃。一位核心研發工程師對筆者說。
GaussDB對外輸出之前，華為也是從服務內部客戶開始。但在華為，內部客戶遠比外部客戶更苛刻更殘酷。“往往只要有一點不滿意，內部客戶就會直接一個郵件捅到Quattroporte或副Quattroporte那裡，連個喘息的機會都不給你，那是真的要命啊！”一位核心研發工程師心有餘悸地回憶說。在服務內部客戶的過程中，GaussDB研發團隊總是膽戰心驚。
因此，從2013年規模上線到2019年，6年的時間裡，GaussOLTP資料庫沒出過任何問題，這一點讓團隊成員極為自豪。
華為強大的研發平臺為Gauss OLTP資料庫的產品質量提供了強有力的保障。在軟硬體基礎設施方面，華為過去幾十年的積累非常深厚，有著整套完整的標準流程和研發支撐體系。Gauss OLTP資料庫首席架構師告訴筆者，高手畢竟是少數，一個產品的開發不能完全依賴編碼高手，在團隊作戰的時候，一個大的研發平臺至關重要，這就是華為資料庫的最大優勢。
2017年，華為與招商銀行開始就GaussDB進行聯合創新；2018年3月，Gauss OLTP資料庫開始在招商銀行綜合支付交易系統成功上線投產，順利承接招商銀行 “手機銀行”和“掌上生活”兩大App交易流水流量，日均請求量高達8500萬，峰值TPS達到3500，截至目前，系統穩定執行。
如今招商銀行的信用卡風警系統、零售實時風險警示系統、手機銀行收支賬單系統、一網通使用者日誌系統、客戶經理平臺系統、供應鏈金融服務平臺系統、分散式交易鏈路追蹤系統等多套業務系統已進入對接開發階段，預計2019年底前將有17套系統採用GaussDB並投產上線。
MPP 分散式並行踩過的坑
華為真正想做資料庫，把資料庫作為一個完整的產品來做，其實是始於2011年底。當時，華為成立了2012實驗室，也有了高斯實驗室和Gauss DB。
就在這年，華為同時啟動了面向OLAP資料庫的研發預演，並足足用了3年的時間來預演程式碼和驗證架構的可行性。研發團隊分析了業界資料庫相關理論和技術，在基於傳統關係型資料庫的SQL引擎和事務強一致性等基礎上，進行了分散式、平行計算的改造。2014年，孵化出GaussOLAP資料庫第一個產品版本。
2015年，華為與工商銀行一起聯合創新，Gauss OLAP資料庫也開始在工商銀行內上線，並逐漸取代某國外品牌資料倉庫。從一開始的十幾個節點到現在的單個叢集超過二百個節點，這大概是目前國內資料倉庫中最大的。事實上GaussOLAP資料庫的產品交付過程也並非一帆風順，也是經歷了諸多磨難，尤其是在MPP大規模通訊上踩過不少坑。
Gauss OLAP資料庫的一位核心研發工程師說：
“
最初，Gauss OLAP資料庫採用的是SCTP通訊協議。當時，工商銀行的EDW資料倉庫已經有上百個節點，再往上擴容，通訊就面臨很大的挑戰。
”
因為，研發團隊在實驗室測試發現，隨著叢集的擴大，SCTP協議存在BUG，問題嚴重，一方面是穩定性，通訊變得很不穩定，丟包嚴重；其次是效能，在大壓力下，效能變得非常不穩定，而且儲存空間已經達到70%了，照這樣下去， 再有幾個月叢集空間肯定就不夠用了，業務就會停擺責任之大，誰也承擔不起。怎麼辦？
經過與客戶溝通，工商銀行要求華為GaussOLAP資料庫團隊必須儘快擴容一倍以上的節點。
這樣的故事，在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的一個非常有差異化競爭力的特性。
搞資料庫，華為是認真的
不過，華為將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%是從事軟體研發人員。這是汪濤在釋出會上，接受媒體採訪時給出的資料。
華為在資料庫領域已經投入了千人左右的研發工程師，這一規模是很多資料庫廠商難忘項背的。不過，華為做資料庫並不是為替代誰，目前華為內部也在使用其他的資料庫，以後也依然會繼續用。華為做GaussDB資料庫的目的，一方面是對華為AI戰略的承接，一方面是為了構築硬體+軟體+生態的戰略佈局。
截止目前，華為GaussDB資料庫和FusionInsight大資料平臺已經應用於全球60個國家及地區，服務於1500多個客戶，擁有500多家商業合作伙伴，並廣泛應用於金融、運營商、政府、能源、醫療、製造、交通等多個行業。
GaussDB也具有云上的版本。目前華為雲已經發布了13款資料庫服務，其中DWS資料倉庫服務就是GaussDB OLAP資料庫的雲化版本，為行業客戶提供雲上資料倉庫服務。華為還將繼續培養基於GaussDB資料庫的生態環境，讓更多的IT公司可以基於新資料庫開發相應的產品，讓GaussDB資料庫在更大範圍內得到應用。
還記得華為GaussDB釋出影片中的一行文字：向數學致敬、向科學家致敬。GaussDB，不僅蘊含著華為對數學和科學的敬畏，也承載著華為對基礎軟體的堅持和夢想。從GaussDB工程師身上，我們看到了一種“軸”，這是對技術的精益求精和偏執。正是這種“軸”，才能讓這群工程師們堅持12年，歷經坎坷，最終在被譽為基礎軟體“CROWN上明珠”的資料庫領域中一舉突圍，破繭成蝶。
華為智慧資料和儲存。