從 HPC 到 AI：探索檔案系統的發展及效能評估

隨著 AI 技術的迅速發展，模型規模和複雜度以及待處理資料量都在急劇上升，這些趨勢使得高效能運算（HPC）變得越來越必要。HPC 透過整合強大的計算資源，比如 GPU 和 CPU 叢集，提供了處理和分析大規模資料所需的算力。

然而，這也帶來了新的挑戰，尤其是在儲存系統方面，包括如何有效處理大量資料、確保資料訪問的高效性以及如何控制成本和運維管理。分散式檔案系統，作為一種高成本效益高的解決方案，正逐漸在 AI 和 HPC 場景中廣泛應用。它們透過跨多個節點分佈儲存資源，有效地處理和管理大資料集，滿足 HPC 對資料存取速度的高要求。

人民大學在人工智慧和電腦科學領域進行了多項研究，其高效能運算中心為科研提供了強有力的支援，並在結合 HPC 與 AI 應用方面積累了一些的經驗。本文將為大家介紹 HPC、大資料及 AI 應用的資料模式和特性；人大對幾款主流分散式檔案系統 Lustre、Alluxio 以及 JuiceFS 也做了初步效能測評，我們將分享這些測評結果，並介紹常用的效能評測工具，希望為選擇 HPC 和 AI 儲存解決方案的使用者提供有價值的參考。

01 大規模資料應用場景：HPC vs 大資料 vs AI

高效能運算 (HPC)

高效能運算（HPC）在科學研究和工程應用中發揮著關鍵作用，諸如氣候預測、蛋白質摺疊以及計算流體力學等領域均依賴於其提供的計算能力。與機器學習和人工智慧採用的方法不同，HPC 常基於模擬和科學公式推演來解決複雜問題。

在 HPC 中，任務可分為計算密集型和資料密集型。例如，天氣預測既需要大量計算資源模擬天氣變化，又需處理和分析龐大資料集。而如分子動力學模擬等計算密集型任務，則更側重於計算處理，對資料依賴較少。

HPC 環境通常採用高頻寬、低延遲的網路，如 InfiniBand，以支援快速資料傳輸。軟體配置上，多節點間的高效資料通訊依賴於如訊息傳遞介面（MPI）這樣的標準。

此外，GPU 的應用在 HPC 中也日益增多，加速各類計算任務。HPC 叢集與傳統資料中心相比，顯著區別在於其網路配置和共享檔案系統的使用，這些特點使得 HPC 能夠有效處理計算密集型任務。

大資料

區別於 HPC，大資料應用在網際網路公司的運用更為普遍，主要是因為這些公司可以持續收集龐大的使用者資料量，如使用者行為和上傳內容等。這些通常是非結構化的資料，比如圖片、音訊和影片。

在這些公司中，大資料工程師常常負責 ETL 工作，即提取、轉換和載入資料到資料倉儲，在那裡資料會被加工整理以供分析或機器學習使用。這與 HPC 的計算密集型任務不同，大資料應用更側重於資料的處理和分析。

成本是大資料應用的一個重要考量，網際網路公司傾向於使用價效比高的標準硬體和開源軟體，以控制成本。例如，Hadoop 這樣的開源軟體因其強大的社群支援和成熟性而廣受歡迎。網際網路公司可以根據自身需求選擇合適的軟體解決方案，無論是採用開源版本以利用其優勢，還是選擇商業版本以獲得更多支援。

AI

近年來，人工智慧（AI）領域的發展已經廣為人知，其工作負載主要包括訓練和推理。特別是隨著大型模型如 GPT 和 Bert 的出現，AI 對高效能運算（HPC）的依賴日益加深，這些複雜的模型迫切需要依靠強大的計算資源來縮短訓練時間；同時，它們也帶來了如何高效管理和分析海量資料的挑戰。

在這個背景下，檔案系統面臨特殊要求，尤其是處理眾多小型的圖片或影片檔案時，這些檔案通常只有幾 KB 到幾 MB 大小，對 IOPS 提出了高要求。

此外，在 AI 模型的訓練過程中，還有一個顯著特點，即同一份資料可能會被用於多種不同引數的調優。這意味著演算法工程師會不斷地對模型結構進行調整和最佳化，包括嘗試不同的引數設定、修改網路架構，以及實驗各種最佳化技巧。

因此，AI 模型訓練不僅是一個計算密集型的任務，同時也是一個需要精細操作和細緻調整的過程。這種對引數和模型結構不斷調整的方法是實現高效、精準 AI 模型的關鍵。

正是基於這種背景，資料預處理在 AI 模型訓練中顯得尤為關鍵。舉一個實際的例子，來自hugging face 子公司開發的大型模型展示了資料預處理的重要性。在處理大型模型的資料時，他們設定了一個較長的處理流程。從最初收集的原始外部網頁資料開始經過多次預處理，如URL 過濾、去重等步驟，原始資料量被大幅壓縮。

透過下圖可以看到，每個步驟都在逐漸減少資料集的大小。經過一系列處理後，最終只有不到10% 的資料量適合用於訓練大型語言模型（LLM）。因此，我們看到在大型模型的訓練過程中，資料預處理佔據了大量工作，包括清洗資料、提取 HTML 標籤、過濾廣告和文字識別等複雜任務。這些步驟雖然繁重，但對於保證資料質量和最佳化訓練結果至關重要。

02 AI 應用與分散式檔案系統的演進

首先，讓我們一同簡單回顧檔案系統的演變歷程，其中每一個階段的新興需求都催生了新一代的檔案系統。

• Lustre 是最早期的檔案系統之一，專為高效能運算（HPC）設計，由美國政府資助並由多個國家實驗室共同開發，以支援科學研究。

• 隨後，Hadoop S3 等檔案系統的出現主要是為了應對網際網路資料量的爆炸性增長，與此同時，也出現了Ceph 等面向大資料處理的檔案系統。這些系統旨在支援大資料應用。Alluxio 提供了一個記憶體快取層。

• AlexNet 神經網路等技術的發展進一步推動了檔案系統的多樣化。

• 進入到 Kubernetes 時代，雲原生資料管理和應用逐漸成為焦點，眾多新興的資料管理系統和應用如 JuiceFS 等都是為了適應這一環境而設計的。

檔案系統作為資料儲存和訪問的基礎設施，對於 AI 模型的訓練和推理過程有著直接的影響。將檔案系統應用於 AI 場景時，往往面臨這兩個關鍵挑戰。

• 對 IOPS 的效能要求：首要挑戰是處理包含大量小檔案的資料集，如圖片和影片，這對檔案系統的IOPS提出了高要求。當前頻寬通常足夠，但檔案系統的 IOPS 處理能力往往限制了效能。

• 對相容性的要求：AI 工作流程的複雜性和跨業務團隊的協作要求檔案系統必須具有高度的相容性，以支援各種資料處理和模型訓練工具，確保資料能夠在團隊間順暢交換和處理。

為提高效能，一些解決方案採用了 SSD 或 NVMe 等高效能儲存介質，並實施本地快取策略。這裡簡單介紹一下學術界的一個常見概念：Burst Buffer ，主要指透過臨時儲存大量資料來緩解傳統儲存系統在處理高速資料流時的瓶頸。在這方面，不同的檔案系統提供了各自獨特的解決方案，會在下文逐一介紹。

同時，在解決相容性問題時，提供 POSIX 介面確保了相容性和可移植性，也能解決使用者的學習成本。POSIX 指的是 Linux 作業系統一系列檔案介面，可以支援 POSIX 的檔案系統可以像操作本機一樣操作分散式檔案系統。但從開發的角度來看，實現 POSIX 相容性可能增加了額外的開發成本和複雜性。而 HDFS 和 S3 這類產品則未採用 POSIX 完全的相容性，簡化了某些方面的實現，但它們也要求開發人員或使用者適應新的操作模式，這可能涉及改變現有的使用習慣和學習新的工具。

接下來將分別介紹幾款適用於 AI 場景的檔案系統，希望能夠幫助使用者更好地理解各個檔案系統在 AI 應用的優勢和侷限。

Lustre

Lustre 在 HPC 場景中表現出色的原因在於，它從設計之初就是為了滿足超級計算機的需求，特別是它對 POSIX 協議的支援以及使用 C 和 C++ 進行開發，這些特性使得 Lustre 非常適合於處理大規模平行計算任務。

Lustre 的架構特別適用於典型的超算叢集環境，其中包括使用 InfiniBand 網路進行高速資料傳輸。叢集中包含了多個計算節點（Computation）和儲存節點（Data Management），用於處理後設資料的 Metadata server，而實際的資料則儲存在物件儲存（object storage）上。這種設計最佳化了對 MPI 應用的支援，特別是 MPI-IO，即多個程序同時對一個檔案進行讀寫的能力，這對於平行計算和科學研究應用尤為重要。

雖然在 AI 和機器學習應用中，MPI-IO 的直接應用可能較少，主要因為這些應用的檔案操作主要寫入 checkpoint，而不涉及分散式程序的直接寫入。然而，對於需要並行處理和複雜資料互動的科學計算應用，MPI-IO 這樣的特點仍然極其重要。

在快取方面，Lustre 檔案系統近期提供了一個功能叫做 PCC（Lustre Persistent Cache on Client）。但實際操作中，它需要運維人員進行大量的配置。

Alluxio

我們嘗試部署了Alluxio 作為資料快取層。Alluxio 的設計理念主要是作為底層儲存系統（例如 HDFS 或 S3 ）之上的快取，以此加速資料訪問的速度，Alluxio 特別適用於大資料場景，如配合 Spark 等大資料處理系統使用。

在 AI 和機器學習應用場景下的測試表明，效能未達到預期。在 AI 場景中，特別是當首次請求包含大量小檔案的資料集時，這一過程極為緩慢。以 ImageNet 資料集為例，我們注意到首次將資料載入到 Alluxio 可能需要幾個小時，這對效能造成了嚴重影響。據最新訊息，Alluxio 也針對這個問題做了最佳化，提供了專門為 AI 設計的儲存方案，目前為商業版，沒有開源。

JuiceFS

我們對 JuiceFS 社群版進行了初步的 POC 測試，尚未在在我們的生產系統中全面部署。

JuiceFS 是一款高效能的雲原生分散式檔案系統。它的設計目標是在雲環境下提供高效的資料儲存和訪問能力。

在 JuiceFS 中，資料被分塊儲存在如 S3 等物件儲存中；後設資料則儲存在如 Redis、MySQL 或 PostgreSQL 這樣的資料庫系統中。這種設計使得後設資料管理既高效又靈活。客戶端透過掛載 FUSE（Filesystem in Userspace）介面來訪問 JuiceFS，這使得它能夠在多種作業系統上無縫執行。同時，JuiceFS 還為使用者提供了一個熟悉的檔案系統介面 POSIX。另外，JuiceFS 的快取功能可以直接支援 burst buffer。

從成本角度來看，JuiceFS 的運營成本遠低於傳統的磁碟陣列。這主要得益於其雲原生的設計，能夠有效利用雲端儲存資源，減少物理硬體的依賴。

03 測評工具和 PoC 結果

在評估檔案系統效能時，iozone, mdtest 和 fio 等 benchmark 工具被廣泛用於測試 IOPS 和頻寬。然而，標準的 benchmark 工具無法完整地反映真實業務場景下的需求和負載特性，為了得到更接近實際工作負載的效能評估，MLPerf 這樣的工具被設計出來。

MLPerf 模擬了真實的 AI 工作負載進行評估，提供了一系列的測試。在計算機視覺領域，它可採用 ResNet 模型進行測試；而在文字處理領域，可能會使用 GPT-3 或 BERT 模型，並在維基百科或 C4 資料集上進行測試。

下面這張圖表概述了在不同領域中 AI 效能基準測試的標準，包括視覺、語言處理和推薦系統等。它指定了每個測試所用的資料集，旨在達到的效能目標（如準確率、錯誤率等），以及各個測試的參考模型（如 ResNet、BERT、GPT-3等）。這為評估和比較 AI 模型的效能提供了一套統一的框架。

PoC 結果

以下是我們的初步測試結果。我們使用 fio 進行了測試，比較了 Lustre 、JuiceFS 和 XFS。

• 在 IOPS 和頻寬讀取效能上，配置了全 NVMe 快閃記憶體的 Lustre 表現出了非常高的效能。

• 在 PyTorch 上執行 ImageNet 資料集的測試中，所有檔案系統完成任務的時間都相近，JuiceFS + S3 和 xfs + local SSD 共享最低。

• 在進行大型語言模型（LLM）的 checkpoint 測試時，Lustre + all flash 只用了1分鐘，遠快於 Lustre + HDD 的 10 分鐘。

04 小結

本文分享了 HPC、大資料和 AI 等需要處理大規模資料的場景及其資料特性。介紹了適用於 AI 場景的常見檔案系統及其優缺點，並展示了人大高效能運算中心的內部測試結果。

企業在選擇檔案系統時，不僅要參考 benchmark 結果，還需考慮實際業務需求和成本。對於運維能力有限的企業，像 Lustre 這樣有著完善支援的檔案系統更加合適。而有運維能力的公司可能會傾向於成本效益更高的開源解決方案。最終的選擇需要綜合考慮成本、運維能力和其他因素。

希望這篇內容能夠對你有一些幫助，如果有其他疑問歡迎加入 JuiceFS 社群與大家共同交流。