在大家剛開始投入到預(yù)訓(xùn)練模型時，有這樣一種觀點：GPU 很貴，相比之下存儲的成本忽略不計，可以直接選性能最好最貴的存儲方案。典型的高性能文件系統(tǒng)有 GPFS、Lustre、Weka，以及其他高性能 NAS 等。這些系統(tǒng)通常依賴全閃存(NVMe) 和高性能網(wǎng)絡(luò)提供極致性能。

同時，當(dāng)算力、數(shù)據(jù)與團(tuán)隊投入都增大的時候，我們又看到了幾個新的事實：

1. 零一萬物在其最新發(fā)表的論文《Yi: Open Foundation Models by 01.AI[1]》(以下簡稱《Yi 論文》)，其預(yù)訓(xùn)練數(shù)據(jù)集包含 3T tokens，通過 BPE tokenization 處理，每個 token 大約占 2Bytes，這意味著 3T tokens 大約等于 6TB 數(shù)據(jù)。然而，準(zhǔn)備可用于正式訓(xùn)練的數(shù)據(jù)集的過程包括數(shù)據(jù)抓取、清洗、轉(zhuǎn)換等多個前置步驟，涉及大量的實驗。這些實驗處理的數(shù)據(jù)量通常是正式訓(xùn)練數(shù)據(jù)集的 100 倍以上。隨著團(tuán)隊規(guī)模的擴(kuò)大，將產(chǎn)生更多實驗結(jié)果和中間數(shù)據(jù)，加上各種模型的 checkpoint 和日志數(shù)據(jù)，預(yù)訓(xùn)練環(huán)節(jié)總數(shù)據(jù)量預(yù)計將達(dá)到 10PB 到 100PB。

2. 正式訓(xùn)練環(huán)節(jié)，如上文推算，雖然數(shù)據(jù)集規(guī)模固定為 6T，企業(yè)可以將全部數(shù)據(jù)存儲于高性能存儲系統(tǒng)中。但是，高性能文件系統(tǒng)的性能都與容量是關(guān)聯(lián)的。例如，每 TB 容量提供 250MBps 吞吐，也就是說僅僅把 6TB 數(shù)據(jù)集存在高性能文件系統(tǒng)，僅能提供 1500MB/s 的吞吐，如果要達(dá)到訓(xùn)練所需的 I/O 性能，需要擴(kuò)大高性能文件系統(tǒng)容量。

于是，出于成本考慮用戶通常不會將所有數(shù)據(jù)僅存儲于之前提及的高性能文件存儲系統(tǒng)。用戶開始采用對象存儲與高性能文件存儲相結(jié)合的策略。這種做法雖然成本更低，但隨之而來的是需要額外人力和時間去處理兩套存儲系統(tǒng)間的數(shù)據(jù)同步、遷移和一致性管理等任務(wù)，這些工作不僅過程繁瑣，而且與追求高效率的目標(biāo)相悖。

一、AI 數(shù)據(jù)工程的存儲挑戰(zhàn)

高吞吐的數(shù)據(jù)訪問挑戰(zhàn)。在 AI 場景中，隨著企業(yè)使用 GPU 越來越多，底層存儲的 IO 已經(jīng)跟不上計算能力。企業(yè)希望存儲系統(tǒng)能提供高吞吐的數(shù)據(jù)訪問能力，充分發(fā)揮 GPU 的計算性能。舉個例子，在智能制造生產(chǎn)線上通過高精度相機(jī)給物品拍照，用缺陷識別模型自動找出質(zhì)量問題。這類模型的訓(xùn)練集只有 1~2 萬張圖片，但每張都是 GB 大小的高精度照片，總?cè)萘坑?10TB 了。訓(xùn)練過程中，如果存儲系統(tǒng)吞吐不足，會成為 GPU 訓(xùn)練的瓶頸。

AI 場景對于 10 億以上文件規(guī)模的存儲管理和高性能訪問的需求越來越強(qiáng)。在自動駕駛領(lǐng)域，用于模型訓(xùn)練的是百 KB 的小圖片，一個訓(xùn)練集由數(shù)千萬張百 KB 圖片組成，一張圖片就是一個文件，總的訓(xùn)練數(shù)據(jù)多達(dá)幾十億、甚至一百億文件。海量小文件管理一直是文件存儲領(lǐng)域的難題。

為熱點數(shù)據(jù)提供吞吐擴(kuò)展能力。在量化投資領(lǐng)域，用于模型訓(xùn)練的金融市場數(shù)據(jù)量相比 CV 領(lǐng)域小了很多，但是需要被多個研究團(tuán)隊共享，這會帶來數(shù)據(jù)熱點問題，就是數(shù)據(jù)存儲的磁盤吞吐已經(jīng)用滿，但是仍然不能滿足應(yīng)用端的需求。

除了由 AI 場景帶來了新的數(shù)據(jù)模式，基礎(chǔ)的計算環(huán)境也發(fā)生了巨大的變化。

如今在資源建設(shè)中，上云幾乎已經(jīng)是默認(rèn)選項。雖然很多團(tuán)隊會建設(shè)自己的 IDC，但也會做私有云的設(shè)計。同時，Kubernetes已經(jīng)成為了云原生架構(gòu)的事實標(biāo)準(zhǔn)。在 AI 業(yè)務(wù)中，整個 Data Pipeline 都構(gòu)建在 Kubernetes 上，算法工程師在平臺上申請資源，使用 Notebook 編寫代碼完成算法調(diào)試，使用 Argo、Airflow 等工作流引擎編排數(shù)據(jù)處理工作流，使用 Fluid 管理數(shù)據(jù)集，使用 BentoML 部署模型到應(yīng)用中。

云原生技術(shù)棧也是企業(yè)在建設(shè)存儲平臺時，普遍會考量的一個因素。隨著云計算的成熟，AI 業(yè)務(wù)更多轉(zhuǎn)向大規(guī)模分布式集群完成。集群中的節(jié)點數(shù)大幅度增加，存儲系統(tǒng)如何面對 Kubernetes 集群中上萬 Pod 的并發(fā)訪問是新的挑戰(zhàn)。

基礎(chǔ)架構(gòu)的IT人員面臨來自業(yè)務(wù)場景、計算環(huán)境的巨變，現(xiàn)有的存儲方案，軟硬一體機(jī)普遍存在這樣的痛點：1)不彈性;2)沒有分布式高可用;3)集群規(guī)模受限，已經(jīng)越來越少被使用;而分布式文件系統(tǒng)，比如 GlusterFS，CephFS，還有面向 HPC 設(shè)計的 Lustre， BeeGFS 和 GPFS，雖然可以部署大容量的集群，但是在云環(huán)境中提供彈性的吞吐能力受限。

結(jié)合上文提到的這些挑戰(zhàn)，我們羅列了對AI場景至關(guān)重要的存儲能力，方便企業(yè)在選擇存儲產(chǎn)品時進(jìn)行比較。

二、AI 數(shù)據(jù)存儲需要的關(guān)鍵能力

第一：POSIX 兼容性和數(shù)據(jù)一致性

在 AI/ML 領(lǐng)域，POSIX 是數(shù)據(jù)訪問最普遍的接口。上一代分布式文件系統(tǒng)，除了 HDFS，也都兼容 POSIX，但是近幾年云上的產(chǎn)品在 POSIX 支持上的做法并不一致。

1. 兼容度。用戶不能只是通過「產(chǎn)品兼容 POSIX」這樣的描述判斷，可以使用 pjdfstest 和 LTP 框架進(jìn)行測試。

2. 數(shù)據(jù)強(qiáng)一致性保證，這是保證計算正確性的基礎(chǔ)。存儲系統(tǒng)有多種不同的一致性實現(xiàn)，比如對象存儲通常是最終一致性(Eventually Consistency)，文件系統(tǒng)通常是強(qiáng)一致性(Strong Consistency)，我們做存儲系統(tǒng)選型時需要注意。

3. 用戶態(tài)還是內(nèi)核態(tài)的選擇。早期開發(fā)者選擇內(nèi)核態(tài)，因為這種方式 I/O 路徑有可能做到最極致的優(yōu)化。但是這幾年，我們遇到了越來越多「逃離內(nèi)核態(tài)」的開發(fā)者，原因有這樣幾個：第一，使用內(nèi)核態(tài)需要文件系統(tǒng)客戶端與內(nèi)核版本綁定，然后 GPU 和高性能網(wǎng)卡的驅(qū)動往往也需要適配特定的內(nèi)核版本，幾樣?xùn)|西排列組合對內(nèi)核版本的選擇和運(yùn)維是很大的負(fù)擔(dān)。第二，內(nèi)核態(tài)客戶端的異常會宕住宿主機(jī)操作系統(tǒng)，這一點對于 Kubernetes 平臺是非常不友好的。第三，用戶態(tài)的 FUSE 庫也在持續(xù)迭代，性能有了很大提升，在 JuiceFS 的客戶中已經(jīng)很好的支持了自動駕駛感知模型訓(xùn)練、量化投資策略訓(xùn)練等業(yè)務(wù)需求，可見在 AI 場景中已經(jīng)不是性能瓶頸。

準(zhǔn)備高質(zhì)量的訓(xùn)練數(shù)據(jù)是構(gòu)建出色基礎(chǔ)模型的基礎(chǔ)。數(shù)據(jù)準(zhǔn)備本身是一個復(fù)雜的流程，正如《Yi 論文》中所展示的那樣：

零一萬物數(shù)據(jù)預(yù)處理清洗流程

每個環(huán)節(jié)的數(shù)據(jù)處理需求都是不同的，而且這個過程在今天仍然沒有一個統(tǒng)一的范式，數(shù)據(jù)工程師仍在不斷實驗。

1. 數(shù)據(jù)工程師幾乎都在用 Python，在并行處理中會用到 Ray，如果使用 Spark 也大多通過 PySpark 編程。這些操作的靈活性和高效性要求底層文件系統(tǒng)具備 POSIX 兼容性，這樣可以比較高效地滿足各種數(shù)據(jù)處理的需求。

2. HDFS 只支持追加寫，無法支持需要覆蓋寫的數(shù)據(jù)處理方法，比如 Pandas。同時，HDFS 的 Python SDK 也不夠成熟。

3. S3 等對象存儲不支持高效的追加或者修改，不支持重命名操作。目錄操作的性能會很慢。有成熟的 Python SDK，但使用上仍然沒有 POSIX 的方式簡單直接。另外，數(shù)據(jù)處理工作還可能會遇到對象存儲的帶寬限制，高并發(fā)下可能會遇到 API 的 QPS 限制。

4. 使用 S3FS 等方案掛載 S3 等對象存儲時，可以支持 POSIX 方式訪問，但很多操作的性能會比我們預(yù)期的慢很多。比如對一個文件做覆蓋寫，需要將它下載到本地進(jìn)行修改，然后再完整上傳，和文件系統(tǒng)中的局部覆蓋寫是完全不同的。對一個目錄做重命名也會遇到同樣的問題。

5. 使用公有云的 NAS 產(chǎn)品，可以用 pjdfstest 做一下 POSIX 兼容性測試。另一個問題是 NAS 的性能與數(shù)據(jù)量是線性相關(guān)的，所以使用中可能會遇到當(dāng)前數(shù)據(jù)量提供的性能不能滿足計算需要的問題。

第二：吞吐的線性擴(kuò)展能力

不同的文件系統(tǒng)，在擴(kuò)展吞吐能力時的原理是截然不同的。上一代分布式存儲系統(tǒng)的設(shè)計中，比如 GlusterFS，CephFS，還有面向 HPC 領(lǐng)域的 Lustre， BeeGFS 和 GPFS ，大多采用全閃方案構(gòu)建。這類存儲系統(tǒng)的吞吐峰值等于集群中的磁盤總性能，用戶需要提高集群的吞吐能力，只能為集群擴(kuò)容，增加更多的磁盤。

但是，當(dāng)有些用戶對容量的需求和對吞吐的需求并不平衡，如對少量熱點數(shù)據(jù)有非常高的吞吐需求。這些傳統(tǒng)的文件系統(tǒng)，此時也只能為整個集群擴(kuò)容，造成容量的浪費。

舉個例子，一個 500TB 容量的集群，如何使用 8TB 一塊的 HDD(磁盤)，2副本需要 126 塊盤，每塊盤的吞吐是 150MB/s，集群的理論最大吞吐是 126x150 = 18GB/s。如果業(yè)務(wù)需要 60GB/s 的吞吐，有兩個方案：

1)換 2TB 一塊的 HDD 盤(吞吐也是 150MB/s)，總共需要 504 塊盤;

2)換 8TB 一塊的 SATA SSD(吞吐是 500MB/s)，還是 126 塊盤。

第一個方案因為多出 4 倍磁盤數(shù)量，集群的節(jié)點數(shù)要相應(yīng)增加。第二個方案由 HDD 換成 SSD，成本也會大幅上升。

可見，在容量、性能和成本三角上很難去平衡，基于這三個角度的容量規(guī)劃也就成為了一個難題。因為事先規(guī)劃，我們無法預(yù)測真正業(yè)務(wù)的發(fā)展、變化和其中的細(xì)節(jié)。

第三：海量文件

管理百億文件，對存儲系統(tǒng)有三方面要求：

彈性擴(kuò)展。用戶從數(shù)千萬擴(kuò)展到數(shù)億，再到數(shù)十億，這個過程靠給幾臺機(jī)器加配置是不行的，一定是存儲集群增加節(jié)點實現(xiàn)橫向擴(kuò)展，才能最好的支持用戶業(yè)務(wù)成長。

橫向擴(kuò)展時的數(shù)據(jù)分布。在系統(tǒng)擴(kuò)展的過程中，很多系統(tǒng)的數(shù)據(jù)分布設(shè)計是基于目錄名前綴做哈希分布的，這種規(guī)則在真實業(yè)務(wù)數(shù)據(jù)中可能會造成分布不均衡。

擴(kuò)縮容復(fù)雜度。隨著文件數(shù)的增加，系統(tǒng)擴(kuò)容是否簡單，運(yùn)維是否簡單穩(wěn)定并且有足夠的工具來掌控存儲集群，是海量文件存儲系統(tǒng)一直的挑戰(zhàn)。有些系統(tǒng)在文件數(shù)量增長到幾十億之后會越來越「脆弱 」。容易運(yùn)維，穩(wěn)定性高一定是業(yè)務(wù)增長需要的。

第四：在 Kubernetes 環(huán)境中的并發(fā)負(fù)載能力與功能支撐

當(dāng)我們查看存儲系統(tǒng)的規(guī)格，有一部分存儲系統(tǒng)會明確告知并發(fā)訪問上限，用戶需要結(jié)合業(yè)務(wù)去做實際的壓測。同時，客戶端多了，也需要進(jìn)行 QoS 治理，包括每個客戶端的流量控制，對讀寫進(jìn)行臨時封禁策略等，這樣才能保證整個平臺的管理可行性。

在 Kubernetes 中還要注意 CSI 的設(shè)計和支持的功能。比如掛載進(jìn)程的部署方式，是否支持 ReadWriteMany，Subpath 掛載，Quota 配額，熱更新等等。

第五：成本

成本是一個非常綜合的概念，軟硬件的采購成本是容易計算的，人們?nèi)菀缀雎缘氖沁\(yùn)行和維護(hù)成本。AI 業(yè)務(wù)規(guī)模從小到大，數(shù)據(jù)量的增長跨越了兩個、甚至三個數(shù)量級。存儲系統(tǒng)容量和吞吐要有足夠的擴(kuò)展能力，而且要方便調(diào)整。

在過去機(jī)房中建設(shè) Ceph、Lustre、BeeGFS 等系統(tǒng)時，一般都按年度規(guī)劃用量，然后采購機(jī)器，等待到位上架，再完成軟件配置的變更，整個時間周期一般需要 2-3 個月，單單服務(wù)器準(zhǔn)備好，完成軟件上的擴(kuò)容配置，也需要 1 周左右。這里的時間成本往往是企業(yè)中最昂貴的成本，而且往往不容易被關(guān)注。如果存儲系統(tǒng)在容量和性能上可以彈性配置，容易擴(kuò)展，意味著業(yè)務(wù)也能更快推向市場。

再看第二個容易被忽視的成本：效率。AI 業(yè)務(wù)流程是一個非常長的 Data Pipeline，每個環(huán)節(jié)都需要和存儲系統(tǒng)打交道，包括數(shù)據(jù)的采集、清洗轉(zhuǎn)換，標(biāo)注、特征提取、訓(xùn)練、回測，到上生產(chǎn)環(huán)境。企業(yè)在一個業(yè)務(wù)階段內(nèi)使用的數(shù)據(jù)往往不超過全部數(shù)據(jù)的 20%，對于這部分熱數(shù)據(jù)有很高的性能需求，其他溫冷的數(shù)據(jù)偶爾訪問或不訪問。

所以我們可以看到很多團(tuán)隊會構(gòu)建多套存儲系統(tǒng)應(yīng)對不同的需求，常見的方案是用一套對象存儲做全部數(shù)據(jù)的歸檔，做到大容量低成本，但性能不高，在 Data Pipeline 上承擔(dān)數(shù)據(jù)攝取和預(yù)處理、清洗環(huán)節(jié)。在對象存儲完成數(shù)據(jù)的預(yù)處理并不是最高效的方式，但因為數(shù)據(jù)量太大，出于成本原因往往是不得已的選擇。然后工程師又需要等待大量時間把數(shù)據(jù)復(fù)制到訓(xùn)練用的文件存儲中，完成模型訓(xùn)練環(huán)節(jié)。

所以，除了存儲系統(tǒng)的軟硬件成本，集群運(yùn)維(包括采購供應(yīng)鏈)投入的時間成本，業(yè)務(wù)在多個存儲系統(tǒng)之間管理數(shù)據(jù)所投入的時間成本都應(yīng)該計算在總成本中。

三、存儲系統(tǒng)選型比較

最后部分，我們把前文提到的存儲產(chǎn)品做個比較，方便大家選型時參考。

(信息來自網(wǎng)絡(luò) 可能有偏差)

在過去 10 年里，云計算快速發(fā)展。上一代在機(jī)房中設(shè)計的存儲系統(tǒng)并不能集成云帶來的優(yōu)勢，比如彈性伸縮。這期間，對象存儲從無到有，為我們帶來了極致的擴(kuò)展性、可用性和低成本，但是它在 AI 場景中也有明顯的短板。

四、多云架構(gòu)：數(shù)據(jù)同步、一致性管理的挑戰(zhàn)

無論是訓(xùn)練或是推理的需求，單一數(shù)據(jù)中心或單一云區(qū)域內(nèi)的 GPU 資源往往無法滿足用戶的全部需求。特別是對于面向 C 端消費者的應(yīng)用，為了提供更佳的用戶體驗，常常需要在多個地理區(qū)域進(jìn)行部署。在這種情況下，用戶面臨的挑戰(zhàn)包括數(shù)據(jù)集和模型在多區(qū)域之間的分發(fā)、同步及一致性管理等。

下圖是某用戶在最初使用多云架構(gòu)時的數(shù)據(jù)管理方案示意圖。用戶需要面對的挑戰(zhàn)有：

多云架構(gòu)數(shù)據(jù)同步示意圖

1. 對象存儲 A 到對象存儲 B 的數(shù)據(jù)同步：在處理對象存儲間的數(shù)據(jù)同步時，雖然可以采用定時同步特定前綴的數(shù)據(jù)或設(shè)計對象更新回調(diào)以觸發(fā)同步，這些方法在小規(guī)模數(shù)據(jù)處理時簡單有效。然而，當(dāng)同步作業(yè)面對大規(guī)模數(shù)據(jù)時，這些同步方案的復(fù)雜性急劇上升。挑戰(zhàn)包括如何管理同步任務(wù)的并發(fā)執(zhí)行、確保數(shù)據(jù)同步的可靠性、任務(wù)失敗后的數(shù)據(jù)重建、系統(tǒng)的觀測性、流量控制以及數(shù)據(jù)一致性校驗等一系列問題。

2. 高性能文件存儲與對象存儲之間的數(shù)據(jù)同步：由于高性能文件存儲的容量有限，需要人工決策哪些數(shù)據(jù)是近期必需的，并安排合適的時間將這些數(shù)據(jù)從對象存儲中復(fù)制過來。當(dāng)存儲空間不足時，又必須協(xié)調(diào)眾多團(tuán)隊成員共同決定刪除哪些數(shù)據(jù)，以釋放空間。這一過程中，每個人都傾向于保留自己的數(shù)據(jù)，從而避免它們被刪除，這使得是否擴(kuò)容或是進(jìn)行團(tuán)隊內(nèi)部協(xié)調(diào)成為一個復(fù)雜的決策問題。而擴(kuò)容并非僅僅關(guān)乎成本，還涉及到額外的運(yùn)維工作和資源投入，增加了同步工作的復(fù)雜度和管理難度。

3. 兩邊高性能文件系統(tǒng)中的數(shù)據(jù)同步：當(dāng)用戶的任務(wù)在區(qū)域 A 完成執(zhí)行后，其可能被調(diào)度至區(qū)域 B 執(zhí)行。這就要求任務(wù) A 所使用的數(shù)據(jù)集需要在區(qū)域 B 內(nèi)可獲取，而且其先前的執(zhí)行輸出和日志也必須同樣可訪問。

4. 同步管理與一致性保證的挑戰(zhàn)：選擇強(qiáng)一致性還是最終一致性依賴于業(yè)務(wù)需求和技術(shù)實現(xiàn)的復(fù)雜度;如果選擇最終一致性，明確其時間窗口的界定也是必要的，以保障系統(tǒng)的整體可靠性和預(yù)期行為。

5. 存儲系統(tǒng)差異問題：這些系統(tǒng)在產(chǎn)品性能、使用限制以及管理策略等方面往往存在細(xì)微差異，這些差異要求用戶采用精細(xì)化的同步和管理方法來確保數(shù)據(jù)一致性和系統(tǒng)效率。