如果你关注过去两三年涌现的新一代数据基础软件项目会发现一个惊人的共性无论是搜索引擎、向量数据库、时序数据库、OLAP、流式计算还是日志分析平台它们几乎都选择了同一个架构基底S3 对象存储。这不是巧合。先看看正在发生什么。从搜索到数据库S3 成为新一代基础软件的共同选择TurboPufferS3 原生向量搜索TurboPuffer 是第一个完全对象存储原生的向量数据库所有数据默认存储在 S3。Cursor 用它为每个代码库建立独立的 S3 namespace数千万 namespace 同时存在不活跃的几乎零成本整体降本 95%。Notion 在上面存储了 100 亿 向量节省了数百万美元。Quickwit直接在 S3 上做全文搜索Quickwit 证明了一个听起来不太可能的事情可以直接在 S3 上执行全文搜索而且速度很快。它用 Rust 基于 TantivyRust 版 Lucene构建自定义了索引格式使得关键搜索路径仅需 3 次随机 seek并通过一个 hot-start bundle 实现了 70ms 的 S3 冷启动。搜索节点完全无状态任何实例可以应答任何查询。性能数据令人印象深刻1PB/天的索引速度50PB 数据上的亚秒级搜索。相比 Elasticsearch存储成本节省 90%。Quickwit 于 2025 年初被 Datadog 收购。InfluxDB 3.0抛弃自研本地存储全面转向 S3InfluxDB 的重写是时序数据库领域最戏剧性的案例。InfluxData 彻底抛弃了自研的 TSM 存储引擎用 Rust 从头重写采用 “FDAP 栈”DataFusion Arrow Parquet Flight。数据以 Parquet 文件存储在 S3 上服务器完全无状态在 Kubernetes 中以无状态 Pod 运行。存储成本比 2.x 版本降低了 75%。ClickHouse Cloud从本地磁盘到共享对象存储经典的 ClickHouse 将数据存储在本地磁盘上每个副本维护自己的完整数据拷贝——高性能但扩缩容意味着大量数据迁移多副本也带来高昂的存储成本。ClickHouse Cloud 用全新的 SharedMergeTree 引擎彻底改变了这一点所有数据存储在共享对象存储S3上计算节点不再持有数据副本完全无状态。2025 年又构建了 Distributed Cache 层让计算节点彻底摆脱本地磁盘依赖。扩缩容变成了加减无状态 Pod不再有数据再平衡。SlateDB把 LSM-Tree 直接建在 S3 上SlateDB 是一个用 Rust 编写的云原生嵌入式 KV 存储引擎定位类似 RocksDB但从零开始为对象存储设计。它将 LSM-Tree 的全部数据——MemTable flush 出的 SST 文件、索引、元数据——直接写入 S3本地不保留任何持久化状态。通过批量写入降低 PUT 成本通过内存 block cache bloom filter 本地 SST 缓存优化读取延迟。SlateDB 为有状态流处理、Serverless 函数、持久化执行等场景提供了一个极简的构建基元嵌入你的进程数据自动持久化到 S3享受 11 nines 的持久性和无限存储容量。HydrolixS3 上的实时日志分析81 倍压缩比Hydrolix 专注于极致的压缩和查询性能所有数据存储在 S3 兼容对象存储上。它的 HDX 压缩引擎实现了 81 倍的典型压缩比398 TiB → 4.91 TiB。在 2025 年超级碗期间为 FOX 提供实时分析峰值 17.4 GB/s 摄入等效 1.4 PB/天550 亿条记录5-10 秒从数据产生到可查询。为什么在 S3 上构建下一代基础软件搜索引擎、向量数据库、时序数据库、OLAP、KV 数据库、可观测性——如此多不同品类的项目做出了同一个选择背后一定有共同的驱动力。答案藏在传统数据系统的存储架构中。本地磁盘耦合之痛传统数据系统——无论是 Kafka、Elasticsearch 还是 ClickHouse——都把数据存储在本地磁盘或挂载的块存储如 AWS EBS上。这种设计在单机时代运行良好但在云原生时代却成了沉重的包袱。计算和存储被锁死在一起。你无法单独扩展计算能力或存储容量。需要更多的查询并发你不得不增加节点每个节点又带来一份数据副本。存储快满了你要么加磁盘如果还有槽位要么加节点然后经历漫长的数据再平衡。数据副本带来巨大浪费。为了高可用传统系统通常在本地磁盘上维护 3 个数据副本。这意味着存储 1TB 的有效数据实际需要购买和管理 3TB 的磁盘空间。而这 3 份数据需要由系统自己负责同步和一致性维护——副本落后了要追赶副本不一致了要修复节点挂了要重新复制。你为存储的每一个字节付了三倍的钱同时还要承担副本管理的全部运维复杂度。节点故障恢复慢且不可预测。一个节点挂了新节点加入后需要从其他副本复制完整的数据期间服务降级甚至不可用。数据量越大恢复越慢——TB 级别的数据恢复动辄数小时。运维团队半夜被叫起来处理的那些事故根源往往就在这里。块存储贵且不够弹性云上的块存储EBS/Persistent Disk解决了部分问题——至少单块磁盘不会因为硬件故障而丢数据。但它依然昂贵而且容量需要提前规划。块存储和计算实例仍然是绑定关系——一块 EBS 只能挂载到一个 EC2 实例计算和存储依然无法独立伸缩。更尴尬的是数据冗余问题。块存储底层确实有自己的副本机制来保证单块盘的持久性但这只是存储层的实现细节并不能替代业务层对跨节点、跨可用区高可用的需求。Kafka 不会因为 EBS 底层有副本就不做 ISR 复制——它仍然需要在多个 broker 之间维护自己的数据副本来保证业务连续性。结果就是冗余被做了两遍块存储底层做了一遍业务层又做了一遍。你为冗余付了双份钱却要自己承担应用层复制的全部复杂度。先行者Snowflake 的启示这波“基于 S3 构建一切”的浪潮很大程度上源于一个项目的成功示范——Snowflake。2012 年Snowflake 的三位创始人两位来自 Oracle一位来自 Vectorwise问了一个问题“果从零开始设计一个梦想中的数据仓库它应该是什么样的”他们的答案是计算和存储必须彻底分离数据存储在 S3 上计算节点独立弹性伸缩。这在当时是一个大胆的决定。2012 年的 S3 还是一个相当“残缺”的存储——没有强一致性覆盖写后可能读到旧版本没有条件写入延迟也远高于本地磁盘。Snowflake 的做法是用精巧的工程设计绕开了 S3 的所有缺陷不可变文件写入 S3 的微分区micro-partition一旦创建就永远不修改。UPDATE 一行数据不是改原文件而是生成全新文件、在元数据中标记旧文件失效。这从根本上回避了 S3 覆盖写的一致性问题——因为根本不做覆盖写。FoundationDB 元数据层哪些文件属于哪个表的哪个版本全部由一个 ACID 事务型 KV 存储FoundationDB管理。Snowflake 从不依赖 S3 的 LIST 操作来发现文件一致性和事务保证完全在自己的元数据层解决S3 只负责可靠地存储和读取不可变文件。2015 年正式发布2020 年 IPO——这是当时最大的软件 IPO 之一。Snowflake 用商业上的巨大成功向整个行业证明了计算存储分离、以对象存储为基底不仅在技术上可行而且能创造巨大的商业价值。此后越来越多的数据基础设施项目开始沿着同一条路前进——而它们画出的架构图惊人地相似。新范式所有人都在画的同一张架构图当你研究这些新一代项目的架构时会发现它们几乎都在画同一张图核心思想极其简单计算无状态存储在 S3中间加缓存。各个系统在这个基础架构上做的差异化主要是缓存策略和写入优化——因为 S3 毕竟有两个固有特性需要适配首字节延迟较高标准 S3 约 50-100ms和按 API 调用计费PUT/GET 都有成本。写入优化的共识做法是内存缓冲 批量 Flush。不是每条消息或每个 key 都立刻写入 S3而是先在内存中缓冲积攒到一定量再作为一个大文件 flush 到 S3——全程不需要本地磁盘。SlateDB 将 MemTable 批量 flush 为 SST 写入对象存储InfluxDB 3.0 的 Ingester 在内存中缓冲后批量生成 Parquet 文件。读取优化的共识做法是多级缓存。热数据留在内存冷数据从 S3 读取。TurboPuffer 称之为“河豚效应”Pufferfish Effect——数据从 S3 的 ~500ms 膨胀到内存的 10ms越频繁访问的数据越快。ClickHouse Cloud 构建了 Distributed Cache 层将缓存从单机内存扩展为集群级共享缓存让计算节点可以完全无盘运行。对象存储经济学一个数量级的成本节省这场迁移背后最强的驱动力是一笔简单的算术。以 AWS 为例EBS gp3 块存储的单价是$0.08/GB/月。但这只是起点——传统数据系统通常需要维护 3 个数据副本来保证高可用实际存储成本变为 $0.08 × 3 $0.24/GB。再考虑到块存储需要提前规划容量、预留空间应对增长实际利用率通常只有 50% 左右有效成本进一步翻倍$0.24 ÷ 50% $0.48/GB。而 S3 标准存储的价格是$0.02/GB/月。持久性11 nines和跨可用区冗余内建在这个价格里不需要额外副本。容量按需使用不存在利用率浪费。$0.48 vs $0.02——仅存储一项差距就是 24 倍。但成本优势不止于存储单价。更深层的节省来自于架构简化无需跨 AZ 复制数据只写入 S3 一次S3 自身提供 11 nines 持久性和跨 AZ 冗余。而传统数据系统在 AWS 上的跨 AZ 复制流量往往是很大的隐性成本项。无需容量预规划S3 容量无限按需付费。不再需要为峰值预留磁盘空间不再有“磁盘快满了”的告警。无需管理数据副本计算节点无状态不存储数据。增减节点不触发数据迁移或再平衡。运维复杂度降维无状态节点意味着故障恢复就是启动一个新 Pod。没有分区再平衡没有副本追赶没有一致性修复。行业数据显示基于 S3 的架构相比传统方案可以带来一个数量级的总成本节省。代价与适用性谈谈取舍S3 架构并非没有代价。诚实地说它引入了两个需要正视的取舍。延迟标准 S3 的首字节延迟在 50-100ms远高于本地 SSD 的微秒级延迟。即使是 S3 Express One Zone也只是降到了个位数毫秒依然比本地 SSD 慢得多。这意味着如果你的核心需求是亚毫秒级延迟如高频交易、游戏后端纯 S3 架构目前还不是最优选择。但对于绝大多数场景——数据管道、日志分析、可观测性、AI 向量搜索、流式计算——亚秒级的延迟完全在业务可接受的范围内而精心设计的缓存策略还能将延迟进一步降低。TurboPuffer 的热查询 p50 仅 8msClickHouse Cloud 通过 Distributed Cache 让查询体验接近本地磁盘。各项目在延迟取舍上的选择本身也构成了一个有趣的设计空间谱。有的项目接受数百毫秒延迟换取极致简单性和低成本有的通过更复杂的多级缓存加速将延迟控制在更低水平比如 Neon 用四层缓存确保查询不直接触及 S3体验接近原生 PostgreSQL。API 成本S3 按 API 调用计费——PUT 约 $5/百万次GET 约 $0.4/百万次。如果不加优化高频小对象读写会导致 API 成本远超存储成本。所有成熟的 S3 原生系统都通过批量化来解决这个问题将多次写入合并为一次大文件上传SlateDB 的 MemTable 批量 flush、InfluxDB 3.0 的 Ingester 批量生成 Parquet将多次读取合并为一次大块 fetchQuickwit 的 hot-start bundle、TurboPuffer 的 cluster 级 batch read。基于 S3 构建的挑战需要强调的是选择 S3 作为基底确实很大程度简化了底层存储的设计与实现但是在 S3 上构建有竞争力的高性能数据系统也远比想象中困难。延迟特性、API 计费模型、一致性窗口、大小对象的性能差异——这些都需要精心设计和仔细权衡。缓冲策略怎么定、缓存层次怎么分、数据格式怎么选、故障恢复路径怎么走每一个决策都直接影响最终的成本效益和系统可靠性。更关键的是这些工程决策不能脱离具体的领域场景——搜索引擎的索引访问模式、时序数据库的写入特征、消息系统的消费模式每个领域都有自己独特的约束和取舍。S3 提供的是一个极具潜力的基础设施原语但把这个潜力转化为生产级的系统既需要扎实的工程能力也需要对领域问题的深刻理解和实战积累。S3 自身也还在进化值得关注的是S3 本身仍在持续进化每一次升级都为基于 S3 构建的系统打开新的可能性。回想 Snowflake 在 2012 年起步时S3 对覆盖写入和删除操作只提供最终一致性eventual consistency——覆盖写后可能读到旧版本删除后对象可能仍然可见LIST 操作可能遗漏刚写入的文件。Snowflake 不得不自建 FoundationDB 集群来管理元数据一致性用不可变文件设计从根本上回避覆盖写问题。Netflix 在 2014 年写了 s3mper用 DynamoDB 作为一致性校验层来弥补 S3 LIST 的不一致AWS 自己为 EMR 做了 EMRFS Consistent ViewCloudera 为 Hadoop 生态做了 S3Guard——方案如出一辙都是在 S3 前面加一层 DynamoDB 元数据来追踪文件状态。整个行业——包括 AWS 自己——都在为 S3 的一致性缺陷买单。此后S3 经历了三次关键升级2020 年Strong Read-after-Write Consistency。S3 开始对所有读取和列表操作提供 strong read-after-write consistency——写入或删除成功后任何后续的 GET 和 LIST 都保证返回最新状态。上述所有 workaround 一夜之间变得不再必要。2023 年条件写入Conditional Write。S3 引入了条件写入原语——只有在对象不存在或未被修改时才执行写入否则返回失败。这让 S3 上可以直接实现乐观并发控制许多场景下不再需要外部锁服务或共识协议。TurboPuffer 用一个 JSON 文件在 S3 上构建了分布式队列Turso 依赖 S3 条件写入实现多区域 SQLite 协调。2023 年Express One Zone。将首字节延迟从 ~100ms 降至个位数毫秒让更多对延迟敏感的场景也可以构建在对象存储之上。每一次升级都不只是性能参数的改善而是解锁了之前不可能的架构模式——read-after-write consistency 让 S3 能够作为 Source of Truth条件写入让无外部协调的分布式系统成为现实Express One Zone 让实时场景进入射程。S3 作为基础设施原语的能力边界还在持续扩展基于它能构建的系统种类和场景也在不断拓宽。写在最后回看历史存储能力的跃迁往往引发上层架构的重塑。硬盘带来了随机访问能力使得数据不再只能顺序扫描直接催生了关系型数据库和 B-tree 索引SSD 将随机读延迟从毫秒级降到微秒级IOPS 提升了几个数量级让 KV 分离WiscKey、大规模并发随机读等之前在 HDD 上不实用的设计成为现实催生了一批面向 SSD 特性优化的新型存储引擎。而从块存储到对象存储是一次更深层的变革。它改变的不仅是性能参数而是存储的基本模型——容量从有限变为无限冗余从应用层自建变为基础设施内建成本从预置付费变为按需计量。这些变化叠加在一起正在催生一代全新的无状态、弹性、低成本的数据基础设施。Snowflake 在 2012 年率先证明了这个方向的可行性和商业价值。如今数据库、搜索引擎、时序数据库、向量数据库、可观测性平台——一个又一个品类已经完成了向 S3 原生架构的转型。而 S3 自身还在持续进化让这条路越走越宽。