AWS SageMaker与S3 Tables革新
全文概览
在AI技术加速迭代的2025年,AWS Pi Day与NVIDIA GTC两大技术盛会的协同效应,揭示了云原生AI基础设施的演进方向。AWS通过推出SageMaker Unified Studio和S3 Tables,直击企业AI开发中的核心痛点:数据孤岛、复杂ETL流程与治理缺失。
SageMaker Unified Studio整合了EMR、Glue、Bedrock等服务,构建了从数据准备到模型部署的统一平台;而S3 Tables作为首个原生支持Apache Iceberg的云存储服务,将对象存储升级为具备事务一致性、模式演进能力的“表级存储”,彻底打破传统Parquet格式的局限。与此同时,AWS与NVIDIA的深度合作(如NVIDIA Blackwell平台与Project Ceiba超算),进一步强化了云与边缘的AI算力协同。这些创新不仅简化了数据到AI的工作流,更通过内置治理能力(如Bedrock Guardrails)与零ETL集成,为企业构建可信、敏捷的AI基础设施提供了关键基石。
阅读收获
- 掌握统一AI开发框架:理解SageMaker如何整合数据湖、数据仓库与生成式AI工具链,实现端到端工作流简化。
- Apache Iceberg实战价值:学习其如何解决Parquet的事务性缺陷,提升结构化数据管理效率。
- AI治理落地策略:通过SageMaker Catalog与Bedrock Guardrails,构建可信模型开发与部署的合规框架。
- 多云数据战略规划:基于S3 Tables的开放架构,设计跨云环境下的数据访问与分析策略。
AWS Pi Day Innovation: Amazon SageMaker and S3
By Rob Strechay[1]| March 24, 2025
摘要:随着GTC和AWS PI Day的落幕,我们回顾了Amazon SageMaker和Amazon S3 Tables的创新进展,这些技术正在革新数据管理和AI开发。全新推出的Amazon SageMaker Unified Studio作为更全面的平台,提供单一环境以简化数据分析与AI工作流,并无缝集成AWS分析及AI/ML服务。与此同时,作为首个原生支持Apache Iceberg的云对象存储,Amazon S3 Tables让表格数据的存储与分析更加便捷。这些创新助力企业加速价值实现、提升协作效率,并统一跨云环境的数据访问。
AWS PI Day与GTC:Oh AI
AWS PI Day 2025(3.14)的势头延续至NVIDIA GTC 2025(3.17-3.21),双方深化了长期合作,加速生成式AI创新。PI Day聚焦通过SageMaker Unified Studio、原生支持Apache Iceberg的S3 Tables,以及零ETL集成等能力,构建统一、开放且安全的数据基础,旨在简化并加速数据到AI的工作流。这些能力为更广泛的AI加速奠定了基础,助力客户以更高敏捷性和信心构建、治理和扩展AI应用。
在GTC上,AWS与NVIDIA联合宣布了一系列扩展这一愿景的举措,包括:将Amazon SageMaker与NVIDIA NIM推理微服务集成以优化GPU性能,以及即将在Amazon EC2和DGX Cloud上推出的NVIDIA Blackwell平台。此外,AWS将为Project Ceiba(基于2万余块NVIDIA Grace Blackwell超级芯片的突破性AI超算)提供基础设施。这些进展强化了AWS云原生ML开发环境与NVIDIA高性能AI计算之间的协同效应,助力客户安全高效地构建和运行大规模下一代AI模型。
SageMaker统一:全面的数据与AI开发环境
SageMaker Unified Studio整合了Amazon EMR、AWS Glue、Amazon Athena、Amazon Redshift、Amazon Bedrock和Amazon SageMaker AI的功能,提供统一体验。用户可在受治理的环境中发现、准备和协作处理数据资产。借助基于Apache Iceberg构建的SageMaker Lakehouse,企业可通过单一界面访问多样化的数据源,包括Amazon S3数据湖、Redshift数据仓库及第三方数据库。
AI驱动型组织面临的挑战
数据是AI的命脉。随着AI重塑行业,企业面临新挑战:数据孤岛、复杂管道、不一致的访问控制等问题阻碍团队协作与AI驱动决策。AWS分析副总裁Sirish Chandrasekaran指出,融合、治理与代理是推动AI转型的三大核心主题。
- 融合:结构化与非结构化数据、数据湖与数据仓库、甚至数据分析师与数据科学家的界限正在消弭。企业亟需无缝整合多元数据源与分析工具的统一平台。
- 治理:AI治理不仅是合规问题,更是建立信任的关键。企业需确保AI模型基于可靠、受治理的数据训练,并遵循负责任的AI政策。
- 代理:企业日益寻求多代理AI应用,例如宝马公司利用AI代理进行实时根因分析,显著缩短工程师排查问题的时间。
SageMaker Unified Studio的关键增强
AWS为SageMaker Unified Studio推出两大重要更新:
- Amazon Q开发者集成:该AI助手现嵌入工作室全平台,支持用户通过自然语言发现数据、生成SQL查询、自动化ETL任务,并构建生成式AI应用。
- Amazon Bedrock集成:最新版本新增Claude 3.7 Sonnet、DeepSeek,以及来自Amazon、Meta和Anthropic的优化推理模型,实现平台内低延迟生成式AI能力。
此外,SageMaker Unified Studio现支持与超过15种数据源的零ETL集成,包括Aurora、DynamoDB、Salesforce、Redshift等,实现无需高成本ETL流程的无缝数据访问。
图1. 使用 SageMaker 加速数据分析
架构流程说明
- AWS IAM Identity Center 管理用户访问和 Amazon SageMaker Unified Studio 的单点登录 (SSO),适用于数据工程师。
- SageMaker Unified Studio 允许数据工程师和数据分析师在销售预测项目上进行协作。
- 将预测项目的销售数据集存储在由 Amazon Simple Storage Service (Amazon S3) 支持的数据湖仓架构中。使用 AWS Glue 进行数据编目,使用 Amazon Redshift Serverless 进行快速数据检索。使用 AWS Lake Formation 权限管理数据,并通过 Iceberg API 访问数据,实现 Amazon S3 和 Amazon Redshift Serverless 层之间的无缝集成。
- SageMaker Unified Studio 为数据工程师提供了一个基于 Web 的界面,允许他们对销售数据集进行必要的转换,而无需离开 SageMaker 或切换控制台。您可以使用 Amazon Q Developer 提供就地 AI 生成的代码建议。
- SageMaker 中的 Studio IDE 界面允许您利用 Amazon Athena 和 Amazon Redshift 分别进行数据探索和繁重的数据转换。您可以将销售数据集和数据转换产生的中间数据集存储在 Amazon S3 中。
- Workflows 工具使用 Amazon Managed Workflows for Apache Airflow (Amazon MWAA) 进行编排,使用 AWS Glue 进行任务执行,从而自动化数据摄取的端到端流程。SageMaker 中的 Query Editor 提供了一个 SQL 笔记本风格的界面,用于针对 Amazon Redshift 和 AWS Glue Data Catalog 中的数据源编写、运行和保存查询,允许用户上传和查看示例数据。
重新定义数据编目与治理
AWS推出SageMaker Catalog作为AI与数据堆栈的控制层。与传统数据编目不同,其特性包括:
- AI驱动的元数据生成,简化数据资产的发现与理解。
- 实时监控与合规性,确保AI模型基于受治理数据训练。
- Bedrock Guardrails,通过自动化策略执行减少生成式AI应用中的幻觉、偏见与毒性。
AWS还采用可数学验证的自动推理技术,强化AI工作流治理,类似IAM策略与S3安全机制多年的验证方式。
Amazon S3 Tables:革新数据存储与分析
Apache Iceberg在云存储中的力量
于re:Invent 2024发布的Amazon S3 Tables是首个原生支持Apache Iceberg的云对象存储。AWS称其查询吞吐量提升最高达3倍,事务处理速率提升10倍,且无需自行管理表存储。S3 Tables无缝衔接AWS分析服务(如Athena、EMR、Glue、Redshift),实现跨平台数据整合。
克服Parquet存储的局限性
多年来,Apache Parquet一直是Amazon S3存储表格数据的主导格式。尽管Parquet提供了高效存储和优化的查询性能,但它缺乏内置的表管理功能,使得模式演进、数据修改和时间旅行等任务变得更为复杂。
S3 Tables基于Parquet的优势,通过集成Apache Iceberg克服了这些挑战,提供以下功能:
- 模式演进:无需中断现有工作流即可添加或删除列。
- 事务一致性:支持ACID事务,确保可靠更新和删除操作。
- 快照与时间旅行:允许用户无需复杂ETL流程即可查询数据的历史版本。
对象存储从Parquet走向Apache Iceberg
以下表格总结了 Parquet 范式和 Apache Iceberg 范式下对象存储的理解、发展关系、主要差异和演进方向:
特征 | Parquet 范式下的对象存储 | Apache Iceberg 范式下的对象存储 |
---|---|---|
核心理解 | 将数据以 Parquet 这种列式存储格式直接存储在对象存储上。Parquet 提供了高效的数据压缩和编码,优化了分析查询的性能,尤其是在读取少量列的场景下。 | Iceberg 是一种开放的表格格式,它构建在现有的对象存储之上(通常使用 Parquet 或 ORC 等格式存储实际数据)。Iceberg 提供了一个抽象层,使得对象存储上的文件集合能够像传统数据库的表一样被管理和查询。 |
发展关系 | Parquet 是一种数据存储格式,是构建数据湖的基础组件。早期的和许多现有的数据湖方案直接使用 Parquet 文件组织数据。 | Iceberg 的出现是为了解决直接使用 Parquet 文件在数据湖中进行复杂操作时面临的挑战,例如事务性、模式演化、数据版本管理等。Iceberg 可以看作是对 Parquet 的增强和管理层。 |
主要差异 | - 数据组织:通常是基于目录和文件名的约定来组织数据分区,缺乏统一的元数据管理。- 事务性:不支持原子性的更新、删除操作。- 模式演化:模式变更通常需要重写数据文件,处理复杂。- 时间旅行:难以实现数据版本回溯。- 数据质量:缺乏内置的数据一致性和完整性保证机制。- 查询优化:依赖计算引擎发现和优化数据,缺乏细粒度的文件级别控制。 | - 数据组织:通过元数据文件集中管理表的 schema、分区、文件列表等信息,提供统一的表视图。- 事务性:支持 ACID 语义的操作,如原子提交更改、防止并发冲突。- 模式演化:支持复杂的 schema 变更,例如添加、删除、重命名列,无需重写数据文件。- 时间旅行:通过管理快照实现历史数据查询和回滚。- 数据质量:可以集成数据验证和完整性检查机制。- 查询优化:Iceberg 元数据可以帮助查询引擎更高效地进行文件过滤和数据读取。 |
演进方向 | - 更优的压缩和编码:持续探索更高效的压缩算法和编码方式以进一步减小存储空间和提升IO性能。- 更好的向量化支持:增强对向量化计算的支持,提升查询效率。- 与更多计算引擎的集成:使其能被更多的分析工具和框架高效访问。- 增强元数据管理:在文件层面提供更丰富的元数据信息,辅助查询优化。 | - 更丰富的功能:例如支持更多的 SQL 语法、更复杂的数据类型、更灵活的权限管理等。- 更广泛的生态集成:与更多的数据处理引擎、云平台、数据治理工具等深度集成。- 性能优化:持续提升元数据管理和查询性能,尤其是在大规模数据集场景下。- 标准化:推动 Iceberg 成为行业标准,促进不同平台和工具之间的互操作性。 |
Parquet 是一种优秀的文件存储格式,为数据分析提供了高效的存储和读取能力。而 Apache Iceberg 则是在 Parquet 等文件格式的基础上构建的更高层次的抽象,旨在为数据湖带来数据仓库级别的管理能力,解决了直接使用文件格式进行数据管理和分析时遇到的诸多问题。Iceberg 的发展是数据湖向湖仓一体 (Lakehouse) 架构演进的关键一步。
图1 – Apache Iceberg 架构
通过SageMaker Lakehouse实现统一数据访问
随着S3 Tables与SageMaker Lakehouse的全面集成,用户现在可以直接从SageMaker统一工作室查询S3 Tables。这实现了:
- 跨多引擎的细粒度安全访问控制。
- 将S3 Table数据与Redshift数据仓库及第三方源(如PostgreSQL和Amazon DynamoDB)进行联表查询。
- 无需复杂ETL流程即可无缝进行分析和机器学习模型开发。
让分析与存储更紧密融合
S3 Tables的推出标志着AWS数据架构的根本性转变,弥合了对象存储与结构化数据分析之间的鸿沟。AWS副总裁安迪·沃菲尔德(Andy Warfield)指出,S3 Tables将S3从传统的对象存储升级为具备结构化数据能力的“一流表存储服务”,这些能力此前仅能通过外部数据库引擎实现。
AWS针对高性能分析和可扩展数据管理对S3 Tables进行了优化,关键增强功能包括:
- 自动合并:通过减少小Parquet文件的管理开销提升查询性能。
- 支持Iceberg REST Catalog API:确保与DuckDB、Apache Spark和Polars等现代查询引擎无缝集成。
- 扩展全球可用性:通过多AWS区域部署,助力企业高效扩展工作负载。
JuiceFS vs Iceberg 元数据管理
Apache Iceberg 的元数据管理层和 JuiceFS 管理的元数据引擎在设计目标、功能特性以及所处的系统架构中存在显著的差异。以下是它们之间主要的区别:
1. 设计目标和定位:
- Apache Iceberg 元数据管理:
- 目标: 为存储在对象存储(如 AWS S3、Azure Blob Storage、GCS)上的海量数据提供类似数据库表格的抽象和管理能力,构建湖仓一体 (Data Lakehouse) 架构。
- 定位: 专注于数据湖场景下的数据组织、事务性操作、模式演化、时间旅行和查询优化等功能,使得数据湖能够支持更复杂和可靠的分析工作负载。
- JuiceFS 元数据引擎:
- 目标: 为分布式文件系统提供高性能、高可靠的元数据管理服务,使得用户能够像使用本地文件系统一样访问存储在对象存储或其他后端存储上的数据。
- 定位: 核心是提供一个符合 POSIX 语义的文件系统接口,关注文件和目录的创建、删除、重命名、权限管理等文件系统操作的性能和一致性。
2. 核心功能和特性:
特性 | Apache Iceberg 元数据管理 | JuiceFS 元数据引擎 |
---|---|---|
管理对象 | 表格(Table)、Schema、分区(Partition)、快照(Snapshot)等数据湖概念。管理的是组成逻辑表的数据文件在对象存储上的组织和状态。 | 文件(File)、目录(Directory)、权限(Permissions)、链接(Symbolic Links)等文件系统概念。管理的是文件和目录的元数据信息,例如文件名、大小、创建时间、访问权限、在后端存储上的位置等。 |
数据存储格式 | 本身不存储实际数据,而是管理指向存储在对象存储上的数据文件(通常是 Parquet 或 ORC 格式)的元数据。 | 同样不存储实际数据,而是记录文件和目录在后端存储(可以是对象存储、磁盘等)上的位置信息。 |
事务性 | 提供 ACID 语义的事务支持,例如在数据写入、删除或更新时,能够保证操作的原子性、一致性、隔离性和持久性,避免数据损坏或不一致。 | 提供文件系统操作的原子性,例如文件重命名操作是原子性的。对于企业版,可能提供更高的事务一致性保证。 |
模式演化 | 支持灵活的模式演化,例如添加、删除、重命名列,修改列类型等,而无需重写底层数据文件,通过更新元数据来实现。 | 主要关注文件和目录属性的管理,模式演化的概念不适用。 |
时间旅行 | 通过保留历史元数据快照,允许用户查询表在过去某个时间点的状态,实现数据版本回溯和审计。 | 通常不直接提供类似“时间旅行”的功能,但可以通过定期备份元数据来实现类似的效果。企业版 JuiceFS 可能提供快照功能。 |
查询优化 | 元数据包含分区信息、文件统计信息等,可以帮助查询引擎(如 Spark、Presto、Athena)进行更高效的数据过滤和读取,减少需要扫描的数据量。 | 元数据引擎的性能直接影响文件系统的整体性能,例如文件查找、目录遍历等操作的速度。部分 JuiceFS 元数据引擎支持缓存,以提升性能。 |
部署和管理 | 元数据通常存储在外部的元数据目录中,例如对象存储上的特定路径或者专用的元数据服务(如 AWS Glue Data Catalog、Apache Hive Metastore)。 | 元数据可以存储在多种后端存储中,例如 Redis、MySQL、TiKV 等。用户需要选择和配置合适的元数据引擎。 |
接口和协议 | 主要通过特定的 API 和集成方式与数据处理引擎交互,例如 Spark 的 Iceberg connector、Flink 的 Iceberg connector 等。 | 主要通过 FUSE (Filesystem in Userspace) 或 NFS 等标准文件系统协议向用户提供文件系统接口。 |
3. 总结:
Apache Iceberg 的元数据管理是为分析型数据场景设计的,专注于表格级别的抽象和管理,旨在提升数据湖的可靠性和易用性,使其能够支持更复杂的数据仓库功能。
JuiceFS 的元数据引擎是为通用文件系统场景设计的,专注于文件和目录的管理,目标是提供高性能和兼容 POSIX 语义的分布式文件系统。
因此,它们在设计目标、管理对象和提供的功能特性上存在本质的区别,服务于不同的应用场景。可以将 Iceberg 的元数据层看作是数据湖上的“表格目录”,而 JuiceFS 的元数据引擎则是分布式文件系统的“文件索引”。
简化数据管理和查询
AWS推出了新功能以简化S3 Tables的管理:
- 直接通过Amazon S3控制台使用Amazon Athena创建和查询表。
- 支持模式定义,并扩展至每个S3表存储桶最多10,000张表。
- 深度集成SageMaker统一工作室,允许数据团队通过单一界面交互S3 Tables。
正如沃菲尔德所强调,AWS始终基于客户反馈持续创新,确保S3 Tables能够满足数据驱动型企业不断增长的需求。通过结合高性能存储、无缝分析集成和简化治理,S3 Tables与SageMaker Lakehouse共同构建了下一代数据基础架构。
AWS在AI、数据平台和数据管理领域的服务创新正加速推进。随着企业渴望采用智能系统(如宝马的案例所示),这类系统正被用于提升生产力并实现真实回报。如果你了解我的观点,或许不会对我的积极态度感到意外——我一直主张“为客户提供解决方案而非单纯服务”,而SageMaker和S3正践行这一承诺。下一代Amazon SageMaker和S3 Tables正在重塑企业处理AI、机器学习和分析的方式。我们坚信,通过提供统一架构、采用开放技术并从初始阶段确保安全环境,这些创新将显著缩短数据驱动项目的投产时间。
我们视这些进展为帮助企业启动AI项目的关键。同时,环境必须能够利用SageMaker的零ETL特性——该特性已扩展为根据应用SLA限制数据移动量。由于企业不会将所有数据迁移至云端,AWS通过拥抱Apache Iceberg等开放标准,大幅简化了数据管道构建并降低成本。S3 Tables真正允许企业选择最适合的计算层,而AWS通过SageMaker统一工作室提供了极具说服力的解决方案。
我们同样认为治理至关重要,需通过技术与业务元数据的融合实现。事实上,若美国未来出台AI相关法规,合规性将成为关键——这类似于金融服务业数十年来遵循的监管框架,但更为严格。因此,我对SageMaker目录(尤其是其AI生成、监控和合规功能)以及Bedrock Guardrails的前景充满信心。目录和元数据将成为核心竞争领域。
作为技术爱好者,我赞赏Sirish和Andy在AWS re:Invent和Pi Day期间持续创新的成果。这些基于客户反馈的功能将助力企业更充分地利用服务价值。无论是数据工程师、分析师还是AI/ML从业者,这些工具都为无缝协作、增强治理和可扩展的AI开发提供了强大基石。
延伸思考
这次分享的内容就到这里了,或许以下几个问题,能够启发你更多的思考,欢迎留言,说说你的想法~
- 技术迁移挑战:企业从传统Parquet架构转向Iceberg驱动的S3 Tables时,如何评估迁移成本与收益平衡点?
- 治理与创新矛盾:在AI法规趋严的背景下,技术团队如何通过SageMaker Catalog的自动化策略,在保证合规性的同时加速模型迭代?
原文标题:AWS Pi Day Innovation: Amazon SageMaker and S3
本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。原始发表:2025-03-29,如有侵权请联系 cloudcommunity@tencent 删除企业存储aws管理数据
发布评论