作者 | 趙晗

地瓜科技成立于 2024 年，由地平線機器人事業(yè)部拆分組建，專注于消費級機器人底層計算平臺的研發(fā)；此外，地瓜科技在 2025 年還發(fā)布了具身智能基座模型。

在機器人數(shù)據(jù)管理和訓(xùn)練推理中，數(shù)據(jù)量龐大，使用對象存儲時面臨小文件、多云數(shù)據(jù)管理等挑戰(zhàn)，在嘗試了百度云 BOS、阿里云 CPFS 和將私有 MinIO 替換為 SSD 存儲后，方案在應(yīng)對上述挑戰(zhàn)時仍然面臨困難。地瓜機器人最終選擇了 JuiceFS 作為核心存儲解決方案。

JuiceFS 對跨云業(yè)務(wù)的天然適配能力，能夠高效支持多云環(huán)境中的數(shù)據(jù)共享需求。在訓(xùn)練場景中，JuiceFS 針對小文件數(shù)據(jù)設(shè)計的緩存機制，能夠有效替代傳統(tǒng)緩存方案，同時在成本和效率之間實現(xiàn)高性價比，完全滿足存儲性能的需求。目前，地瓜機器人的文件管理規(guī)模已達(dá)到千萬級別。

本文將詳細(xì)介紹我們的業(yè)務(wù)背景、存儲痛點、方案選型、落地實踐與生產(chǎn)調(diào)優(yōu)經(jīng)驗，希望對同行業(yè)的技術(shù)實踐與方案選型提供參考與借鑒。

1 機器人行業(yè)的存儲痛點

云平臺作為地瓜機器人的技術(shù)核心中樞，承擔(dān)仿真環(huán)境搭建、數(shù)據(jù)生成與模型訓(xùn)練、模型輕量化部署及可視化驗證等關(guān)鍵業(yè)務(wù)職能。平臺所涉及的數(shù)據(jù)類型多元，主要包括傳感器圖像數(shù)據(jù)、激光雷達(dá)點云數(shù)據(jù)、模型權(quán)重與配置數(shù)據(jù)、電機運行數(shù)據(jù)及地圖構(gòu)建數(shù)據(jù)等。

對象存儲雖能滿足海量數(shù)據(jù)的基礎(chǔ)存儲需求，但在機器人業(yè)務(wù)高頻出現(xiàn)的海量小文件處理場景中，性能短板尤為突出。地瓜機器人的存儲系統(tǒng)面臨四大核心挑戰(zhàn)：

海量小文件的元數(shù)據(jù)性能瓶頸：機器人模型訓(xùn)練環(huán)節(jié)涉及千萬至億級規(guī)模的傳感器圖像、激光雷達(dá)數(shù)據(jù)與模型文件，傳統(tǒng)對象存儲（如標(biāo)準(zhǔn) S3）在處理該規(guī)模數(shù)據(jù)時，元數(shù)據(jù)操作性能存在顯著瓶頸，文件列表檢索、屬性獲取等常規(guī)操作的固定 API 延遲通常為 10–30 ms，直接制約訓(xùn)練與推理環(huán)節(jié)的 QPS 表現(xiàn)，影響整體研發(fā)效率。

多云協(xié)同與數(shù)據(jù)流通效率低下：當(dāng)前機器人企業(yè)普遍采用多云架構(gòu)開展研發(fā)與生產(chǎn)業(yè)務(wù)，如何保障數(shù)據(jù)在不同云平臺及地域間高效同步與共享，成為行業(yè)普遍面臨的核心問題。傳統(tǒng)存儲方案跨云數(shù)據(jù)流通效率偏低，且大多與單一云服務(wù)商深度綁定，易形成技術(shù)依賴，難以實現(xiàn)靈活的跨云業(yè)務(wù)部署與數(shù)據(jù)協(xié)同。

性能、成本與運維的 “不可能三角”：高性能并行文件系統(tǒng)可提供高吞吐、低延遲的存儲服務(wù)，但通常依賴全閃存陣列或?qū)Ｓ糜布O(shè)備，前期硬件投入與后期運維成本高昂，且部署運維流程復(fù)雜。低成本對象存儲雖具備良好的彈性擴展能力，卻難以支撐 AI 訓(xùn)練場景下 GPU 集群所需的高吞吐 I/O 負(fù)載。行業(yè)常規(guī)方案是將 S3 數(shù)據(jù)同步至高速文件系統(tǒng)作為緩存使用，但額外的數(shù)據(jù)同步流程大幅降低業(yè)務(wù)易用性，無法實現(xiàn)存儲與計算的高效協(xié)同。

數(shù)據(jù)集版本管理困難：機器人模型迭代速度快，需對多版本數(shù)據(jù)集進(jìn)行高效、精細(xì)化管理。若采用物理拷貝的方式實現(xiàn)數(shù)據(jù)集版本控制，會直接導(dǎo)致底層存儲容量成倍消耗，顯著推高存儲成本，同時多版本數(shù)據(jù)的檢索、復(fù)用與維護難度也會大幅上升。

地瓜科技云平臺架構(gòu)圖

2 存儲選型：JuiceFS vs. MinIO/S3 vs. PFS

為解決上述存儲痛點，地瓜機器人確立了明確的選型評估標(biāo)準(zhǔn)，圍繞存儲架構(gòu)、協(xié)議兼容性、元數(shù)據(jù)性能、擴展性、多云適配能力、成本效率、運維復(fù)雜度七大核心維度，對行業(yè)主流存儲方案開展全面對比測試。

圖片基于上述對比結(jié)果，JuiceFS 在核心性能、擴展性、多云適配與成本效率等多個關(guān)鍵維度均展現(xiàn)出顯著優(yōu)勢，成為地瓜機器人統(tǒng)一存儲解決方案的首選。

同時，JuiceFS 在智能駕駛領(lǐng)域已實現(xiàn)廣泛落地，地平線等行業(yè)頭部企業(yè)已通過 JuiceFS 完成千 PB 級別的數(shù)據(jù)承載，具備成熟的大規(guī)模場景應(yīng)用經(jīng)驗。

針對地瓜機器人業(yè)務(wù)場景，JuiceFS 的核心技術(shù)優(yōu)勢主要體現(xiàn)在以下四大方面：

• 解耦架構(gòu)：JuiceFS 采用元數(shù)據(jù)與數(shù)據(jù)分離的架構(gòu)設(shè)計，將數(shù)據(jù)持久化存儲在低成本對象存儲（如 S3、OSS），元數(shù)據(jù)則托管于 Redis 或 TiKV 等數(shù)據(jù)庫組件。這種解耦架構(gòu)實現(xiàn)了存儲的彈性擴展，避免對單一云服務(wù)商的依賴。

• 分塊與緩存機制：JuiceFS 使用 Chunk、Slice、Block 三級分塊機制，有效提高了小文件讀取效率，并提升了并發(fā)讀寫能力。此外，結(jié)合多級緩存（內(nèi)存、本地 SSD、分布式緩存），可降低熱數(shù)據(jù)訪問延遲，滿足高吞吐訓(xùn)練需求。

• 云原生適配性：通過提供 CSI 驅(qū)動，JuiceFS 在 Kubernetes 環(huán)境中提供與計算節(jié)點解耦的持久化存儲，支持容器無狀態(tài)化部署和跨云遷移。它支持?jǐn)?shù)據(jù)共享，提升應(yīng)用的高可用性和靈活性，并適配多種 Kubernetes 部署方式。

• AI 訓(xùn)練全鏈路支持：JuiceFS 完整支持 POSIX、HDFS 和 S3 API，兼容主流 AI 框架（如 PyTorch、TensorFlow），無需修改代碼即可接入，降低技術(shù)門檻。

• 支持多云：其跨云能力和高性能元數(shù)據(jù)引擎確保數(shù)據(jù)流轉(zhuǎn)高效，完美契合了我們“算力隨需而動”的戰(zhàn)略。

從成本維度來看，JuiceFS 在初期小規(guī)模部署時成本優(yōu)勢不突出，但當(dāng)數(shù)據(jù)規(guī)模突破 PB 級，尤其達(dá)到 10PB、100PB 級別并與全閃存方案對比時，其依托對象存儲的低成本架構(gòu)優(yōu)勢將全面凸顯。此外，JuiceFS 的運維成本極低，地瓜機器人當(dāng)前僅需一名工程師即可負(fù)責(zé)整個云平臺與存儲系統(tǒng)的運維工作，遠(yuǎn)低于傳統(tǒng)方案所需的人員投入。

3 從社區(qū)版到企業(yè)版，應(yīng)對更大規(guī)模場景需求

隨著業(yè)務(wù)的不斷擴展，我們在使用 Redis 作為元數(shù)據(jù)引擎時，發(fā)現(xiàn)物理內(nèi)存容量限制了數(shù)據(jù)的擴展。當(dāng)文件數(shù)量接近億級時，元數(shù)據(jù)查詢的延遲顯著增加，進(jìn)而影響了訓(xùn)練任務(wù)的并發(fā)效率。在使用 clone 功能后，元數(shù)據(jù)的量大幅增加，另外我們在跨云場景中對元數(shù)據(jù)同步和鏡像文件系統(tǒng)的能力提出了更高要求。同時，我們還希望在目錄級別進(jìn)行更細(xì)粒度的容量限制和權(quán)限管理。

考慮到這些需求，以及希望利用 GPU 機器本地 SSD 構(gòu)建分布式緩存層來提升性能，我們決定并行部署 JuiceFS 企業(yè)版，將超大規(guī)模目錄管理、多機協(xié)同訓(xùn)練等核心場景遷移至該版本。通過這種場景化拆分，我們有效提升了整體存儲系統(tǒng)的適配性，并為未來的業(yè)務(wù)增長提供堅實的基礎(chǔ)。以下是我們在實際場景中應(yīng)用的企業(yè)版關(guān)鍵特性。

特性 1- 高性能元數(shù)據(jù)引擎：解決超大規(guī)模目錄檢索瓶頸

針對億級文件目錄下的遍歷、深分頁查詢等高頻操作，我們曾遇到傳統(tǒng)存儲方案 “越查越慢” 的問題 —— 單目錄文件量突破千萬后，分頁查詢偏移量超過 10 萬條時，響應(yīng)延遲會從百毫秒級飆升至秒級，嚴(yán)重影響數(shù)據(jù)篩選效率。

切換至 JuiceFS 企業(yè)版后，其元數(shù)據(jù)的原生目錄樹形存儲架構(gòu)發(fā)揮了關(guān)鍵作用：不同于扁平化 KV 對文件元數(shù)據(jù)的無序存儲，這種樹形結(jié)構(gòu)可直接定位目錄層級，減少元數(shù)據(jù)掃描范圍。我們實際測試中，單目錄 1.2 億文件的深分頁查詢（偏移量 50 萬條），延遲從原來的 3.8 秒降至 210 毫秒，完全滿足大規(guī)模數(shù)據(jù)集的檢索需求；同時，該引擎支持單卷千億級文件存儲，目前我們已基于此支撐 3 個 PB 級訓(xùn)練數(shù)據(jù)集的穩(wěn)定管理，匹配業(yè)務(wù)增長預(yù)期。

特性 2- 企業(yè)級分布式緩存：提升多機多卡訓(xùn)練數(shù)據(jù)共享效率

在多機多卡訓(xùn)練場景中，我們曾面臨 “緩存命中率低、跨節(jié)點帶寬擁堵” 的問題 —— 開源版僅支持節(jié)點本地緩存，當(dāng)多節(jié)點同時拉取同一數(shù)據(jù)集時，每個節(jié)點都需要訪問對象存儲，導(dǎo)致單節(jié)點帶寬占用率超過 90%，訓(xùn)練任務(wù)啟動延遲平均達(dá) 20 分鐘。

借助 JuiceFS 企業(yè)版的分布式緩存功能，我們通過 3 行命令在 12 臺訓(xùn)練節(jié)點組成的局域網(wǎng)內(nèi)搭建了分布式緩存，數(shù)據(jù)集只需要從對象存儲拉取一次，并緩存在節(jié)點本地 SSD 組成的緩存池中。多機協(xié)同訓(xùn)練的緩存命中率從原來的 45% 提升至 92%，跨節(jié)點帶寬占用率降至 15% 以下，訓(xùn)練任務(wù)啟動時間縮短至 3 分鐘內(nèi)，大幅提升了算力利用率。

特性 3- 增強型跨云協(xié)同：構(gòu)建低運維成本的跨云數(shù)據(jù)底座

由于我們的研發(fā)環(huán)境分布在阿里云、百度云兩個平臺，此前存在 “跨云數(shù)據(jù)同步慢、運維成本高” 的痛點 —— 通過傳統(tǒng)同步工具實現(xiàn)兩地數(shù)據(jù)一致，需配置 8 個定時任務(wù)，同步延遲平均達(dá) 4 小時，且需專人每周排查同步失敗問題。

基于 JuiceFS sync 工具，結(jié)合內(nèi)部 AI 運維工具實現(xiàn)了同步策略自動化配置：系統(tǒng)可根據(jù)數(shù)據(jù)熱度自動調(diào)整同步優(yōu)先級，跨云數(shù)據(jù)延遲控制在 10 分鐘內(nèi)；同時，同步任務(wù)的失敗重試、日志告警等均實現(xiàn)自動化，無需專人值守，運維投入減少 70%，目前已穩(wěn)定支撐兩個云平臺多個訓(xùn)練項目共享同一套數(shù)據(jù)集。后續(xù)，將使用企業(yè)版的鏡像文件系統(tǒng)功能來應(yīng)對跨云數(shù)據(jù)協(xié)同。

4 JuiceFS 調(diào)優(yōu)攻略

客戶端緩存與寫入性能調(diào)優(yōu)實踐

需重點關(guān)注緩存策略與 Kubernetes 資源限額之間的兼容性問題。如使用內(nèi)存作為本地緩存路徑，配置不合理可能引發(fā) Mount Pod 內(nèi)存異常增長，或因資源配額預(yù)留不足，導(dǎo)致長周期訓(xùn)練任務(wù)出現(xiàn)檢查點丟失、文件句柄寫入異常等情況。

在寫入性能調(diào)優(yōu)方面，開啟 writeback 模式可在一定程度上提升小文件寫入吞吐，但結(jié)合生產(chǎn)環(huán)境對數(shù)據(jù)一致性的要求，我們?nèi)圆捎?write-through 同步寫入模式，以降低極端宕機場景下的數(shù)據(jù)風(fēng)險。建議僅在對數(shù)據(jù)可靠性要求較低的臨時計算、離線數(shù)據(jù)清洗等場景中，根據(jù)實際需求謹(jǐn)慎啟用 writeback 模式以提升寫入效率。

部署與網(wǎng)絡(luò)拓?fù)鋬?yōu)化

為獲得更穩(wěn)定的性能表現(xiàn)，在部署時強烈建議將元數(shù)據(jù)引擎與計算節(jié)點規(guī)劃在同一 region 區(qū)域內(nèi)。實際運行中觀察到，跨 region 部署會使元數(shù)據(jù)操作延遲出現(xiàn)數(shù)倍至十倍的上升，對數(shù)據(jù)解壓等 I/O 密集型操作的效率影響較為明顯。將元數(shù)據(jù)服務(wù)與 GPU 計算資源部署在同一 region 內(nèi)，有助于在保障性能的同時控制網(wǎng)絡(luò)傳輸成本，提升整體資源利用效率。

數(shù)據(jù)預(yù)熱與緩存優(yōu)化策略

在萬兆網(wǎng)絡(luò)環(huán)境下，可充分利用 JuiceFS 的數(shù)據(jù)預(yù)熱機制，結(jié)合業(yè)務(wù)場景合理調(diào)整數(shù)據(jù)塊大小，以更好地發(fā)揮網(wǎng)絡(luò)帶寬能力，提升讀吞吐量。配合分布式緩存架構(gòu)，可有效改善多機并發(fā)場景下的數(shù)據(jù)共享效率，提升高并發(fā)讀取時的緩存命中率，從而優(yōu)化大規(guī)模 AI 訓(xùn)練任務(wù)的整體運行表現(xiàn)。

資源配額與高可用保障策略

企業(yè)級多角色運維、存儲職責(zé)分離場景下，為規(guī)避配置不一致的運行風(fēng)險，建議精細(xì)化管控 K8s 環(huán)境中 JuiceFS CSI 驅(qū)動的資源配額。通過合理設(shè)置 Mount Pod 的 CPU 與內(nèi)存 Request/Limit，可減少因資源搶占導(dǎo)致的 Pod 重啟或節(jié)點異常，實際使用中可根據(jù)集群負(fù)載動態(tài)調(diào)整資源預(yù)留比例。

同時，對業(yè)務(wù)連續(xù)性要求較高的場景，可開啟 Mount Pod 的掛載點自動恢復(fù)功能，實現(xiàn)存儲服務(wù)的自動化故障恢復(fù)，進(jìn)一步保證底層存儲的穩(wěn)定性。

多租戶實踐

我們?yōu)榇笮推髽I(yè)客戶提供獨立文件系統(tǒng)和存儲桶，并通過子目錄級別的目錄隔離和權(quán)限管控實現(xiàn)中小型企業(yè)客戶與終端用戶的隔離。大型企業(yè)客戶可以靈活擴展吞吐量和容量，避免共享存儲桶帶來的性能瓶頸。對于中小型企業(yè)和終端用戶，我們通過子目錄隔離和權(quán)限管控確保數(shù)據(jù)安全與獨立性，同時實現(xiàn)精確計量與計費。這一架構(gòu)在保障租戶隔離的同時，也能靈活調(diào)配資源，提高系統(tǒng)管理效率。

版本管理

通過 juicefs clone 命令，可以快速創(chuàng)建原始數(shù)據(jù)集的副本，并獨立修改，而不影響原數(shù)據(jù)。克隆操作僅復(fù)制文件的元數(shù)據(jù)，數(shù)據(jù)則只額外存儲變更部分，節(jié)省底層存儲空間。此功能支持管理多個版本，便于回滾和恢復(fù)，確保數(shù)據(jù)的安全性和版本控制。

5 小結(jié)與展望

JuiceFS 在元數(shù)據(jù)性能、擴展能力、跨云適配性與綜合成本效率等方面的特性，支撐其成為我們構(gòu)建統(tǒng)一存儲層的選擇。目前地瓜科技采用 JuiceFS 社區(qū)版與企業(yè)版并行部署的模式，適配不同業(yè)務(wù)場景下的差異化存儲訴求。

未來，我們計劃將 JuiceFS 進(jìn)一步落地至具身智能領(lǐng)域，針對性解決該場景下的專屬存儲需求，包括時序數(shù)據(jù)高吞吐處理、多模態(tài)數(shù)據(jù)精準(zhǔn)對齊、邊緣與云端協(xié)同存儲及仿真與真實場景數(shù)據(jù)的融合管理等。后續(xù)積累更多實踐經(jīng)驗后，我們將持續(xù)分享具身機器人場景下的存儲實踐心得。

關(guān)于 AI 場景的存儲實踐與技術(shù)探索，歡迎評論區(qū)一起交流探討。

關(guān)于作者

趙晗，地瓜機器人云平臺架構(gòu)師；負(fù)責(zé)數(shù)據(jù)業(yè)務(wù)架構(gòu)、云平臺基礎(chǔ)設(shè)施。