每個環(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 方式訪問，但很多操作的性能會比我們預期的慢很多。比如對一個文件做覆蓋寫，需要將它下載到本地進行修改，然后再完整上傳，和文件系統(tǒng)中的局部覆蓋寫是完全不同的。對一個目錄做重命名也會遇到同樣的問題。（請參考另外一篇文章）
5. 使用公有云的 NAS 產(chǎn)品，可以用?pjdfstest 做一下 POSIX 兼容性測試。另一個問題是 NAS 的性能與數(shù)據(jù)量是線性相關(guān)的，所以使用中可能會遇到當前數(shù)據(jù)量提供的性能不能滿足計算需要的問題。

所以，對于數(shù)據(jù)工程師，一個全功能的 POSIX 文件系統(tǒng)是數(shù)據(jù)處理、清洗環(huán)節(jié)的最佳拍檔。JuiceFS 完全兼容 POSIX ，同時也支持 HDFS、S3 API 的訪問方式，在數(shù)據(jù)處理、清洗的整個流程中能很好地支持各種各樣的計算負載。

關(guān)于 POSIX 兼容性在 AI 訓練中的重要作用，可參考案例，韓國國民搜索 NAVER：為 AI 平臺引入存儲方案 JuiceFS。

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

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

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

1. 對象存儲 A 到對象存儲 B 的數(shù)據(jù)同步：在處理對象存儲間的數(shù)據(jù)同步時，雖然可以采用定時同步特定前綴的數(shù)據(jù)或設計對象更新回調(diào)以觸發(fā)同步，這些方法在小規(guī)模數(shù)據(jù)處理時簡單有效。然而，當同步作業(yè)面對大規(guī)模數(shù)據(jù)時，這些同步方案的復雜性急劇上升。挑戰(zhàn)包括如何管理同步任務的并發(fā)執(zhí)行、確保數(shù)據(jù)同步的可靠性、任務失敗后的數(shù)據(jù)重建、系統(tǒng)的觀測性、流量控制以及數(shù)據(jù)一致性校驗等一系列問題。
2. 高性能文件存儲與對象存儲之間的數(shù)據(jù)同步：由于高性能文件存儲的容量有限，需要人工決策哪些數(shù)據(jù)是近期必需的，并安排合適的時間將這些數(shù)據(jù)從對象存儲中復制過來。當存儲空間不足時，又必須協(xié)調(diào)眾多團隊成員共同決定刪除哪些數(shù)據(jù)，以釋放空間。這一過程中，每個人都傾向于保留自己的數(shù)據(jù)，從而避免它們被刪除，這使得是否擴容或是進行團隊內(nèi)部協(xié)調(diào)成為一個復雜的決策問題。而擴容并非僅僅關(guān)乎成本，還涉及到額外的運維工作和資源投入，增加了同步工作的復雜度和管理難度。
3. 兩邊高性能文件系統(tǒng)中的數(shù)據(jù)同步：當用戶的任務在區(qū)域 A 完成執(zhí)行后，其可能被調(diào)度至區(qū)域 B 執(zhí)行。這就要求任務 A 所使用的數(shù)據(jù)集需要在區(qū)域 B 內(nèi)可獲取，而且其先前的執(zhí)行輸出和日志也必須同樣可訪問。
4. 同步管理與一致性保證的挑戰(zhàn)：選擇強一致性還是最終一致性依賴于業(yè)務需求和技術(shù)實現(xiàn)的復雜度；如果選擇最終一致性，明確其時間窗口的界定也是必要的，以保障系統(tǒng)的整體可靠性和預期行為。
5. 存儲系統(tǒng)差異問題：這些系統(tǒng)在產(chǎn)品性能、使用限制以及管理策略等方面往往存在細微差異，這些差異要求用戶采用精細化的同步和管理方法來確保數(shù)據(jù)一致性和系統(tǒng)效率。

手工維護上述這套數(shù)據(jù)架構(gòu)，運維負擔可想而見，如果不止兩個區(qū)域，上面所有的問題將更加復雜。能否讓上面這些問題自動化？JuiceFS 使用鏡像功能滿足了這樣的需求，目前已經(jīng)成了大模型訓練和推理業(yè)務中的必備功能。

在 JuiceFS 數(shù)據(jù)鏡像方案中，所有主站點的數(shù)據(jù)變動都會自動同步到各個鏡像站點。元數(shù)據(jù)同步在確定的時間窗口內(nèi)完成，同城可以達到毫秒級延遲，跨城市在國內(nèi)約為 10-30 毫秒，跨大洲則為亞分鐘級。在指定時間窗口中，鏡像站點保證數(shù)據(jù)一致性。

數(shù)據(jù)同步完成的時間基本上與在網(wǎng)絡環(huán)境中傳輸一個 4MB 文件所需的時間相同。如果數(shù)據(jù)尚未完成同步，從鏡像站訪問文件時，JuiceFS 會自動處理其中的 I/O 路徑，確保文件可以被訪問。這種處理機制可能會導致短暫的性能下降，但不會影響程序正確執(zhí)行。而當用戶在鏡像站產(chǎn)生新數(shù)據(jù)并寫入 JuiceFS 時，數(shù)據(jù)會自動回寫到數(shù)據(jù)源站，此時的寫入性能取決于網(wǎng)絡狀況。更多實踐案例：知乎如何在多云架構(gòu)下使用 JuiceFS 鏡像功能？

04 模型加載慢，GPU 等待時間久

模型加載就是將模型完整讀取載入顯存的過程，在訓練啟動、訓練恢復和推理服務部署時都包含模型加載過程。模型通常是一個大文件，隨著模型參數(shù)的增加，模型文件的大小也從幾十 GB 增長到 TB 級別，通常采用 pickle 或 safetensor 等格式。

加載過程需要從存儲系統(tǒng)中單線程順序讀取，影響速度的關(guān)鍵因素是單線程順序讀取時的吞吐量，JuiceFS 當前版本加載模型吞吐性能為 1500MB/s。經(jīng)過為模型加載場景的優(yōu)化后，讀吞吐可以提升至 3GB/s。

另一方面，以 PyTorch 加載 pickle 格式模型的過程為例，在順序讀取模型文件的同時會完成 pickle 數(shù)據(jù)的反序列化，這個過程也會消耗時間。在我們的測試中，從內(nèi)存盤加載 Llama 2 7B 全精度模型，pickle 格式，26GB 大小，吞吐性能是 2.2GB/s。因為內(nèi)存是最快的存儲介質(zhì)，所以我們將其視為極限值。從 JuiceFS 加載同樣的模型，吞吐性能為 2.07GB/s，是極限值的 94%。

基于這樣的表現(xiàn)，越來越多 AI 用戶在推理業(yè)務中使用 JuiceFS 存儲模型，加速模型加載，省下了可觀的 GPU 成本。這里可以參考 BentoML 的優(yōu)化經(jīng)驗，他們是一家模型部署 SaaS 服務，要為客戶管理大量模型，非常關(guān)心模型加載性能。

結(jié)尾

最近兩年大語言模型（LLM，Large Language Model）飛速發(fā)展，參數(shù)規(guī)模迅速提升，這不僅意味著模型大小在增長，也意味著用于訓練的數(shù)據(jù)規(guī)模同時在更快增加，這對于存儲系統(tǒng)的挑戰(zhàn)不言而喻。

JuiceFS 的幾方面能力得到了客戶的認可：

• 高性價比；
• POSIX 100% 兼容性，同時支持 HDFS、S3 協(xié)議；
• 通過緩存集群可以彈性擴展集群吞吐能力；
• 自動多云數(shù)據(jù)同步，省去人工遷移的低效，和一致性管理的挑戰(zhàn)；
• 加速模型部署，節(jié)約推理成本。

我們將繼續(xù)與大家分享在 AI 發(fā)展過程中所觀察到的變化，和對存儲方案的探索，也期待與業(yè)內(nèi)同仁交流與討論。

zhupb