企業內部存儲架構的發展和演進，是個長期延續的過程， IT規劃人員有可能將人工智能（AI）視為未來幾年才需要投入的改造工程。

然而，AI大浪到來比想象中更快，越來越多行業將使用AI推動業務的變革。

另一方面，AI工作的負載不同于以往任何處理過的IT負載。

AI工作負載具有全新的特點，它面對的是海量的非結構化數據集，需要極高的隨機訪問性能，極低延時以及大規模存儲容量。

AI不僅會創造全新的行業，而且還將從根本上改變現有組織業務開展的方式。

IT規劃人員需要立即開始著眼關注其存儲基礎架構是否已經為即將到來的AI浪潮做好了準備。

AI對存儲提出了怎樣的要求？在回答現在有什么面向AI的存儲解決方案時，我們需要先了解一下，人工智能下的數據到底有哪些特征，基于這些數據，到底需要一個什么樣的存儲？我們通過逐層分析，將最終過濾出AI業務對存儲的綜合訴求。

海量非結構化數據存儲AI業務中除了個別業務場景主要針對結構化數據進行分析外（例如消費記錄、交易記錄等風險控制、趨勢預測場景），大多數場景需要處理的是非結構化數據，例如圖像識別、語音識別、自動駕駛等，這些場景通常使用的是深度學習的算法，必須依賴海量圖片、語音、視頻的輸入。

數據共享訪問多個AI計算節點需要共享訪問數據。

由于AI架構需要使用到大規模的計算集群（GPU服務器），集群中的服務器訪問的數據來自一個統一的數據源，即一個共享的存儲空間。

這種共享訪問的數據有諸多好處，它可以保證不同服務器上訪問數據的一致性，減少不同服務器上分別保留數據帶來的數據冗余等。

那么哪種接口能提供共享訪問？塊存儲，需要依賴上層的應用（例如Oracle RAC）實現協同、鎖、會話的切換等機制，才能實現在多節點間共享塊存儲設備，因此不適合直接用于AI應用。

能實現共享訪問的通常有對象存儲和文件存儲，從數據訪問的接口層面看，好像都能實現數據共享。

但哪個接口更方便，我們需要深入地看一下AI的上層應用框架如何使用存儲。

我們以AI生態中非常流行的PyTorch為例，PyTorch在加載圖片數據時，通常會調用以下程序：from torchvision import datasets, transformsdataset = datasets.ImageFolder('path/to/data', transform=transforms)那么torchvision的datasets.ImageFolder如何加載圖片呢？我們來看看ImageFolder的構造函數，這里面會有一個默認的default_loader：默認的default_loader會是什么行為呢？我們再來看，通常情況下，default_loader會調用pil_loader方法：那pil_loader怎么讀數據的呢？謎底即將揭曉：這就是最典型的Python直接訪問文件系統文件的open方法，所以很明顯，PyTorch會默認通過文件接口訪問數據。

如果需要通過其它存儲接口調用ImageFolder，還需要為其編寫特定的loader，這就增加了額外不必要的開發工作量。

因此，從AI應用框架的角度看，文件接口是最友好的存儲訪問方式。

讀多寫少，高吞吐，低延時AI數據特點是讀多寫少，要求高吞吐、低延時。

深度學習過程訓練中，需要對數據進行訓練，以視覺識別為例，它需要加載數千萬張，甚至上億張圖片，針對圖片使用卷積神經網絡、ResNet等算法，生成識別的模型。

完成一輪訓練后，為了減少圖片輸入順序的相關性對訓練結果帶來的影響，會將文件次序打亂之后，重新加載，訓練多個輪次（每個輪次稱之為epoch）。

這就意味著每個epoch都需要根據新的順序加載數千萬、上億張圖片。

圖片的讀取速度，即延時，對完成訓練過程的時間長短會造成很大影響。

前面提到，對象存儲和文件存儲都可以為GPU集群提供共享的數據訪問，那么哪個存儲接口能提供更低的延時呢？業界領先的國際水準的高性能對象存儲，讀延時約為9ms，而高性能文件系統延時通常為2-3ms，考慮到數億張圖片的n次加載，這個差距會被放大到嚴重影響AI訓練效率。

從文件加載的角度看，高性能文件系統在延時特性上，也成為AI的首選。

IO Pattern復雜大文件、小文件，順序讀、隨機讀混合場景。

不同的業務類型所對應的數據具有不同特點，例如視覺識別，通常處理的是100KB以下的小文件；語音識別，大多數1MB以上的大文件，對這些獨立的文件，采用的是順序讀。

而有的算法工程師，會將幾十萬、甚至千萬個小文件聚合成一個數百GB，甚至TB級別的大文件，在每個epoch中，根據框架隨機生成的序列，對這些大文件進行隨機讀。

在無法預測文件大孝IO類型的背景下，對復雜IO特征的高性能支持，也是AI業務對存儲的需求。

AI業務容器化AI應用業務逐步向Kubernetes容器平臺遷移，數據訪問自然要讓AI業務在容器平臺中最方便地使用。

理解這一點非常容易，在業務單機運行的時代，數據放在直通到服務器的磁盤上，稱之為DAS模式。

到了業務運行在多物理機組成的集群時代，為了統一管理和方便使用數據，數據存放在SAN陣列上。

到云時代，數據跟著放到了云上，放到了適合云訪問的分布式存儲、對象存儲里。

由此可見，數據總是需要通過業務訪問最方便的方式進行存放和管理。

那么到了容器時代、云原生時代，數據自然應該放到云原生應用訪問和管理最方便的存儲上。

運行平臺向公有云發展公有云成為AI業務更青睞或首選的運行平臺，而公有云原生的存儲方案更面向通用型應用，針對AI業務的高吞吐、低延時、大容量需求，存在一定欠缺。

AI業務大多具有一定的潮汐性，公有云彈性和按需付費的特性，再加上公有云高性能GPU服務器產品的成熟及使用，使公有云的計算資源成為了AI業務降本增效的首眩而與AI業務相配套，具有前面所述特點的公有云存儲方案，卻仍然缺失。

近年來，我們看到一些國外的存儲廠商（例如NetApp、Qumulo、ElastiFile等），將其產品發布并運行在了公有云上，是公有云的原生存儲產品和方案距離用戶特定業務應用訴求存在缺失的的印證和解讀。

同樣，適合AI應用的存儲方案在公有云上的落地，是解決AI在公有云進一步落地的最后一公里問題。

現有哪些AI存儲方案，能滿足以上AI大規模應用的需求嗎？數據直接存入GPU服務器的SSD，即DAS方式。

這種方式能保證數據讀取的高帶寬、低延時，然而相較而言，缺點更為明顯，即數據容量非常有限，與此同時，SSD或NVMe磁盤的性能無法被充分發揮（通常情況下，高性能NVMe的性能利用率不足50%），不同服務器間的SSD形成孤島，數據冗余現象非常嚴重。

因此，這種方式在真正的AI業務實踐中，極少被使用。

共享的向上擴展（Scale-Up）的存儲陣列是可用的共享解決方案中最常見的，也可能是最熟悉的方案。

與DAS一樣，共享的存儲陣列也存在類似的缺點，相對于傳統的工作負載，AI的工作負載實際上會將這些缺點暴露得更快。

最明顯的是系統可以存儲多少總數據？ 大多數傳統陣列系統每個系統幾乎只能增長到1 PB的存儲，并且由于大多數AI大規模工作負載將需要數十PB的存儲量，因此企業只能不斷采購新的存儲陣列，導致數據孤島的產生。

即使克服了容量挑戰，傳統陣列存儲也會造成性能問題。

這些系統通常只能支持有限數量的存儲控制器，最常見的是兩個控制器，而典型的AI工作負載是高度并行的，它很容易使小型控制器不堪重負。

用戶通常使用的是GlusterFS、CephFS、Lustre，開源分布式文件系統的首要問題是管理和運維的復雜度。

其次，GlusterFS、CephFS對海量小文件，及大規模、大容量背景下的性能難以保證。

考慮到高昂的GPU價格，如果在數據訪問上不能給予足夠的支撐，GPU的投入產出比將大幅降低，這是AI應用的管理者們最不希望看到的。

在對象存儲上搭建文件訪問接口網關。

首先對象存儲對隨機寫或追加寫存在天然劣勢，會導致AI業務中出現寫操作時，不能很好支持。

其次，對象存儲在讀延時上的劣勢，經過文件訪問接口網關后，再一次被放大。

雖然通過預讀或緩存的方式，可以將一部分數據加載到前端的SSD設備上，但這會帶來以下幾個問題：1）導致上層AI框架需要針對底層的特殊架構進行適配，對框架具有入侵性，例如執行預讀程序；2）會帶來數據加載速度不均，在數據加載過程中，或前端SSD緩存不命中時，GPU利用率下降50%-70%。

以上這些方案，僅從數據規模的可擴展性、訪問性能、AI平臺的通用性上分析來看，都不是理想的面向AI的存儲方案。

YRCloudFile面向AI場景的存儲產品YRCloudFile具備的幾大特性非常契合AI應用的綜合需求。

總結通過分析，我們希望能夠給AI業務的規劃人員提供關于AI業務對存儲實際需求的觀察和洞見，幫助客戶在AI業務落地，提供AI存儲產品的優化方案。

AI將成為信息化工業革命后，再次改變世界的技術和方向，AI浪潮已經在不經意間來到我們的身邊，是時候考慮面向AI的新型存儲了。