S3 Files: AWS存储架构的范式转变
核心发现
🚀 重大发布: AWS正式推出S3 Files —— 将EFS (Elastic File System) 集成到S3中，允许任何现有的S3数据直接作为网络文件系统访问。这是AWS存储架构的重大演进。
背景: 数据摩擦问题
文章开篇讲述了Andy Warfield在UBC与基因组学研究人员合作的经历 —— 科学家们产生大量测序数据，但花费大量时间在数据搬运上：
- S3擅长并行性、成本和持久性
- 但所有工具都期望本地Linux文件系统
- 研究人员不断在S3和文件系统之间复制数据
- 这种"数据摩擦"在媒体娱乐、机器学习预训练、硅设计、科学计算等领域普遍存在
AI Agent放大数据摩擦
随着AI编程工具的兴起，这个问题被急剧放大：
- Agent非常擅长使用Unix工具直接在本地文件系统上操作数据
- 使用S3意味着Agent需要做更多推理：列出文件、传输到本地、然后操作
- 随着构建应用的成本急剧下降，代码/数据分离变得比以往任何时候都更有意义
S3的三层演进
1. S3 Tables (2024 re:Invent)
托管的原生表格原语，基于Apache Iceberg：
- 自动压缩
- 跨区域表复制
- 目前已有超过200万张表存储在S3 Tables中
2. S3 Vectors (2024 re:Invent)
S3原生的向量索引数据类型：
- 设计锚定在S3对象的性能、成本和持久性配置文件中
- 完全弹性：从几百条记录快速创建索引，扩展到数十亿条记录
- 特别适合存储视角的向量搜索
3. S3 Files (2026)
集成EFS到S3，允许网络文件系统访问：
- 可以在EC2 VM、容器或Lambda中挂载任何S3 bucket或前缀
- 修改会传播回S3
- 文件可以作为对象访问，对象可以作为文件访问
- 无需将数据从S3复制出来即可使用pandas、训练作业或设计工具
设计挑战
Andy承认这个功能比预期复杂：
"建造者讨厌过早决定他们的数据是放在文件系统还是对象存储中..."
文件是复杂且棘手的数据类型，与对象存储的整合比Tables或Vectors更困难。团队实际上在S3 Tables之前就开始了Files的工作。
深层含义
- 应用会来来去去，数据比任何应用都长寿 —— 这是存储系统设计的核心原则
- 随着应用开发加速，数据越容易连接和操作，我们就越能探索新方式从中受益
- S3正在从纯对象存储演变为多模态数据平台
相关标签
AWS S3 Cloud Storage AI Infrastructure Data Platform