亚马逊 S3 缺乏数据集抽象，存储管理问题凸显，一层解决之道待寻

亚马逊 S3 迎来 20 周年2026 年 4 月 29 日消息亚马逊 S3 最近迎来了 20 周年。自 2008 年起就有人开始使用它至今它仍是其最青睐的云存储方式具有价格低廉、可扩展性强、数据持久且能满足众多用例速度需求等优点。如今许多公司将其作为几乎所有数据的事实存储架构涵盖表格数据、非结构化日志、机器学习训练数据集、媒体文件、备份、导出数据等。数据组织与“数据集”概念S3 将数据组织到存储桶中每个存储桶可容纳几乎无限数量的对象。很多团队最终会拥有包含多种不同类型数据的大型存储桶其中存在明显属于同一类别的对象组如以 Parquet 格式存储的逻辑表、特定系统生成的日志等这些被称为“数据集”。然而S3 没有一种原生方式来表明这些对象属于同一类别。前缀承担超出预期工作通常采用命名约定通过前缀来组织相关对象即这些对象共享相同的起始路径使用“/”字符作为分隔符形成类似文件夹层次结构的形式。但 AWS 明确表示 S3 没有文件夹“/”也无特殊含义。从技术层面可行但实际应用中人们按前缀组织数据是因为查看存储桶的人需要这是理解数十亿个对象的方式。并非所有前缀作用相同不同级别的前缀有不同意义有意义的边界才是数据集其上面的前缀是组织性前缀下面的前缀是实现细节。缺乏数据集抽象的问题若 S3 不了解什么是数据集许多基本的存储管理问题会变得更复杂。查看存储桶时无法直接获取其中数据集列表及相关信息也无法将数据集作为整体进行存档、恢复或删除。前缀虽能编码一些语义信息但通常不够S3 没有合适地方在数据集级别存储元数据重要元数据往往存储在其他地方且会逐渐碎片化并失去价值。相关工具的不足数据目录在表格数据领域提供部分解决方案但需每个数据集显式注册且与物理存储层脱节未覆盖大部分数据资产也难以发现数据集的存在。AWS 托管的 Iceberg 服务 S3 Tables 对表格数据更接近解决方案但仅针对表格数据其余数据资产不受影响。安全工具解决问题的另一个方面但无法提供数据存在原因等信息。这些工具都无法完全填补空白因为 S3 未将数据集作为原生概念。结构性问题Netflix 在 S3 中管理着艾字节级别的数据通过在 Storage Lens 之上构建自定义 ETL 来汇总存储数据Pinterest 拥有近艾字节的数据在 S3 Inventory 和访问日志基础上构建内部管道跟踪数据集情况。大公司有能力在 S3 之上构建自己的层但大多数公司做不到这是一个结构性问题且同样问题也出现在 Google Cloud Storage 和 Azure Blob Storage 中。成本表象与核心问题组织应能对所有数据进行核算但现有工具不足以实现这一目标。FinOps 工具从降低成本角度出发大多在存储桶、对象或前缀级别操作几乎没有工具将数据集作为原生单元也无法附加广泛元数据。成本通常是潜在管理和治理问题的表象核心问题是数据闲置却无人能准确核算。即使数据引起注意也难以安全删除转移到 Glacier 存储只是掩盖问题。缺少的关键层似乎缺少一个能发现存储桶中有意义数据集并将其作为原生实体处理的层。该层可附加元数据与存储紧密相连基于物理布局。区分数据集和组织性前缀的结构大多已存在于数据中但还未转化为可供大家使用的层。该层确定的边界需具有持久性能处理现有存储桶和数据无需手动注册每个数据集。有人思考该问题并围绕它开展工作欢迎有类似问题或共鸣者交流。