隨着移動互聯網、物聯網、AI 計算等技術和市場的迅速發展，數據規模指數級膨脹，對於分佈式文件系統作爲大規模數據場景的存儲底座提出了更高的要求。已有分佈式文件系統解決方案存在着短板，只能適應有限的場景：
>> 新型分佈式文件系統無法承接傳統領域內的所有 WorkLoad：通過只支持部分 POSIX 接口來簡化系統設計，無法完全兼容 POSIX 協議。
>> 傳統分佈式文件系統無法支持海量小文件場景：爲了保證低延遲，元數據的可擴展性較差、隨文件規模性能和穩定性下降嚴重，無法支持如 AI 訓練、自動駕駛等文件規模達到十億甚至百億規模的 AI 場景。
因此，設計出一款不僅能完美兼容傳統應用，又能適應最新 AI 場景需求的分佈式文件存儲，顯得意義重大。這樣的分佈式文件系統需要滿足：
-
完全兼容 POSIX 協議。
-
在確保元數據低延遲、穩定的情況下，可線性擴展，支持百億文件規模，具備超大規模文件數量元數據操作能力的同時具備超高的性能穩定性。
要想達到以上目標，百度滄海·文件存儲 CFS 給出的技術解答是設計新一代的 Namespace 子系統，在實現創建文件每秒百萬級 QPS 的同時，保證各項性能指標表現穩定。
這使得文件存儲 CFS 不僅可以支持傳統應用，作爲傳統業務上雲的存儲方案；也可以應用於最新的 AI 場景，滿足海量文件規模處理的應用需求。
Namespace 的技術現狀
Namespace 子系統的功能主要是維護文件系統的文件屬性、目錄樹結構等元數據信息，同時支持兼容 POSIX 的目錄樹及文件操作，如：文件/目錄創建、查找（Lookup/Getattr）刪除及重命名（Rename）等。
當前，業界分佈式文件系統領域衍生出各種類型的 Namespace 技術架構，可以歸類爲如下幾種:
-
單機架構：配合單機全內存，可做到低延遲，無法橫向擴展，最大規模僅支持5億文件數，代表產品爲 HDFS。
-
並行架構：適用於 HPC 等並行文件系統應用場景，元數據靜態切分到多機部署，單機利用一主一備保證可用性，缺乏彈性擴展能力。
-
分佈式架構：將元數據按照某種方式切分和擴展到一組機器上，按照集羣的方式管理。
相對於單機架構不可擴展及並行架構對擴展性的弱支持，分佈式 Namespace 架構在擴展性上做的更加徹底。
那麼直接引入一套現成的分佈式 Namespace 架構是否可以直接解決上文提到的挑戰呢?
答案是否定的，因爲現有的分佈式 Namespace 架構都存在各自的侷限性和不足。
-
基於 Hash Based 架構儘管具有很好的擴展性及負載均衡效果，但是其犧牲了 POSIX 兼容語義的支持。該架構方案將文件全路徑 Hash 來組織打散到分佈式 Meta 集羣，對於 Lookup 路徑查找非常友好同時容易實現，但是缺點是犧牲了元數據的局部性，尤其是 rename 的實現複雜度高且性能很差，這類架構主要停留在學術研究，沒有在工業界大規模應用，典型的系統如 Dr.Hadoop,GiraffaFS；
-
基於子樹劃分架構保證了元數據的局部性，可兼容 POSIX 語義，但是擴展性不夠好 。該架構方案通過將層級目錄樹拆分成多個子樹並將每顆子樹按照相應的負載策略部署到不同的 Meta 節點中，單節點上具有很好的元數據局部性，但是缺點就是容易產生熱點，負載均衡難以實現，擴展性不夠好，典型的實現如 CephFS、IndexFS;
相對於前兩種架構都具有明顯的侷限性且難以彌補，近幾年脫穎而出的基於分佈式數據庫或分佈式 KV 的 Namespace 架構兼顧了擴展性及 POSIX 語義兼容支持。
該方案通常採用分層架構：上層維護了一層元數據處理層，該層將目錄樹 POSIX 操作轉化爲數據庫事務請求。下層是分佈式數據庫或分佈式 KV 層，負責元數據的存儲管理，同時對上層的數據庫事務請求進行語義處理。
通過這樣的分層架構就做到了對 POSIX 語義的完整兼容。同時，利用分佈式數據庫或分佈式 KV 本身的可擴展性，做到了 NameSpace 架構的可擴展。
另外，爲了進一步提升 POSIX 語義的處理速度，通常會維護一層 Hint Cache 來加速元數據的處理。
雖然該架構方案可以在存儲層面做到彈性可擴展且簡化了元數據的處理，但由於現有架構對鎖及數據庫事務存在強依賴，Namespace 在寫延遲及寫性能的擴展性層面仍然存在不足，難以支持每秒創建百萬以上的文件的需求。
百度智能雲 CFS 在此架構基礎上改進和擴展出新一代的 Namespace 架構。
CFS 的 Namespace 架構
百度滄海的文件存儲 CFS 作爲百度智能雲提供的分佈式文件存儲服務，通過標準的文件訪問協議（NFS/SMB），爲雲上的虛機、容器等計算資源提供無限擴展、高可靠、地域級別共享的文件存儲能力。
爲了兼顧傳統及 AI 場景的用戶需求，彈性可擴展且兼容 POSIX一直被作爲 CFS 架構尤其是 Namespace 子系統的重要設計目標。
基於分佈式 KV 架構，CFS 採用自研的分佈式索引系統來支撐 Namespace 子系統，並基於該索引系統實現了分層架構，即 POSIX 語義層+分佈式 KV 層。該索引系統經過 CFS 產品多年的打磨，目前可以非常好地解決 Namespace 層級結構擴展性與低延遲的需求。
相比於其他基於分佈式數據庫或分佈式 KV 的分佈式文件系統（比如HopsFS），CFS 不直接依賴底層分佈式數據庫或分佈式 KV 層的鎖及事務機制來維持 POSIX 語義，而是通過以下創造性的設計配合來解決：
-
適配層級結構數據模型，定製化 Schema 來降低 KV 層數據之間的關聯性。
-
在 POSIX 語義層設計一套針對 Namespace 層級結構、相對數據庫鎖及事務機制更輕量的一致性協議，保障所有 Namespace 層的讀寫操作不會破壞 POSIX 語義。
基於以上設計，CFS 在 Namespace 層的讀寫操作都具備非常低的延遲和好的線性擴展能力，具體性能參考下文測試結果。
除此之外，爲了進一步優化延遲，CFS 團隊在該架構的各個層面做了深入優化：
-
單機層面進一步優化延遲：單機 KV 引擎適配了 AEP 等高速硬件，確保 Namespace 關鍵路徑低延遲。
-
一致性協議層面進一步優化擴展性及延遲：POSIX 語義層一致性協議採用無狀態實現，不同節點之間無需同步、無需單獨部署，而是作爲 LIB 編譯到 Client 或者接入模塊，簡化了架構的維護及 Namespace 讀寫路徑，同時進一步保障了架構的可擴展性。
Namespace 性能測試
爲了驗證 CFS 產品 Namespace 架構的擴展性及性能穩定性，我們分別從擴展索引系統 KV 節點和 Meta Client 節點兩個維度來測試，在驗證擴展性同時給出相應單次請求的延遲數據及穩定性。
說明：以下測試 workload 均採用 Mdtest 作爲元數據測試工具，其中 Meta Client 作爲文件系統協議接入層對接標準的NFS協議，壓測中的線程工作在相同 FS 不同路徑上。
KV 節點擴展
以下數據對比了10個 KV 節點和20個 KV 節點在併發 mkdir 的性能數據表現（圖中 BE 對應分佈式 KV 層一個後端 KV 節點）：
通過以上數據可以看出：
-
20個 KV 節點相對於10個 KV 節點在寫吞吐上接近於兩倍的提升；
-
當系統負載正常情況下一次 Namespace 寫延遲只需要 2ms 左右；
-
當系統負載過高且瓶頸來到 KV 層，延遲長尾表現穩定；
綜上，可以看出 CFS 的架構在 KV 層可以支持線性擴展。
Meta Client 擴展
以下是基於集羣的 KV 層固定爲24個 KV 節點的對應數據，一方面通過擴展 Meta Client 數來驗證架構在語義層的擴展性，另一方面驗證架構在讀和寫是否具備突破百萬 QPS 的能力。
通過以上數據可以看出：
-
Namespace 寫和讀吞吐可以在 POSIX 語義層做到線性擴展，其中寫操作（文件\目錄創建）可以達到100萬 QPS，即每秒可支持創建百萬文件；路徑查找（Lookup）可以達到400萬 QPS，目錄/文件屬性獲取（Getattr）可以達到600萬 QPS。
-
延遲方面寫延遲爲2ms，讀延遲只需要百 us 級。
CFS 可以在元數據讀寫操作上都可以做到支持線性擴展的同時保證低延遲以及性能穩定性，並且在此基礎上完成每秒創建百萬文件的挑戰。