本文作者 Dr.Werner Vogels
亚马逊副总裁兼CTO
在re:Invent 2024大会上，我谈到了“Simplexity”这个概念——许多系统起初设计简单，但随着修复漏洞、添加功能和响应用户反馈，往往会逐渐变得复杂。在亚马逊，我们花了数十年的时间不断简化工程复杂性，确保开发者能够专注于最关键的部分：他们自己的业务逻辑。而Amazon S3正是这一理念的最佳例证。
3月14日是圆周率日，也是Amazon S3的19岁生日。我想分享一篇来自Amazon S3副总裁兼杰出工程师Andy Warfield的文章。他带我们回顾了Amazon S3如何从一个简单的对象存储服务，逐步成长为功能强大的数据系统。文章中，Andy详细展示了客户反馈如何一点一滴地塑造了Amazon S3的每个细节。这是一个关于Amazon S3如何在规模扩展到数百万亿个对象的同时，依然保持简单的精彩故事。
希望您和我一样喜欢这篇文章。
——Werner Vogels
亚马逊副总裁兼CTO
简单易用就是Amazon S3的核心优势
2006年3月14日，注定是一个值得铭记的日子。这一天，NASA的“火星勘测轨道飞行器”历经七个月的太空旅程，成功进入火星轨道；Linux内核2.6.16版本发布；而我正忙着准备一场求职面试。同一天，Amazon S3作为亚马逊云科技的首个公共的云服务正式上线。
回想那一天，不禁让人感慨时光的流转与变化：当时，我正在赶往多伦多大学参加面试。那是我博士毕业前参加的十几场大学面试中的一场，而我当时的梦想是成为一名教授。在此之前，我在英国剑桥度过了四年时光，专注于研究超级管理程序、存储和I/O虚拟化技术，这些技术后来在云计算的发展中扮演了重要角色。就在那一天，当我即将结束研究生生涯，迈向人生新阶段时，Amazon S3也迎来了第一批外部客户的数据。
2017年，我正式加入Amazon S3团队，而此时Amazon S3存储的对象数量已经突破一万亿。如今，Amazon S3在全球36个区域存储着数百万亿个对象，成为几乎所有行业和应用领域的主要存储方案。3月14是圆周率日，也是Amazon S3的19岁生日。过去二十年里，Amazon S3逐渐成长为全球最受瞩目的分布式系统之一。在为团队工作的过程中，我深刻体会到，我们开发的软件、背后的团队，以及客户对Amazon S3的期望，这三者紧密相连。从这三个方面来看，Amazon S3更像是一个不断进化的有机体，不仅持续优化自身，也在向开发者学习，不断成长。
倾听开发者的声音，并积极回应
我加入亚马逊快八年了，那时就知道Amazon S3已经被广泛用于各种应用和服务，其中很多都是我日常会用到的。那时，我就经常看到Netflix、Pinterest、SmugMug和Snowflake等公司，通过技术讨论、博客或研究论文，分享他们基于Amazon S3构建应用的经验。但我当时并没有意识到，我们的工程团队会花这么多时间与Amazon S3客户的工程师交流，了解他们如何使用Amazon S3，而这些外部开发者的反馈对我们的功能优先级影响之大，远超我的想象。
实际上，我们几乎所有的功能迭代，尤其是那些广受欢迎的更新，都是直接基于Amazon S3客户的需求而推出的。过去一年，Amazon S3推出了许多有趣的新功能，比如Amazon S3 Tables（后文会详细聊到）。但对我个人来说，甚至对整个团队而言，最让我们有成就感的其实是那些看似“基础”的功能，比如一致性优化、条件操作以及提升每个账户的存储桶上限。这些功能的意义在于，它们消除了限制，真正让Amazon S3变得更简单。
Amazon S3 Tables：
https://aws.amazon.com/blogs/aws/new-amazon-s3-tables-storage-optimized-for-analytics-workloads/
一致性优化：
https://www.allthingsdistributed.com/2021/04/s3-strong-consistency.html
条件操作：
https://aws.amazon.com/about-aws/whats-new/2024/11/amazon-s3-enforcement-conditional-write-operations-general-purpose-buckets/
提升每个账户的存储桶上限：
https://aws.amazon.com/about-aws/whats-new/2024/11/amazon-s3-up-1-million-buckets-per-aws-account/
“简单”这一理念对我们来说至关重要，而我们对它的理解，也随着近二十年来Amazon S3的构建与运营不断演进。许多人将“简单”与API本身联系起来——毕竟，作为一个基于HTTP的存储系统，它处理不可变对象，并且只有四个核心操作（PUT、GET、DELETE和LIST），乍一看似乎很简单。然而，随着开发者在Amazon S3上需求的不断变化，API也在不断演进，从这个角度来看，我不确定我们是否还能用“简单”来描述它。
事实上，我们逐渐意识到，让Amazon S3变得简单其实比我们想象的更具挑战性。
我们希望Amazon S3能让开发者专注于数据本身，而不用操心其它事情。当系统中某些功能需要开发者额外付出精力时，这种“不简单”会分散他们的注意力，并消耗大量时间。在存储服务中，这些干扰因素表现为多种形式——而Amazon S3简单性的核心特点之一就是弹性。使用Amazon S3时，您无需预先配置容量或性能，也完全不用担心空间不足的问题。
许多开发者习以为常的特性，比如弹性扩展、高耐久性和高可用性，其实背后凝聚了大量的工作。只有当这些特性变得“理所当然”时，我们才算真正成功，因为这意味着它们不再成为干扰。
当我们把Amazon S3迁移到强一致性模型时，客户的反响比我们预想的还要热烈（尽管我们原本就预期会获得相当积极的反响！）。我们知道这会很受欢迎，但在一次又一次的会议中，开发者们纷纷提到他们因此删除了代码，简化了系统。过去一年，随着我们逐步推出条件操作，客户的反应也与此前如出一辙。
作为Amazon S3团队的一名工程师，我最喜欢的一件事就是有机会了解客户构建的系统。我尤其喜欢了解那些直接在Amazon S3上构建数据库、文件系统和其它基础设施服务的初创公司，因为这些客户通常在新兴领域快速成长，他们的反馈也为我们提供了许多独特的改进思路。这些客户通常是我们新功能最积极的用户之一（当然，他们并非唯一的积极用户）。一旦Amazon S3推出新功能，他们就会迅速开始使用。
最近，我和Turbopuffer的CEO Simon Hørup Eskildsen聊了聊。Turbopuffer是一个基于Amazon S3构建的无服务器向量数据库，设计非常精妙。他提到，自己写了一个脚本，每小时跟踪并推送Amazon S3 “What’s new”博客的更新通知。我还见过其他客户，他们会猜测Amazon S3可能发布的新API，并编写脚本在后台持续探测这些API，甚至一探测就是好几年！
每当我们推出带有新REST动词的功能时，通常会设置一个仪表盘来统计相关请求的调用频率。有趣的是，团队常常会发现，在功能正式发布之前，仪表盘就开始显示流量，后来才知道这是这些客户在探测新功能的结果。
去年在re:Invent上宣布的“桶数量限制”更新，也是一个类似的例子。
虽然这个改动看起来不算大，但开发者们却非常兴奋。要知道，以前Amazon S3每个账户最多只能创建100个桶，现在想想，这个限制确实有点奇怪。我们之前一直忙着扩展对象数量和存储容量，对单个桶里的对象数量和容量完全没有限制，却从没认真想过客户是不是需要管理大量桶的情况。
不过近年来，客户开始指出这个限制是一个明显的痛点，我们也逐渐意识到人们对桶（bucket）和对象（object）的看法存在一些有趣的差异。对象更多是程序化的产物：它们通常由其它软件创建、访问，并最终被删除。而桶的数量限制却使它变得更像是一个“人性化”的概念：通常是由人通过控制台或命令行界面（CLI）创建桶，也往往是由人来跟踪组织中所有正在使用的桶。
客户告诉我们，他们很喜欢桶这种抽象概念，因为它不仅能将对象分组，还能关联安全策略等属性，方便将对象作为数据集统一管理。很多时候，客户希望用桶来与自己的客户共享数据集。他们希望桶也能通过程序化的方式来管理。
于是，我们开始着手扩展桶的数量限制。
这个例子很有趣，它说明我们的限制和痛点不仅可能让客户感到不便，而且在规模扩大后，解决起来也可能非常棘手。在Amazon S3中，桶的元数据系统与对象元数据的更大命名空间的工作方式不同。我们称这个系统为“Metabucket”，即便在单个账户最多只能创建100个桶的限制下，它也已经为应对规模扩展进行了多次重写。
为了支持客户在每个账户下创建数百万个桶的需求，显然需要对Metabucket进行进一步的扩展。
不过，在解决这一规模的问题时，还有一些更微妙的方面需要考虑：我们需要仔细评估桶名称数量增加带来的影响、程序化创建桶对应用设计的安全性影响，甚至涉及性能和用户界面（UI）的优化。举个有趣的例子，在亚马逊云科技控制台的很多地方，其它服务会弹出一个窗口小工具，帮助客户查看和管理他们的Amazon S3存储桶。比如Athena就会通过这种方式让您指定查询结果的存储位置。这个小工具有多种形式，具体取决于使用场景。它会先列出账户中的所有存储桶，然后通常会调用HeadBucket来收集每个存储桶的额外元数据。当团队开始研究如何扩展时，他们创建了一个包含大量存储桶的测试账户，并开始在亚马逊云科技控制台中测试渲染时间。
结果发现，在某些情况下，渲染Amazon S3存储桶列表可能需要几十分钟才能完成。在研究存储桶扩展的用户体验时，我们与数十个服务合作，共同解决了这个问题。
我们还推出了新的ListBuckets API的分页版本，并将存储桶数量限制在1万个以内。如果客户需要更多资源，可以主动选择更高的限制。这样一来，我们就避免了控制台渲染中出现的类似问题。即使在功能上线后，团队也仔细跟踪了客户对ListBuckets调用的使用情况，以便在发现新限制可能带来意外影响时，主动联系客户。
性能至关重要
多年来，Amazon S3从最初主要用于通过较慢的网络链接存储归档数据，逐步发展为更强大的存储服务。随着Amazon S3能力的提升，客户自然希望用他们的数据做更多事情。这形成了一个有趣的飞轮效应：性能的提升推动了客户对更高性能的需求，而任何限制都可能成为干扰开发者专注核心工作的绊脚石。
在性能方面，我们的思路与容量管理的理念一致：它必须实现完全弹性。我们决定，只要不影响其他用户，任何客户都可以充分利用Amazon S3的全部性能。
这推动我们朝着两个重要方向努力：
提前规划，帮助客户充分挖掘数据性能，省去复杂的配置步骤。
构建精密的自动化机制和保护措施，让客户在尽可能提升性能的同时，也能与其他用户和谐共存。
我们首先从Amazon S3的透明化设计入手，详细记录了请求并行化、重试策略等关键细节，并将这些优秀实践集成到通用运行时（CRT）库中。如今，我们看到单个GPU实例通过CRT实现了每秒数百吉比特（Gb）的数据吞吐量，数据在Amazon S3中高效流动。
起初，我们主要关注吞吐量优化，但客户对数据访问速度的需求也在不断增长。
为此，我们在2023年推出了Amazon S3 Express One Zone，这是Amazon S3首个基于SSD的存储类别，采用单可用区架构，尽可能降低访问延迟。对性能的需求一直在持续攀升——比如我们的机器学习客户Anthropic，现在已经能做到每秒处理数十TB数据，而娱乐公司则直接通过Amazon S3流式传输媒体内容。
在我看来，随着客户将Amazon S3的使用体验更深度地整合到他们的应用中，并希望我们为更多实时交互的场景提供支持，这一趋势很可能会进一步加速。这其实是一个很好的例子：通过解决性能瓶颈，开发者可以更专注于构建创新，而不是花时间处理各种棘手的难题。
简单和速度之间的平衡
过去二十年间，对简单的追求不断推动我们探索许多有趣的方向。就像我之前提到的所有例子，从扩展存储桶限制到提升性能，再到其它数不清的功能优化，特别是跨区域复制、对象锁定和版本控制等功能，都为数据保护和持久性提供了非常可靠的保障。回顾Amazon S3的发展历程，很容易列出一长串功能升级，并逐一说明它们如何让用户更轻松地管理对象。
但现在，我想对“简单”做一点自我反思：在我提到的几乎所有例子中，我们对简单性的改进，实际上都是针对最初的功能，而这些功能在推出时并不够简单。换句话说，我们推出的很多功能，往往随着时间的推移需要变得更简单。有些问题我们一开始就意识到了，而有些则是后来才发现的。
我想在这里强调的是，简单和速度之间其实存在着一种非常重要的平衡，而且这种平衡是双向的。
一方面，追求简单有点像“追逐完美”，因为您永远无法做到尽善尽美，这样就有可能陷入过度设计和反复推敲的困境，最终什么都无法发布。
但另一方面，急于发布一个存在明显缺陷的产品，可能会让早期用户感到失望，更糟糕的是，这可能会让您陷入一种境地，后续需要花费更高的成本来简化它。
在Amazon S3的发展过程中，简单与速度之间的平衡常常引发激烈的产品讨论。不过，我认为团队在处理这种平衡时表现得非常有策略性。不过，当您把注意力集中在这个问题上时，您永远不会感到满意，因为您总是会觉得自己要么行动太慢，要么标准不够高。对我而言，这种矛盾完美体现了我们在每一次产品发布时所感受到的焦虑。
Amazon S3 Tables：
一切皆对象，但对象并非万能
十多年来，人们一直在Amazon S3中存储表格数据。2013年，Apache Parquet格式横空出世，专门为高效存储表格数据而设计。如今，它已成为Amazon S3中各类数据集的实际标准，并为数百万数据湖奠定了基础。Amazon S3存储着EB级的Parquet数据，每天处理数百PB的Parquet数据请求。随着时间的推移，Parquet不断发展，逐渐支持了Apache Hadoop、Spark等主流分析工具，并与Hive集成，使得大量Parquet文件能够合并成一个单一表格。
然而，随着Parquet的普及，以及越来越多的分析工作转向基于Parquet的表格，它的局限性也逐渐暴露出来。开发者们喜欢用Parquet构建数据湖，但他们渴望一种更强大的表格抽象：支持更精细的操作，比如插入或更新单行数据，或者通过添加、删除列来调整表结构。遗憾的是，在不可变的对象存储上，实现这些功能并不容易。2017年，Apache Iceberg项目正式启动，目标是构建一个比Parquet更强大的表格抽象层。
对象存储的特点是简单且不可变，但表格却完全不同。为此，Iceberg引入了一个元数据层，并设计了一种创新的数据组织方式，让表格能够基于Amazon S3对象构建。Iceberg通过一系列快照来表示表格的更新，每个快照都记录了从上一版本以来的所有变更。这种方式不仅让小的更新无需重写整个表格，还为表格提供了版本管理能力。用户可以轻松在时间轴上回溯或前进，查看历史状态，而这些快照也支持数据库所需的事务性变更，能够自动更新多个条目。
Iceberg和其它类似的开放表格格式，本质上是一种独立的存储系统。然而，它们的结构是外部化的，客户代码需要管理Iceberg数据与元数据对象之间的关系，并负责垃圾回收等任务。这种设计虽然灵活，但也带来了一些挑战。
首先，基于快照的小更新容易产生大量碎片，影响表格性能。因此，需要通过压缩和垃圾回收来清理这些碎片、回收已删除的空间，从而提升性能。
其次，这些表格实际上由成千上万的对象组成，而且访问模式高度依赖于具体的应用程序。因此，许多现有的Amazon S3功能，比如智能分层和跨区域复制，在Iceberg表格上无法完全按预期工作。
当我们与那些在Iceberg上运行大规模（通常是多PB级别）数据库的客户交流时，他们对表数据类型（而非对象数据类型）提供的更丰富交互功能感到兴奋，但也分享了一些挑战和从中获得的经验。
由于Iceberg依赖客户代码来处理压缩、垃圾回收和分层等任务（这些通常是对象存储系统内部管理的内容），许多用户感到颇为头疼。这些经验丰富的Iceberg用户非常直白地告诉我们，使用Iceberg时，他们其实是在Amazon S3对象之上重新搭建了一套表格的基础功能。他们问我们，为什么Amazon S3不能承担更多工作，让这个过程变得更简单？正是这些反馈让我们开始认真思考，如何在Amazon S3中实现一个真正的表格抽象功能，最终促成了Amazon S3 Tables的发布。
但表格功能的开发并不仅仅是为了在Amazon S3上做一个“托管版Iceberg”。
表格是Amazon S3上非常常见的数据类型，和视频、图片或PDF不同，表格涉及复杂的跨对象结构，需要支持条件操作、后台维护，还要与其它存储功能无缝集成。所以，在决定推出Amazon S3 Tables时，我们对Iceberg作为开放表格格式（OTF）的能力非常认可，尤其是它能在Amazon S3上实现表格抽象。
但我们希望将这种抽象功能做得更彻底，让它像Amazon S3中的对象一样，成为Amazon S3的核心功能之一。在re:Invent 2024大会上发布的Amazon S3 Tables，从多个方面将Iceberg与Amazon S3深度融合：首先，每个表格都有自己的独立访问端点，从权限管理的角度来看，它就是一个独立的资源。这样一来，用户可以直接对表格本身设置权限策略，而不需要去管理它背后的每一个对象，访问控制和共享变得简单多了。
接下来，我们开发了一些API，让创建表格和提交快照的操作变得更简单。同时，通过研究Iceberg如何组织数据对象，我们在底层做了一些性能优化，显著提升了整体运行效率。
在这个过程中，我们一直在“简单”和“速度”之间寻找平衡。来自内部和预览客户的反馈显示，Amazon S3 Tables比用户自己管理的Iceberg更高效。但我们也意识到，还有很多地方可以继续简化和优化。在Amazon S3 Tables发布后的14周里，我们看到了许多进展：例如，Amazon S3 Tables已经全面支持Iceberg REST Catalog（IRC）API，用户可以直接在控制台中查询数据。这还只是开始，我们还有很多工作要做。
一直以来，我们都把Amazon S3定位为一个对象存储，重点强调它的核心特性——安全性、弹性、可用性、持久性和性能。这些特性也是我们通过对象API努力实现的目标。但通过开发Tables，我们发现了一个有趣的现象：真正定义Amazon S3的，其实是这些存储特性，而不仅仅是对象API本身。
用户的反馈也印证了这一点：他们觉得Amazon S3 Tables的设计非常直观，用他们的话说：“Amazon S3为对象提供的一切，现在也为表格提供了。”我们需要确保Amazon S3 Tables能够满足用户的期待。让它们像对象一样，成为简单、通用且面向开发者的基础功能。
通过不断优化Amazon S3上的表格抽象，我们希望在分析引擎和更广泛的应用数据之间架起一座桥梁。为此，我们与DuckDB展开了合作，加速了Duck对Iceberg的支持。未来，我们还会继续探索更多机会，简化开发者与表格数据之间的连接。例如，许多应用内部的数据都以表格形式存储，通常会嵌入类似SQLite的库式数据库。我们相信，当用户能够轻松在Spark等工具中直接分析数据，同时又能与自己的应用和数据获取管道无缝交互时，就说明Amazon S3 Tables真正成功了。
展望未来
随着Amazon S3即将迎来第二个十年的尾声，我深刻感受到，我们对它的理解已经发生了巨大的变化。我们的客户始终在推动我们探索更多可能性，从支持数百亿个对象的扩展，到引入诸如Amazon S3 Tables等全新数据类型。
展望未来，我满怀期待，开发者们将继续探索新方式，突破存储的极限。Amazon S3的探索之旅远未结束，我迫不及待与客户一同开启未来的无限可能。我们将始终团结一心，为您构建值得信赖的存储系统。
正如Werner常说的那句话：“现在，去创造吧！”
推荐阅读
《构建与运营：超大规模存储系统Amazon S3》
https://www.allthingsdistributed.com/2023/07/building-and-operating-a-pretty-big-storage-system.html?utm_campaign=related+posts&utm_source=simplicity+table+stakes
《创新从未止步：亚马逊云科技块存储简史》
https://www.allthingsdistributed.com/2023/07/building-and-operating-a-pretty-big-storage-system.html?utm_campaign=related+posts&utm_source=simplicity+table+stakes
《最终一致性：再审视》
https://www.allthingsdistributed.com/2008/12/eventually_consistent.html?utm_campaign=related+posts&utm_source=simplicity+table+stakes
星标不迷路，开发更极速！
关注后记得星标「亚马逊云开发者」
听说，点完下面4个按钮
就不会碰到bug了！
点击阅读原文查看博客！获得更详细内容！
扫一扫
9437
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
