人工智能是數據的消耗大戶，對存儲有針對性的需求。這次我們講講面向AI場景的存儲性能優化思路。
談優化之前，我們先分析一下AI訪問存儲的幾個特點：
- 海量文件，訓練模型的精準程度依賴於數據集的大小，樣本數據集越大，就爲模型更精確提供了基礎。通常，訓練任務需要的文件數量都在幾億，十幾億的量級，對存儲的要求是能夠承載幾十億甚至上百億的文件數量。
- 小文件，很多的訓練模型都是依賴於圖片、音頻片段、視頻片段文件，這些文件基本上都是在幾KB到幾MB之間，對於一些特徵文件，甚至只有幾十到幾百個字節。
- 讀多寫少，在大部分場景中，訓練任務只讀取文件，把文件讀取上來之後就開始計算，中間很少產生中間數據，即使產生了少量的中間數據，也是會選擇寫在本地，很少選擇寫回存儲集羣，因此是讀多寫少，並且是一次寫，多次讀。
- 目錄熱點，由於訓練時，業務部門的數據組織方式不可控，系統管理員不知道用戶會怎樣存儲數據。很有可能用戶會將大量文件存放在同一個目錄，這樣會導致多個計算節點在訓練過程中，會同時讀取這一批數據，這個目錄所在的元數據節點就會成爲熱點。跟一些AI公司的同事交流中，大家經常提到的一個問題就是，用戶在某一個目錄下存放了海量文件，導致訓練的時候出現性能問題，其實就是碰到了存儲的熱點問題。
綜上，對於AI場景來說，分佈式存儲面臨三大挑戰：
- 海量文件的存儲
- 小文件的訪問性能
- 目錄熱點
海量文件的存儲
首先討論海量文件存儲的問題。海量文件存儲的核心問題是什麼，是文件的元數據管理和存儲。爲什麼海量文件會是一個難題，我們看下傳統的分佈式文件存儲架構，以HDFS，MooseFS爲例，他們的元數據服務都是主備模式，只有一組元數據。這一組MDS就會受限於CPU，內存，網絡以及磁盤等因素，很難支持海量文件的存儲，也很難給高併發訪問業務提供對應的存儲性能。MooseFS單集羣最大隻能支持20億的文件數量。傳統的分佈式文件存儲都是針對大文件進行設計的，如果按照每個文件100MB計算，只需要1千萬的文件，其總容量就有1PB了，所以對於大文件場景，集羣容量是首要考慮的問題。但在AI場景中情況則不同，我們前面分析到，AI場景中80%以上是小文件，一個文件只有幾十KB，文件數量動輒就幾十億，文件的數量成爲了文件系統要解決的首要矛盾。
針對這個問題，該如何解決呢？我們第一反應就是做橫向水平擴展，把單點的MDS集羣化。橫向擴展的元數據集羣可以很好地解決單MDS的問題。第一，緩解了CPU，內存的壓力；第二，多個MDS也可以存儲更多的元數據信息；第三，元數據的處理能力也能夠水平擴展，進而提升海量文件併發訪問的性能。
分佈式MDS的主流架構有三種：
第一種是靜態子樹，目錄的存放位置是固定的，目錄和文件的元數據以及他們數據都放在該節點上。NFS是一個典型的靜態子樹用法，每個NFS Server代表了一個元數據節點，只要能夠保證各個掛載點的順序和位置一致，多個NFS Server可以組成一個分佈式的文件存儲集羣。它的優點是方式簡單，不需要代碼實現，只需要把多個NFS Server拼湊起來，保證掛載點一致就行。對應的，缺點也很明顯，一個是運維不方便，各個客戶端節點需要保證掛載點一致，需要人工干預，換個說法，這個方案並不是統一的命名空間，會帶來維護上的複雜度；另外一個是會有數據熱點問題，當一批數據進來後，基本上都會落在同一個NFS server上。訓練任務讀取這批數據的時候，所有的壓力也都會集中在這個NFS server上，這個節點就會成爲熱點。
第二種是動態子樹，目錄元數據會隨着訪問的熱度在不同的MDS節點上進行遷移，保證MDS之間的負載是均衡的。CephFS就是採用的這種方式，動態子樹這個概念也是Ceph的作者提出來的。理論上來說這是一種相對完美的架構，消除了熱點問題，元數據集羣擴容也很方便。但是理想很豐滿，現實很骨感，它的工程複雜度比較高，很難做到穩定。
第三種是Hash，GlusterFS採用的是這種方式，當然了GlusterFS是採用的基於路徑的hash方式。它的優點是文件位置分散的比較均勻，不會有熱點問題。但是劣勢也很明顯，元數據缺乏本地性，查詢類的操作會很慢（例如對目錄進行檢索），需要遍歷整個集羣。
YRCloudFile採用的是靜態子樹+目錄Hash兩者結合的方式。這種方式有三個要素：
- 根目錄在固定的MDS節點；
- 每一級目錄都會根據Entry name進行hash再次選擇MDS，保證橫向擴展的能力；
- 目錄下文件的元數據進行存放時，不進行hash，而是跟父目錄在同一個節點，保證一定程度的元數據本地性。
這種做法帶來兩個好處，其一是實現了元數據的分佈存儲，從而通過擴展元數據節點即可支持百億級別的文件數量，其二是在一定程度上保證了元數據的檢索性能，減少在多個節點上進行元數據檢索和操作。
小文件的訪問性能
其次，我們討論小文件性能訪問。關於小文件，我們需要知道幾點：第一，爲什麼關注小文件，前邊我們提到，AI訓練中，大的圖片，語音文件通常會切片後進行分析，有助於分析特徵，訓練的文件大小通常在幾KB到幾MB之間，小文件的吞吐性能直接影響了AI訓練效率；第二，小文件的性能瓶頸在哪裏，讀取一個小文件，需要多次元數據操作加一次數據操作。通常的改進思路，小文件內聯，小文件聚合和客戶端讀緩存。這部分內容，本文先賣個關子，後續再通過單獨的文章闡述。
目錄熱點
最後我們重點來討論下目錄熱點的問題。
從這個圖中，我們可以看到，假如dir3目錄中有大量文件，比如說幾百萬，上千萬文件，訓練的時候，多個計算節點需要同時讀這批文件的時候，dir3所在的MDS節點就會變成一個熱點。
如何去解決熱點問題呢？直觀的想法，既然目錄變成了一個熱點，那就對目錄進行拆分。對目錄進行拆分有兩種思路，一種是目錄的鏡像擴展，另一種是增加虛擬子目錄。兩種都能解決熱點所引發的性能問題。
目錄的鏡像擴展，就是對指定的目錄進行設置，這個目錄及其下的文件元數據會在指定的幾個MDS節點上存在，具體的這些MDS節點的位置信息會記錄在目錄的inode中，對這個目錄內的文件進行open/close/unlink等操作的時候，會根據filename進行hash，找到對應MDS節點，再對文件進行操作，這樣就把熱點問題分攤到了指定的幾個MDS節點上。整個思路類似於web架構中的負載均衡，如圖所示。
我們採用的是第二種，增加虛擬子目錄的方式。這種方式雖然多了一層目錄的查詢操作，但是足夠靈活，可以把熱點分攤到集羣中所有的元數據節點，同時也可以解決另外一個問題，就是單目錄的文件數量問題。增加虛擬子目錄可以很好的解決這個問題，使單目錄可以支撐20億左右的文件數量，並且可以根據虛擬子目錄的數量靈活調整。
我們通過訪問/dir1/dir2/file1舉例來看看虛擬子目錄是如何實現的。假設dir2是開啓了dirStripe功能。訪問流程：
- 在MDS1上拿到根目錄的inode信息，查看沒有開啓dirStripe
- 在MDS1上獲取dir1的dentry信息，找到所屬owner（mds2）
- 在MDS2上拿到dir1的inode信息，查看沒有開啓dirStripe
- 在MDS2上獲取dir2的dentry信息，找到所屬owner（mds3）
- 在MDS3上拿到dir2的inode信息，查看開啓了dirStripe
- 根據file1的filename，hash到虛擬目錄2上
- 在MDS3上獲取虛擬目錄2的dentry信息，找到所屬owner(mds4)
- 在MDS4上拿到file1的inode信息，返回給客戶端
測試模擬了AI訓練中，多個客戶端併發訪問同一個目錄的場景。圖中的結果是增加目錄拆分前後的性能對比，從圖中可以看到，無論是hard read, hard write，還是stat delete，目錄拆分後，都有10倍以上的性能提升。
總結
本文針對海量文件存儲、小文件訪問性能、熱點訪問三個維度，分析了面向AI場景下，分佈式文件系統面臨的挑戰，以及我們的應對思路，也希望藉此文和更多技術專家交流如何對AI場景下的存儲方案進行針對性的優化。
關於焱融科技
焱融科技是一家以軟件定義存儲技術爲核心競爭力的高新技術企業，在分佈式存儲等關鍵技術上擁有自主知識產權，是容器存儲的領導者。焱融科技針對各行業業務特性，打造個性化行業解決方案，提供一站式的產品與服務。焱融科技系列產品已服務於人工智能、金融、政府、製造業、互聯網等行業的衆多客戶。瞭解更多焱融科技信息，請訪問官網http://www.yanrongyun.com。