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

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

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

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

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

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

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

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

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

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

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

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

基于我們前面討論的挑戰(zhàn)，百度滄?！ご鎯?chǔ)自主研發(fā)了統(tǒng)一元數(shù)據(jù)底座。

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

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

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

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

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

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

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

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

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

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

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

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

在分布式層級(jí) Namespace 優(yōu)化上，我們主要解決了兩個(gè)核心問題：

• 第一個(gè)是單分區(qū)事務(wù)優(yōu)化：通過將目錄的屬性信息分離，成為目錄的孩子節(jié)點(diǎn)，同時(shí)，底層事務(wù) K-V 控制屬于同一個(gè)目錄的元數(shù)據(jù)在同一個(gè)分片，我們將絕大部分的元數(shù)據(jù)操作從 2PC 優(yōu)化到 1PC。
• 第二個(gè)是路徑解析優(yōu)化：通過在傳統(tǒng)表結(jié)構(gòu)（Inode 表）之上引入目錄索引表（Index 表）來加速路徑解析。具體來說，就是把同一個(gè)文件系統(tǒng)的目錄索引表放置在同一個(gè)分片中，即 Index 分片，實(shí)現(xiàn)了將路徑解析從 N 次 RPC 優(yōu)化到 1 次 RPC 調(diào)用。

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

• 加速目錄 rename：Index 分片的引入除了加速路徑解析，也為加速目錄 rename 提供了機(jī)會(huì)，有了 Index 這個(gè)目錄分片，我們就可以把目錄 rename 執(zhí)行過程中觸發(fā)的分布式成環(huán)檢測優(yōu)化為單機(jī)成環(huán)檢測，從而極大地提升目錄 rename 的性能。
• 加速寫操作：由于 Namespace 之間是互相隔離的，一個(gè) Namesapce 對(duì)應(yīng)一個(gè) Index 分片，這樣我們就可以把時(shí)鐘服務(wù) offload 到 Index 分片，從而減少從 TSO 獲取時(shí)鐘這一次 RPC 開銷。

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

• 讀取性能瓶頸：盡管路徑解析變成了單節(jié)點(diǎn)操作，但因?yàn)槁窂缴疃却蟛糠殖^ 10 層，底層單機(jī)引擎的多次查詢?nèi)匀粫?huì)消耗大量 CPU 資源。
• 寫入性能瓶頸：所有的目錄修改操作都需要訪問 Index?分片?，所以我們需要盡可能的提升 Index?分片的寫入吞吐。

其次，快速路徑解析可能導(dǎo)致同目錄下的目錄修改操作事務(wù)沖突和高延遲：

• 事務(wù)沖突：當(dāng)執(zhí)行 mkdir 或者 rmdir 操作時(shí)，我們需要同時(shí)修改 Index?分片和 Inode 分片，這使得 mkdir 或者 rmdir 成為一個(gè)跨分片的兩階段提交（2PC）事務(wù)。如果并發(fā)向某一個(gè)目錄下插入子目錄，由于父目錄頻繁更新，會(huì)導(dǎo)致大量的分布式事務(wù)沖突。
• 高延遲：目錄修改操作觸發(fā)兩階段提交協(xié)議，這會(huì)導(dǎo)致 mkdir/ rmdir 的高延遲。

百度滄海·存儲(chǔ)團(tuán)隊(duì)通過一系列技術(shù)創(chuàng)新系統(tǒng)性地解決了上述問題。

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

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

• 在單機(jī)架構(gòu)下，我們強(qiáng)制層級(jí) Namespace 依賴的 Inode 信息和目錄樹信息綁定分配到同一組存儲(chǔ)節(jié)點(diǎn)。這其實(shí)就是前面提到的 co-located 功能。這個(gè)時(shí)候，不需要跨機(jī)事務(wù)和多次 RPC 就可以完成文件創(chuàng)建、目錄 rename 等元數(shù)據(jù)操作，這時(shí)候系統(tǒng)跟單機(jī)架構(gòu)的延遲一致。
• 當(dāng)文件規(guī)模達(dá)到 10 億量級(jí)的臨界點(diǎn)之后，會(huì)觸發(fā)分布式數(shù)據(jù)庫按不同的表邊界分裂。分布式數(shù)據(jù)庫的分裂操作對(duì)上層業(yè)務(wù)無感，Inode 表動(dòng)態(tài)水平擴(kuò)展，這個(gè)時(shí)候單機(jī)事務(wù)轉(zhuǎn)換為跨節(jié)點(diǎn)事務(wù)，單次 RPC 轉(zhuǎn)換為多次 RPC。這樣單機(jī)架構(gòu)就可以平滑地過渡到分布式架構(gòu)了。雖然，分布式架構(gòu)的性能相對(duì)于單機(jī)架構(gòu)有一些衰減，單次操作到毫秒級(jí)延遲，但是可以做到線性擴(kuò)展。
• 在單機(jī)架構(gòu)下還有一個(gè)問題待解決，就是如何提升系統(tǒng)的吞吐。我們的做法是把文件語義操作下推到元數(shù)據(jù)底座上，減少跟上層組件的通訊次數(shù)，能夠支持到幾十萬 TPS。

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

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

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

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

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

• 擴(kuò)展性受限與高可用性不足
  • 架構(gòu)瓶頸：?采用?master-slave 架構(gòu)，擴(kuò)展性受限于單機(jī)的存儲(chǔ)空間和處理能力。
  • 單點(diǎn)故障風(fēng)險(xiǎn)：Master 作為單點(diǎn)，故障可能導(dǎo)致整個(gè)系統(tǒng)不可用。盡管使用一致性協(xié)議或者共享存儲(chǔ)實(shí)現(xiàn)了高可用，但是這種方式的實(shí)現(xiàn)都是狀態(tài)機(jī)方式，觸發(fā) bug 往往就會(huì)導(dǎo)致所有 master 節(jié)點(diǎn)故障。
  • 迭代效率低：以 HDFS namenode 為例，其模塊迭代需極為謹(jǐn)慎，任何問題都可能造成集群不可用，降低了系統(tǒng)的迭代速度。
• 離線 EC 導(dǎo)致性能瓶頸
  • 寫入過程復(fù)雜：數(shù)據(jù)先以 3 副本方式寫入分布式 K-V 存儲(chǔ)，當(dāng)分布式 K-V 中單個(gè)分片數(shù)據(jù)寫入達(dá)到閥值的時(shí)候，再通過讀取進(jìn)行 EC 編碼，最終寫入 EC 系統(tǒng)中。這樣多次的讀寫操作消耗大量 CPU 和 I/O，導(dǎo)致寫性能和讀吞吐量降低。
• 存放副本機(jī)制成本高
  • 固定副本數(shù)：采用 1.5 副本的 EC 編碼系統(tǒng)無法進(jìn)一步降低成本。

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

百度滄?！ご鎯?chǔ)最新的第三代數(shù)據(jù)底座架構(gòu)采用了無邏輯單點(diǎn)的微服務(wù)架構(gòu)。這里有兩個(gè)關(guān)鍵詞：一個(gè)是無邏輯單點(diǎn)，一個(gè)是微服務(wù)架構(gòu)。

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

同時(shí)，這個(gè)數(shù)據(jù)底座提供了高效 EC 機(jī)制，這個(gè)機(jī)制有兩個(gè)特點(diǎn)：

• 在線 EC：數(shù)據(jù)被 Put 進(jìn)來后，數(shù)據(jù)面底座直接將數(shù)據(jù)進(jìn)行 EC，然后將 EC 之后的各個(gè)分片 Shard 寫入到對(duì)應(yīng)的各個(gè) DataNode 中去。在線 EC 的好處是不需要一個(gè)積攢和轉(zhuǎn)儲(chǔ)的過程，簡化工程復(fù)雜度，減少轉(zhuǎn)儲(chǔ)之前的額外空間占用和 I/O 開銷。
• 可變 EC：提供 1.5、1.33 甚至更低的副本數(shù)。

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

• 分層架構(gòu)路線：構(gòu)建統(tǒng)一的分布式文件系統(tǒng)作為底座，進(jìn)而基于該系統(tǒng)開發(fā)上層的云存儲(chǔ)產(chǎn)品，包括對(duì)象存儲(chǔ)、塊存儲(chǔ)、文件存儲(chǔ)等。
• 組件化架構(gòu)路線：通過提煉出統(tǒng)一的元數(shù)據(jù)和數(shù)據(jù)面組件作為底座，上層的云存儲(chǔ)產(chǎn)品基于這個(gè)組件式底座進(jìn)行積木式進(jìn)行搭建，比如百度滄?！ご鎯?chǔ)的架構(gòu)路線。

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

zhupb