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

同時，當算力、數據與團隊投入都增大的時候，我們又看到了幾個新的事實：

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

2. 正式訓練環節，如上文推算，雖然數據集規模固定為 6T，企業可以將全部數據存儲于高性能存儲系統中。但是，高性能文件系統的性能都與容量是關聯的。例如，每 TB 容量提供 250MBps 吞吐，也就是說僅僅把 6TB 數據集存在高性能文件系統，僅能提供 1500MB/s 的吞吐，如果要達到訓練所需的 I/O 性能，需要擴大高性能文件系統容量。

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

一、AI 數據工程的存儲挑戰

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

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

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

除了由 AI 場景帶來了新的數據模式，基礎的計算環境也發生了巨大的變化。

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

云原生技術棧也是企業在建設存儲平臺時，普遍會考量的一個因素。隨著云計算的成熟，AI 業務更多轉向大規模分布式集群完成。集群中的節點數大幅度增加，存儲系統如何面對 Kubernetes 集群中上萬 Pod 的并發訪問是新的挑戰。

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

結合上文提到的這些挑戰，我們羅列了對AI場景至關重要的存儲能力，方便企業在選擇存儲產品時進行比較。

二、AI 數據存儲需要的關鍵能力

第一：POSIX 兼容性和數據一致性

在 AI/ML 領域，POSIX 是數據訪問最普遍的接口。上一代分布式文件系統，除了 HDFS，也都兼容 POSIX，但是近幾年云上的產品在 POSIX 支持上的做法并不一致。

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

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

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

準備高質量的訓練數據是構建出色基礎模型的基礎。數據準備本身是一個復雜的流程，正如《Yi 論文》中所展示的那樣：

零一萬物數據預處理清洗流程

每個環節的數據處理需求都是不同的，而且這個過程在今天仍然沒有一個統一的范式，數據工程師仍在不斷實驗。

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

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

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

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

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

第二：吞吐的線性擴展能力

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

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

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

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

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

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

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

第三：海量文件

管理百億文件，對存儲系統有三方面要求：

彈性擴展。用戶從數千萬擴展到數億，再到數十億，這個過程靠給幾臺機器加配置是不行的，一定是存儲集群增加節點實現橫向擴展，才能最好的支持用戶業務成長。

橫向擴展時的數據分布。在系統擴展的過程中，很多系統的數據分布設計是基于目錄名前綴做哈希分布的，這種規則在真實業務數據中可能會造成分布不均衡。

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

第四：在 Kubernetes 環境中的并發負載能力與功能支撐

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

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

第五：成本

成本是一個非常綜合的概念，軟硬件的采購成本是容易計算的，人們容易忽略的是運行和維護成本。AI 業務規模從小到大，數據量的增長跨越了兩個、甚至三個數量級。存儲系統容量和吞吐要有足夠的擴展能力，而且要方便調整。

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

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

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

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

三、存儲系統選型比較

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

(信息來自網絡 可能有偏差)

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

四、多云架構：數據同步、一致性管理的挑戰

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

下圖是某用戶在最初使用多云架構時的數據管理方案示意圖。用戶需要面對的挑戰有：

多云架構數據同步示意圖

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

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

3. 兩邊高性能文件系統中的數據同步：當用戶的任務在區域 A 完成執行后，其可能被調度至區域 B 執行。這就要求任務 A 所使用的數據集需要在區域 B 內可獲取，而且其先前的執行輸出和日志也必須同樣可訪問。

4. 同步管理與一致性保證的挑戰：選擇強一致性還是最終一致性依賴于業務需求和技術實現的復雜度;如果選擇最終一致性，明確其時間窗口的界定也是必要的，以保障系統的整體可靠性和預期行為。

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