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

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

  1. 數(shù)據(jù)工程師幾乎都在用 Python，在并行處理中會(huì)用到 Ray，如果使用 Spark 也大多通過 PySpark 編程。這些操作的靈活性和高效性要求底層文件系統(tǒng)具備 POSIX 兼容性，這樣可以比較高效地滿足各種數(shù)據(jù)處理的需求。
  2. HDFS 只支持追加寫，無法支持需要覆蓋寫的數(shù)據(jù)處理方法，比如 Pandas。同時(shí)，HDFS 的 Python SDK 也不夠成熟。
  3. S3 等對(duì)象存儲(chǔ)不支持高效的追加或者修改（只能整體覆蓋），不支持重命名操作。目錄操作的性能會(huì)很慢。有成熟的 Python SDK，但使用上仍然沒有 POSIX 的方式簡(jiǎn)單直接。另外，數(shù)據(jù)處理工作還可能會(huì)遇到對(duì)象存儲(chǔ)的帶寬限制，高并發(fā)下可能會(huì)遇到 API 的?QPS?限制。
  4. 使用 S3FS 等方案掛載 S3 等對(duì)象存儲(chǔ)時(shí)，可以支持 POSIX 方式訪問，但很多操作的性能會(huì)比我們預(yù)期的慢很多。比如對(duì)一個(gè)文件做覆蓋寫，需要將它下載到本地進(jìn)行修改，然后再完整上傳，和文件系統(tǒng)中的局部覆蓋寫是完全不同的。對(duì)一個(gè)目錄做重命名也會(huì)遇到同樣的問題。（請(qǐng)參考另外一篇文章）
  5. 使用公有云的 NAS 產(chǎn)品，可以用?pjdfstest 做一下 POSIX 兼容性測(cè)試。另一個(gè)問題是 NAS 的性能與數(shù)據(jù)量是線性相關(guān)的，所以使用中可能會(huì)遇到當(dāng)前數(shù)據(jù)量提供的性能不能滿足計(jì)算需要的問題。

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

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

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

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

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

多云架構(gòu)數(shù)據(jù)同步示意圖
多云架構(gòu)數(shù)據(jù)同步示意圖
  1. 對(duì)象存儲(chǔ) A 到對(duì)象存儲(chǔ) B 的數(shù)據(jù)同步：在處理對(duì)象存儲(chǔ)間的數(shù)據(jù)同步時(shí)，雖然可以采用定時(shí)同步特定前綴的數(shù)據(jù)或設(shè)計(jì)對(duì)象更新回調(diào)以觸發(fā)同步，這些方法在小規(guī)模數(shù)據(jù)處理時(shí)簡(jiǎn)單有效。然而，當(dāng)同步作業(yè)面對(duì)大規(guī)模數(shù)據(jù)時(shí)，這些同步方案的復(fù)雜性急劇上升。挑戰(zhàn)包括如何管理同步任務(wù)的并發(fā)執(zhí)行、確保數(shù)據(jù)同步的可靠性、任務(wù)失敗后的數(shù)據(jù)重建、系統(tǒng)的觀測(cè)性、流量控制以及數(shù)據(jù)一致性校驗(yàn)等一系列問題。
  2. 高性能文件存儲(chǔ)與對(duì)象存儲(chǔ)之間的數(shù)據(jù)同步：由于高性能文件存儲(chǔ)的容量有限，需要人工決策哪些數(shù)據(jù)是近期必需的，并安排合適的時(shí)間將這些數(shù)據(jù)從對(duì)象存儲(chǔ)中復(fù)制過來。當(dāng)存儲(chǔ)空間不足時(shí)，又必須協(xié)調(diào)眾多團(tuán)隊(duì)成員共同決定刪除哪些數(shù)據(jù)，以釋放空間。這一過程中，每個(gè)人都傾向于保留自己的數(shù)據(jù)，從而避免它們被刪除，這使得是否擴(kuò)容或是進(jìn)行團(tuán)隊(duì)內(nèi)部協(xié)調(diào)成為一個(gè)復(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ù)實(shí)現(xiàn)的復(fù)雜度；如果選擇最終一致性，明確其時(shí)間窗口的界定也是必要的，以保障系統(tǒng)的整體可靠性和預(yù)期行為。
  5. 存儲(chǔ)系統(tǒng)差異問題：這些系統(tǒng)在產(chǎn)品性能、使用限制以及管理策略等方面往往存在細(xì)微差異，這些差異要求用戶采用精細(xì)化的同步和管理方法來確保數(shù)據(jù)一致性和系統(tǒng)效率。

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

多云架構(gòu)下使用 JuiceFS 鏡像
多云架構(gòu)下使用 JuiceFS 鏡像

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

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

04 模型加載慢，GPU 等待時(shí)間久

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

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

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

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

結(jié)尾

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

JuiceFS 的幾方面能力得到了客戶的認(rèn)可：

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

分享到

zhupb

相關(guān)推薦