目前業(yè)界基于分布式 KVDB 系統(tǒng)來構(gòu)建大規(guī)模文件和對象存儲系統(tǒng)的元數(shù)據(jù)服務(wù)已形成流行趨勢，如Google Colossus、Microsoft ADLS、HopsFS、JuiceFS等。這種趨勢出現(xiàn)的背景是現(xiàn)代分布式KVDB或NoSQL存儲系統(tǒng)技術(shù)發(fā)展的成熟。利用分布式KVDB的能力，能夠極大簡化元數(shù)據(jù)服務(wù)的設(shè)計，這已經(jīng)成為很多存儲系統(tǒng)，尤其是云存儲的共識。分布式KVDB或NoSQL系統(tǒng)在分布式事務(wù)支持、擴展能力、高并發(fā)性能等方面的優(yōu)勢，使得基于其作為文件系統(tǒng)元數(shù)據(jù)的持久化層，來構(gòu)建海量分布式文件系統(tǒng)的開發(fā)過程大大簡化。3FS采用的正是這種架構(gòu)，它使用FoundationDB來持久化文件元數(shù)據(jù)，包括文件路徑、屬性、目錄結(jié)構(gòu)等。其中核心鍵值對有兩種：

通過這樣的Schema設(shè)計，即可在分布式KVDB中構(gòu)建出文件系統(tǒng)目錄樹的結(jié)構(gòu)，文件路徑的增刪改查操作轉(zhuǎn)化為了分布式KVDB的單key或多key的增刪改查操作。

基于這種元數(shù)據(jù)服務(wù)架構(gòu)的分布式文件系統(tǒng)具體優(yōu)點如下：

1.高可擴展性和可靠性

分布式KVDB系統(tǒng)天然支持水平擴展，用于保存文件系統(tǒng)元數(shù)據(jù)，以實現(xiàn)單一命名空間承載千億甚至更高量級文件或目錄數(shù)的規(guī)格。同時，文件系統(tǒng)元數(shù)據(jù)服務(wù)的可靠性、均衡性可以由其保證。借助FoundationDB已實現(xiàn)的高可用及擴展性，3FS的元數(shù)據(jù)服務(wù)（Meta Service）與元數(shù)據(jù)持久化存儲層實現(xiàn)了“存算分離”，Meta Service可以完全做到無狀態(tài)，具備了獨立擴展能力，Client請求也可以下發(fā)到任意節(jié)點。

此外，元數(shù)據(jù)的分散性也可以得以保證，傳統(tǒng)文件系統(tǒng)元數(shù)據(jù)服務(wù)器（MDS）經(jīng)常遇到的部分目錄的熱點問題以及目錄分裂策略問題也得以緩解。

2. 簡化一致性模型

分布式KVDB本身支持強一致性事務(wù)，基于其開發(fā)應(yīng)用的復(fù)雜度大大降低，關(guān)于文件系統(tǒng)元數(shù)據(jù)的所有一致性問題可以下沉給KVDB去解決。3FS基于FoundationDB的 Serializable隔離級別，樂觀并發(fā)控制和分布式鎖等能力保證了各種元數(shù)據(jù)并發(fā)操作（如文件創(chuàng)建、刪除、Rename、目錄遍歷）時的ACID語義。以往文件系統(tǒng)的MDS服務(wù)中的經(jīng)典問題，比如目錄樹節(jié)點的rename成環(huán)問題、孤兒節(jié)點問題，都可以通過FoundationDB的事務(wù)模型來解決，Meta Service只負(fù)責(zé)文件POSIX語義解析即可。

3FS利用 FoundationDB 的串行化隔離級別事務(wù)的元數(shù)據(jù)操作有：

• 使用只讀事務(wù)的查詢類操作：fstat、lookup、listdir等。
• 使用讀寫事務(wù)的更新類操作：create、link、unlink、rename等。

3. 靈活的數(shù)據(jù)模型擴展

支持動態(tài)添加元數(shù)據(jù)字段（如自定義標(biāo)簽），無需修改底層存儲結(jié)構(gòu)。并且如果擴展新的元數(shù)據(jù)字段，如3FS的Meta Service，客戶端、存儲服務(wù)等其他組件可以按需單獨升級，大大提升在線集群維護靈活性。

然而，任何事物都是有兩面性的，在實際工程實踐中，使用分布式KVDB存儲文件系統(tǒng)元數(shù)據(jù)仍存在一些挑戰(zhàn)：

1. 事務(wù)開銷大影響元數(shù)據(jù)性能

分布式KVDB在實現(xiàn)上通常都會把已保存的整個key空間按照從小到大的順序切分成相連但不交疊的區(qū)域，稱為分片。每個節(jié)點都承載一定數(shù)量的分片，跨分片更新多個key的數(shù)據(jù)時涉及的事務(wù)操作開銷較大：

• 前述Metadata key的布局特點決定了文件系統(tǒng)的create、rename等常見更新類操作，若嚴(yán)格按照標(biāo)準(zhǔn)POSIX協(xié)議實現(xiàn)，在FoundationDB側(cè)等同于一個事務(wù)中更新多個key的操作。例如創(chuàng)建一個文件，就會涉及到新增這個文件的inode key、dentry key以及修改其父目錄inode key的屬性信息。如果多個key被分配到KVDB集群的不同分片上，為保證事務(wù)操作的原子性會觸發(fā)兩階段提交（2PC），相比單個key或者多個key落在同一個分片上的情況（可簡化為1PC提交），時延明顯增加。

注：3FS在實現(xiàn)上為減少事務(wù)沖突，選擇在文件創(chuàng)建時不更新父目錄屬性，以犧牲通用文件POSIX語義來換取特定場景下的性能。

• 由于FoundationDB采用串行化快照事務(wù)隔離級別（SSI），這種高隔離級別的事務(wù)開銷較大，事務(wù)沖突場景下性能衰退嚴(yán)重。當(dāng)兩個并行的元數(shù)據(jù)更新操作發(fā)生沖突時，KVDB層檢測到事務(wù)沖突后會導(dǎo)致一個事務(wù)被取消，之后在IO路徑上觸發(fā)Meta Service層的重試事務(wù)，可能影響吞吐量。另外，通用文件系統(tǒng)里更復(fù)雜的操作（如遞歸刪除目錄），會涉及大量事務(wù)提交，性能影響更大。

注：3FS采用支持非空目錄刪除與標(biāo)記刪除來盡力規(guī)避這種問題，以犧牲通用文件POSIX語義來換取特定場景下的性能。

2. 元數(shù)據(jù)的擴展能力有限

因為SSI的串行化隔離級別在KVDB的實現(xiàn)上依賴一個全局的單點TSO時鐘，這會成為擴展的瓶頸。在大規(guī)模集群場景下，整個文件系統(tǒng)的并發(fā)能力的上限受到限制，并且TSO時鐘本身的授時開銷也會增加元數(shù)據(jù)訪問的時延。

注：3FS通過FFrecord文件來規(guī)避這個問題，通過在應(yīng)用層將小文件合并成大文件，保存在FoundationDB中的元數(shù)據(jù)量可以大幅減少。

杉巖AgileDB：元數(shù)據(jù)服務(wù)架構(gòu)的創(chuàng)新設(shè)計與高效實踐

杉巖非結(jié)構(gòu)化數(shù)據(jù)分布式統(tǒng)一存儲產(chǎn)品的元數(shù)據(jù)服務(wù)也采用了與3FS類似的架構(gòu)，但使用的不是FoundationDB等通用分布式KVDB，而是全自研的分布式KV存儲——杉巖AgileDB。杉巖AgileDB與杉巖文件和對象存儲產(chǎn)品的網(wǎng)關(guān)層聯(lián)動配合，繼承了基于分布式KVDB的文件系統(tǒng)元數(shù)據(jù)架構(gòu)的優(yōu)點，同時克服了其局限性。相較于通用分布式KVDB（下表以FoundationDB和TiKV為例進行說明），杉巖AgileDB在特性的實現(xiàn)方式上做了一些取舍，并且實現(xiàn)了一些獨特功能，簡單比較如下：

從前述章節(jié)可以看出，使用分布式KVDB作為文件系統(tǒng)的元數(shù)據(jù)底座，如何既做到POSIX語義盡量的兼容，又降低大規(guī)模場景下KVDB的事務(wù)開銷對性能的影響，是個難題，需要根據(jù)實際業(yè)務(wù)場景作出合理取舍。杉巖數(shù)據(jù)在平衡這兩方面的過程中，自研的杉巖AgileDB發(fā)揮了重要作用，以下列舉其中兩個有代表性的實現(xiàn)機制：

1. 跨分片的元數(shù)據(jù)操作事務(wù)開銷優(yōu)化

杉巖AgileDB的元數(shù)據(jù)核心鍵值的設(shè)計與3FS整體類似但稍有不同，AgileDB的inode key和dentry key在普通文件和目錄下是合并的，只有硬鏈接場景才會分開。當(dāng)目錄下文件數(shù)量過多，可能會導(dǎo)致該目錄所有子項的key跨杉巖AgileDB的多個內(nèi)部分片，此時創(chuàng)建文件時更新父目錄的屬性信息（已用容量統(tǒng)計、文件數(shù)量統(tǒng)計等），必然需要 2PC 事務(wù)提交機制來保證 ACID；同時，在同一個目錄下的不同文件、子目錄的并發(fā)創(chuàng)建、刪除等操作會對父目錄上計數(shù)等屬性信息的更新帶來大量沖突。

為解決這個問題，杉巖設(shè)計了自適應(yīng)的虛擬目錄機制：

對于跨AgileDB分片的實際目錄，在每個分片中為其放置一個特殊的key（虛擬目錄屬性key）來標(biāo)記該分片與真實目錄的所屬關(guān)系，value則存放虛擬目錄的屬性信息。AgileDB可根據(jù)分片的分裂和合并自動更新這個特殊key，業(yè)務(wù)無感知。

在創(chuàng)建文件的過程中，動態(tài)去獲取該目錄下所有子項分布在哪些分片，找到虛擬目錄屬性key，如果創(chuàng)建文件的過程中分片正在分裂，則等待分裂完成且AgileDB生成新的虛擬目錄屬性key后，再獲取正確的虛擬目錄屬性key。創(chuàng)建文件的元數(shù)據(jù)的key和父目錄屬性信息（存入虛擬目錄屬性key）將被組成一個單分片事務(wù)提交（1PC）。

實際目錄屬性信息采用lazy的方式更新：僅當(dāng)應(yīng)用獲取實際目錄的屬性信息時，AgileDB通過協(xié)處理能力將多個分片中的虛擬目錄屬性key信息以只讀事務(wù)獲取后合并信息并返回。

通過自適應(yīng)的虛擬目錄機制，將跨區(qū)域的實際目錄的2PC更新轉(zhuǎn)化為虛擬目錄的1PC更新，減少了事務(wù)的開銷，同時由于每個虛擬目錄包含的元數(shù)據(jù)是實際目錄的子集，這種分解方式進一步縮小了沖突域，緩解了實際目錄下并發(fā)更新操作帶來的沖突問題。

2. 單行多列族事務(wù)特性，支持文件系統(tǒng)高級功能

文件系統(tǒng)的一些高級功能均依賴按時間序保存的元數(shù)據(jù)Change log，比如異常場景下元數(shù)據(jù)的回放、跨站點的數(shù)據(jù)復(fù)制、元數(shù)據(jù)推送至其它大數(shù)據(jù)平臺進行數(shù)據(jù)分析與檢索等高級功能，這些功能要求Change log與文件元數(shù)據(jù)在寫入KVDB時是強一致的。

全局Change log不能通過在KVDB中簡單的增加以粗粒度時間戳為key的Change log記錄來解決，這樣在文件元數(shù)據(jù)更新時為保證原子性，就必須通過事務(wù)同步更新它，如此以來又會導(dǎo)致2PC提交而增加延遲，同時也會給多并發(fā)場景下的元數(shù)據(jù)更新操作引入性能瓶頸點。杉巖AgileDB通過支持多列族的行事務(wù)來解決這類問題：

• 將元數(shù)據(jù)內(nèi)容和日志獨立存儲在不同的列族上，同時對不同列族之間的數(shù)據(jù)創(chuàng)建映射。通過該映射可以快速獲取與某個元數(shù)據(jù)內(nèi)容關(guān)聯(lián)的Change log記錄，并且在數(shù)據(jù)庫發(fā)生數(shù)據(jù)遷移時，按照映射保證操作數(shù)據(jù)和日志始終處于同一個節(jié)點上。
• 對于Change log列族，AgileDB在內(nèi)部以時間序建立索引，對Change log 進行有序排列，滿足業(yè)務(wù)對Change log的快速范圍訪問和刪除需求。

單行多列族特性的設(shè)計使得元數(shù)據(jù)的更新和Change log記錄在同一個事務(wù)中提交時，不需要跨分片走2PC提交即可保證原子性，在AgileDB分片因擴縮容等導(dǎo)致的分裂、合并等場景下也不受影響，在不增加事務(wù)開銷的同時，很好的支持了通用文件系統(tǒng)的站點同步等高級功能。

基于AgileDB的杉巖分布式存儲系統(tǒng)的優(yōu)勢

元數(shù)據(jù)是非結(jié)構(gòu)化數(shù)據(jù)存儲系統(tǒng)的“靈魂”，杉巖數(shù)據(jù)的下一代融合對象存儲產(chǎn)品、面向工業(yè)質(zhì)檢大數(shù)據(jù)存儲的IDM產(chǎn)品都使用AgileDB作為元數(shù)據(jù)底座。杉巖融合對象存儲產(chǎn)品融合了CIFS/NFS/FTP/FUSE/S3協(xié)議，提供了比傳統(tǒng)分布式文件系統(tǒng)和對象存儲系統(tǒng)更大規(guī)模的存儲能力和并發(fā)性能，并且實現(xiàn)了文件和對象協(xié)議的原生無損互通。集成AgileDB的杉巖融合對象存儲系統(tǒng)有以下特點：

• 全對稱架構(gòu)，元數(shù)據(jù)存儲組件和數(shù)據(jù)存儲組件一樣，無單點瓶頸（AgileDB通過HLC避免了事務(wù)通過單點授時），提供了更高擴展能力以及安裝部署的靈活性。
• 單對象存儲桶或單文件系統(tǒng)命名空間輕松支持千億以上海量小文件的存儲。
• 根據(jù)不同業(yè)務(wù)的需要可創(chuàng)建不同類型的對象存儲桶：樹形結(jié)構(gòu)的文件桶或扁平結(jié)構(gòu)的普通對象桶。兩種桶在同一個AgileDB實例上通過不同的schema來實現(xiàn)，互不影響。
• 文件和對象協(xié)議原生無損互通，無需協(xié)議轉(zhuǎn)換網(wǎng)關(guān)。二者共享元數(shù)據(jù)與Change log日志，通過文件接口寫入的數(shù)據(jù)，可以利用對象接口為其定義業(yè)務(wù)標(biāo)簽，文件系統(tǒng)命名空間中的數(shù)據(jù)也可借助對象存儲的生命周期管理功能實現(xiàn)數(shù)據(jù)流動。
• AgileDB作為存儲系統(tǒng)的內(nèi)部的元數(shù)據(jù)服務(wù)，可通過Kafka或消息推送接口與其它外部大數(shù)據(jù)分析系統(tǒng)或組件連接，支撐更高級的業(yè)務(wù)元數(shù)據(jù)分析能力。

總結(jié)

3FS的技術(shù)實現(xiàn)架構(gòu)及相關(guān)性能數(shù)據(jù)證明，存儲系統(tǒng)的產(chǎn)品中處處存在trade off。只有真正了解自身需求，在整個系統(tǒng)端到端的設(shè)計中做出細(xì)粒度的解構(gòu)，在分布式文件系統(tǒng)的核心組件——元數(shù)據(jù)服務(wù)上，這種服務(wù)無狀態(tài)、數(shù)據(jù)下沉至第三方分布式KVDB的“存算分離”式設(shè)計，才不會因為分離帶來的網(wǎng)絡(luò)開銷以及分布式KVDB的事務(wù)開銷而拉低整個系統(tǒng)的性能。

杉巖數(shù)據(jù)針對客戶的應(yīng)用場景，自研了AgileDB分布式KVDB系統(tǒng)，并且將其應(yīng)用于自研海量對象與文件融合存儲產(chǎn)品上，拓展了分布式KVDB作為大型存儲系統(tǒng)元數(shù)據(jù)底座這一技術(shù)架構(gòu)的應(yīng)用邊界。

nina