中文精炼导读
核心观点
- AWS 推出 S3 Files：可以把任意 S3 bucket 或前缀挂载进 EC2 VM、容器或 Lambda 函数的文件系统，通过文件接口读写数据，改动自动同步回 S3——"把对象当文件用、把文件当对象用"。
- 问题源于"数据摩擦"（data friction）：作者 Andy Warfield 在 UBC 与向日葵基因组研究者合作时发现，S3 在并行、成本与持久性上优秀，但研究者手里的工具（GATK4、Linux 文件系统、NFS）全都期待本地文件系统——数据不得不反复复制、维护多个不一致的副本；这种摩擦在媒体、ML 预训练、芯片设计、科学计算中无处不在。
- agentic 工具放大了数据摩擦：编码 agent 习惯用丰富的 Unix 工具直接操作本地文件，若数据在 S3，就迫使 agent"深入推理"——主动列文件、转到本地、再在本地副本上操作；原生支持文件让数据立刻更易访问、更有价值。
- 团队曾想"把 EFS 和 S3 放进一口大锅炖出两全其美"（早期项目代号 EFS3），但设计上每个决定都会让文件或对象某一方做出妥协，最终结论是：那不是"两全其美"，而是"最低共同标准"——文件与对象的边界本身才是要建的功能。
- 关键洞察是"分阶段访问模式"：极少数应用会同时对同一数据用文件与对象接口，常见的是多阶段流水线——于是不需要收敛两种语义，而是"同一份数据放在一处、为每种访问模式提供正确的视图"：文件视图（NFS close-to-open 一致性）+ 对象视图（S3 原子 PUT 强一致）+ 同步层。
内容精讲
文章以一段亲历故事开场：在加入 Amazon 前，Andy Warfield 在 UBC 想探索计算机系统与基因组学的交叉，加入了研究向日葵 DNA 的植物学教授 Loren Rieseberg 的实验室。向日葵比人类"滥交"得多——人类 DNA 约 30 亿碱基对、任意两人 99.9% 相同；向日葵基因组更大（约 36 亿碱基对）且个体间遗传变异高出 10 倍。基因组分析被研究者称为"突发并行"（burst parallel）计算：可以大规模并行、但单次运行时间相对短，本地硬件经常"要用的时候不够、不用的时候闲置"。他们的想法是用 S3 和无服务器计算并行跑成千上万任务，让研究者极快完成复杂分析，结束再缩回零。生物学家在 Linux 上用 GATK4（与 Spark 集成的基因组分析工具包），数据都存在共享 NFS 上。迁移到云时，团队用容器打包分析跑在 S3 上，速度、可复现性与并行性能都很好——但最大的教训在存储边界：S3 对并行、成本、持久性都很好，可他们用到的每个工具都期待本地 Linux 文件系统，于是研究者永远在复制数据、维护多个不一致的副本。
"Agent 放大数据摩擦"是文章的重要观察。作者承认 agentic 工具正在深刻改变软件开发——它们很擅长写代码，且进步快得让大家都在思考这意味着什么。真正让他兴奋的是 agentic 开发彻底改变了构建应用的成本结构：美元、时间，尤其是"写出可用代码所需技能"的成本。历史上成功应用总是结合两种脱节的技能：应用领域的专业知识（基因组学、金融、设计）和写代码的机械技能；agent 恰好揭示了写软件的门槛有多高，并突然允许拥有深层领域技能而非编码技能的人写应用。当应用被更快、更实验性、更多样地编写时，代码/数据的划分变得比以往更有意义——"应用来来去去，数据永远活得比它们久"。存储系统历来不只是安全存数据，还要帮数据与单个应用解耦；应用开发加速后，这个属性更重要——数据越容易挂接和使用，越能玩、能建、能探索。
作者先讲了 S3 Tables 这个"先例"：S3 存着 EB 级 parquet 数据、仅该格式就平均每秒超 2500 万请求；Iceberg 等开放表格式作为更富功能的表抽象兴起，但只能通过对象 API 表面化表格、仍带锐边（安全策略难管、要自己维护表维护与压缩），且大量工作专门为 Spark 驱动——而人们把数据存在 S3 正是因为想用任何工具（尤其是还不存在的工具）来工作。于是 2024 年 re:Invent 发布了 S3 Tables 作为托管的、一等公民的表原语：数据存 Iceberg 但加上保护数据完整性与持久性的护栏、压缩自动化、跨区域复制，如今已有超 200 万张表。
S3 Files 的诞生过程是一段精彩的设计史。早期想法是"把 EFS 和 S3 放进一口大锅炖一炖，得到两全其美"，项目代号 EFS3（作者庆幸没保留这个名字）。但每次坐下来设计都遇到艰难的技术挑战和取舍，每个决定里文件或对象的某种呈现都要让出一点、变得不那么好——团队成员称之为"一堆难以下咽的妥协"。团队不是第一批发现"把文件和对象收敛进单一存储系统"有多难的人。他们把资深工程师关在会议室讨论数天，激烈争论后依然没有让所有人满意的方案。2024 年圣诞前，团队改变方向：枚举所有具体的妥协点后发现，那"不是两全其美，而是最低共同标准"——两边都能想到会在意外、微妙而恼人的方式下崩溃的负载。
文件与对象的深刻边界是整篇文章的核心洞察。文件是操作系统的构造：持久存在，使用时却极其丰富——经常被用作跨线程、跨进程、跨应用通信的方式；应用 API 支持就地更新记录、追加日志、任意子区域并发读写，mmap() 等 OS 功能把文件当作可细粒度变更的共享持久数据。而对象世界把"写对象中间"几乎视为亵渎：不可变性是烧进 API 与应用的基本假设，工具会下载并校验内容哈希、用版本化保留旧副本，最显著的是围绕"整对象创建"的通知构建复杂工作流——S3 每天仅发给无服务器事件监听器的对象通知就超过 3000 亿条，跨区域复制（CRR）等系统依赖这些通知的 at-least-once 语义。团队意识到：文件交互敏捷、常变、语义丰富；对象语义相对聚焦而狭窄——这条边界才是需要关注和构建的，而不是试图隐藏它。
"Stage and Commit"是围绕边界构建的答案。还有一连串看似琐碎却致命的差异：路径分隔符——文件系统有一等公民的 "/"，S3 也有但只是"建议"，LIST 命令允许指定任意解析为分隔符的字符，甚至有客户在同一路径里嵌入多种分隔符；因为 S3 没有目录，可以存在"以斜杠结尾的对象"——看起来像目录其实是文件，团队曾一度觉得这是酷功能、称之为"filerectories"（文件目录），幸好没保留。团队最终决定"拥抱边界"：让两侧保留各自的命名约定与语义，当对象或文件无法跨边界移动时，就不移动，而是发出事件让客户监控、必要时采取行动——这是把复杂性下放到开发者，但作者认为这是对的：不在它们本已预期运行的地方造成失败、建一条接纳绝大多数路径名的边界、并提供检测与纠正机制。
性能方面，文件与对象命名空间的优化目标完全不同：文件系统有大量依赖数据的元数据访问，访问文件常要访问/更新目录记录、沿路径遍历所有目录记录，所以快速文件系统命名空间倾向把目录元数据集中在一台主机；对象命名空间完全扁平、优化高度并行的点查询与更新，S3 里单个"目录"可以有数十亿对象、被数十万客户端并行访问。采纳策略上，S3 已二十年历史，团队要的是现有客户立即可用于自己数据、而非迁移到全新事物的方案——他们不愿引入可能破坏依赖 S3 文档化对象语义的应用的新行为。最终意识到：没必要收敛文件与对象语义来解决数据孤岛问题——客户需要的是"同一份数据在一个地方，为每种访问模式提供正确视图"：文件视图提供完整 NFS close-to-open 一致性，对象视图提供完整 S3 原子 PUT 强一致，加一层同步层让它们保持连接。所有的争论（难以下咽的妥协清单、filerectories 的荒谬讨论）最终都变成了正确的东西。
阅读价值
适合存储工程师、平台架构师、ML 预训练与数据科学团队，以及所有与"数据从 S3 到本地工具之间反复搬运"作斗争的人：文章用基因组学的真实故事讲透"数据摩擦"问题，再用 S3 Files 的设计过程展示"为什么不能简单把文件与对象合二为一、边界本身才是功能"这一深刻洞见；对理解 S3 的演进哲学（文件视图 + 对象视图 + 同步层）与 agent 时代存储的重要性都有直接价值。
本文为中文精炼导读,由 AI 基于原文整理,内容与图片版权归原作者所有。原文: https://www.allthingsdistributed.com/2026/04/s3-files-and-the-changing-face-of-s3.html?utm_campaign=inbound&utm_source=rss