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

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

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

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

01 機(jī)器人行業(yè)的存儲痛點(diǎn)

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

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

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

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

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

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

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

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

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

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

• 解耦架構(gòu)：JuiceFS 采用元數(shù)據(jù)與數(shù)據(jù)分離的架構(gòu)設(shè)計(jì)，將數(shù)據(jù)持久化存儲在低成本對象存儲（如 S3、OSS），元數(shù)據(jù)則托管于 Redis 或 TiKV 等數(shù)據(jù)庫組件。這種解耦架構(gòu)實(shí)現(xiàn)了存儲的彈性擴(kuò)展，避免對單一云服務(wù)商的依賴。
• 分塊與緩存機(jī)制：JuiceFS 使用 Chunk、Slice、Block 三級分塊機(jī)制，有效提高了小文件讀取效率，并提升了并發(fā)讀寫能力。此外，結(jié)合多級緩存（內(nèi)存、本地 SSD、分布式緩存），可降低熱數(shù)據(jù)訪問延遲，滿足高吞吐訓(xùn)練需求。

• 云原生適配性：通過提供 CSI 驅(qū)動，JuiceFS 在 Kubernetes 環(huán)境中提供與計(jì)算節(jié)點(diǎn)解耦的持久化存儲，支持容器無狀態(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 的運(yùn)維成本極低，地瓜機(jī)器人當(dāng)前僅需一名工程師即可負(fù)責(zé)整個云平臺與存儲系統(tǒng)的運(yùn)維工作，遠(yuǎn)低于傳統(tǒng)方案所需的人員投入。

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

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

考慮到這些需求，以及希望利用 GPU 機(jī)器本地 SSD 構(gòu)建分布式緩存層來提升性能，我們決定并行部署 JuiceFS 企業(yè)版，將超大規(guī)模目錄管理、多機(jī)協(xié)同訓(xùn)練等核心場景遷移至該版本。通過這種場景化拆分，我們有效提升了整體存儲系統(tǒng)的適配性，并為未來的業(yè)務(wù)增長提供堅(jiān)實(shí)的基礎(chǔ)。以下是我們在實(shí)際場景中應(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ù)掃描范圍。我們實(shí)際測試中，單目錄 1.2 億文件的深分頁查詢（偏移量 50 萬條），延遲從原來的 3.8 秒降至 210 毫秒，完全滿足大規(guī)模數(shù)據(jù)集的檢索需求；同時，該引擎支持單卷千億級文件存儲，目前我們已基于此支撐 3 個 PB 級訓(xùn)練數(shù)據(jù)集的穩(wěn)定管理，匹配業(yè)務(wù)增長預(yù)期。

特性 2- 企業(yè)級分布式緩存：提升多機(jī)多卡訓(xùn)練數(shù)據(jù)共享效率
在多機(jī)多卡訓(xùn)練場景中，我們曾面臨 “緩存命中率低、跨節(jié)點(diǎn)帶寬擁堵” 的問題 —— 開源版僅支持節(jié)點(diǎn)本地緩存，當(dāng)多節(jié)點(diǎn)同時拉取同一數(shù)據(jù)集時，每個節(jié)點(diǎn)都需要訪問對象存儲，導(dǎo)致單節(jié)點(diǎn)帶寬占用率超過 90%，訓(xùn)練任務(wù)啟動延遲平均達(dá) 20 分鐘。借助 JuiceFS 企業(yè)版的分布式緩存功能，我們通過 3 行命令在 12 臺訓(xùn)練節(jié)點(diǎn)組成的局域網(wǎng)內(nèi)搭建了分布式緩存，數(shù)據(jù)集只需要從對象存儲拉取一次，并緩存在節(jié)點(diǎn)本地 SSD 組成的緩存池中。多機(jī)協(xié)同訓(xùn)練的緩存命中率從原來的 45% 提升至 92%，跨節(jié)點(diǎn)帶寬占用率降至 15% 以下，訓(xùn)練任務(wù)啟動時間縮短至 3 分鐘內(nèi)，大幅提升了算力利用率。

特性 3- 增強(qiáng)型跨云協(xié)同：構(gòu)建低運(yùn)維成本的跨云數(shù)據(jù)底座
由于我們的研發(fā)環(huán)境分布在阿里云、百度云兩個平臺，此前存在 “跨云數(shù)據(jù)同步慢、運(yùn)維成本高” 的痛點(diǎn) —— 通過傳統(tǒng)同步工具實(shí)現(xiàn)兩地數(shù)據(jù)一致，需配置 8 個定時任務(wù)，同步延遲平均達(dá) 4 小時，且需專人每周排查同步失敗問題。基于 JuiceFS sync 工具，結(jié)合內(nèi)部 AI 運(yùn)維工具實(shí)現(xiàn)了同步策略自動化配置：系統(tǒng)可根據(jù)數(shù)據(jù)熱度自動調(diào)整同步優(yōu)先級，跨云數(shù)據(jù)延遲控制在 10 分鐘內(nèi)；同時，同步任務(wù)的失敗重試、日志告警等均實(shí)現(xiàn)自動化，無需專人值守，運(yùn)維投入減少 70%，目前已穩(wěn)定支撐兩個云平臺多個訓(xùn)練項(xiàng)目共享同一套數(shù)據(jù)集。后續(xù)，將使用企業(yè)版的鏡像文件系統(tǒng)功能來應(yīng)對跨云數(shù)據(jù)協(xié)同。

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

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

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

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

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

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

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

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

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

05 小結(jié)與展望

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

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