亚马逊把数据分析做成了"聊天对话"

企业数据湖动辄PB级，但能用好它的永远是那帮会写SQL的人。亚马逊最近的一套新架构，想让业务人员直接用自然语言"聊"出分析结果。

这套方案到底在解决什么

传统数据分析的堵点很清晰：业务人员有需求，但要排队等数据团队写查询。等报表出来，决策窗口可能已经过了。

亚马逊的解法是把"智能体"（agentic AI，具备自主决策能力的人工智能系统）塞进数据分析流程。用户用日常语言提问，系统自动拆解意图、生成查询、跨结构化与非结构化数据找答案，最后可视化呈现。

整套架构跑在亚马逊云科技的标准服务上：S3存数据、SageMaker和Glue搭湖仓、Athena做无服务器SQL查询、QuickSight负责仪表盘和对话式智能体。

他们选了一个很务实的验证方式——用TPC-H数据集，这是业界标准的基准测试数据，模拟真实的订单、客户、明细业务场景。好处是任何人都能复现，不是拿私有数据做 demo。

三种数据格式，一次查询打通

技术细节上，这套方案同时支持三种存储形态：

• S3 Table：亚马逊原生的Iceberg兼容表管理，直接在S3里实现ACID事务

• Apache Iceberg：开源开放表格式，支持时间旅行、分区演进

• Parquet：列式存储，分析场景的性能基准

Athena作为无服务器查询引擎，可以跨这三种格式统一跑SQL。业务用户不需要关心数据存在哪、什么格式，自然语言提问后，背后的智能体自己决定查哪张表、怎么关联。

亚马逊特别强调"集成知识库"（integrated knowledge bases）这个概念——通过QuickSight Spaces把数据资产、业务术语、权限模型打包成可复用的知识单元。这样不同部门的用户看到的是各自语境下的"数据语义层"，而不是裸表结构。

安全与治理怎么落地

自助分析最怕的是"一放就乱"。这套架构把安全管控嵌在数据层：S3的权限、Lake Formation的细粒度访问控制、IAM的角色策略，层层往下透传。

智能体不是绕过这些管控，而是在管控框架内执行。用户能问什么问题、能看到什么数据，提前在QuickSight Spaces里配置好。查询执行时，Athena会校验最终生成的SQL是否符合行级、列级的权限策略。

这种设计思路是"民主化但不失控"——降低使用门槛，但不降低安全水位。

为什么值得关注

这不是又一个BI工具的迭代，而是数据分析交互范式的转移。从"人学机器的语言（SQL）"变成"机器理解人的语言"，中间隔着工程化落地的巨大鸿沟。

亚马逊的方案值得看的点在于：它没有造新轮子，而是用现有云服务的组合（S3+Glue+Athena+SageMaker+QuickSight）拼出完整链路。对企业来说，这意味着不需要为"自然语言分析"单独采购一套孤岛系统，而是在既有数据湖架构上叠加智能层。

当然，TPC-H是干净的标准数据集。真实企业的数据质量、口径混乱、历史包袱，才是这类方案要面对的硬仗。这套架构在复杂业务场景下的容错能力、多轮对话的上下文保持、以及生成查询的可解释性，还需要更多实战验证。

当数据分析的门槛从"会写SQL"降到"会说话"，企业的决策节奏会被怎样重塑？那些原本被排除在数据闭环之外的业务角色，又会催生出什么新的协作模式？