1.????統(tǒng)一元數(shù)據(jù)底座演進

首先介紹百度滄?!ご鎯υ獢?shù)據(jù)底座的發(fā)展歷程。這張圖展示了我們?nèi)軜?gòu)的演進過程。

首先,第一代架構(gòu)。在初期,我們的元數(shù)據(jù)存儲分布在多套系統(tǒng)之上,比如對象存儲,同時依賴于 MySQL 和一套分布式 K-V 鍵值系統(tǒng)。這種多系統(tǒng)并存的方式雖然滿足了當時的需求,但也帶來了高昂的運維成本。更為關(guān)鍵的是,MySQL 無法做到線性擴展,難以應對快速增長的數(shù)據(jù)需求。

隨后,第二代架構(gòu),誕生于 2017 年。當時,HopsFS 論文的發(fā)表讓我們看到了基于分布式事務數(shù)據(jù)庫解決對象和文件元數(shù)據(jù)存儲擴展性問題的可能性。受到啟發(fā),我們啟動了自研通用 NewSQL 項目。經(jīng)過兩年的努力,文件存儲 CFS 和對象存儲 BOS 的系統(tǒng)擴展性得到了顯著性提升。然而,盡管擴展性得到了改善,元數(shù)據(jù)的性能仍未達到理想狀態(tài),這成為我們下一步優(yōu)化的重點。

進入第三代架構(gòu),自 2019 年起,我們意識到通用 NewSQL 的設(shè)計無法在云存儲元數(shù)據(jù)場景中充分發(fā)揮性能優(yōu)勢。于是,我們深入分析了百度內(nèi)部各個云存儲場景的元數(shù)據(jù)特征,面向這些場景進行了重新設(shè)計,終于解決了上一代架構(gòu)擴展性和性能難以兼顧的問題。當前這一系統(tǒng)已成為百度滄?!ご鎯Φ暮诵闹危瓿闪舜笠?guī)模全面的上線,服務于百度智能云的對象存儲 BOS、文件存儲 CFS 以及百度內(nèi)部的類 HDFS 文件系統(tǒng) AFS,極大地提升了產(chǎn)品的競爭力。

接下來我將講述為什么通用 NewSQL 在元數(shù)據(jù)存儲中會引入額外的開銷。

主要原因在于通用 NewSQL 并不感知元數(shù)據(jù)的語義,這導致了多方面的資源浪費。為了更好地理解這一點,我將從 4 個維度進行詳細闡述:分區(qū)(Partition)、事務與索引、單機引擎以及接口設(shè)計。

首先,從 Partition 的角度來看,元數(shù)據(jù)具有高度的局部性。例如,一個目錄下的所有元數(shù)據(jù),或者一個小規(guī)模文件系統(tǒng)的所有元數(shù)據(jù),往往需要集中存儲以提高訪問效率。然而,通用 NewSQL 難以保證這種局部性,無法將相關(guān)的元數(shù)據(jù)全部放置在同一個 Shard 中。這意味著,當我們訪問這些元數(shù)據(jù)時,常常需要跨 Shard 進行操作,從而導致跨 Shard 事務的高額開銷,影響整體性能。

其次,談到事務與索引,通用系統(tǒng)的事務處理往往伴隨著較大的開銷。以多版本并發(fā)控制(MVCC)為例,雖然它能夠提高并發(fā)性,但也帶來了額外的垃圾回收(GC)開銷。此外,二級索引在通用系統(tǒng)中通常依賴分布式事務來保障原子性,這進一步加劇了系統(tǒng)的負擔。分布式事務本身開銷巨大,導致整體性能難以達到理想狀態(tài)。

第三,從單機引擎的角度分析,通用 NewSQL 通常采用單一的單機引擎,目前較多采用 Log-Structured Merge-Tree(LSM-Tree)結(jié)構(gòu)。雖然 LSM-Tree 在寫性能方面表現(xiàn)出色,但在某些場景下并不理想。例如,對于數(shù)據(jù)量較小且主要進行點查詢的表,LSM-Tree 的性能不如全內(nèi)存的哈希引擎。這種不適配性導致了資源的低效利用和性能瓶頸。

最后,關(guān)于接口設(shè)計,基于通用 NewSQL 的實現(xiàn),會導致元數(shù)據(jù)的語義與元數(shù)據(jù)的存儲層徹底分離。這種分層解耦的架構(gòu)雖然在軟件工程角度有低耦合、高內(nèi)聚的優(yōu)點,但也帶來了額外的開銷。為了降低這些開銷,我們需要將元數(shù)據(jù)的語義下沉到底層的事務 K-V 系統(tǒng)中,使得存儲層能夠更好地理解和優(yōu)化元數(shù)據(jù)的操作,從而提升整體性能。

綜上所述,通用 NewSQL 由于無法感知和優(yōu)化元數(shù)據(jù)的特定語義,導致在分區(qū)管理、事務處理、存儲引擎選擇以及接口設(shè)計等多個方面產(chǎn)生了額外的開銷。因此,我們需要針對元數(shù)據(jù)的特性,設(shè)計專用的存儲解決方案,以更好地滿足性能和擴展性的需求。

基于我們前面討論的挑戰(zhàn),百度滄?!ご鎯ψ灾餮邪l(fā)了統(tǒng)一元數(shù)據(jù)底座。

從系統(tǒng)架構(gòu)上看,百度滄海的底座與業(yè)界的 NewSQL 系統(tǒng)相似,但在設(shè)計上有一個關(guān)鍵性的核心差異——?Meta-Aware。簡單來說,這意味著底層的事務 K-V 系統(tǒng)能夠深度感知元數(shù)據(jù)的語義,從而實現(xiàn)更高效的處理。

接下來,我將從 4 個方面詳細闡述這一核心差異及其帶來的優(yōu)勢。

首先,從分區(qū)(Partition)角度來看,支持自定義分裂策略和 co-located 機制。具體來說,我們能夠確保一個目錄下的所有元數(shù)據(jù)或一個文件系統(tǒng)中的所有元數(shù)據(jù)被分配到同一個 Shard。這一設(shè)計確保了大部分操作只需在單個 Shard 內(nèi)完成,從而避免了跨 Shard 事務帶來的高額開銷,顯著提升了系統(tǒng)的性能和響應速度。

其次,在事務與索引方面,元數(shù)據(jù)操作通常是短事務。我們實現(xiàn)了一個 TTL 為 5 秒的內(nèi)存 MVCC 機制,只在內(nèi)存中維持多版本,僅將一個版本進行持久化存儲,這樣就大大減少了多版本 GC 的開銷。此外,我們同時支持了同步和異步二級索引機制,對于有強一致性需求的場景采用同步索引,對于那些一致性要求不高的場景采用異步索引,有效避免了分布式事務帶來的高額開銷。這種設(shè)計使得系統(tǒng)能夠靈活應對不同一致性需求的業(yè)務場景。

第三,從單機引擎角度,統(tǒng)一元數(shù)據(jù)底座支持根據(jù)表的訪問特征來選擇最合適的存儲引擎。目前,我們支持 LSM-Tree 引擎、全內(nèi)存哈希引擎等多種引擎。例如,對于數(shù)據(jù)量大且有范圍查詢需求的場景,我們采用?LSM-Tree 引擎。而對于訪問頻繁且數(shù)據(jù)量小的表,全內(nèi)存哈希引擎則能提供更高的查詢效率。這種靈活的引擎選擇確保了不同類型的元數(shù)據(jù)操作都能獲得最佳的性能表現(xiàn)。

最后,在接口(SDK)設(shè)計方面,我們引入了協(xié)處理器機制,將文件存儲的目錄樹邏輯下推到底層事務 K-V 系統(tǒng),從而避免額外的 RPC 開銷,加速了元數(shù)據(jù)操作的效率。

綜上所述,百度滄海的統(tǒng)一元數(shù)據(jù)底座通過 Meta-Aware 的設(shè)計理念,在分區(qū)管理、事務處理、存儲引擎選擇以及接口設(shè)計等多個方面實現(xiàn)了顯著優(yōu)化,不僅有效降低了系統(tǒng)開銷,提高了性能,還增強了系統(tǒng)的擴展性和靈活性。正是這些創(chuàng)新性的設(shè)計,使得百度滄海的統(tǒng)一元數(shù)據(jù)底座能夠更好地滿足我們復雜多變的業(yè)務需求。

2.????統(tǒng)一層級 Namespace 底座演進

接下來我將為大家介紹百度滄海的統(tǒng)一層級 Namespace 架構(gòu)的演進歷程。我們的層級目錄樹架構(gòu)經(jīng)歷了三個階段演進:

首先,第一階段:類似 HDFS 的單機方案。在這一階段,我們采用了類似 HDFS 的單機架構(gòu)。這種方案的最大優(yōu)點是極低的延遲,能夠在高并發(fā)訪問下保持高效的響應速度。然而,這種單機方案存在明顯的擴展性瓶頸,其規(guī)模只能支持到 10 億級別的元數(shù)據(jù)。隨著業(yè)務規(guī)模的不斷擴大,這一限制逐漸顯現(xiàn),無法滿足未來更大規(guī)模的數(shù)據(jù)需求。

隨后,進入第二階段:基于分布式數(shù)據(jù)庫的分布式 Namespace 方案。為了突破單機方案的限制,我們轉(zhuǎn)向了基于分布式數(shù)據(jù)庫構(gòu)建的分布式 Namespace 架構(gòu)。這一方案的主要優(yōu)勢在于可線性擴展,能夠隨著業(yè)務增長靈活地擴展系統(tǒng)容量。然而,分布式方案的本質(zhì)是犧牲局部性來保障擴展性,而局部性的犧牲必然會帶來性能的損耗,為了解決局部性犧牲而帶來的性能瓶頸,百度滄海在第二階段內(nèi)演進了三代架構(gòu),不斷優(yōu)化分布式 Namespace。

最后,第三階段:單機分布式一體化方案。我們提出并實現(xiàn)了單機分布式一體化方案,做到了規(guī)模自適應。當系統(tǒng)規(guī)模較小時,這一方案能夠發(fā)揮單機 Namespace 系統(tǒng)的性能優(yōu)勢,實現(xiàn)百微秒級的低延遲。隨著業(yè)務規(guī)模的擴大,系統(tǒng)能夠無感平滑遷移到分布式架構(gòu),實現(xiàn)水平擴展,滿足不同規(guī)模階段的需求。這種一體化方案不僅兼顧了性能與擴展性,還大幅提升了系統(tǒng)的靈活性和可維護性。

在分布式層級 Namespace 優(yōu)化上,我們主要解決了兩個核心問題:

除了加速路徑解析,Index 的引入還帶來了其他優(yōu)化的機遇:

然而,這個方案帶來了以下技術(shù)挑戰(zhàn):首先,單服務器的 Index 分片面臨單點性能瓶頸問題:

其次,快速路徑解析可能導致同目錄下的目錄修改操作事務沖突和高延遲:

百度滄?!ご鎯F隊通過一系列技術(shù)創(chuàng)新系統(tǒng)性地解決了上述問題。

單機和分布式架構(gòu)能夠做到合二為一的最核心的一個點是在規(guī)模達到臨界點的時候,后端架構(gòu)做到平滑切換。

我們具體的實現(xiàn)方法是這樣做的:無論是單機架構(gòu)和分布式架構(gòu),都基于我們自研的統(tǒng)一元數(shù)據(jù)底座去構(gòu)建:

3.????統(tǒng)一數(shù)據(jù)底座演進

百度滄?!ご鎯?shù)據(jù)面的架構(gòu)可以概括為三個階段。第一個階段,硬件上 HDD 為主、SSD 量較少,架構(gòu)上采用的 master-slave 結(jié)構(gòu)。一個管控節(jié)點管理數(shù)據(jù)節(jié)點,使用 3 副本系統(tǒng)的設(shè)計,單個系統(tǒng)只支持單個數(shù)據(jù)中心。

第二階段,HDD 和 SSD 混用,SSD 量較第一個階段上升,節(jié)點結(jié)構(gòu)仍然采用 master-slave 結(jié)構(gòu),數(shù)據(jù)存儲使用離線 EC,單個系統(tǒng)支持多個數(shù)據(jù)中心。

第三階段,大規(guī)模使用 SSD,同時為了降低成本,開始使用磁帶存儲,并使用 PMEM 等加速硬件,采用無邏輯單點的微服務結(jié)構(gòu),數(shù)據(jù)存儲使用在線?EC。

第一代架構(gòu)的痛點顯而易見,3 副本導致高存儲成本,此外無法應對機房級別故障。盡管第二代架構(gòu)在支持 EC 和多數(shù)據(jù)中心架構(gòu)上有所改進,但依然存在以下顯著問題:

綜上所述,由于第二代系統(tǒng)在 master-slave 架構(gòu)帶來的擴展性和性能瓶頸、離線 EC 導致的性能問題以及固定副本機制導致的高成本,成為制約系統(tǒng)進一步優(yōu)化和擴展的主要障礙,第三代系統(tǒng)致力于系統(tǒng)性的解決上述問題。

百度滄?!ご鎯ψ钚碌牡谌鷶?shù)據(jù)底座架構(gòu)采用了無邏輯單點的微服務架構(gòu)。這里有兩個關(guān)鍵詞:一個是無邏輯單點,一個是微服務架構(gòu)。

無邏輯單點的意思是系統(tǒng)中任何一組狀態(tài)機停止工作,系統(tǒng)可用性和性能不受影響。微服務架構(gòu)的意思是從功能的維度將原來單體的結(jié)構(gòu)分拆,比如數(shù)據(jù)校驗、數(shù)據(jù)修復、負載均衡、容量均衡等等,從而加快迭代效率。這種結(jié)構(gòu)的好處是:可用性更高,擴展性更強,迭代效率更快,能夠支持 ZB 級別數(shù)據(jù)。

同時,這個數(shù)據(jù)底座提供了高效 EC 機制,這個機制有兩個特點:

在云存儲系統(tǒng)的構(gòu)建中,業(yè)界一般存在 2 種架構(gòu)路線:

目前,這 2 種路線已在不同云廠商落地,均打造出了優(yōu)秀的云存儲產(chǎn)品,很好地助力了社會經(jīng)濟的發(fā)展。關(guān)于百度滄?!ご鎯y(tǒng)一技術(shù)底座架構(gòu)的更多技術(shù)分享,圍繞擴展性、穩(wěn)定性、高性能等方面的討論,將陸續(xù)在「微信公眾號——百度智能云技術(shù)站發(fā)布,歡迎大家持續(xù)關(guān)注。

分享到

zhupb

相關(guān)推薦