光影煥像（Lightillusions）是一家專注于空間智能技術(shù)，結(jié)合 3D 視覺、圖形學(xué)和生成模型技術(shù)，致力于打造創(chuàng)新的 3D 基礎(chǔ)模型公司。公司由譚平教授領(lǐng)導(dǎo)，譚教授曾擔(dān)任阿里巴巴達(dá)摩院實(shí)驗(yàn)室負(fù)責(zé)人，目前是香港科技大學(xué)的教授，同時(shí)擔(dān)任馮諾伊曼人工智能研究室副院長，并是香港科技大學(xué)與比亞迪聯(lián)合實(shí)驗(yàn)室的主任。

區(qū)別于二維模型，三維模型單個(gè)模型的大小可達(dá)幾 GB，尤其是點(diǎn)云數(shù)據(jù)等復(fù)雜模型。當(dāng)數(shù)據(jù)量達(dá)到 PB 級(jí)別時(shí)，管理與存儲(chǔ)成為巨大的挑戰(zhàn)。經(jīng)過嘗試 NFS、GlusterFS 等方案后，我們最終選擇了 JuiceFS，成功搭建了一個(gè)統(tǒng)一的存儲(chǔ)平臺(tái)，為多個(gè)場(chǎng)景服務(wù)，并支持跨平臺(tái)訪問，包括 Windows 和 Linux 系統(tǒng)。該平臺(tái)目前已管理上億文件，數(shù)據(jù)處理速度提升了 200%~250%，還實(shí)現(xiàn)了高效的存儲(chǔ)擴(kuò)容，同時(shí)運(yùn)維管理得到了極大簡(jiǎn)化，使得團(tuán)隊(duì)能夠更專注于核心任務(wù)的推進(jìn)。

01 3D-AIGC 存儲(chǔ)需求

我們的研究主要集中在感知和生成兩個(gè)方向。在三維領(lǐng)域，任務(wù)的復(fù)雜性與圖像和文本處理有本質(zhì)區(qū)別，這對(duì)我們的 AI 模型、算法以及基礎(chǔ)設(shè)施建設(shè)都提出了更高的要求。

我們通過一個(gè) 3D 數(shù)據(jù)處理流程，來展示三維數(shù)據(jù)處理的復(fù)雜性。下圖左側(cè)是一個(gè)三維模型，包含紋理（左上角的折射紋理）和幾何信息（右下角的幾何結(jié)構(gòu)）。首先，我們生成渲染圖像。每個(gè)模型還附帶文本標(biāo)簽，描述其內(nèi)容、幾何特征和紋理特征，這些標(biāo)簽與每個(gè)模型緊密相關(guān)。此外，我們還處理幾何數(shù)據(jù)，如采樣點(diǎn)以及從數(shù)據(jù)預(yù)處理過程中得到的必要數(shù)值（如 3DS、SDF 等）。需要注意的是，三維模型的文件格式非常多樣，圖片格式也各不相同。

我們的工作場(chǎng)景涉及語言模型、圖像/視頻模型到三維模型，隨著數(shù)據(jù)量的增長，存儲(chǔ)負(fù)擔(dān)也在不斷增加。以下是這些場(chǎng)景中數(shù)據(jù)使用的主要特點(diǎn)：

• 語言模型的數(shù)據(jù)通常由大量小文件組成。盡管單個(gè)文本文件較小，但隨著數(shù)據(jù)量的增加，文件數(shù)量可能達(dá)到數(shù)百萬甚至數(shù)千萬個(gè)，這使得管理如此龐大的文件數(shù)成為存儲(chǔ)的一個(gè)主要難點(diǎn)。
• 圖像和視頻數(shù)據(jù)，尤其是高分辨率圖像和長時(shí)間的視頻，通常較為龐大。單張圖像的大小通常在幾百 KB 到幾 MB 之間，而視頻文件可能達(dá)到 GB 級(jí)別。在預(yù)處理過程中，如數(shù)據(jù)增強(qiáng)、分辨率調(diào)整和幀提取等，數(shù)據(jù)量會(huì)顯著增加，特別是在視頻處理中，每個(gè)視頻通常會(huì)被拆解為大量的圖像文件，管理這些龐大的文件集，帶來了更高的復(fù)雜性。
• 三維模型，特別是點(diǎn)云數(shù)據(jù)等復(fù)雜模型，單個(gè)模型的大小可達(dá)幾 GB。三維數(shù)據(jù)的預(yù)處理過程比其他數(shù)據(jù)更加復(fù)雜，涉及紋理映射、幾何重建等多個(gè)步驟，這些處理不僅消耗大量計(jì)算資源，還可能增加數(shù)據(jù)體積。此外，三維模型通常由多個(gè)文件組成，文件數(shù)量龐大，隨著數(shù)據(jù)量的增長，管理這些文件的難度也會(huì)增加。

由上述環(huán)節(jié)的存儲(chǔ)特點(diǎn)，我們希望構(gòu)建的存儲(chǔ)平臺(tái)能夠滿足以下幾項(xiàng)要求：

• 多樣的數(shù)據(jù)格式與跨節(jié)點(diǎn)共享：不同模型的數(shù)據(jù)格式差異較大，特別是三維模型的格式復(fù)雜性和跨平臺(tái)兼容問題，存儲(chǔ)系統(tǒng)需要支持多種格式，并有效管理跨節(jié)點(diǎn)和跨平臺(tái)的數(shù)據(jù)共享。

• 可以處理不同尺寸的數(shù)據(jù)模型：無論是語言模型的小文件、大規(guī)模圖片/視頻數(shù)據(jù)，還是三維模型的大文件，存儲(chǔ)系統(tǒng)必須具備高擴(kuò)展性，以應(yīng)對(duì)快速增長的存儲(chǔ)需求，并高效處理大尺寸數(shù)據(jù)的存儲(chǔ)和訪問。

• 跨云與集群存儲(chǔ)的挑戰(zhàn)：隨著數(shù)據(jù)量的增加，特別是三維模型的 PB 級(jí)存儲(chǔ)需求，跨云和集群存儲(chǔ)問題愈加突出。存儲(chǔ)系統(tǒng)需要支持跨區(qū)域、跨云的無縫數(shù)據(jù)訪問和高效的集群管理。

• 方便擴(kuò)容：無論是語言模型、圖片/視頻模型，還是三維模型，擴(kuò)容需求始終存在，尤其是三維模型的存儲(chǔ)和處理對(duì)擴(kuò)容的需求更高。

• 簡(jiǎn)單的運(yùn)維：存儲(chǔ)系統(tǒng)應(yīng)提供簡(jiǎn)便的管理界面和工具，尤其是對(duì)于三維模型的管理，運(yùn)維要求更高，自動(dòng)化管理和容錯(cuò)能力是必不可少的。

02 存儲(chǔ)方案探索：從 NFS、Gluster、CephFS 到 JuiceFS

前期方案：NFS 掛載

最初，我們采用了最簡(jiǎn)單的方案——使用 NFS 進(jìn)行掛載。然而，在實(shí)際操作中，我們發(fā)現(xiàn)訓(xùn)練集群和渲染集群需要各自獨(dú)立的集群來進(jìn)行掛載操作。這種方式的維護(hù)非常繁瑣，尤其是當(dāng)添加新的數(shù)據(jù)時(shí)，我們需要單獨(dú)為每個(gè)新數(shù)據(jù)寫入掛載點(diǎn)。到了數(shù)據(jù)量達(dá)到約 100 萬物體級(jí)別時(shí)，我們已經(jīng)無法繼續(xù)維持這種方案，因此在早期階段，我們就放棄了這一方案。

中期方案：GlusterFS

GlusterFS 是一個(gè)相對(duì)易于上手的選擇，安裝配置簡(jiǎn)單，性能也能得到一定保障，且無需劃分多個(gè)掛載點(diǎn)，只需增加新節(jié)點(diǎn)即可。雖然在前期使用時(shí)，GlusterFS 大大減輕了我們的工作量，但我們也發(fā)現(xiàn)它的生態(tài)系統(tǒng)存在一些問題。

首先，GlusterFS 許多執(zhí)行腳本和功能需要手動(dòng)編寫定時(shí)任務(wù)。特別是在添加新存儲(chǔ)時(shí)，它還會(huì)有一些額外要求，例如需要按特定倍數(shù)增加節(jié)點(diǎn)。此外，像克隆、數(shù)據(jù)同步等操作的支持也相對(duì)較弱，導(dǎo)致我們?cè)谑褂眠^程中頻繁查閱文檔，且許多操作并不穩(wěn)定。例如，使用 FIO 等工具進(jìn)行測(cè)速時(shí)，結(jié)果并不總是可靠。

更為嚴(yán)重的問題是，當(dāng)存儲(chǔ)的小文件數(shù)量達(dá)到一定規(guī)模時(shí)，GlusterFS 的性能會(huì)急劇下降。舉個(gè)例子，一個(gè)模型可能會(huì)生成 100 張圖片，若有 1000 萬個(gè)模型，就會(huì)產(chǎn)生 10 億張圖片。GlusterFS 在后期的尋址變得極為困難，尤其是小文件過多時(shí)，性能會(huì)顯著下降，導(dǎo)致系統(tǒng)崩潰。

最終選型：CephFS vs JuiceFS

隨著存儲(chǔ)需求的增加，我們決定轉(zhuǎn)向可持續(xù)性更好的方案。在評(píng)估了多種方案后，我們主要對(duì)比了 CephFS 和 JuiceFS。雖然 Ceph 被廣泛使用，但通過自己的實(shí)踐和對(duì)比文檔，我們發(fā)現(xiàn) Ceph 的運(yùn)維和管理成本非常高，尤其對(duì)于我們這樣的小團(tuán)隊(duì)來說，處理這些復(fù)雜的運(yùn)維任務(wù)顯得尤為困難。

JuiceFS 有兩個(gè)原生自帶的特性非常符合我們的需求。首先是客戶端數(shù)據(jù)緩存功能。對(duì)于我們的模型訓(xùn)練集群，通常會(huì)配備高性能的 NVMe 存儲(chǔ)。如果能夠充分利用客戶端的緩存，便能顯著加速模型訓(xùn)練，并減少對(duì) JuiceFS 存儲(chǔ)的壓力。

其次，JuiceFS 對(duì) S3 的兼容性對(duì)我們也至關(guān)重要。由于我們基于存儲(chǔ)開發(fā)了一些可視化平臺(tái)用于數(shù)據(jù)標(biāo)注、整理和統(tǒng)計(jì)，S3 兼容性使得我們能夠快速進(jìn)行網(wǎng)頁開發(fā)，支持可視化和數(shù)據(jù)統(tǒng)計(jì)操作等功能。

03 基于 JuiceFS 的存儲(chǔ)平臺(tái)實(shí)踐

元數(shù)據(jù)引擎選擇與拓?fù)?/h3>

JuiceFS 采用的是元數(shù)據(jù)與數(shù)據(jù)分離的架構(gòu)，有多種元數(shù)據(jù)引擎可供選擇。我們首先快速驗(yàn)證了 Redis 存儲(chǔ)方案，官方提供了詳細(xì)的文檔支持。Redis 的優(yōu)勢(shì)在于其輕量化，配置過程通常只需一天或半天時(shí)間，數(shù)據(jù)遷移也相對(duì)順利。然而，當(dāng)小文件數(shù)量超過 1 億時(shí)，Redis 的速度和性能會(huì)顯著下降。

正如之前提到的，每個(gè)模型可能會(huì)渲染出 100 張圖片，再加上其他雜項(xiàng)文件，導(dǎo)致小文件的數(shù)量急劇增加。雖然我們可以通過打包小文件來減輕問題，但一旦打包后進(jìn)行修改或可視化操作，復(fù)雜性就大大增加。因此，我們希望能夠保留原始的小圖片文件，以便后續(xù)處理。

隨著文件數(shù)量的增加，很快超出 Redis 的處理能力，我們決定將存儲(chǔ)系統(tǒng)遷移到 TiKV 和 Kubernetes 組合上。TiKV 與 K8s 的組合能夠?yàn)槲覀兲峁└呖捎玫脑獢?shù)據(jù)存儲(chǔ)方案。此外，通過基準(zhǔn)測(cè)試我們發(fā)現(xiàn)，盡管 TiKV 的性能稍遜一籌，但差距并不顯著，且相較于 Redis，它對(duì)小文件的支持更好。我們也咨詢過 JuiceFS 的工程師，了解到 Redis 在集群模式下的擴(kuò)展性較差，于是我們準(zhǔn)備切換到 TiKV。

最新架構(gòu)：JuiceFS + TiKV + SeaweedFS

我們使用了 JuiceFS 來管理對(duì)象存儲(chǔ)。TiKV 和 K8s 來搭建元數(shù)據(jù)存儲(chǔ)系統(tǒng)。對(duì)象存儲(chǔ)部分使用了 SeaweedFS，這使得我們能夠快速擴(kuò)展存儲(chǔ)規(guī)模，且無論是小數(shù)據(jù)還是大數(shù)據(jù)，訪問速度都很快。此外，我們的對(duì)象存儲(chǔ)分布在多個(gè)平臺(tái)：包括本地存儲(chǔ)、阿里云存儲(chǔ)以及國外的 R2 和 Amazon 對(duì)象存儲(chǔ)。通過 JuiceFS，我們能夠?qū)⑦@些不同存儲(chǔ)系統(tǒng)集成起來，并提供一個(gè)統(tǒng)一的接口。

為了更好地管理系統(tǒng)資源，我們?cè)?K8s 上搭建了資源監(jiān)控平臺(tái)。當(dāng)前系統(tǒng)由大約 60 臺(tái) Linux 機(jī)器和若干 Windows 機(jī)器組成，負(fù)責(zé)渲染和數(shù)據(jù)處理任務(wù)。我們對(duì)讀取穩(wěn)定性進(jìn)行了監(jiān)控，結(jié)果顯示，即使是多臺(tái)異構(gòu)服務(wù)器同時(shí)進(jìn)行讀取操作，整個(gè)系統(tǒng)的 I/O 性能依然非常穩(wěn)定，基本能夠充分利用帶寬資源。

實(shí)踐中遇到的問題

在優(yōu)化存儲(chǔ)方案的過程中，我們最初嘗試了 EC（糾刪碼） 存儲(chǔ)方案，旨在減少存儲(chǔ)需求并提升效率。然而，在大規(guī)模數(shù)據(jù)遷移中，EC 存儲(chǔ)的計(jì)算速度較慢，并且在高吞吐量和頻繁數(shù)據(jù)變化的場(chǎng)景下，性能表現(xiàn)不佳，尤其與 SeaweedFS 結(jié)合時(shí)，存在性能瓶頸?；谶@些問題，我們決定放棄 EC 存儲(chǔ)，轉(zhuǎn)而采用副本存儲(chǔ)方案。

我們?cè)O(shè)置了獨(dú)立服務(wù)器并配置了定時(shí)任務(wù)，以進(jìn)行大數(shù)據(jù)量的元數(shù)據(jù)備份。在 TiKV 中，我們實(shí)現(xiàn)了冗余副本機(jī)制，采用了多個(gè)副本方案來確保數(shù)據(jù)的完整性。同時(shí)，在對(duì)象存儲(chǔ)方面，我們采用了雙副本編碼來進(jìn)一步提高數(shù)據(jù)可靠性。雖然副本存儲(chǔ)能夠有效保證數(shù)據(jù)冗余和高可用性，但由于處理 PB 級(jí)數(shù)據(jù)和大量增量數(shù)據(jù)，存儲(chǔ)成本依然較高。未來，我們可能會(huì)考慮進(jìn)一步優(yōu)化存儲(chǔ)方案，以降低存儲(chǔ)成本。

另外，我們也發(fā)現(xiàn)當(dāng)使用全閃存服務(wù)器 + JuiceFS 并未帶來顯著的性能提升。瓶頸主要出現(xiàn)在網(wǎng)絡(luò)帶寬和延遲上。因此，我們計(jì)劃在后期考慮使用 InfiniBand（IB）連接存儲(chǔ)服務(wù)器和訓(xùn)練服務(wù)器，以最大化資源利用效率。

04 小結(jié)

在使用 GlusterFS 時(shí)，我們每天最多只能處理 20 萬個(gè)模型；而切換到 JuiceFS 后，處理能力大幅提升，日均數(shù)據(jù)處理能力增加了 2.5 倍，小文件吞吐能力也顯著提高，特別是在存儲(chǔ)量達(dá)到 70% 后，系統(tǒng)仍能保持穩(wěn)定運(yùn)行。此外，擴(kuò)容也非常便捷，而之前的架構(gòu)，擴(kuò)容過程非常繁瑣，操作起來比較麻煩。

最后再總結(jié)一下 JuiceFS 在三維生成任務(wù)中表現(xiàn)出來的優(yōu)勢(shì)：

• 小文件性能： 小文件處理能力是一個(gè)關(guān)鍵點(diǎn)，JuiceFS 依然提供了一個(gè)較好的解決方案。

• 跨平臺(tái)特性： 跨平臺(tái)支持非常重要。我們發(fā)現(xiàn)有些數(shù)據(jù)只能在 Windows 軟件中打開，因此需要同時(shí)在 Windows 和 Linux 系統(tǒng)上處理相同的數(shù)據(jù)，并在同一個(gè)掛載節(jié)點(diǎn)上進(jìn)行讀寫。這種需求使得跨平臺(tái)的特性尤為關(guān)鍵，JuiceFS 的設(shè)計(jì)很好地解決了這一問題。

• 低運(yùn)維成本： JuiceFS 的運(yùn)維成本極低。配置完成后，只需要進(jìn)行一些簡(jiǎn)單的測(cè)試和節(jié)點(diǎn)的管理（例如，丟棄某些節(jié)點(diǎn)并監(jiān)控魯棒性）。我們?cè)谶w移數(shù)據(jù)時(shí)花費(fèi)了大約半年的時(shí)間，到目前為止并未遇到太大的問題。

• 本地緩存機(jī)制： 之前，如果想使用本地緩存，我們需要手動(dòng)在代碼中實(shí)現(xiàn)本地緩存邏輯，但 JuiceFS 提供了非常方便的本地緩存機(jī)制，通過設(shè)置掛載參數(shù)來優(yōu)化訓(xùn)練場(chǎng)景的性能。

• 遷移成本低： 尤其是在遷移小文件時(shí)，我們發(fā)現(xiàn)使用 JuiceFS 進(jìn)行元數(shù)據(jù)和對(duì)象存儲(chǔ)的遷移非常方便，節(jié)省了我們大量時(shí)間和精力。相比之下，之前使用其他存儲(chǔ)系統(tǒng)遷移時(shí)，過程非常痛苦。

綜上所述，JuiceFS 在大規(guī)模數(shù)據(jù)處理中的表現(xiàn)非常出色，提供了高效、穩(wěn)定的存儲(chǔ)解決方案。它不僅簡(jiǎn)化了存儲(chǔ)管理和擴(kuò)容過程，還大大提升了系統(tǒng)性能，讓我們能夠更加專注于核心任務(wù)的推進(jìn)。

此外，官方提供一些工具也非常便捷，例如我們使用 Sync 在處理小文件遷移時(shí)，效率極高。在沒有額外性能優(yōu)化的情況下，我們成功遷移了 500TB 的數(shù)據(jù)，其中包含大量的小數(shù)據(jù)和圖片文件，遷移時(shí)間不到 5 天，結(jié)果超出我們的預(yù)期。

我們希望本文中的一些實(shí)踐經(jīng)驗(yàn)，能為正在面臨類似問題的開發(fā)者提供參考，如果有其他疑問歡迎加入 JuiceFS 社區(qū)與大家共同交流。