貝殼機器學習平臺的計算資源，尤其是 GPU，主要依賴公有云服務，並分佈在不同的地理區域。為了讓儲存可以靈活地跟隨計算資源，儲存系統需具備高度的靈活性，支援跨區域的資料訪問和遷移，同時確保計算任務的連續性和高效性；此外，隨著資料量的增長，後設資料管理的壓力也在逐漸加大。
貝殼機器學習平臺團隊從去年開始對儲存系統進行重構，選擇了基於 JuiceFS 的儲存方案。目前 JuiceFS 作為儲存底座服務於整個機器學習平臺，不僅提高了對混合多雲架構的適應性，還大幅提升了資料處理效率。
該儲存平臺已支援多個場景，例如，模型載入時間從超過 10 分鐘縮短至 30 秒以內，提升 20 多倍，大幅提高了資源利用效率。此外，貝殼團隊基於 JuiceFS 研發了多 AZ 分散式快取以及映象功能**。本文將詳細介紹貝殼在此重構過程中的演進歷程和具體實踐。
01 貝殼 AI 基礎設施演化
最初的機器學習過程非常簡單。在貝殼早期，機器學習只需要一臺 GPU 機器，掛載一塊本地硬碟，然後進行調優即可。隨著工程自動化程度的要求變高和規模的不斷擴大，這種原始的“裸金屬”方式無法承載算力排程的效率。因此，逐漸出現了面向單機房或單叢集的架構，以滿足自動化發展的需求。在這個階段，引入了 Kubernetes 叢集和 NAS 共享儲存，掛載到機器後完成訓練任務。
隨著大型模型的出現，模型規模急劇增大，對算力的需求隨之增加。在當前中國的特殊市場環境下，獲取算力資源變得更加困難，公有云已成為主要的算力來源。在公有云平臺上協調 GPU 資源時，使用者可能會面臨地域限制的挑戰，這一變化促使包括貝殼在內的企業對 AI 基礎設施架構進行調整。
目前，我們團隊負責的兩個平臺，混合雲 KCS 容器服務和 AIStudio 機器學習平臺，均基於容器技術並構建在大型混合雲平臺上。容器平臺依賴於自建 IDC，覆蓋多個機房，並整合各種公有云服務，涵蓋北京、上海等多個地區。貝殼的基礎設施規模經歷了從裸機交付到單 Kubernetes 叢集交付，再到多叢集、多機房交付的演變，直至聯邦制交付模式，實現了跨地域的資源管理。
演化趨勢
在平臺演化過程中，基礎設施層呈現出如下這些變化：
算力和存力分散：以實際場景為例，當資料位於北京而訓練任務需要在上海進行時，直接掛載北京的資料卷將因網路延遲導致訓練效率低下。因此，如何縮短計算和儲存之間的距離，提高資料訪問效率，成為了基礎設施架構最佳化的關鍵。
儲存跟著算力跑：在算力資源緊張的背景下，我們不得不考慮如何讓儲存更接近計算能力。由於 GPU 資源的獲取變得困難，傳統的“算力跟著儲存跑”的策略可能需要轉變為“儲存跟著算力跑”。這要求我們根據計算任務的實際地理位置靈活配置儲存資源，確保兩者之間的高效協同。
跨地域資料管理難題：我們面臨的儲存與算力之間的遠距離問題。為了縮短這一距離，最直接但效率極低的方式是資料複製。即將資料從一處轉移到另一處，尤其是當需要跨越較大距離，如從北京到上海時，其效率問題尤為突出。以我們最近的一次資料遷移為例，涉及 20 TB的資料遷移需要耗時 11 天，主要是因為涉及大量大小檔案的處理，對於當前依賴高效資料處理，尤其是 AI 訓練的業務來說，這樣的效率是無法接受的。
存算分離：鑑於單盤儲存容量的上限，我們需要採用儲存與計算分離的架構來確保整體儲存容量的充足性。這種架構不僅能夠應對儲存容量需求的增長，還能夠提高系統的靈活性和可擴充套件性。
檔案系統架構的演變：檔案系統的發展已成為一個關鍵挑戰，從傳統的本地磁碟到如 Network File System的共享儲存系統，再到貝殼採用的開源多節點檔案系統。這些變化推動了資料儲存方式的革新，也引入了新的問題。
02 儲存方案探索：CubeFS & JuiceFS
鑑於基礎設施的發展趨勢及貝殼內部的具體需求，我們需要確儲存儲層能夠應對以下挑戰：
-
支援多地域混合雲架構：儲存解決方案必須支援多地域混合雲架構，以滿足不同地域的資料儲存需求；
-
百億到千億級別小檔案儲存能力：目前，貝殼的檔案系統資料量已達到 14PB，檔案總數近 50億。隨著 AI 的快速發展，大量歷史資料被清洗並轉化為可訓練資料和結構化資料。我們目前每週的資料增長量已佔到總檔案數的十分之一，即每週新增近 5億個小檔案。預計這種趨勢將在今年持續，給我們的儲存系統帶來嚴峻挑戰。因此，我們的系統需要能夠支援從百億到千億級別的小檔案儲存；
-
儲存效能：面對廣泛分佈的檔案儲存需求，尤其是在 AI 應用中對效能的極高要求，如何提升儲存系統效能，以滿足不斷增長的資料儲存和訪問需求，成為我們當前必須解決的問題；
-
低成本與低維護：我們追求降低成本和維護需求，儘量減少對第三方元件的依賴，確保在提升效能的同時，控制成本在可接受的範圍內。
針對貝殼的特定場景，我們深入研究了 CubeFS 與 JuiceFS 並將他們應用於不同場景。模型訓練場景對 I/O 吞吐和 IOPS 要求極高，我們在 IDC 內部主要採用 CubeFS 全快閃記憶體儲叢集來構建檔案系統，目前 CubeFS 在貝殼內部已具備一定應用規模。
對於跨機房、地區或者地域的複雜資料處理場景我們選擇了使用 JuiceFS。例如，在進行模型訓練時，通常需要先處理原始資料，執行資料清洗任務，隨後再生成中間資料或者訓練資料。此外，這些資料還需在多個地點之間進行遷移。貝殼基於 JuiceFS 的靈活架構設計了支援跨地域、混合雲架構的檔案系統來應對貝殼AI基礎設施的快速發展。
JuiceFS 依託於公有云物件儲存，不僅成本低廉，還能提供幾乎無限的儲存容量，最大限度地發揮雲端儲存的優勢；其效能主要依賴於物件儲存和後設資料引擎。後設資料引擎的選型能滿足各種場景，特別是處理大量小檔案的能力。JuiceFS 成功解決了我們在非單機房模型訓練場景中遇到的問題，如資料集清洗、同步以及容量限制等，有效填補了貝殼生態中對跨機房、高擴充套件性檔案系統的空缺。
03 基於 JuiceFS 的儲存底座設計
後設資料引擎架構設計
JuiceFS 採用的是後設資料和資料分離的架構。對於後設資料引擎的選型，我們考慮了三個方案。
-
第一，Redis 以高效能聞名，但由於我們對資料丟失的零容忍態度，特別是在儲存大量訓練資料的場景中，我們很快排除了使用 Redis 的方案。此外，考慮到需要支援大量檔案和實現跨機房同步的挑戰，Redis 叢集的規模及其同步功能的侷限性，也是我們決定放棄使用它的主要原因；
-
第二，具有同步能力的 TiKV 和 OceanBase ；
-
第三，自研後設資料引擎。
最終我們選擇了 TiKV 和 OceanBase，主要基於以下幾個原因：
-
穩定性：對於貝殼的當前狀況而言，穩定性是至關重要的。TIKV 和 OceanBase 這兩支團隊在開源社群中擁有非常成熟的運維體系，特別是在實現跨地域資料同步方面，它們提供了非常成熟的解決方案。相比之下，如果我們完全自主研發，不僅研發週期會很長，而且可能不利於我們整體專案的快速落地，特別是在 AI 領域快速發展的背景下。
-
效能：我們也對這兩種後設資料引擎進行了效能測試。結果顯示，在效能層面上，它們的差異並不大。
-
其他因素：在大多數場景中，I/O 效能受限是一個常見問題。後設資料可能只是其中的一部分原因，還可能受到專線頻寬、物件儲存等其他因素的影響。綜合考慮這些因素，我們最終選擇了 OceanBase 作為最終的後設資料引擎。
該架構的核心在於充分利用公有云資源，以貝殼北京區域的 OceanBase 叢集為例。在北京，我們設有專門用於 AI 計算的機房和負責其他服務的主機房。面對支援 OceanBase 在上海的同步需求時，高昂的專線費用和同步工具的效率及延遲問題成為挑戰。
經過多方權衡，我們選擇了一個既經濟又高效的策略：利用騰訊雲作為主要的公有云提供商，透過其雲內網同步能力實現北京到上海的資料同步。具體操作中，我們採用騰訊雲的 MySQL服務及其內網同步機制，有效解決了跨區域同步的延遲，實現了每秒約 2 萬條記錄的寫入效能，延遲保持在秒級。
在貝殼的後設資料引擎架構中，寫入操作需首先在北京的主力機房進行，隨後系統將資料分發至各機房，確保 了後設資料的一致性和實時性。這一策略有效提升了資料處理和分發的效率，為業務提供穩定可靠的支援。
多 AZ 分散式快取加速
在使用 JuiceFS 的過程中，我們面臨的主要任務是同步後設資料及物件儲存中的實際資料。JuiceFS 企業版可提供分散式快取方案，我們目前使用的是社群版，它在異地同步及資料加速方面有一定限制。因此，為了快速從北京到上海的資料同步需求，我們自主研發了一套分散式快取加速系統。
該系統本質上是一個物件儲存代理系統，協議層是自研的，持久化層完全依賴於雲服務提供商提供的物件儲存服務。我們透過構建一系列的快取加速能力，使訪問雲物件儲存的效能與訪問基於本地 NVMe 構建的物件儲存服務（如 MinIO）的效能相當，同時該系統支援多寫複製，當把資料寫入北京區域時，可以同時向上海或其他區域進行同步寫入，再結合 JuiceFS 的單機快取加速功能，進一步提高了資料訪問速度。
架構設計
該分散式快取加速系統採用了與 JuiceFS gateway 類似的設計，建立了一個 S3 閘道器，負責資料分發和同步複製任務。雖然資料同步並非實時，對於大檔案的同步通常延遲控制在分鐘級。然而，得益於 JuiceFS 檔案分塊特性和我們的快取策略，我們能夠實現幾乎即時的資料同步，一旦資料寫入北京區域，它幾乎可以立即被同步到上海或其他區域。
我們的分散式快取系統主要包括兩個核心元件：kos-proxy 和 kos-cache。kos-proxy 作為 S3 協議的代理，提供鑑權、控制面等功能，類似於 MinIO Gateway 這樣的無狀態服務。而 kos-cache 則負責儲存分發出去的物件儲存檔案，其快取維度基於 bucket+檔案物件。當物件過大時，系統會自動拆分成多個檔案塊進行儲存。以 k8s 叢集為例，我們可以在每個節點上部署 kos-cache，以確保物件儲存的資料能夠分散在多個快取節點中，從而在當前機房實現最快的訪問速度。在最佳情況下，我們甚至可以直接從本地快取中獲取所需資料，極大地提升了訪問效率和響應速度。
原理：分散式雜湊技術
關於分散式快取的基本原理，其核心是運用了分散式雜湊技術。在系統架構中，無論是作為代理服務的 kos-proxy 還是作為快取節點的 kos-cache，都是架構的關鍵組成部分。核心區別在於快取資料的共享策略：如果快取節點設定為共享資料，它們就直接作為資料的存取點；如果設定為不共享，這些節點則充當資料的轉發代理。目前，我們支援三種接入方式：
-
第一種是閘道器形式，透過配置域名對外提供服務；
-
第二種是 side-car 方式，特別適用於 k8s 環境，透過向容器注入代理服務，使得訪問 S3 儲存如同訪問本地儲存一般便捷；
-
第三種方式是 SDK 對接，我們與 JuiceFS 進行了深度整合，實現了基於 JuiceFS 的 kos 後端儲存，無需額外配置 proxy 元件，資料即可直接寫入遠端儲存。
分散式物件儲存系統支援跨區域的訪問控制（ACL），所有 kos-cache 節點共享一個統一的控制面。這一控制面類似於一個龐大的聯邦系統，無論在北京還是上海，都能透過它進行統一的管理和排程。每個節點都持有部分虛擬的儲存單元，這些單元透過雜湊演算法進行分配和管理。
在實際應用中，我們採用了 128 個 token 值進行雜湊計算。雜湊策略主要基於兩個維度：一是根據 bucket +檔案 key 的資訊查詢對應的虛擬節點；二是結合 region 和 zone 資訊，根據複製因子和 zone 配置，將資料寫入到指定的區域。例如，如果設定了兩個複製因子，並且目標區域僅包括北京和上海，系統會首先選擇北京區域進行寫入，然後在確保 zone 不同的前提下，將資料同步到上海區域。這種設計確保了資料在寫入時能夠同時分發到不同的地區，有效解決了跨地區訪問的問題。
效能提升
在儲存效能提升方面，由於當前硬體設施的侷限性，我們主要透過最佳化資料同步機制來提高儲存效率，確保資料能夠更快速地完成跨地區同步。
首先，我們所進行的分散式快取加速測試，雖能作為參考，但並不具備實際跨地區部署的代表性。這是因為測試環境僅限於 IDC 內部，即北京區內的測試，並未涵蓋跨地區的實際部署場景。跨地區的效能差異顯著，通常表現為幾十兆至幾百兆的頻寬下降，直至基地級別的差異，這使得當前的測試結果在跨地區部署中缺乏參考意義。
然而，在與騰訊雲的跨雲訪問測試中，相較於本地 IDC 的訪問效能，我們的分散式快取加速方案實現了大約 25% 的效能提升。
這一提升雖顯著，但系統仍存在瓶頸。特別是在處理大量小檔案時，系統的效能衰減尤為嚴重。這一問題的根源在於我們的系統目前尚未整合後設資料系統，而是依賴於本地磁碟進行後設資料儲存。此外，由於我們廣泛採用 S3 協議，公司內許多依賴於 S3 協議的元件，如可觀測性工具（如 Prometheus），都基於該分散式快取加速系統。在實際應用中，我們已成功透過該系統提升了查詢效能，例如，現在能夠輕鬆查詢 30 天甚至 60 天的資料，而之前即使查詢 14 天的資料也會遇到效能瓶頸。
綜上所述，儘管我們的分散式快取加速系統在本地 IDC 內表現出色，但在跨地區部署中仍需進一步最佳化。同時，我們也在積極探索後設資料系統的整合方案，以進一步提升系統效能，滿足各類應用場景的需求。
映象檔案系統
當進行跨區資料複製時，使用者首先在北京區建立一個資料集（JuiceFS 卷），這個資料集本質上是一個可在北京區掛載的 JuiceFS 卷，其底層將自動完成卷的初始化。隨後，使用者需要執行第二步操作，即在上海區建立一個映象檔案系統，並確保該檔案系統與北京區的捲進行關聯。
我們的系統會自動完成所有必要的配置，使得使用者只需在北京區寫入資料，系統便會自動將資料同步至上海區。此外，映象檔案系統的配置是靈活的，使用者可以根據需要配置多個映象位置，如北京、天津或其他地區。
然而，在實際應用中，我們遇到了一個重要的挑戰。映象檔案系統必須設定為只讀模式，這不僅僅是在 JuiceFS 層面，還需要在後設資料許可權分配和 S3 許可權分配等方面也進行相應設定。這樣的設定可以確保資料的安全性，避免在意外情況下發生寫操作，從而導致同步機制出現不可控的場景。
因此，我們決定將這一過程產品化，主要是為了避免互動過程中出現的不可控因素，尤其是防止資料在兩地同時寫入而產生的雙寫問題。透過這種產品化的解決方案，我們能夠向使用者提供更穩定、可靠的資料同步服務。
目前，我們正在積極推廣這個內部檔案系統產品平臺，其核心功能之一是實現兩個檔案系統之間的資料同步。雖然這些功能雖然處於技術的底層，但卻是非常關鍵的。這種同步功能不僅在技術層面高效，還能開啟多種創新的應用場景，為使用者帶來實際與潛在的價值。
該檔案系統平臺最佳化的首個方面是資料同步的即時性。它允許資料同步從資料寫入階段便開始進行，這與傳統的 AI 工作流程形成鮮明對比。在傳統流程中，資料生產、清洗、複製和訓練等步驟耗時較長，特別是在資料複製環節，由於基建能力的不足（如頻寬較小等因素），效率往往低下，進而影響整個工程效率。我們的檔案系統透過最佳化鏈路，從資料生產到資料清洗，有效減少了資料複製的時間，使資料能夠更快地進入訓練階段。
其次，基於該檔案系統的能力，我們進一步實現了資料預熱的場景。當資料集龐大且使用者不需要所有資料都進行兩端同步時，可以選擇性地針對清洗後的資料或定向型資料進行預熱處理。這一功能有助於使用者將資料從一個區域快速分佈到另一個區域，以加速特定任務（如訓練）的執行。
總的來說，我們開發這一內部檔案系統產品平臺提高了整個基礎設施的工程效率，減少了資料複製時間，幫助使用者能夠高效地完成各類任務。
04 JuiceFS 的工程實踐與案例分析
AI 模型倉庫
隨著大模型時代的來臨，模型的大小不斷增大，我們目前處理的最大模型已超過 130GB。在此，我們聚焦一個簡單的場景：模型訓練完成後的推理階段。在這個階段，需要部署大量的服務，類似於微服務架構，可能需要開啟超過 100 個副本來執行推理任務。對於如此龐大的模型，如果直接分發到開發叢集中，將面臨嚴峻的挑戰。以 S3 作為模型倉庫為例，如果一次性拉取大模型到多個副本，將會對頻寬造成巨大壓力，甚至可能導致 S3 服務崩潰，進而影響到其他線上業務。因此，大模型導致的高頻寬佔用成為我們迫切需要解決的問題。為此，我們採取了三個原則來最佳化模型管理和分發過程。
-
首先，力求避免物理複製，即避免直接從中心倉庫拉取大模型到所有副本。相反，我們考慮先在機房內部進行模型的分發，以減少對外部頻寬的依賴，但這種方法可能帶來較長的分發週期。
-
其次，避免中心化設計。傳統的中心化儲存在處理大模型時容易受到頻寬限制。因此，我們尋求更分散式的解決方案，以減少對中心儲存的依賴。
-
最後，充分利用公司內部已有的技術能力進行復用。貝殼在機器學習平臺建設方面起步較早，因此我們可以利用這些成熟的技術和框架來最佳化模型管理和分發。例如，我們已經成功將 JuiceFS 等技術應用於模型儲存和管理中，進一步提升了系統的效率和穩定性。
我們基於 JuiceFS 的架構設計了一套 AI 模型倉庫方案。該方案的核心思想包括以下幾個部分：
模型部署和管理：我們提供了基於 JuiceFS 卷和模型服務控制面的原理。此外，還配套了一個模型倉庫的命令列工具，類似於Docker，使用者可以透過這個工具進行模型的部署和管理。
模型服務控制：我們主要關注於鑑權、後設資料等一系列管理功能。而模型本身則儲存在 JuiceFS 卷中。鑑於模型與映象的相似性，它們都需要標籤（Tag）來標識版本。因此，我們利用 JuiceFS 的網路能力，透過後設資料的複製而非底層資料的真實複製，實現了模型版本管理。
模型的拉取：我們提供了兩種模型部署方式。第一種是在 Kubernetes 環境中，直接將 JuiceFS 卷掛載到 Pod，利用 PV 和 PVC 自動將模型檔案掛載進去，這適用於資料密集型場景。
第二種方式是遠端拉取，例如直接在物理機上操作，我們提供了一種方法將模型直接拉取到本地並啟動。對於遠端拉取，我們利用後設資料和映象檔案系統的加速技術，使下載過程既高效又完整，相當於在內網中進行下載。此外，由於我們在機房內進行了快取加速，這種方式幾乎不會對頻寬造成影響，與傳統的直接從物件儲存中拉取模型形成鮮明對比。
05 未來展望與技術創新
首先，我要強調我們當前面臨的一項緊迫且務實的挑戰：針對 JuiceFS 打造具備企業級控制面能力。JuiceFS 在使用過程中展現出的技術靈活性，雖然帶來了諸多便利，但同時也引入了不可控因素，尤其是在大規模部署時，一旦出現問題，其排查難度顯著增加。
為了解決這一問題，我們計劃引入一系列規則與限流機制，以應對可能出現的資源過度消耗情況，如同時啟動多個客戶端寫入同一 JuiceFS 卷等場景。這不僅需要增強對 JuiceFS 的控制能力，也是我們未來發展的重要方向之一。
具體而言，我們將從三個維度著手：
-
提升運維效率：透過社群版支援的平滑升級等方式，確保 JuiceFS 在企業內部的使用更加高效；
-
增強可觀測性：這不僅僅侷限於 JuiceFS 本身的監控，而是整個體系架構的可觀測能力；
-
強化管理功能：包括動態限流規則的下發和配置的動態調整等。
此外，在解決 AI 問題時，我們觀察到了一個顯著的趨勢，即資料生產方式的變革。當前，大量資料被直接儲存在各種檔案系統中，如 CubeFS 和 JuiceFS，而上層的資料處理方案尚未形成統一標準。例如，多模態資料的融合、資料向檔案系統的直接寫入以及基於向量化資料探索的 Region 等技術的興起，都反映了這一趨勢。
為了應對這一變革，我們提出了一個務虛的設想，即如何藉助 AI 的能力來提升檔案系統的資料處理能力，實現資料處理與 AI 的一體化。在近期的工作中，我們已明確將解決儲存效能問題作為重點，特別是在與 RDMA 技術的整合方面，以期透過社群的共同努力，推動這一探索的深入發展。