在過去兩年多的時(shí)間里，隨著 AI 大模型的快速發(fā)展，JuiceFS 在攜程內(nèi)部得到了越來(lái)越多 AI 用戶的關(guān)注。目前，攜程通過 JuiceFS 管理著 10PB 數(shù)據(jù)規(guī)模，為 AI 訓(xùn)練等多個(gè)場(chǎng)景提供存儲(chǔ)服務(wù)。
本文將介紹攜程如何使用 JuiceFS，以及基于 JuiceFS 實(shí)現(xiàn)的關(guān)鍵管理能力，包括多租戶權(quán)限管理、計(jì)費(fèi)功能、故障排查和監(jiān)控等方面。同時(shí)，還將分享 3 個(gè)生產(chǎn)環(huán)境中的排障案例。最后，我們對(duì)比了 JuiceFS 與極速 NAS 的性能與成本，JuiceFS 在大多數(shù)業(yè)務(wù)場(chǎng)景中能提供與極速 NAS 接近的性能，同時(shí)成本僅為極速 NAS 的十分之一。
01 JuiceFS 在攜程的應(yīng)用：從冷存到 AI 場(chǎng)景
攜程早在 2022 年就已經(jīng)開始接入 JuiceFS，當(dāng)時(shí)的主要目的是替代 GlusterFS，以提高其列表性能，服務(wù) DBA，處理偏冷的數(shù)據(jù)。此外，這種解決方案能夠與 OSS 的生命周期和運(yùn)行策略相搭配，有效地降低 DBA 處理冷數(shù)據(jù)的成本。點(diǎn)擊此處查看早期案例。
隨著 AI 應(yīng)用的需求變化，尤其是在 AI 模型訓(xùn)練過程中，存儲(chǔ)需求開始轉(zhuǎn)向大帶寬讀寫和頻繁的寫入操作，如模型的 checkpoint 保存、數(shù)據(jù)分發(fā)及存儲(chǔ)等。
AI 這個(gè)場(chǎng)景最大的痛點(diǎn)在于，攜程的訓(xùn)練和推理系統(tǒng)被分開管理，導(dǎo)致存儲(chǔ)架構(gòu)非常割裂。訓(xùn)練過程中產(chǎn)生的模型需要通過復(fù)雜的上傳和下載流程來(lái)分發(fā)到其他平臺(tái)，這個(gè)過程顯得非常低效且繁瑣。
目前的做法是，訓(xùn)練平臺(tái)和推理平臺(tái)通過 JuiceFS CSI 掛載相同的卷，但對(duì)權(quán)限進(jìn)行區(qū)分：訓(xùn)練平臺(tái)具備讀寫權(quán)限（ReadWriteMany），而推理平臺(tái)則僅具備只讀權(quán)限（ReadOnlyMany）。對(duì)于只讀負(fù)載，預(yù)讀功能可通過 JuiceFS 中的相關(guān)參數(shù)進(jìn)行調(diào)優(yōu)，以提高性能。
此外，AI 應(yīng)用面臨的另一個(gè)問題是存儲(chǔ)性能的瓶頸，尤其是在讀性能方面。AI 推理任務(wù)需要較高的帶寬，而許多存儲(chǔ)產(chǎn)品的帶寬表現(xiàn)有限。與 OSS 配合使用時(shí)，存儲(chǔ)帶寬可以根據(jù)數(shù)據(jù)量的增加而自動(dòng)擴(kuò)展。例如，OSS 為用戶提供的帶寬與數(shù)據(jù)流量成正比，數(shù)據(jù)使用量越大，分配的帶寬也越大，這種設(shè)計(jì)使得 AI 用戶在大規(guī)模數(shù)據(jù)讀取時(shí)能夠獲得所需的帶寬。
02 JuiceFS 部署架構(gòu) & 關(guān)鍵能力
我們搭建的部署架構(gòu)與社區(qū)大部分的推薦方案一致，采用了 TiKV + OSS 的組合。具體來(lái)說(shuō)，架構(gòu)由以下幾個(gè)核心組成部分構(gòu)成：
TiKV & PD 作為元數(shù)據(jù)引擎：TiKV 支持分布式架構(gòu)和事務(wù)處理，具備出色的性能。通過跨 IDC 部署，確保系統(tǒng)的高可用性。
Ali OSS 作為存儲(chǔ)底座：結(jié)合專線網(wǎng)絡(luò)提供大帶寬傳輸能力。同時(shí)，OSS 的自動(dòng)轉(zhuǎn)冷功能使得系統(tǒng)在成本控制上具有優(yōu)勢(shì)，性價(jià)比高。
JuiceFS 客戶端的定制化：對(duì) JuiceFS 客戶端 進(jìn)行了針對(duì)性修改，特別是在內(nèi)部管理功能上，例如自助服務(wù)、計(jì)費(fèi)系統(tǒng)、控制限速等。我們還進(jìn)行了優(yōu)化，以便用戶在 Kubernetes (k8s) 環(huán)境中能夠方便地使用。
關(guān)鍵能力 1：多租戶權(quán)限管理與計(jì)費(fèi)
我們要為多個(gè)用戶群體提供服務(wù)，包括 AI、DBA 等不同領(lǐng)域的用戶。為了保證資源的合理使用，我們?yōu)槊總€(gè)申請(qǐng)用戶提供了獨(dú)立的 token，用戶需使用 token 進(jìn)行掛載，以此實(shí)現(xiàn)資源的隔離。
為了控制成本，我們對(duì)用戶的使用進(jìn)行嚴(yán)格監(jiān)控和計(jì)費(fèi)。我們?cè)诿總€(gè)卷（Volume）級(jí)別進(jìn)行實(shí)時(shí)監(jiān)控，并按小時(shí)生成賬單，確保每個(gè)用戶的使用情況得到清晰記錄和計(jì)費(fèi)。
在 Kubernetes 環(huán)境中，很多用戶選擇使用動(dòng)態(tài)存儲(chǔ)類來(lái)實(shí)現(xiàn)存儲(chǔ)的自動(dòng)化調(diào)度。但為了實(shí)現(xiàn)自助申請(qǐng)并便于計(jì)費(fèi)，我們采用了靜態(tài) PVC。這種方式可以方便地關(guān)聯(lián)卷，并與自動(dòng)化流程相結(jié)合，確保每個(gè)卷的費(fèi)用被精確記錄。在 JuiceFS 中，每個(gè)卷都記錄了一個(gè)全局變量（totalUsedSpace），該變量用于追蹤與計(jì)費(fèi)相關(guān)的使用情況。
雖然社區(qū)也支持對(duì)子目錄的計(jì)費(fèi)，但對(duì)于我們初期開發(fā)而言，按卷級(jí)別計(jì)費(fèi)相對(duì)簡(jiǎn)單和高效。
計(jì)費(fèi)原理
攜程內(nèi)部使用的工具 FinOps 可以定期拉取阿里云費(fèi)用中心的數(shù)據(jù)，以獲取每個(gè)云產(chǎn)品的費(fèi)用信息。通過這個(gè)工具，我們能夠?qū)崿F(xiàn)對(duì)各項(xiàng)云服務(wù)費(fèi)用的實(shí)時(shí)監(jiān)控。
在使用這個(gè)工具時(shí)，當(dāng)申請(qǐng) JuiceFS 卷時(shí)，需要進(jìn)行關(guān)聯(lián)，卷的創(chuàng)建會(huì)與相應(yīng)的用戶關(guān)聯(lián)。為了有效管理，我們每小時(shí)都會(huì)進(jìn)行一次打點(diǎn)監(jiān)控，記錄空間使用情況、文件引用數(shù)量等指標(biāo)，并將這些數(shù)據(jù)發(fā)送到 FinOps 系統(tǒng)。然后，F(xiàn)inOps 會(huì)對(duì)每個(gè)卷進(jìn)行費(fèi)用分?jǐn)?，?OSS 的費(fèi)用按比例分?jǐn)偟矫總€(gè)卷的所有者。
費(fèi)用異常：存儲(chǔ)泄露
在日常運(yùn)營(yíng)中，主要關(guān)注的是費(fèi)用的上升情況和費(fèi)用占用的趨勢(shì)。這些費(fèi)用數(shù)據(jù)能夠反映出是否存在異常問題。在一次費(fèi)用分析中，我們遇到了一個(gè)典型問題：通過 JuiceFS 統(tǒng)計(jì)的使用量沒有明顯變化，但整個(gè) OSS 的成本卻有所上升。經(jīng)過進(jìn)一步分析，確認(rèn)阿里云的收費(fèi)政策和 OSS 單價(jià)并未變化。然而，分?jǐn)偝鋈サ膯蝺r(jià)卻上升了，導(dǎo)致了整體費(fèi)用的增加。
在檢查 JuiceFS 的計(jì)費(fèi)統(tǒng)計(jì)和阿里云 OSS 上的文件量統(tǒng)計(jì)時(shí)，我們發(fā)現(xiàn)兩者之間存在顯著的差異。OSS 提供了一個(gè)存儲(chǔ)空間清單功能，可以查看當(dāng)前整個(gè) bucket 下所有文件的使用量。我們通過使用 OSS 清單對(duì)數(shù)據(jù)進(jìn)行聚合，發(fā)現(xiàn) JuiceFS 統(tǒng)計(jì)的用量遠(yuǎn)低于 OSS 統(tǒng)計(jì)的用量。這導(dǎo)致了用戶在 JuiceFS 中的存儲(chǔ)空間使用量被低估，從而使得 OSS 存儲(chǔ)空間的費(fèi)用被錯(cuò)誤地分?jǐn)偨o其他用戶，進(jìn)而導(dǎo)致其他用戶的單價(jià)上升。
這一差異的根本原因在于 JuiceFS 刪除文件的實(shí)現(xiàn)方式。對(duì)于大量刪除的文件，JuiceFS 使用軟刪除策略標(biāo)記文件為已刪除，但后臺(tái)會(huì)逐步刪除這些數(shù)據(jù)。由于在使用過程中禁用了所有后臺(tái)任務(wù)，導(dǎo)致用戶的刪除操作產(chǎn)生了許多待處理（pending）和失敗的刪除請(qǐng)求。
進(jìn)一步分析后，我們發(fā)現(xiàn) JuiceFS 存在兩種數(shù)據(jù)泄露情況：一是待處理刪除（pending delete），二是回收站（trash）中的數(shù)據(jù)。為了應(yīng)對(duì)這一問題，我們?cè)O(shè)置了一個(gè)額外的監(jiān)控服務(wù)，每隔 6 小時(shí)掃描一次潛在的數(shù)據(jù)泄露。如果發(fā)現(xiàn)泄露數(shù)據(jù)，我們會(huì)啟用一個(gè)專門的客戶端，取消禁用后臺(tái)任務(wù)，并清理這些泄露的數(shù)據(jù)。
功能禁用
禁用回收站：回收站功能在很多用戶場(chǎng)景下并不需要開啟?；厥照臼呛笈_(tái)任務(wù)，需要額外的資源進(jìn)行清理，尤其是在使用 TiKV（如 RocksDB 數(shù)據(jù)庫(kù)）的情況下，回收站會(huì)對(duì)數(shù)據(jù)庫(kù)性能造成一定壓力，尤其在出現(xiàn)突發(fā)的大規(guī)模刪除時(shí)。因此，我們選擇不啟用回收站功能。
禁用備份元數(shù)據(jù)（BackupMeta）功能：JuiceFS 提供了元數(shù)據(jù)備份功能，但在數(shù)據(jù)量較大時(shí)，邏輯備份速度較慢，無(wú)法滿足我們的需求。為了提高備份效率，我們更傾向于使用 TiKV 提供的官方備份工具來(lái)進(jìn)行數(shù)據(jù)庫(kù)備份，這樣可以更好地支持大規(guī)模數(shù)據(jù)的備份需求。
關(guān)鍵能力 2：日志收集與管理，提高排障效率
我們使用內(nèi)部工具將 TiKV 和 PD 中的日志收集到 ClickHouse，通過 Kafka 傳輸并最終存儲(chǔ)到 ClickHouse 。
通過這樣的日志收集，我們能夠及時(shí)捕捉集群中的錯(cuò)誤信息。許多情況下，集群可能會(huì)產(chǎn)生大量的錯(cuò)誤，但用戶并未察覺，且從客戶端來(lái)看，性能似乎并未受到顯著影響。然而，經(jīng)過多次事故的處理，我們發(fā)現(xiàn)很多問題都是通過分析 TiKV 的日志來(lái)發(fā)現(xiàn)的，從而能在早期階段及時(shí)解決潛在問題。
關(guān)鍵能力 3：監(jiān)控
在監(jiān)控方面，我們挑選了 TiKV 官方提供的一些關(guān)鍵指標(biāo)來(lái)構(gòu)建自有的監(jiān)控系統(tǒng)。TiKV 和 TiDB 的整體監(jiān)控體系相對(duì)復(fù)雜，官方提供的監(jiān)控看板包含了大量信息，顯得過于繁雜。剛接手時(shí)，這一部分確實(shí)沒有很清晰的理解。
在實(shí)踐過程中，我們最終選取了幾個(gè)核心的指標(biāo)，以便更有效地監(jiān)控 TiKV 的性能：
- 性能相關(guān)指標(biāo)：包括 CPU、內(nèi)存使用情況以及熱點(diǎn)讀寫。
- PD（相關(guān)指標(biāo)：重點(diǎn)監(jiān)控 Region leader 分布與調(diào)度情況。
- GC（垃圾回收）相關(guān)指標(biāo)：包括 GC 時(shí)間和 MVCC 刪除等信息。
在 JuiceFS 客戶端的監(jiān)控中，我們通過 Prometheus 接口獲取 CSI 的指標(biāo)。然而，對(duì)于普通掛載情況，特別是在用戶自行部署 JuiceFS 的機(jī)器上，我們無(wú)法直接控制或訪問這些數(shù)據(jù)。因此，我們使用 JuiceFS 提供的 state 文件來(lái)采集簡(jiǎn)化的監(jiān)控指標(biāo)。大部分場(chǎng)景中，state 文件已經(jīng)能夠覆蓋我們需要的指標(biāo)。為了高效采集數(shù)據(jù)，我們?cè)诿颗_(tái)機(jī)器上部署了一個(gè) DaemonSet，通過該工具定期讀取 state 文件并進(jìn)行監(jiān)控。
客戶端監(jiān)控看板包括以下內(nèi)容：CPU 和內(nèi)存使用情況、啟動(dòng)時(shí)間和啟動(dòng)參數(shù)、Golang 性能指標(biāo)（如堆內(nèi)存中的活躍對(duì)象）、以及讀寫性能（包括緩沖區(qū)和塊緩存的使用情況）。除了關(guān)注客戶端的讀寫性能外，更多時(shí)候我們更側(cè)重于整體帶寬情況。
關(guān)鍵能力 4：元數(shù)據(jù)備份
在 TiKV 生態(tài)中，存在兩個(gè)不同的 br 備份工具。TiKV 文檔中提到的 br 工具只能備份通過 rawKV API 寫入的數(shù)據(jù)，無(wú)法備份通過 txnKV API 寫入的數(shù)據(jù)。
與此不同，TiDB 倉(cāng)庫(kù)中的 br 工具更側(cè)重于備份 TiDB 數(shù)據(jù)。這個(gè)工具提供了 backup txn 子命令，專門用于備份通過 txnKV API 寫入的數(shù)據(jù)。最終，我們采用了 TiDB 的全量快照備份方案，每日進(jìn)行定時(shí)備份。
在使用 TiKV 集群版本 v5.2 并直接應(yīng)用 TiDB br 工具的 master 分支代碼 時(shí)，遇到了一些問題：
- 雖然可以成功備份數(shù)據(jù)，但在恢復(fù)時(shí)出現(xiàn)了錯(cuò)誤。
- 在備份過程中，TiKV 持續(xù)嘗試執(zhí)行備份操作，且無(wú)法停止。
針對(duì)這些問題，我們將其反饋給了 TiKV 社區(qū)，并在社區(qū)的幫助下成功解決了相關(guān) bug。解決問題后，我們對(duì)備份過程進(jìn)行了優(yōu)化，通過設(shè)置備份限速為 50MB/s，使得備份過程能夠在大約 15 分鐘 內(nèi)完成。
TiKV 備份通過 trip-tikv-manager 服務(wù)進(jìn)行管理，該服務(wù)負(fù)責(zé)調(diào)度和執(zhí)行備份任務(wù)。備份數(shù)據(jù)被存儲(chǔ)在獨(dú)立的對(duì)象存儲(chǔ) 中，目前使用的是 Ceph 存儲(chǔ)系統(tǒng)。
目前，在我們的最大集群擴(kuò)展后的生產(chǎn)環(huán)境中，能夠在 20 分鐘內(nèi)完成全量備份。備份任務(wù)基本上會(huì)在每天定時(shí)執(zhí)行，并通過監(jiān)控實(shí)時(shí)查看備份狀態(tài)。由于 JuiceFS 服務(wù)全天沒有明顯低谷，我們選擇在白天對(duì) TiKV 進(jìn)行備份。
鑒于我們的系統(tǒng)部署為三中心結(jié)構(gòu)，并已對(duì) Region 實(shí)施了 Zone 級(jí)別的隔離，即便單一中心發(fā)生宕機(jī)，也不會(huì)影響到 TiKV 的可用性。因此，我們將 TiKV 的備份視作一種額外的安全措施，僅執(zhí)行快照級(jí)別的備份與恢復(fù)操作。
03 生產(chǎn)環(huán)境排障案例
案例 1：TiKV MVCC (Multi-Version Concurrency Control) 堆積
這個(gè)問題是在去年 9 月被發(fā)現(xiàn)的。當(dāng)時(shí)我們發(fā)現(xiàn)，盡管 TiKV 數(shù)據(jù)庫(kù)和 JuiceFS 的整體使用量并沒有顯著增長(zhǎng)，但數(shù)據(jù)庫(kù)的磁盤空間和引擎大小卻急劇下降。奇怪的是，TiKV 的 CPU 使用率和 QPS 并未發(fā)生明顯變化。進(jìn)一步分析日志后，發(fā)現(xiàn)大量與 region 相關(guān)的報(bào)錯(cuò)，這些錯(cuò)誤是由于 MVCC（多版本并發(fā)控制） 堆積引起的。MVCC 堆積后，region 內(nèi)的舊版本數(shù)據(jù)不斷累積，導(dǎo)致 region 無(wú)法正常分割，從而阻礙了硬盤空間的及時(shí)回收。
通過深入排查并使用 tikv-ctl 工具解碼報(bào)錯(cuò)的 region 中的 key 后，我們發(fā)現(xiàn)這些 key 均來(lái)自同一個(gè) JuiceFS 卷。由于用戶頻繁更新文件，JuiceFS 中的 chunk Key 數(shù)量不斷增加，每次更新都會(huì)在 TiKV 中生成新的版本，從而迅速消耗內(nèi)存和磁盤資源。
進(jìn)一步分析我們發(fā)現(xiàn)，TiKV MVCC 堆積問題與 JuiceFS 的元數(shù)據(jù)定義和存儲(chǔ)方式密切相關(guān)。TiKV 作為支持 MVCC 的數(shù)據(jù)庫(kù)，能夠保證事務(wù)的隔離性。每當(dāng)數(shù)據(jù)被更新時(shí)，TiKV 會(huì)為每個(gè)寫入操作分配一個(gè)時(shí)間戳（TSO），從而創(chuàng)建一個(gè)新的版本，而不是直接修改原有數(shù)據(jù)。這種機(jī)制確保了事務(wù)的隔離性，并保證了讀操作可以讀取到一致的數(shù)據(jù)。
在實(shí)際應(yīng)用中，JuiceFS 會(huì)將文件切分為多個(gè) chunk，每個(gè) chunk 包含若干 slice。當(dāng)一個(gè) chunk 被頻繁更新時(shí)，TiKV 會(huì)為該 chunk 創(chuàng)建新的版本，導(dǎo)致相同 chunk key 在 TiKV 中產(chǎn)生多個(gè)版本。
頻繁更新同一 chunk 會(huì)使 TiKV 無(wú)法及時(shí)回收過期的版本，從而迅速消耗存儲(chǔ)資源，最終導(dǎo)致 MVCC 堆積。隨著這些未回收的舊版本不斷積累，TiKV 的存儲(chǔ)壓力逐漸增加，可能會(huì)導(dǎo)致性能下降，甚至引發(fā)磁盤空間不足等問題。
具體來(lái)說(shuō)，高頻更新文件導(dǎo)致以下兩方面的性能問題：
JuiceFS ：由于 chunk 記錄的 slice 數(shù)量不斷增多，JuiceFS 需要更多時(shí)間來(lái)恢復(fù)完整的文件視圖。當(dāng) slice 數(shù)量過多時(shí)，JuiceFS 會(huì)暫停寫入，并強(qiáng)制執(zhí)行數(shù)據(jù)壓縮（compaction）操作。
TiKV：頻繁寫入版本會(huì)增加 RocksDB 中存儲(chǔ)的數(shù)據(jù)量，導(dǎo)致 LSM 樹的讀性能下降，從而影響 TiKV 的整體性能。
針對(duì)上述問題，我們采取了一種更加激進(jìn)的垃圾回收（GC）策略。具體做法是設(shè)置一個(gè)獨(dú)立服務(wù)，每隔 5 分鐘通知 TiKV 的 PD 節(jié)點(diǎn)，告知它在接下來(lái)的 25 分鐘內(nèi)的數(shù)據(jù)可以被 GC 回收。這樣，TiKV 在 GC 時(shí)能夠通過 compaction 過程高效回收無(wú)用數(shù)據(jù)，減少了 GC 對(duì) CPU 的占用。同時(shí)，通過加速 TiKV 的 compaction 過程，能夠有效降低 MVCC 堆積的風(fēng)險(xiǎn)，防止版本過度堆積而導(dǎo)致的性能瓶頸。
案例 2：大量容器同時(shí)掃盤打爆 TiKV
在進(jìn)行大量容器同時(shí)掃描磁盤時(shí)，TiKV 負(fù)載超過 70%，甚至出現(xiàn)崩潰的情況。經(jīng)過排查發(fā)現(xiàn)，所有卷都是通過 CSI 形式掛載的。在使用 CSI 掛載 JuiceFS 時(shí)，會(huì)啟動(dòng)一個(gè)單獨(dú)的 Pod 并在其中掛載 JuiceFS 客戶端。由于 JuiceFS 客戶端與應(yīng)用 Pod 完全隔離，無(wú)法感知應(yīng)用中的掛載點(diǎn)操作，導(dǎo)致 TiKV 的 PD（Placement Driver）管理節(jié)點(diǎn)的利用率不斷上升。
進(jìn)一步調(diào)查后，發(fā)現(xiàn)大量 GET 請(qǐng)求，主要是文件查找操作。雖然 OSS 監(jiān)控?cái)?shù)據(jù)顯示一切正常，但 TiKV 卻持續(xù)受到來(lái)自歷史失敗請(qǐng)求的壓力，導(dǎo)致性能下降。卷中存在大量小文件和超大目錄，導(dǎo)致 TiKV 不斷處理類似“掃盤”行為的請(qǐng)求。最初我們認(rèn)為問題出在宿主機(jī)上的某些應(yīng)用，但進(jìn)一步排查后發(fā)現(xiàn)，JuiceFS 應(yīng)用的 Pod 中有一個(gè)定時(shí)任務(wù)，該任務(wù)會(huì)定期掃描目錄。多個(gè) Pod 同時(shí)對(duì)一個(gè)超大目錄進(jìn)行掃描，造成 TiKV 負(fù)載極大。
針對(duì)這一問題，采取了以下對(duì)策：
消除 updatedb 的影響：通過使用 ConfigMap 將 /etc/updatedb.conf 掛載到用戶 Pod 中，覆蓋鏡像自帶的配置，并在配置中禁止掃描 JuiceFS 掛載點(diǎn)。
限流元數(shù)據(jù)操作：為了防止用戶不經(jīng)意間的行為影響 TiKV 集群的性能，我們修改了 JuiceFS 和 TiKV 相關(guān)代碼，在元數(shù)據(jù)部分添加了限流機(jī)制，避免 TiKV 因過多文件查找請(qǐng)求而過載。
進(jìn)一步限流代碼：盡管之前對(duì) OSS 帶寬進(jìn)行了限流，但問題仍未完全解決。因此，我們進(jìn)一步添加了針對(duì)元數(shù)據(jù)操作的限流代碼，特別是針對(duì) TiKV 的元數(shù)據(jù)操作，從而緩解了 TiKV 集群服務(wù)質(zhì)量下降的問題。
案例 3：JuiceFS client OOM
在使用 JuiceFS 的過程中，AI 用戶，存在不規(guī)范的使用方式。這些用戶會(huì)在 JuiceFS 中存儲(chǔ)訓(xùn)練數(shù)據(jù)集，這些數(shù)據(jù)集可能是圖片或文檔，都是小文件，而且通常都是講大量小文件集中存儲(chǔ)在一個(gè)目錄中。某些目錄中的文件數(shù)量甚至達(dá)到數(shù)百萬(wàn)，甚至數(shù)千萬(wàn)個(gè)。當(dāng)多個(gè)應(yīng)用同時(shí)發(fā)起目錄讀取請(qǐng)求時(shí)，可能會(huì)導(dǎo)致內(nèi)存溢出（OOM）問題，尤其是在目錄中包含大量小文件時(shí)。
為了解決這一問題，我們對(duì)線上 JuiceFS 客戶端進(jìn)行了 pprof dump 分析，確認(rèn)問題出在 JuiceFS 的目錄讀取實(shí)現(xiàn)。具體而言，在 JuiceFS 中，目錄讀取是一個(gè)阻塞式操作。每次讀取目錄時(shí)，系統(tǒng)會(huì)拉取該目錄下所有文件的名稱和屬性。如果目錄中包含大量文件，這一過程會(huì)消耗大量?jī)?nèi)存。例如，對(duì)于一個(gè)包含 500 萬(wàn)個(gè)文件的目錄，單次目錄讀取請(qǐng)求會(huì)導(dǎo)致內(nèi)存占用達(dá)到 3.7GB，并且這部分內(nèi)存會(huì)被長(zhǎng)時(shí)間持有。
為了解決這一問題，團(tuán)隊(duì)將全量讀取目錄的實(shí)現(xiàn)修改為流式緩沖讀取方式，從而有效減少了內(nèi)存占用，并防止了 OOM 問題的發(fā)生。在與社區(qū)溝通并反饋該問題后，社區(qū)積極參與修復(fù)，最終成功解決了這一問題。 meta: support dir stream #5162
04 JuiceFS 的成本優(yōu)勢(shì)：十分之一極速 NAS
我們對(duì) JuiceFS 與阿里極速 NAS 的進(jìn)行了性能對(duì)比，結(jié)果顯示，在大部分讀寫場(chǎng)景下都不落于極速 NAS，甚至性能更加優(yōu)秀。
JuiceFS 具有客戶端緩存和預(yù)取功能，并且采用了 OSS 大帶寬、以及數(shù)據(jù)和元數(shù)據(jù)分離的設(shè)計(jì)，這使得它在大部分應(yīng)用場(chǎng)景中表現(xiàn)出色，尤其是在大模型推理應(yīng)用中。大模型推理應(yīng)用通常需要高帶寬的順序讀取場(chǎng)景。
通過將 JuiceFS 與 OSS 結(jié)合使用，我們實(shí)現(xiàn)了一個(gè)分布式文件系統(tǒng)方案，能夠在大多數(shù)業(yè)務(wù)場(chǎng)景中提供與極速 NAS 相同的功能和接近的性能，而成本僅為極速 NAS 的十分之一。 這一成本優(yōu)勢(shì)是 JuiceFS 方案的最大魅力之一，它能夠顯著降低我們的運(yùn)營(yíng)成本。
Q&A
Q：大模型對(duì)于存儲(chǔ)的主要需求是什么，還是只關(guān)注性價(jià)比？
A：在大模型場(chǎng)景中，我們最關(guān)心的是順序讀寫帶寬。訓(xùn)練過程涉及訓(xùn)練數(shù)據(jù)和模型的加載，以及檢查點(diǎn)（checkpoint）的寫入。推理過程則主要涉及模型的加載。盡管整個(gè)流程中涉及一些寫操作，但讀操作占主導(dǎo)，因此，我們特別重視提升讀帶寬的性能。
Q：從對(duì)象存儲(chǔ)拉取數(shù)據(jù)慢，有什么建議?
A：JuiceFS 非常適合 AI 負(fù)載場(chǎng)景，能夠提供非常高的順序讀寫帶寬。對(duì)于順序讀寫，JuiceFS 可以啟用預(yù)讀功能，提前從 OSS 拉取數(shù)據(jù)，這能有效提升性能。然而，由于 OSS 的延遲一般高于 50ms，這可能會(huì)影響隨機(jī)讀寫的性能。如果對(duì)低延遲有較高要求，NFS-Ex 和 CPFS 都能提供 1ms 以內(nèi)的 4K 隨機(jī)讀寫延遲。此外，JuiceFS 官方也提供了分布式緩存方案來(lái)降低延遲?？傮w來(lái)說(shuō)，這之間是性能與成本之間的權(quán)衡。
Q：TiKV元數(shù)據(jù)規(guī)模大概能支撐到多大的量？數(shù)據(jù)量大的場(chǎng)景，元數(shù)據(jù)是不是成為瓶頸？
A：提供一組攜程的數(shù)據(jù)供參考，我們的一臺(tái)生產(chǎn)集群，TiKV節(jié)點(diǎn)數(shù)量為 6 個(gè)，每個(gè)節(jié)點(diǎn)配置為 64 核 256 G 內(nèi)存，承載著接近 40 億個(gè)文件的負(fù)載。在這種配置下，TiKV 的 get p99 延遲仍然保持在 1.5ms 以下。實(shí)際生產(chǎn)中，元數(shù)據(jù)的延遲與 OSS 的延遲不在同一量級(jí)，因此 TiKV 并未成為瓶頸。
