企業(yè)內(nèi)部存儲架構(gòu)的發(fā)展和演進，是個長期延續(xù)的過程， IT規(guī)劃人員有可能將人工智能（AI）視為未來幾年才需要投入的改造工程。然而，AI大浪到來比想象中更快，越來越多行業(yè)將使用AI推動業(yè)務(wù)的變革。另一方面，AI工作的負載不同于以往任何處理過的IT負載。AI工作負載具有全新的特點，它面對的是海量的非結(jié)構(gòu)化數(shù)據(jù)集，需要極高的隨機訪問性能，極低延時以及大規(guī)模存儲容量。
AI不僅會創(chuàng)造全新的行業(yè)，而且還將從根本上改變現(xiàn)有組織業(yè)務(wù)開展的方式。IT規(guī)劃人員需要立即開始著眼關(guān)注其存儲基礎(chǔ)架構(gòu)是否已經(jīng)為即將到來的AI浪潮做好了準(zhǔn)備。
AI對存儲提出了怎樣的要求？
在回答現(xiàn)在有什么面向AI的存儲解決方案時，我們需要先了解一下，人工智能下的數(shù)據(jù)到底有哪些特征，基于這些數(shù)據(jù)，到底需要一個什么樣的存儲？我們通過逐層分析，將最終過濾出AI業(yè)務(wù)對存儲的綜合訴求。
海量非結(jié)構(gòu)化數(shù)據(jù)存儲
AI業(yè)務(wù)中除了個別業(yè)務(wù)場景主要針對結(jié)構(gòu)化數(shù)據(jù)進行分析外（例如消費記錄、交易記錄等風(fēng)險控制、趨勢預(yù)測場景），大多數(shù)場景需要處理的是非結(jié)構(gòu)化數(shù)據(jù)，例如圖像識別、語音識別、自動駕駛等，這些場景通常使用的是深度學(xué)習(xí)的算法，必須依賴海量圖片、語音、視頻的輸入。
數(shù)據(jù)共享訪問
多個AI計算節(jié)點需要共享訪問數(shù)據(jù)。由于AI架構(gòu)需要使用到大規(guī)模的計算集群（GPU服務(wù)器），集群中的服務(wù)器訪問的數(shù)據(jù)來自一個統(tǒng)一的數(shù)據(jù)源，即一個共享的存儲空間。這種共享訪問的數(shù)據(jù)有諸多好處，它可以保證不同服務(wù)器上訪問數(shù)據(jù)的一致性，減少不同服務(wù)器上分別保留數(shù)據(jù)帶來的數(shù)據(jù)冗余等。
那么哪種接口能提供共享訪問？
塊存儲，需要依賴上層的應(yīng)用（例如Oracle RAC）實現(xiàn)協(xié)同、鎖、會話的切換等機制，才能實現(xiàn)在多節(jié)點間共享塊存儲設(shè)備，因此不適合直接用于AI應(yīng)用。
能實現(xiàn)共享訪問的通常有對象存儲和文件存儲，從數(shù)據(jù)訪問的接口層面看，好像都能實現(xiàn)數(shù)據(jù)共享。但哪個接口更方便，我們需要深入地看一下AI的上層應(yīng)用框架如何使用存儲。我們以AI生態(tài)中非常流行的PyTorch為例，PyTorch在加載圖片數(shù)據(jù)時，通常會調(diào)用以下程序：
from torchvision import datasets， transforms
dataset = datasets.ImageFolder（‘path/to/data’， transform=transforms）
那么torchvision的datasets.ImageFolder如何加載圖片呢？我們來看看ImageFolder的構(gòu)造函數(shù)，這里面會有一個默認的default_loader：
默認的default_loader會是什么行為呢？我們再來看，通常情況下，default_loader會調(diào)用pil_loader方法：
那pil_loader怎么讀數(shù)據(jù)的呢？謎底即將揭曉：
這就是最典型的Python直接訪問文件系統(tǒng)文件的open方法，所以很明顯，PyTorch會默認通過文件接口訪問數(shù)據(jù)。如果需要通過其它存儲接口調(diào)用ImageFolder，還需要為其編寫特定的loader，這就增加了額外不必要的開發(fā)工作量。
因此，從AI應(yīng)用框架的角度看，文件接口是最友好的存儲訪問方式。
讀多寫少，高吞吐，低延時
AI數(shù)據(jù)特點是讀多寫少，要求高吞吐、低延時。深度學(xué)習(xí)過程訓(xùn)練中，需要對數(shù)據(jù)進行訓(xùn)練，以視覺識別為例，它需要加載數(shù)千萬張，甚至上億張圖片，針對圖片使用卷積神經(jīng)網(wǎng)絡(luò)、ResNet等算法，生成識別的模型。完成一輪訓(xùn)練后，為了減少圖片輸入順序的相關(guān)性對訓(xùn)練結(jié)果帶來的影響，會將文件次序打亂之后，重新加載，訓(xùn)練多個輪次（每個輪次稱之為epoch）。這就意味著每個epoch都需要根據(jù)新的順序加載數(shù)千萬、上億張圖片。圖片的讀取速度，即延時，對完成訓(xùn)練過程的時間長短會造成很大影響。
前面提到，對象存儲和文件存儲都可以為GPU集群提供共享的數(shù)據(jù)訪問，那么哪個存儲接口能提供更低的延時呢？業(yè)界領(lǐng)先的國際水準(zhǔn)的高性能對象存儲，讀延時約為9ms，而高性能文件系統(tǒng)延時通常為2-3ms，考慮到數(shù)億張圖片的n次加載，這個差距會被放大到嚴(yán)重影響AI訓(xùn)練效率。
從文件加載的角度看，高性能文件系統(tǒng)在延時特性上，也成為AI的首選。
IO Pattern復(fù)雜
大文件、小文件，順序讀、隨機讀混合場景。不同的業(yè)務(wù)類型所對應(yīng)的數(shù)據(jù)具有不同特點，例如視覺識別，通常處理的是100KB以下的小文件；語音識別，大多數(shù)1MB以上的大文件，對這些獨立的文件，采用的是順序讀。而有的算法工程師，會將幾十萬、甚至千萬個小文件聚合成一個數(shù)百GB，甚至TB級別的大文件，在每個epoch中，根據(jù)框架隨機生成的序列，對這些大文件進行隨機讀。
在無法預(yù)測文件大小、IO類型的背景下，對復(fù)雜IO特征的高性能支持，也是AI業(yè)務(wù)對存儲的需求。
AI業(yè)務(wù)容器化
AI應(yīng)用業(yè)務(wù)逐步向Kubernetes容器平臺遷移，數(shù)據(jù)訪問自然要讓AI業(yè)務(wù)在容器平臺中最方便地使用。理解這一點非常容易，在業(yè)務(wù)單機運行的時代，數(shù)據(jù)放在直通到服務(wù)器的磁盤上，稱之為DAS模式。到了業(yè)務(wù)運行在多物理機組成的集群時代，為了統(tǒng)一管理和方便使用數(shù)據(jù)，數(shù)據(jù)存放在SAN陣列上。到云時代，數(shù)據(jù)跟著放到了云上，放到了適合云訪問的分布式存儲、對象存儲里。由此可見，數(shù)據(jù)總是需要通過業(yè)務(wù)訪問最方便的方式進行存放和管理。那么到了容器時代、云原生時代，數(shù)據(jù)自然應(yīng)該放到云原生應(yīng)用訪問和管理最方便的存儲上。
運行平臺向公有云發(fā)展
公有云成為AI業(yè)務(wù)更青睞或首選的運行平臺，而公有云原生的存儲方案更面向通用型應(yīng)用，針對AI業(yè)務(wù)的高吞吐、低延時、大容量需求，存在一定欠缺。AI業(yè)務(wù)大多具有一定的潮汐性，公有云彈性和按需付費的特性，再加上公有云高性能GPU服務(wù)器產(chǎn)品的成熟及使用，使公有云的計算資源成為了AI業(yè)務(wù)降本增效的首選。而與AI業(yè)務(wù)相配套，具有前面所述特點的公有云存儲方案，卻仍然缺失。近年來，我們看到一些國外的存儲廠商（例如NetApp、Qumulo、ElastiFile等），將其產(chǎn)品發(fā)布并運行在了公有云上，是公有云的原生存儲產(chǎn)品和方案距離用戶特定業(yè)務(wù)應(yīng)用訴求存在缺失的的印證和解讀。同樣，適合AI應(yīng)用的存儲方案在公有云上的落地，是解決AI在公有云進一步落地的最后一公里問題。
現(xiàn)有哪些AI存儲方案，能滿足以上AI大規(guī)模應(yīng)用的需求嗎？
DAS方式
數(shù)據(jù)直接存入GPU服務(wù)器的SSD，即DAS方式。這種方式能保證數(shù)據(jù)讀取的高帶寬、低延時，然而相較而言，缺點更為明顯，即數(shù)據(jù)容量非常有限，與此同時，SSD或NVMe磁盤的性能無法被充分發(fā)揮（通常情況下，高性能NVMe的性能利用率不足50%），不同服務(wù)器間的SSD形成孤島，數(shù)據(jù)冗余現(xiàn)象非常嚴(yán)重。因此，這種方式在真正的AI業(yè)務(wù)實踐中，極少被使用。
傳統(tǒng)陣列
共享的向上擴展（Scale-Up）的存儲陣列是可用的共享解決方案中最常見的，也可能是最熟悉的方案。與DAS一樣，共享的存儲陣列也存在類似的缺點，相對于傳統(tǒng)的工作負載，AI的工作負載實際上會將這些缺點暴露得更快。最明顯的是系統(tǒng)可以存儲多少總數(shù)據(jù)？ 大多數(shù)傳統(tǒng)陣列系統(tǒng)每個系統(tǒng)幾乎只能增長到1 PB的存儲，并且由于大多數(shù)AI大規(guī)模工作負載將需要數(shù)十PB的存儲量，因此企業(yè)只能不斷采購新的存儲陣列，導(dǎo)致數(shù)據(jù)孤島的產(chǎn)生。即使克服了容量挑戰(zhàn)，傳統(tǒng)陣列存儲也會造成性能問題。這些系統(tǒng)通常只能支持有限數(shù)量的存儲控制器，最常見的是兩個控制器，而典型的AI工作負載是高度并行的，它很容易使小型控制器不堪重負。
普通分布式文件系統(tǒng)
用戶通常使用的是GlusterFS、CephFS、Lustre，開源分布式文件系統(tǒng)的首要問題是管理和運維的復(fù)雜度。其次，GlusterFS、CephFS對海量小文件，及大規(guī)模、大容量背景下的性能難以保證?？紤]到高昂的GPU價格，如果在數(shù)據(jù)訪問上不能給予足夠的支撐，GPU的投入產(chǎn)出比將大幅降低，這是AI應(yīng)用的管理者們最不希望看到的。
對象存儲在對象存儲上搭建文件訪問接口網(wǎng)關(guān)。首先對象存儲對隨機寫或追加寫存在天然劣勢，會導(dǎo)致AI業(yè)務(wù)中出現(xiàn)寫操作時，不能很好支持。其次，對象存儲在讀延時上的劣勢，經(jīng)過文件訪問接口網(wǎng)關(guān)后，再一次被放大。雖然通過預(yù)讀或緩存的方式，可以將一部分數(shù)據(jù)加載到前端的SSD設(shè)備上，但這會帶來以下幾個問題：1）導(dǎo)致上層AI框架需要針對底層的特殊架構(gòu)進行適配，對框架具有入侵性，例如執(zhí)行預(yù)讀程序；2）會帶來數(shù)據(jù)加載速度不均，在數(shù)據(jù)加載過程中，或前端SSD緩存不命中時，GPU利用率下降50%-70%。
以上這些方案，僅從數(shù)據(jù)規(guī)模的可擴展性、訪問性能、AI平臺的通用性上分析來看，都不是理想的面向AI的存儲方案。
YRCloudFile——面向AI場景的存儲產(chǎn)品
YRCloudFile具備的幾大特性非常契合AI應(yīng)用的綜合需求。
首先，這是一款可共享訪問的分布式文件存儲，可供GPU集群共享訪問。提供的是文件訪問接口，最適合對接AI的上層平臺。
支持高性能訪問海量的非結(jié)構(gòu)化數(shù)據(jù)。通過YRCloudFile客戶端，上層GPU服務(wù)器可對存儲集群內(nèi)的不同節(jié)點實現(xiàn)并發(fā)訪問，通過IO500測試，以及AI業(yè)界頭部企業(yè)驗證，性能處于業(yè)界一流水平。在海量文件的場景下，能保持性能的持續(xù)穩(wěn)定輸出。YRCloudFile在元數(shù)據(jù)和數(shù)據(jù)服務(wù)的設(shè)計和實現(xiàn)上所做的大量優(yōu)化，確保了AI業(yè)務(wù)復(fù)雜IO類型對數(shù)據(jù)訪問的性能要求。
通過Kubernetes平臺，可無縫調(diào)度和使用YRCloudFile提供的存儲能力。YRCloudFile除了提供標(biāo)準(zhǔn)的CSI接口外，還提供了RWX讀寫、PV配額、PVC resize、PVC QoS等企業(yè)級功能，可以有力支撐在Kubernetes上運行的AI業(yè)務(wù)對數(shù)據(jù)訪問的需要。
支持公有云部署。YRCloudFile目前已經(jīng)可以在AWS、阿里云、騰訊云上快速部署，彌補了公有云對AI特定場景所需要的性能、可擴展性、運營和維護上提出的特殊要求。
總結(jié)
通過分析，我們希望能夠給AI業(yè)務(wù)的規(guī)劃人員提供關(guān)于AI業(yè)務(wù)對存儲實際需求的觀察和洞見，幫助客戶在AI業(yè)務(wù)落地，提供AI存儲產(chǎn)品的優(yōu)化方案。AI將成為信息化工業(yè)革命后，再次改變世界的技術(shù)和方向，AI浪潮已經(jīng)在不經(jīng)意間來到我們的身邊，是時候考慮面向AI的新型存儲了。
下載文檔
