華為CloudNative分散式資料庫技術解析

【IT168 專稿】 本文根據Calvin Sun在2018年5月11日【第九屆中國資料庫技術大會】現場演講內容整理而成。

講師簡介：Calvin Sun， 華為雲資料庫首席架構師。Calvin Sun於2017年10月加入華為加拿大多倫多研究所，目前擔任Cloud BU雲資料庫首席架構師。Calvin有20多年的資料庫核心開發經驗，曾擔任過Oracle雲服務團隊MySQL雲服務高階顧問;是Twitter MySQL核心團隊的負責人;也曾擔任 Oracle InnoDB開發團隊負責人，期間帶領團隊負責了InnoDB MySQL 5.5和5.6版本的開發。更早的時候，他還擋任MySQL儲存引擎開發團隊的負責人。Calvin曾在多個資料庫會議上做過專題演講。

摘要：

在雲時代，企業IT業務走向跨地區、全球化部署，IT應用軟體逐漸雲化、分散式化，要求資料庫也要基於雲場景架構設計，具備跨地區分散式部署的能力。華為Cloud Native分散式資料庫正是這樣的一款新型資料庫。在這次講座中，將簡要介紹其高可靠、高效能、易擴充套件等金融級的關鍵特性，並重點剖析其技術原理，最後還將深入揭開其背後的技術內幕。

分享大綱：

1、金融行業雲技術發展現狀;

2、雲資料庫發展歷程;

3、高可用架構實踐。

正文：

1、金融行業雲技術發展現狀

2018年中國資訊通訊學院公佈了一份統計資料。資料顯示：大概41%的金融企業在用雲端計算，還有46%是計劃使用。這對於雲端計算運營商來說，說明整個市場存在著很大的發展機會。

另外，從資料庫應用情況看，主要是Oracle、DB2、MySQL和PostgreSQL。其中Oracle佔比為62.61%，DB2佔比為21.8%，MySQL佔比為15.23%，PostgreSQL佔6.76%，其他佔比7.88%。由於金融行業對資料庫要求比較高，所以Oracle是首選。但是現在來看，尤其隨著雲環境的成熟，AWS、阿里、華為等企業都基於MySQL在做雲部署。在今後的幾年內，MySQL大有靠前之勢。

資料還顯示，金融行業對於雲端計算有著特定的行業要求。大概67.81%的企業希望縮短應用部署時間;62.56%的企業希望節約成本;60.94%的企業希望在服務安全性上有保障。

上述這些資料，對於我們雲服務商來說，有很大的參考作用。對於華為來說，這幾年一直致力於雲端。華為的策略是，提供雲服務的“黑土地”，即提供基礎設施服務。不同的應用服務提供商可以基於華為提供的底層技術平臺來為使用者提供服務。

2017年11月份，華為和招商銀行共同成立了“分散式資料庫聯合創新實驗室”。這將是華為雲在金融行業的樣板，雙方將共同應對“Cloud First”的挑戰。利用雲、大資料、人工智慧先進技術，藉助領先的金融業務實踐和優秀資源，以及在分散式資料庫上積極探索，雙方為客戶提供普惠、個性化、智慧化的金融服務。

2、雲資料庫發展歷程

在傳統資料庫中，儲存和計算都是一體模式，一主多輔的架構。如果一個主機宕掉，那麼備機就會替代主機。這種架構在很多情況下還算實用，但是在金融這種強調高可靠性、資料量大的行業，傳統資料庫架構很難支撐。尤其，在主機和備機切換的時候，要花很長時間，還可能會造成資料丟失。

最近幾年有幾個大的趨勢，特別是在雲端。

第一，資料和儲存的分離。Gartner有份資料，到2019年，90%以上的雲資料庫都會戰略性地採取資料和儲存的分離。如果你不這樣做，就意味著被淘汰。這種說法可能存在著誇張的成份，但是這確實是不可忽略的趨勢。

第二，硬體的進步。在CPU、儲存、網路方面，都有大的改進，尤其在GPU、FPGA方面，進步明顯。如何藉助這些硬體的發展來提高雲資料庫的效能?這是我們在設計新的資料庫時，必須要考量的因素。

第三，人工智慧和機器演算法的提高。AI和機器學習，也是雲資料庫開發重點要考慮的問題。

那麼，最近幾年，雲資料庫一些先驅都做了哪些事情呢?

1)、AWS Aurora

Aurora是Amazon為雲端計算而專門定製的一款關係型資料庫，於2014年底釋出，其目標主要是最小化網路IO，提升系統的可擴充套件性與可用性。Aurora的設計哲學是log is database，對資料的更改只寫日誌，也即write-once。Aurora系統設計人員認為傳統的資料庫不論如何擴充套件都在複製整個系統棧，在不同的層面做耦合;為了更好地適應雲端計算，他們認為應該將資料庫系統這個“盒子”開啟，把計算和儲存分離，在不同的層面進行擴充套件。Aurora將恢復子系統委託給底層可靠的儲存系統，依賴這個來保障系統服務層級(Service Level Agreement, SLA)。這種方式大大減少了網路流量的使用，後來很多企業都想模仿Aurora，做類似的架構。

2)、阿里的PolarDB

PoalrDB，最大的特點也是計算和儲存的分離，但是和AWS的Aurora有些不同。頁面依然是從計算節點寫到儲存節點，對於網路的要求相對較高。但是減少了很多使用者狀態和系統狀態的切換，資料庫做了很多IO最佳化。另外，主庫透過RDMA將日誌資料傳送到儲存節點的記憶體中，儲存節點之間再透過RDMA互相複製，每個儲存節點用SPDK將資料寫入NVMe介面的儲存介質裡，整個過程CPU不用訪問被同步的資料塊(Payload)，實現資料零複製。

3)華為Cloud Native

這種計算和儲存分離的模式，華為也在做。在設計Cloud Native資料庫的時候，就考慮到靈活性需求，包括主備的切換和節點的增加等，把更多操作下沉。華為Cloud Native在硬體方面有很強大的團隊，和華為儲存有深度合作，儲存部門提供了專用平臺，把資料庫本身的操作下沉到儲存節點。華為Cloud Native最大化地利用了ssd的屬性，提升了資料庫的效能。另外，還有多租戶的考慮。利用新的網路技術，包括人工智慧技術，幫助使用者提升資料中心的吞吐量，提升網路應用的可伸縮性，並且能自動調優。

3、高可用架構實踐

實際上，華為把資料庫分成了三部分：SQL層、抽象層和儲存層。從物理層面看，就兩層，一個是SQL層，採取的是一主多備的模式;另外是儲存層，可維護不同租戶的資料庫服務，包括構建頁面、日誌處理等相關功能。

針對SQL層，透過管理客戶端連線，解析SQL請求，把計劃、查詢和管理事務隔離，採用的是一個RW和RO多個副本的形式。同時，華為還有個HWSQL，基於HWSQL在做很多效能增強，包括Query result cache、 Query plan cache以及Online DD等。

整個設計的獨特之處是，透過多個節點的SQL複製，可減少頻繁從儲存器讀取頁面。當主伺服器上發生更新時，read replicas資料庫也會收到事務，提交更新列表。

另外還有一個儲存抽象層(SAL)。SAL是一個邏輯層，可在儲存單元裡隔離SQL前端、事務和查詢執行。在運算元據庫頁面時，SAL可支援訪問同一頁面的多個版本。基於spaceID、pageID，SAL可將所有資料分片，並且儲存和記憶體資源也按照比例增長。

在效能方面，我們也充分利用了華為自身的一些特點，系統容器用的是華為自己的Hi1882高效能晶片。所以，在效能上要比一般容器要好。還有RDMA，透過這個應用大大減少了計算成本。而Co-Processor，則用盡量少的資源實現了資料處理，減少了SQL節點的工作負載。

