📰 概要

AWS正在革掉数据仓库的命。

2026年5月4日，QuickSight新增S3 Tables数据源，可以直接查询存储在S3中的Apache Iceberg表，无需构建传统的数据仓库中间层。

过去，这条链路是：S3存数据→ETL处理→数据仓库（如Redshift）→BI工具。三套基础设施，才能拿到一个分析结果。

现在：S3存数据→直接查询→可视化。

对AI应用开发者来说，这意味着训练数据和业务数据可以原生存在S3里，不需要搬来搬去。

🔍 解读

为什么这事值得关注？

Apache Iceberg解决了一个核心问题：数据湖里的数据如何高效查询？答案是表格式标准化——让S3上的文件像数据库表一样被查询，而不需要先把数据加载进数据库。

AWS把这条路走到了极致：直接在QuickSight里查询S3的Iceberg表，跳过Redshift，跳过Glue，跳过所有中间处理。

数据在哪，分析在哪，成本在哪——三者合一。

💎 深挖

为什么是现在

S3 Tables是AWS在2024年12月发布的。这次更新让QuickSight直接成为S3数据的查询前端，补上了最后一环。

QuickSight同时新增了"Generate Analysis"功能：用自然语言提示词自动生成仪表板。

结合S3 Tables，这意味着AI应用的数据分析可以做到：数据存在S3→自然语言查询→自动生成仪表板，全程不需要写SQL，不需要建数据管道。

对比传统方案

传统方案需要：S3存储 + ETL处理 + Redshift/数据仓库 + BI工具，四层堆叠。

S3 Tables + QuickSight：S3存储 + QuickSight直查，两层。

中间少了两套系统，维护成本、计算成本、存储成本全部下降。S3存储成本是每GB每月0.023美元，而Redshift的存储成本高出一个数量级。

对AI应用的影响

AI应用的数据层通常有两个需求：存储大量非结构化数据（S3），存储结构化业务数据（传统数据库）。

S3 Tables让结构化业务数据也能原生存储在S3上，统一管理。对于做RAG（检索增强生成）的AI应用，你的向量数据库、业务数据库、数据湖，可以全部建立在S3上。

什么情况不适合用

S3 Tables不是万能的。

如果你需要毫秒级实时分析，S3的查询延迟达不到要求。Iceberg表适合分析型工作负载（AP），不适合交易型工作负载（TP）。

对于数据量在TB级别、查询频次适中的AI应用来说，S3 Tables + QuickSight是目前性价比最高的组合之一。