4 月 7 日，AWS 官方發(fā)布了一項新服務(wù)——Amazon S3 Files，允許用戶無需搬遷數(shù)據(jù)，即可將 S3 存儲桶作為高性能共享文件系統(tǒng)掛載到計算節(jié)點(diǎn)上。

這不是業(yè)界第一次嘗試讓 S3 以文件系統(tǒng)方式被訪問：從早期的 s3fs，到 AWS 后來推出的 Mountpoint for Amazon S3，再到今天的 S3 Files，S3 “像文件系統(tǒng)一樣被訪問”這條路，其實(shí)已經(jīng)走了很多年。區(qū)別在于，前兩者更多是在訪問層做文章，而這一次，AWS 終于把共享訪問、文件系統(tǒng)語義和托管高性能層真正捏成了一個原生方案。

這也讓 S3 Files 成為一個值得單獨(dú)分析的新選項。對于希望以文件方式訪問現(xiàn)有 S3 數(shù)據(jù)的業(yè)務(wù)來說，它提供了原生、輕量的方案；但放到 AI 模型訓(xùn)練、大數(shù)據(jù)分析等更復(fù)雜的場景中，它的實(shí)際表現(xiàn)究竟如何，仍需要結(jié)合其底層實(shí)現(xiàn)與運(yùn)行機(jī)制來看。

本文將圍繞 S3 Files 的底層實(shí)現(xiàn)、性能邊界以及與 JuiceFS 的差異展開分析。

01 S3 Files ：以 EFS 為高性能層的 S3 原生文件系統(tǒng)方案

從底層實(shí)現(xiàn)看，S3 Files 使用 Amazon EFS（Elastic File System）作為托管的高性能存儲層，用來承接需要低延遲訪問的數(shù)據(jù)和相關(guān)元數(shù)據(jù)，并在此基礎(chǔ)上為 S3 提供完整的文件系統(tǒng)語義，包括一致性、文件鎖和 POSIX 權(quán)限。

可以把它理解為：AWS 在對象存儲之上增加了一層基于 EFS 的文件系統(tǒng)訪問面，使原本只能通過對象接口訪問的數(shù)據(jù)，也能以目錄、文件和掛載點(diǎn)的形式被計算節(jié)點(diǎn)直接使用；而文件系統(tǒng)與 S3 之間的數(shù)據(jù)變化，則由服務(wù)在后臺自動同步。

基于這種架構(gòu)，S3 Files 并不會搬遷全量數(shù)據(jù)，而是只將當(dāng)前工作集中的一部分?jǐn)?shù)據(jù)按需放到高性能層中；而數(shù)據(jù)的“Source of Truth”依然保留在 S3 中。

02 S3 Files 如何工作：掛載、導(dǎo)入與同步機(jī)制

對 S3 Files 來說，掛載只是開始，真正影響體驗的是掛載之后的數(shù)據(jù)路徑：作用域如何確定，首次訪問會導(dǎo)入什么，哪些請求會進(jìn)入高性能層，寫入后又會如何同步回 S3。這些機(jī)制，也直接決定了后文要討論的性能邊界與成本結(jié)構(gòu)。

以 EC2 掛載現(xiàn)有 S3 bucket 為例，真正需要看清的不是掛載命令本身，而是掛載之后數(shù)據(jù)會如何被導(dǎo)入、訪問與同步。下面是幾個關(guān)鍵的技術(shù)細(xì)節(jié)與步驟。

a) 先確定作用域：導(dǎo)入全量 S3 桶，還是指定部分目錄

兩者皆可。 S3 Files 支持將整個 S3 存儲桶作為文件系統(tǒng)掛載，也支持通過 Prefix（前綴） 限制作用域，

例如只掛載 s3://my-bucket/data/ml/ 目錄下。對于包含數(shù)千萬個對象的龐大 S3 桶尤為重要，因為過大的作用域會增加元數(shù)據(jù)同步的負(fù)擔(dān)。

在計算節(jié)點(diǎn)上使用 S3 Files 時，AWS 提供了定制的掛載客戶端 amazon-efs-utils。掛載時使用的并不是存儲桶名稱，而是 AWS 為 S3 Files 分配的 file system ID。

創(chuàng)建一個本地掛載目錄，并使用專用的 s3files 文件系統(tǒng)類型進(jìn)行掛載：

sudo yum -y install amazon-efs-utils
sudo mkdir /mnt/s3files
sudo mount -t s3files fs-1234567890abcdef0:/ /mnt/s3files

如果只希望訪問某個子目錄，也可以在掛載路徑中進(jìn)一步指定。但從實(shí)踐上看，更推薦在創(chuàng)建 S3 Files 時就把作用域限定到明確的 prefix，而不是在一個過大的存儲桶上再做后置控制。

b) 首次訪問時會發(fā)生什么：導(dǎo)入觸發(fā)方式與大小閾值

S3 Files 并不會在掛載后立即把整個數(shù)據(jù)集搬入高性能層。它的數(shù)據(jù)導(dǎo)入由訪問事件觸發(fā)，默認(rèn)模式是 ON_DIRECTORY_FIRST_ACCESS：當(dāng)你第一次訪問某個目錄時，系統(tǒng)會導(dǎo)入該目錄下文件的元數(shù)據(jù)，并將符合條件的小文件數(shù)據(jù)異步導(dǎo)入 EFS 高性能層。

如果配置為 ON_FILE_ACCESS，則首次遍歷目錄時只導(dǎo)入元數(shù)據(jù)，只有在文件第一次被實(shí)際讀取時，數(shù)據(jù)才會進(jìn)入高性能層。這種方式更節(jié)省空間和導(dǎo)入成本，但首讀延遲也會更高。

這里最關(guān)鍵的控制參數(shù)是 sizeLessThan。默認(rèn)情況下，只有小于 128 KB 的文件才會在導(dǎo)入時進(jìn)入高性能層；更大的文件通常只導(dǎo)入元數(shù)據(jù)，內(nèi)容仍然主要通過 S3 獲取。換句話說，S3 Files 優(yōu)先優(yōu)化的是小文件和低延遲訪問，而不是把所有數(shù)據(jù)都預(yù)熱到高性能層中。對于 AI 訓(xùn)練這類以 10 MB 級圖片、音視頻文件為主的數(shù)據(jù)集來說，這一點(diǎn)尤其關(guān)鍵：即使完成了目錄遍歷，這些大文件在默認(rèn)配置下也未必會真正進(jìn)入高性能層。

c) 同步周期與沖突解決機(jī)制

S3 Files 會在后臺自動維護(hù)文件系統(tǒng)與 S3 之間的雙向同步。S3 側(cè)發(fā)生變化后，文件系統(tǒng)視圖會隨之更新；而在計算節(jié)點(diǎn)上的寫入，則會先落到 EFS 高性能層，再由后臺批量同步回 S3。默認(rèn)情況下，系統(tǒng)會對修改進(jìn)行一段時間的聚合，再執(zhí)行回寫。

沖突處理的原則也很明確：S3 始終是 Source of Truth。 如果文件系統(tǒng)側(cè)的修改尚未同步回 S3，而對應(yīng)對象已經(jīng)在 S3 中被其他應(yīng)用更新，系統(tǒng)會以 S3 中的最新版本為準(zhǔn)，并將沖突文件移入 .s3files-lost+found-* 目錄。

03 S3 Files 的性能邊界與成本結(jié)構(gòu)

上一節(jié)解釋的是 S3 Files 如何運(yùn)行，這一節(jié)進(jìn)一步討論的，則是這種運(yùn)行方式會帶來怎樣的性能邊界與成本結(jié)構(gòu)。高性能層占用、大文件讀取路徑、寫入流轉(zhuǎn)，以及局部更新和目錄操作帶來的放大效應(yīng)，是實(shí)際選型中最需要重點(diǎn)考量的四個方面。

a) EFS 高性能層的占用、回收與成本

S3 Files 的高性能層并不是按容量上限做 LRU 淘汰，而是按訪問時間進(jìn)行生命周期管理。 默認(rèn)情況下，已同步到 S3 且 30 天未被讀取的數(shù)據(jù)會從 EFS 高性能層中移除；這一時間由 daysAfterLastAccess 控制，可配置范圍為 1–365 天。

這意味著，它的成本取決于有多少數(shù)據(jù)需要駐留在 EFS 中，以及駐留多久。 如果工作集很大且長期保持活躍，相關(guān)費(fèi)用就會持續(xù)上升。

b) 大文件直讀與隨機(jī)讀：其實(shí)是客戶端在“穿透”讀取

S3 Files 對大文件的處理，并不是把所有讀取都留在 EFS 高性能層中完成。默認(rèn)情況下，sizeLessThan 的值為 128 KB，它決定的是哪些文件會在導(dǎo)入時把數(shù)據(jù)放入高性能層；而對于已經(jīng)同步到 S3 的數(shù)據(jù)，128 KB 及以上的讀取會直接從 S3 流式返回。

也就是說，S3 Files 的優(yōu)化重點(diǎn)更偏向小文件和低延遲訪問，而不是讓大文件讀取長期穩(wěn)定命中高性能層。

這條直讀路徑依賴于計算資源本身具備讀取源存儲桶的權(quán)限。AWS 官方文檔明確要求相關(guān)角色擁有 s3:GetObject 和 s3:GetObjectVersion 等權(quán)限；否則，客戶端就無法直接從 S3 讀取數(shù)據(jù)。

c) 順序?qū)懙拇鷥r：大規(guī)模寫入會引入額外流轉(zhuǎn)成本

S3 Files 的寫路徑并不是直接落到 S3。所有寫操作都會先進(jìn)入 EFS 高性能層，再由后臺同步回 S3。

這意味著，如果你的場景會持續(xù)產(chǎn)生大量結(jié)果數(shù)據(jù)，例如順序?qū)懭霐?shù)百 TB 的訓(xùn)練產(chǎn)物或分析結(jié)果，那么這些數(shù)據(jù)在流經(jīng) S3 Files 時，會額外引入兩類成本：

• 數(shù)據(jù)流轉(zhuǎn)成本：寫入先進(jìn)入高性能層，隨后再同步回 S3。相比直接寫入 S3，這條路徑會多出一層中間流轉(zhuǎn)開銷。
• 短期駐留成本：數(shù)據(jù)同步完成后，并不會立刻從高性能層中移除，而是要等到滿足過期條件后才會清理。默認(rèn)情況下，這意味著大批量寫入產(chǎn)生的臨時數(shù)據(jù)，可能在一段時間內(nèi)持續(xù)占用 EFS 容量。

以某一區(qū)域當(dāng)前價格為例，寫入 EFS 約為 0.03/GB，僅數(shù)據(jù)流轉(zhuǎn)這一層，每 1 TB 寫入就大約會多出 $90 的附加成本。如果這些數(shù)據(jù)在同步完成后仍然繼續(xù)駐留在 EFS 中，還會進(jìn)一步產(chǎn)生對應(yīng)的高性能層存儲費(fèi)用。

這也是為什么，S3 Files 更適合讀取現(xiàn)有數(shù)據(jù)，而不適合長期承接大規(guī)模、持續(xù)性的結(jié)果寫入。

d) 局部更新與目錄操作：對象模型帶來的放大效應(yīng)

S3 Files 底層不對數(shù)據(jù)進(jìn)行切塊，而是盡量保持文件與 S3 對象之間的直接映射。這帶來的代價是：一旦涉及大文件的局部隨機(jī)寫或追加寫，應(yīng)用層看起來只是一次很小的更新，底層同步回 S3 時卻更容易放大為顯著的對象寫入與版本開銷。

例如，用戶通過 S3 Files 在一個 100 GB 的 lmdb 文件中追加了一條 100 KB 的圖片 key，應(yīng)用側(cè)看到的只是一次很小的寫入；但這類修改并不會立刻回寫到 S3，而是會在大約 60 秒內(nèi)先做聚合，再同步回存儲桶。它不會像塊存儲那樣只改動一個離散塊，而更可能放大為對象寫入、同步時延和版本存儲成本。 文件越大、修改越頻繁，這種代價就越值得警惕。

目錄重命名同樣受 S3 扁平命名空間限制。S3 本身沒有傳統(tǒng)文件系統(tǒng)中的目錄元數(shù)據(jù)，因此執(zhí)行 rename 或 mv 時，S3 Files 不能只改一條元數(shù)據(jù)，而是必須在 S3 側(cè)為目錄中的每個文件寫入新對象并刪除舊對象。對于擁有千萬級對象的目錄，這會顯著拉長同步時間，并增加 S3 請求成本；在同步完成前，文件系統(tǒng)視圖與 S3 視圖之間還可能暫時不完全一致。

總體來看，S3 Files 的優(yōu)勢在于原生接入、零數(shù)據(jù)遷移，以及對現(xiàn)有 S3 資產(chǎn)的良好兼容。它的代價則在于：一旦場景轉(zhuǎn)向大文件讀取、持續(xù)寫入、頻繁局部更新或大目錄操作，性能和成本都會更快被放大。也正因為如此，S3 Files 的優(yōu)勢更適合發(fā)揮在輕量共享訪問場景中；而在訓(xùn)練、數(shù)據(jù)生產(chǎn)和大規(guī)模分析等重負(fù)載場景下，它的代價往往會更早暴露出來。

04 JuiceFS vs S3 Files：兩種不同的架構(gòu)思路

前一節(jié)已經(jīng)看到，S3 Files 的很多邊界并非偶然，而是這類方案的共性結(jié)果。無論是早期的 s3fs、主打高吞吐讀取的 Mountpoint for Amazon S3，還是今天的 S3 Files，它們都盡量保持文件與 S3 對象之間的直接映射，以換取對現(xiàn)有 S3 數(shù)據(jù)的透明訪問能力。

這條路線的優(yōu)勢是透明和低改造，代價則是先天受制于 S3 的對象模型。 這也是為什么目錄操作更容易退化為對象級請求，大文件的局部更新也更容易演化為寫放大、同步延遲和額外成本。

也正因為如此，JuiceFS 與這類方案的差異，并不是某個功能點(diǎn)或單項指標(biāo)的差別，而是兩條架構(gòu)路線的根本區(qū)別。JuiceFS 不是“把 S3 掛出來用”的訪問層，而是構(gòu)建在對象存儲之上的云原生分布式文件系統(tǒng)。 它采用數(shù)據(jù)與元數(shù)據(jù)解耦的架構(gòu)：文件數(shù)據(jù)存放在底層對象存儲中，元數(shù)據(jù)則由高性能鍵值數(shù)據(jù)庫獨(dú)立管理，因此更適合承接訓(xùn)練、分析和數(shù)據(jù)生產(chǎn)等更重的生產(chǎn)型負(fù)載。

為了讓大家能更直觀地進(jìn)行架構(gòu)選型，我們從底層架構(gòu)到高階特性，將 JuiceFS 與 S3 Files 進(jìn)行了全方位對比：

05 小結(jié)

沒有絕對完美的銀彈，只有最適合特定場景的方案。

S3 Files 的面世，填補(bǔ)了 AWS 官方生態(tài)中“無縫、免搬遷將 S3 原生轉(zhuǎn)換為文件系統(tǒng)”的空白。它的設(shè)計非常明顯：S3 對象生態(tài)的 100% 格式透明，并針對性優(yōu)化 AI 場景的小文件（<128KB）的讀寫性能。

什么時候選擇 S3 Files？

如果核心訴求是在不改動現(xiàn)有架構(gòu)的前提下，讓舊應(yīng)用、Shell 腳本或傳統(tǒng)軟件直接以文件方式訪問現(xiàn)有 S3 數(shù)據(jù)；或者需要一個通用的共享文件空間，且以只讀、小文件、順序讀寫為主，那么 S3 Files 會是更自然的選擇。它的原生托管、即插即用和零數(shù)據(jù)遷移能力，可以顯著降低接入門檻（但是為了這個便利性可能需要付出高昂的 EFS 存儲和同步成本來交換）。

什么時候選擇 JuiceFS？

如果業(yè)務(wù)面向 AI 模型訓(xùn)練、數(shù)據(jù)生產(chǎn)、高性能計算（HPC）或大數(shù)據(jù)分析，面臨千萬級小文件、TB 級大文件隨機(jī)讀寫，或?qū)?mmap、緩存命中率和整體吞吐有更高要求，那么 JuiceFS 會更適合。相比 S3 Files，JuiceFS 的數(shù)據(jù)切塊、獨(dú)立元數(shù)據(jù)引擎和更靈活的緩存體系，更適合承接重負(fù)載和長期運(yùn)行的生產(chǎn)型和 AI 訓(xùn)推文件系統(tǒng)場景。

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