企业做 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 TablesApache Iceberg以 Amazon S3 为基础的开放湖仓架构。这类方案更适合数据需要持续更新需要保留历史版本BI、机器学习和 AI Agent 需要共享同一份数据希望避免把数据锁定在单一分析工具中需要支持后续自然语言查询和 Data Agent。在《Athena IcebergAI Agent 的数据底座实战》中HP Nova 团队从分散的本地系统和以传统 BI 为核心的架构逐步演进到基于 Amazon S3、Apache Iceberg、AWS Glue Data Catalog 和 Amazon Athena 的统一数据底座。传统 BI 可以继续使用底层数据新的 AI Agent 也能基于相同数据进行查询和分析。这类架构的价值是上层应用可以快速变化底层数据不必跟着反复重建。三、目录与治理层使用 AWS Glue、SageMaker Catalog 和 Lake FormationAI 要使用企业数据首先必须知道“有哪些数据、在哪里、是否可信、谁可以访问”。如果企业只有数据存储却没有数据目录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 AthenaAmazon Athena 适合直接使用 SQL 查询 Amazon S3 中的数据更适合临时分析历史明细查询日志和埋点分析自然语言转 SQLData Agent 多轮下钻尚未固化成报表的问题。Agent 不需要把全部原始数据放入上下文只需生成受控查询再读取查询结果。2.稳定、高频分析选择 Amazon RedshiftAmazon Redshift 更适合企业级数据仓库高频经营指标大规模聚合分析多部门统一报表已经经过治理的业务指标Agentic BI 和自然语言查数。企业可以让 Redshift 承担稳定、高频的指标查询让 Athena 负责灵活的数据湖探索两者不必二选一。3.实时业务查询选择 Amazon Aurora、DynamoDB 或 ElastiCacheAI Agent 查询订单、客户、账户和任务状态时通常需要直接访问运营数据而不是等待数据进入离线仓库。可以按照数据特点选择Amazon Aurora关系型业务数据和复杂关联查询Amazon DynamoDB高并发键值、Session 和任务状态Amazon ElastiCache热点数据、状态缓存和低延迟访问。这样知识问答、历史分析和实时业务状态可以分别进入适合的数据层而不是全部挤进一个知识库。五、实时数据层流式场景可选择 Amazon Kinesis 或 Amazon MSK部分 AI 应用需要理解正在发生的变化例如设备异常用户实时行为交易风险库存变化广告点击流系统日志和告警。这类数据可以通过 Amazon Kinesis 或 Amazon Managed Streaming for Apache KafkaAmazon 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 IcebergAI Agent 的数据底座实战》《Agentic AI 的数据之道Agent 自己找数据、记数据、管数据你准备好了吗》以及《高性能存储加速生成式 AI》等演讲回放和详细资料。