隨著 AI 時代的快速發展，對存儲技術提出了更高的要求，尤其是在大規模、高性能和低成本方面。為了應對這些挑戰，百度滄海·存儲打造了一個高度可復用的統一技術底座。我們在這個統一的技術底座中解決了云存儲的共性問題，讓上層存儲系統的迭代更高效。

首先，我將簡要介紹一下百度滄海·存儲統一技術底座的整體架構。這個統一的技術底座由三個核心組件構成，分別是統一的元數據底座、統一的層級 Namespace 以及統一的數據底座。

我們認為各種存儲系統實際上是由元數據面和數據面兩部分組成，通過提煉出高度可復用的元數據面和數據面的統一技術底座，就能積木式搭建各種云存儲系統，比如對象存儲、文件存儲、塊存儲等，最大化減少重復開發的工作。

接下來，我將詳細介紹這三個核心組件。

首先是統一的元數據底座。這個元數據底座是專門為元數據場景設計的分布式事務 K-V 存儲系統。基于 Meta-Aware 的設計理念，具備萬億級別的元數據存儲能力。它支撐了對象存儲 BOS 和文件存儲 CFS/AFS 的元數據存儲。

然后是統一的層級 Namespace。基于統一的元數據底座構建的層級 Namespace，已經進化到了單機分布式一體化架構，具有高性能和良好的可擴展性。

最后是統一的數據底座。這是一個在線糾刪碼 EC 存儲系統，旨在提供高吞吐量和低成本的統一數據存儲服務。該系統采用無邏輯單點的微服務架構，支持 ZB 級別數據規模。

這三個核心組件共同構建了百度滄海的統一技術底座，支撐了上層的各類存儲產品，如對象存儲 BOS、塊存儲 CDS 以及文件存儲 CFS/AFS 等。

目前，最新的第三代統一技術底座已經支持了百度滄海·存儲數據湖加速方案 2.0 的規模化應用。

圖片

圖片

1.    統一元數據底座演進

首先介紹百度滄海·存儲元數據底座的發展歷程。這張圖展示了我們三代架構的演進過程。

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

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

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

圖片

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

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

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

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

第三，從單機引擎的角度分析，通用 NewSQL 通常采用單一的單機引擎，目前較多采用 Log-StructuredMerge-Tree（LSM-Tree）結構。雖然 LSM-Tree 在寫性能方面表現出色，但在某些場景下并不理想。例如，對于數據量較小且主要進行點查詢的表，LSM-Tree 的性能不如全內存的哈希引擎。這種不適配性導致了資源的低效利用和性能瓶頸。

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

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

圖片

基于我們前面討論的挑戰，百度滄海·存儲自主研發了統一元數據底座。

從系統架構上看，百度滄海的底座與業界的 NewSQL 系統相似，但在設計上有一個關鍵性的核心差異—— Meta-Aware。簡單來說，這意味著底層的事務 K-V 系統能夠深度感知元數據的語義，從而實現更高效的處理。

接下來，我將從 4 個方面詳細闡述這一核心差異及其帶來的優勢。

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

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

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

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

綜上所述，百度滄海的統一元數據底座通過 Meta-Aware 的設計理念，在分區管理、事務處理、存儲引擎選擇以及接口設計等多個方面實現了顯著優化，不僅有效降低了系統開銷，提高了性能，還增強了系統的擴展性和靈活性。

正是這些創新性的設計，使得百度滄海的統一元數據底座能夠更好地滿足我們復雜多變的業務需求。

圖片

2.    統一層級 Namespace 底座演進

接下來我將為大家介紹百度滄海的統一層級 Namespace 架構的演進歷程。我們的層級目錄樹架構經歷了三個階段演進：

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

隨后，進入第二階段：基于分布式數據庫的分布式 Namespace 方案。為了突破單機方案的限制，我們轉向了基于分布式數據庫構建的分布式 Namespace 架構。這一方案的主要優勢在于可線性擴展，能夠隨著業務增長靈活地擴展系統容量。然而，分布式方案的本質是犧牲局部性來保障擴展性，而局部性的犧牲必然會帶來性能的損耗，為了解決局部性犧牲而帶來的性能瓶頸，百度滄海在第二階段內演進了三代架構，不斷優化分布式 Namespace。

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

圖片

在分布式層級 Namespace 優化上，我們主要解決了兩個核心問題：

• 第一個是單分區事務優化：通過將目錄的屬性信息分離，成為目錄的孩子節點，同時，底層事務 K-V 控制屬于同一個目錄的元數據在同一個分片，我們將絕大部分的元數據操作從 2PC 優化到 1PC。
• 第二個是路徑解析優化：通過在傳統表結構（Inode 表）之上引入目錄索引表（Index 表）來加速路徑解析。具體來說，就是把同一個文件系統的目錄索引表放置在同一個分片中，即 Index 分片，實現了將路徑解析從 N 次 RPC 優化到 1 次 RPC 調用。

除了加速路徑解析，Index 的引入還帶來了其他優化的機遇：

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

然而，這個方案帶來了以下技術挑戰：

首先，單服務器的 Index 分片面臨單點性能瓶頸問題:

• 讀取性能瓶頸：盡管路徑解析變成了單節點操作，但因為路徑深度大部分超過 10 層，底層單機引擎的多次查詢仍然會消耗大量 CPU 資源。
• 寫入性能瓶頸：所有的目錄修改操作都需要訪問 Index 分片 ，所以我們需要盡可能的提升 Index 分片的寫入吞吐。

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

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

百度滄海·存儲團隊通過一系列技術創新系統性地解決了上述問題。

圖片

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

我們具體的實現方法是這樣做的：無論是單機架構和分布式架構，都基于我們自研的統一元數據底座去構建：

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

圖片

3.    統一數據底座演進

百度滄海·存儲數據面的架構可以概括為三個階段。第一個階段，硬件上 HDD 為主、SSD 量較少，架構上采用的 master-slave 結構。一個管控節點管理數據節點，使用 3 副本系統的設計，單個系統只支持單個數據中心。

第二階段，HDD 和 SSD 混用，SSD 量較第一個階段上升，節點結構仍然采用 master-slave 結構，數據存儲使用離線 EC，單個系統支持多個數據中心。

第三階段，大規模使用 SSD，同時為了降低成本，開始使用磁帶存儲，并使用 PMEM 等加速硬件，采用無邏輯單點的微服務結構，數據存儲使用在線 EC。

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

• 擴展性受限與高可用性不足

架構瓶頸： 采用 master-slave 架構，擴展性受限于單機的存儲空間和處理能力。

單點故障風險：Master 作為單點，故障可能導致整個系統不可用。盡管使用一致性協議或者共享存儲實現了高可用，但是這種方式的實現都是狀態機方式，觸發 bug 往往就會導致所有 master 節點故障。

迭代效率低：以 HDFS namenode 為例，其模塊迭代需極為謹慎，任何問題都可能造成集群不可用，降低了系統的迭代速度。

• 離線 EC 導致性能瓶頸

寫入過程復雜：數據先以 3 副本方式寫入分布式 K-V 存儲，當分布式 K-V 中單個分片數據寫入達到閥值的時候，再通過讀取進行 EC 編碼，最終寫入 EC 系統中。這樣多次的讀寫操作消耗大量 CPU 和 I/O，導致寫性能和讀吞吐量降低。

• 存放副本機制成本高

固定副本數：采用 1.5 副本的 EC 編碼系統無法進一步降低成本。

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

圖片

百度滄海·存儲最新的第三代數據底座架構采用了無邏輯單點的微服務架構。這里有兩個關鍵詞：一個是無邏輯單點，一個是微服務架構。

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

同時，這個數據底座提供了高效 EC 機制，這個機制有兩個特點：

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

圖片

在云存儲系統的構建中，業界一般存在 2 種架構路線：

• 分層架構路線：構建統一的分布式文件系統作為底座，進而基于該系統開發上層的云存儲產品，包括對象存儲、塊存儲、文件存儲等。
• 組件化架構路線：通過提煉出統一的元數據和數據面組件作為底座，上層的云存儲產品基于這個組件式底座進行積木式進行搭建，比如百度滄海·存儲的架構路線。

目前，這 2 種路線已在不同云廠商落地，均打造出了優秀的云存儲產品，很好地助力了社會經濟的發展。