默認(rèn)的default_loader會(huì)是什么行為呢？我們?cè)賮?lái)看，通常情況下，default_loader會(huì)調(diào)用pil_loader方法：

那pil_loader怎么讀數(shù)據(jù)的呢？謎底即將揭曉：

這就是最典型的Python直接訪(fǎng)問(wèn)文件系統(tǒng)文件的open方法，所以很明顯，PyTorch會(huì)默認(rèn)通過(guò)文件接口訪(fǎng)問(wèn)數(shù)據(jù)。如果需要通過(guò)其它存儲(chǔ)接口調(diào)用ImageFolder，還需要為其編寫(xiě)特定的loader，這就增加了額外不必要的開(kāi)發(fā)工作量。

因此，從AI應(yīng)用框架的角度看，文件接口是最友好的存儲(chǔ)訪(fǎng)問(wèn)方式。

讀多寫(xiě)少，高吞吐，低延時(shí)

AI數(shù)據(jù)特點(diǎn)是讀多寫(xiě)少，要求高吞吐、低延時(shí)。深度學(xué)習(xí)過(guò)程訓(xùn)練中，需要對(duì)數(shù)據(jù)進(jìn)行訓(xùn)練，以視覺(jué)識(shí)別為例，它需要加載數(shù)千萬(wàn)張，甚至上億張圖片，針對(duì)圖片使用卷積神經(jīng)網(wǎng)絡(luò)、ResNet等算法，生成識(shí)別的模型。完成一輪訓(xùn)練后，為了減少圖片輸入順序的相關(guān)性對(duì)訓(xùn)練結(jié)果帶來(lái)的影響，會(huì)將文件次序打亂之后，重新加載，訓(xùn)練多個(gè)輪次（每個(gè)輪次稱(chēng)之為epoch）。這就意味著每個(gè)epoch都需要根據(jù)新的順序加載數(shù)千萬(wàn)、上億張圖片。圖片的讀取速度，即延時(shí)，對(duì)完成訓(xùn)練過(guò)程的時(shí)間長(zhǎng)短會(huì)造成很大影響。

前面提到，對(duì)象存儲(chǔ)和文件存儲(chǔ)都可以為GPU集群提供共享的數(shù)據(jù)訪(fǎng)問(wèn)，那么哪個(gè)存儲(chǔ)接口能提供更低的延時(shí)呢？業(yè)界領(lǐng)先的國(guó)際水準(zhǔn)的高性能對(duì)象存儲(chǔ)，讀延時(shí)約為9ms，而高性能文件系統(tǒng)延時(shí)通常為2-3ms，考慮到數(shù)億張圖片的n次加載，這個(gè)差距會(huì)被放大到嚴(yán)重影響AI訓(xùn)練效率。

從文件加載的角度看，高性能文件系統(tǒng)在延時(shí)特性上，也成為AI的首選。

IO Pattern復(fù)雜

大文件、小文件，順序讀、隨機(jī)讀混合場(chǎng)景。不同的業(yè)務(wù)類(lèi)型所對(duì)應(yīng)的數(shù)據(jù)具有不同特點(diǎn)，例如視覺(jué)識(shí)別，通常處理的是100KB以下的小文件；語(yǔ)音識(shí)別，大多數(shù)1MB以上的大文件，對(duì)這些獨(dú)立的文件，采用的是順序讀。而有的算法工程師，會(huì)將幾十萬(wàn)、甚至千萬(wàn)個(gè)小文件聚合成一個(gè)數(shù)百GB，甚至TB級(jí)別的大文件，在每個(gè)epoch中，根據(jù)框架隨機(jī)生成的序列，對(duì)這些大文件進(jìn)行隨機(jī)讀。

在無(wú)法預(yù)測(cè)文件大小、IO類(lèi)型的背景下，對(duì)復(fù)雜IO特征的高性能支持，也是AI業(yè)務(wù)對(duì)存儲(chǔ)的需求。

AI業(yè)務(wù)容器化

AI應(yīng)用業(yè)務(wù)逐步向Kubernetes容器平臺(tái)遷移，數(shù)據(jù)訪(fǎng)問(wèn)自然要讓AI業(yè)務(wù)在容器平臺(tái)中最方便地使用。理解這一點(diǎn)非常容易，在業(yè)務(wù)單機(jī)運(yùn)行的時(shí)代，數(shù)據(jù)放在直通到服務(wù)器的磁盤(pán)上，稱(chēng)之為DAS模式。到了業(yè)務(wù)運(yùn)行在多物理機(jī)組成的集群時(shí)代，為了統(tǒng)一管理和方便使用數(shù)據(jù)，數(shù)據(jù)存放在SAN陣列上。到云時(shí)代，數(shù)據(jù)跟著放到了云上，放到了適合云訪(fǎng)問(wèn)的分布式存儲(chǔ)、對(duì)象存儲(chǔ)里。由此可見(jiàn)，數(shù)據(jù)總是需要通過(guò)業(yè)務(wù)訪(fǎng)問(wèn)最方便的方式進(jìn)行存放和管理。那么到了容器時(shí)代、云原生時(shí)代，數(shù)據(jù)自然應(yīng)該放到云原生應(yīng)用訪(fǎng)問(wèn)和管理最方便的存儲(chǔ)上。

運(yùn)行平臺(tái)向公有云發(fā)展

公有云成為AI業(yè)務(wù)更青睞或首選的運(yùn)行平臺(tái)，而公有云原生的存儲(chǔ)方案更面向通用型應(yīng)用，針對(duì)AI業(yè)務(wù)的高吞吐、低延時(shí)、大容量需求，存在一定欠缺。AI業(yè)務(wù)大多具有一定的潮汐性，公有云彈性和按需付費(fèi)的特性，再加上公有云高性能GPU服務(wù)器產(chǎn)品的成熟及使用，使公有云的計(jì)算資源成為了AI業(yè)務(wù)降本增效的首選。而與AI業(yè)務(wù)相配套，具有前面所述特點(diǎn)的公有云存儲(chǔ)方案，卻仍然缺失。近年來(lái)，我們看到一些國(guó)外的存儲(chǔ)廠(chǎng)商（例如NetApp、Qumulo、ElastiFile等），將其產(chǎn)品發(fā)布并運(yùn)行在了公有云上，是公有云的原生存儲(chǔ)產(chǎn)品和方案距離用戶(hù)特定業(yè)務(wù)應(yīng)用訴求存在缺失的的印證和解讀。同樣，適合AI應(yīng)用的存儲(chǔ)方案在公有云上的落地，是解決AI在公有云進(jìn)一步落地的最后一公里問(wèn)題。

現(xiàn)有哪些AI存儲(chǔ)方案，能滿(mǎn)足以上AI大規(guī)模應(yīng)用的需求嗎？

• DAS方式

數(shù)據(jù)直接存入GPU服務(wù)器的SSD，即DAS方式。這種方式能保證數(shù)據(jù)讀取的高帶寬、低延時(shí)，然而相較而言，缺點(diǎn)更為明顯，即數(shù)據(jù)容量非常有限，與此同時(shí)，SSD或NVMe磁盤(pán)的性能無(wú)法被充分發(fā)揮（通常情況下，高性能NVMe的性能利用率不足50%），不同服務(wù)器間的SSD形成孤島，數(shù)據(jù)冗余現(xiàn)象非常嚴(yán)重。因此，這種方式在真正的AI業(yè)務(wù)實(shí)踐中，極少被使用。

• 傳統(tǒng)陣列

共享的向上擴(kuò)展（Scale-Up）的存儲(chǔ)陣列是可用的共享解決方案中最常見(jiàn)的，也可能是最熟悉的方案。與DAS一樣，共享的存儲(chǔ)陣列也存在類(lèi)似的缺點(diǎn)，相對(duì)于傳統(tǒng)的工作負(fù)載，AI的工作負(fù)載實(shí)際上會(huì)將這些缺點(diǎn)暴露得更快。最明顯的是系統(tǒng)可以存儲(chǔ)多少總數(shù)據(jù)？ 大多數(shù)傳統(tǒng)陣列系統(tǒng)每個(gè)系統(tǒng)幾乎只能增長(zhǎng)到1 PB的存儲(chǔ)，并且由于大多數(shù)AI大規(guī)模工作負(fù)載將需要數(shù)十PB的存儲(chǔ)量，因此企業(yè)只能不斷采購(gòu)新的存儲(chǔ)陣列，導(dǎo)致數(shù)據(jù)孤島的產(chǎn)生。即使克服了容量挑戰(zhàn)，傳統(tǒng)陣列存儲(chǔ)也會(huì)造成性能問(wèn)題。這些系統(tǒng)通常只能支持有限數(shù)量的存儲(chǔ)控制器，最常見(jiàn)的是兩個(gè)控制器，而典型的AI工作負(fù)載是高度并行的，它很容易使小型控制器不堪重負(fù)。

• 普通分布式文件系統(tǒng)

用戶(hù)通常使用的是GlusterFS、CephFS、Lustre，開(kāi)源分布式文件系統(tǒng)的首要問(wèn)題是管理和運(yùn)維的復(fù)雜度。其次，GlusterFS、CephFS對(duì)海量小文件，及大規(guī)模、大容量背景下的性能難以保證?？紤]到高昂的GPU價(jià)格，如果在數(shù)據(jù)訪(fǎng)問(wèn)上不能給予足夠的支撐，GPU的投入產(chǎn)出比將大幅降低，這是AI應(yīng)用的管理者們最不希望看到的。

• 對(duì)象存儲(chǔ)

在對(duì)象存儲(chǔ)上搭建文件訪(fǎng)問(wèn)接口網(wǎng)關(guān)。首先對(duì)象存儲(chǔ)對(duì)隨機(jī)寫(xiě)或追加寫(xiě)存在天然劣勢(shì)，會(huì)導(dǎo)致AI業(yè)務(wù)中出現(xiàn)寫(xiě)操作時(shí)，不能很好支持。其次，對(duì)象存儲(chǔ)在讀延時(shí)上的劣勢(shì)，經(jīng)過(guò)文件訪(fǎng)問(wèn)接口網(wǎng)關(guān)后，再一次被放大。雖然通過(guò)預(yù)讀或緩存的方式，可以將一部分?jǐn)?shù)據(jù)加載到前端的SSD設(shè)備上，但這會(huì)帶來(lái)以下幾個(gè)問(wèn)題：1）導(dǎo)致上層AI框架需要針對(duì)底層的特殊架構(gòu)進(jìn)行適配，對(duì)框架具有入侵性，例如執(zhí)行預(yù)讀程序；2）會(huì)帶來(lái)數(shù)據(jù)加載速度不均，在數(shù)據(jù)加載過(guò)程中，或前端SSD緩存不命中時(shí)，GPU利用率下降50%-70%。

以上這些方案，僅從數(shù)據(jù)規(guī)模的可擴(kuò)展性、訪(fǎng)問(wèn)性能、AI平臺(tái)的通用性上分析來(lái)看，都不是理想的面向AI的存儲(chǔ)方案。

YRCloudFile——面向AI場(chǎng)景的存儲(chǔ)產(chǎn)品

YRCloudFile具備的幾大特性非常契合AI應(yīng)用的綜合需求。

• 首先，這是一款可共享訪(fǎng)問(wèn)的分布式文件存儲(chǔ)，可供GPU集群共享訪(fǎng)問(wèn)。提供的是文件訪(fǎng)問(wèn)接口，最適合對(duì)接AI的上層平臺(tái)。
• 支持高性能訪(fǎng)問(wèn)海量的非結(jié)構(gòu)化數(shù)據(jù)。通過(guò)YRCloudFile客戶(hù)端，上層GPU服務(wù)器可對(duì)存儲(chǔ)集群內(nèi)的不同節(jié)點(diǎn)實(shí)現(xiàn)并發(fā)訪(fǎng)問(wèn)，通過(guò)IO500測(cè)試，以及AI業(yè)界頭部企業(yè)驗(yàn)證，性能處于業(yè)界一流水平。在海量文件的場(chǎng)景下，能保持性能的持續(xù)穩(wěn)定輸出。YRCloudFile在元數(shù)據(jù)和數(shù)據(jù)服務(wù)的設(shè)計(jì)和實(shí)現(xiàn)上所做的大量?jī)?yōu)化，確保了AI業(yè)務(wù)復(fù)雜IO類(lèi)型對(duì)數(shù)據(jù)訪(fǎng)問(wèn)的性能要求。
• 通過(guò)Kubernetes平臺(tái)，可無(wú)縫調(diào)度和使用YRCloudFile提供的存儲(chǔ)能力。YRCloudFile除了提供標(biāo)準(zhǔn)的CSI接口外，還提供了RWX讀寫(xiě)、PV配額、PVC resize、PVC QoS等企業(yè)級(jí)功能，可以有力支撐在Kubernetes上運(yùn)行的AI業(yè)務(wù)對(duì)數(shù)據(jù)訪(fǎng)問(wèn)的需要。
• 支持公有云部署。YRCloudFile目前已經(jīng)可以在AWS、阿里云、騰訊云上快速部署，彌補(bǔ)了公有云對(duì)AI特定場(chǎng)景所需要的性能、可擴(kuò)展性、運(yùn)營(yíng)和維護(hù)上提出的特殊要求。

總結(jié)

通過(guò)分析，我們希望能夠給AI業(yè)務(wù)的規(guī)劃人員提供關(guān)于AI業(yè)務(wù)對(duì)存儲(chǔ)實(shí)際需求的觀察和洞見(jiàn)，幫助客戶(hù)在AI業(yè)務(wù)落地，提供AI存儲(chǔ)產(chǎn)品的優(yōu)化方案。AI將成為信息化工業(yè)革命后，再次改變世界的技術(shù)和方向，AI浪潮已經(jīng)在不經(jīng)意間來(lái)到我們的身邊，是時(shí)候考慮面向AI的新型存儲(chǔ)了。

songjy