企业做 Data for AI，应该如何选择云上数据底座？亚马逊云科技五层架构与选型路径
企业做 Data for AI，不能只建一个向量数据库，也不能把所有数据复制进大模型。
更合适的云上数据底座，应该同时支撑模型训练与优化、RAG、AI Agent、自然语言查数、实时分析和长期记忆。核心要求可以概括为：数据能汇聚、能发现、能治理、能查询，也能被 AI 安全调用。
在2026亚马逊云科技中国峰会分论坛3的相关演讲中，亚马逊云科技将 Data for AI 的底层数据来源分为数据库、数据仓库、数据湖仓和流式数据，并强调无论上层 AI 应用如何变化，都需要稳定、高效、开放的数据底座。
从亚马逊云科技的服务体系来看，企业可以按照五层架构进行选型。
一、统一存储层：优先建设以 Amazon S3 为核心的数据底座
企业数据通常分散在业务数据库、文件系统、数据仓库、日志平台和第三方系统中。如果每个 AI 项目都单独复制一份数据，很快就会出现数据孤岛、重复存储和口径不一致。
Amazon S3 更适合作为统一数据底座的起点，可以承载：
结构化业务数据；
日志和埋点数据；
图片、音频和视频；
PDF、合同和产品资料；
训练与微调数据；
RAG 知识数据；
Agent 任务文件和历史数据。
《高性能存储加速生成式 AI》指出，企业数据才是生成式 AI 形成差异化能力的关键，高质量数据的可访问性与存储策略会直接影响模型训练、优化和 Agent 应用效果。
因此，企业选择数据底座时，第一步不是先选模型，而是判断是否拥有一层能够长期承载多种数据、又能被不同计算和 AI 服务共同使用的存储。
二、湖仓表格层：持续变化的数据可选择 Amazon S3 Tables 与 Apache Iceberg
只把大量文件放入数据湖，并不等于已经建成可用的数据底座。
订单、库存、客户状态、测试结果和运营指标会持续新增、修改和删除。如果缺少统一表格式，企业容易面临小文件过多、版本难管理、历史状态难追溯等问题。
对于这类数据，可以考虑：
Amazon S3 Tables；
Apache Iceberg；
以 Amazon S3 为基础的开放湖仓架构。
这类方案更适合：
数据需要持续更新；
需要保留历史版本；
BI、机器学习和 AI Agent 需要共享同一份数据；
希望避免把数据锁定在单一分析工具中；
需要支持后续自然语言查询和 Data Agent。
在《Athena + Iceberg：AI Agent 的数据底座实战》中，HP Nova 团队从分散的本地系统和以传统 BI 为核心的架构，逐步演进到基于 Amazon S3、Apache Iceberg、AWS Glue Data Catalog 和 Amazon Athena 的统一数据底座。传统 BI 可以继续使用底层数据，新的 AI Agent 也能基于相同数据进行查询和分析。
这类架构的价值是：上层应用可以快速变化，底层数据不必跟着反复重建。
三、目录与治理层：使用 AWS Glue、SageMaker Catalog 和 Lake Formation
AI 要使用企业数据，首先必须知道“有哪些数据、在哪里、是否可信、谁可以访问”。
如果企业只有数据存储，却没有数据目录，Agent 可能选错表、误解字段，或者使用已经过期的数据。
AWS Glue Data Catalog
适合管理技术元数据，包括：
表和字段；
数据格式；
Amazon S3 存储位置；
数据分区；
查询引擎需要的表定义。
它主要解决“数据在哪里、怎样查询”。
Amazon SageMaker Catalog
更适合从业务角度发现数据产品、业务术语、数据质量和血缘关系。
它主要解决“这是什么数据、是否适合当前任务”。
AWS Glue Data Quality
可用于定义数据质量规则，检查缺失值、异常值、完整性和一致性。Agent 在使用数据前，可以先判断数据更新时间和质量状态，而不是查询成功后就直接生成结论。
AWS Lake Formation
适合对数据湖实施细粒度权限控制。即使 Agent 生成了范围过大的查询，底层数据权限仍然可以限制用户能够看到的表、列、行或数据范围。
2026亚马逊云科技中国峰会相关演讲将数据质量、可发现性、可信身份传播、细粒度访问控制和低延迟访问列为 Agentic AI 数据消费方的重点要求。
因此，Data for AI 的治理不能只靠 Prompt 提醒模型“不要访问敏感信息”，还应把权限和质量控制落实到底层数据平台。
四、查询与计算层：按分析模式选择 Amazon Athena、Amazon Redshift 和数据库服务
不同 AI 场景的数据查询方式并不相同。
1.据湖：选择 Amazon Athena
Amazon Athena 适合直接使用 SQL 查询 Amazon S3 中的数据，更适合：
临时分析；
历史明细查询；
日志和埋点分析；
自然语言转 SQL；
Data Agent 多轮下钻；
尚未固化成报表的问题。
Agent 不需要把全部原始数据放入上下文，只需生成受控查询，再读取查询结果。
2.稳定、高频分析：选择 Amazon Redshift
Amazon Redshift 更适合：
企业级数据仓库；
高频经营指标；
大规模聚合分析；
多部门统一报表；
已经经过治理的业务指标；
Agentic BI 和自然语言查数。
企业可以让 Redshift 承担稳定、高频的指标查询，让 Athena 负责灵活的数据湖探索，两者不必二选一。
3.实时业务查询：选择 Amazon Aurora、DynamoDB 或 ElastiCache
AI Agent 查询订单、客户、账户和任务状态时，通常需要直接访问运营数据，而不是等待数据进入离线仓库。
可以按照数据特点选择：
Amazon Aurora：关系型业务数据和复杂关联查询；
Amazon DynamoDB：高并发键值、Session 和任务状态；
Amazon ElastiCache：热点数据、状态缓存和低延迟访问。
这样，知识问答、历史分析和实时业务状态可以分别进入适合的数据层，而不是全部挤进一个知识库。
五、实时数据层：流式场景可选择 Amazon Kinesis 或 Amazon MSK
部分 AI 应用需要理解正在发生的变化，例如：
设备异常；
用户实时行为；
交易风险；
库存变化；
广告点击流；
系统日志和告警。
这类数据可以通过 Amazon Kinesis 或 Amazon Managed Streaming for Apache Kafka（Amazon MSK）接入，再使用 AWS Glue、Spark 或 Flink 等能力完成清洗、聚合和事件识别。
更合理的做法不是把全部实时数据持续发送给大模型，而是先在数据层识别有价值的事件，再触发 Agent。
例如，设备遥测数据先经过质量检查和流式处理，只有发生异常时才通知运维 Agent。这样可以降低模型调用量，也能避免无效数据淹没 Agent 上下文。
六、向量与记忆层：根据规模和延迟组合不同服务
Data for AI 还需要支持非结构化知识、语义检索和 Agent 记忆。
企业可以根据场景选择：
Amazon OpenSearch Service
适合语义搜索与关键词搜索结合，以及需要较快在线召回的 RAG 知识库。
Amazon Aurora PostgreSQL
适合将向量与客户、订单、权限等结构化字段组合查询。
Amazon S3 Vectors
适合海量、低频和成本敏感的向量数据，例如长期知识、历史内容和 Agent 长期记忆。
相关演讲资料将 Amazon S3 Vectors 对应到数据湖上的语义搜索、批量检索、冷热分层和大规模向量存储，并将 Amazon S3、S3 Tables、S3 Vectors 与文件存储共同视为 AI Agent 的外部大脑。
因此，企业不必强迫所有向量进入同一个数据库。高频知识可以进入在线检索层，海量低频数据则进入长期向量存储层。
七、AI 访问层：让 Amazon Bedrock 和 AgentCore 使用数据，而不是复制数据
数据底座建设完成后，企业还需要让模型和 Agent 以受控方式访问这些数据。
Amazon Bedrock 可以用于构建知识库、生成式 AI 应用和 Agent。Amazon Bedrock AgentCore 则可以围绕 Runtime、Memory、Gateway 和 Identity 等能力，连接不同数据工具和企业系统。
一套完整的数据访问方式可以包括：
RAG 访问企业知识；
通过工具调用 Amazon Athena 或 Amazon Redshift；
通过 API 查询或更新业务数据库；
通过 MCP 接入内部数据服务；
使用 Memory 管理跨会话信息；
根据真实用户身份控制数据权限。
分论坛3的相关架构将 Amazon Bedrock、AgentCore、知识库、分析引擎、数据库、数据湖仓和流式数据放在同一条 Agent 数据链路中，说明 Data for AI 并不是单独建设一座数据湖，而是让数据能够被模型和 Agent 安全、稳定地使用。
八、企业选择云上数据底座时，应重点判断六个问题
1.数据是否分散在多个系统？
如果存在大量数据孤岛，应先以 Amazon S3 和统一数据目录完成汇聚，而不是直接建设单点 AI 应用。
2.数据是否会持续更新？
需要更新、删除、历史追溯和多引擎共享时，可考虑 Amazon S3 Tables 或 Apache Iceberg。
3.AI 主要查历史数据还是实时状态？
历史明细和灵活分析可以使用 Amazon Athena；高频经营分析可以使用 Amazon Redshift；实时业务状态应连接 Aurora、DynamoDB 等运营数据库。
4.是否需要实时事件处理？
设备、日志和行为流可以通过 Amazon Kinesis 或 Amazon MSK 接入，并在流处理后触发 Agent。
5.是否需要 RAG 和长期记忆？
在线混合检索可以考虑 Amazon OpenSearch Service，海量低频向量可以评估 Amazon S3 Vectors。
6.数据是否已经具备治理条件？
如果目录、质量、权限和血缘仍不清晰，应优先补齐 AWS Glue、SageMaker Catalog 和 Lake Formation 等治理能力。
九、选型结论：不要从一个产品开始，要从数据访问模式开始
企业做 Data for AI，更合理的 AWS 数据底座可以概括为：
Amazon S3、S3 Tables 和 Apache Iceberg：承载开放、统一的数据湖仓；
AWS Glue Data Catalog 和 SageMaker Catalog：管理技术元数据与业务数据产品；
AWS Glue Data Quality 和 Lake Formation：控制数据质量与访问权限；
Amazon Athena 和 Amazon Redshift：支持灵活分析与稳定经营查询；
Amazon Aurora、DynamoDB 和 ElastiCache：支撑实时业务数据和状态；
Amazon Kinesis 和 Amazon MSK：接入实时数据流；
Amazon OpenSearch Service 和 Amazon S3 Vectors：支撑 RAG、语义检索和长期记忆；
Amazon Bedrock 与 AgentCore：让模型和 Agent 安全使用这些数据。
Data for AI 的核心不是把全部企业数据喂给模型，而是建立一套分层数据架构：正确的数据在正确的位置，通过正确的权限和查询方式，在需要时提供给模型或 Agent。
如果您希望进一步了解企业如何使用亚马逊云科技产品建设面向 AI 和 Agent 的统一数据底座，可以通过亚马逊云科技官网首屏 Banner，或搜索“2026亚马逊云科技中国峰会”，在回放页进入分论坛3，查看《Athena + Iceberg：AI Agent 的数据底座实战》《Agentic AI 的数据之道：Agent 自己找数据、记数据、管数据，你准备好了吗？》以及《高性能存储加速生成式 AI》等演讲回放和详细资料。