AWS Redshift RG实例整合数据湖查询，消除Spectrum扫描费以锁定用户
内容摘要
核心要点
AWS于2026年5月12日宣布推出Amazon Redshift RG实例系列，由AWS Graviton处理器驱动。官方声称，与当前RA3实例相比，RG实例在运行数据仓库工作负载时性能提升高达2.2倍，每vCPU价格降低30%。
关键架构变动在于其集成数据湖查询引擎。该引擎直接在Redshift集群的计算节点上执行针对Amazon S3数据湖的SQL查询（支持Apache Iceberg和Apache Parquet）。这完全取代了此前作为独立服务运行的Amazon Redshift Spectrum。这意味着数据湖查询不再需要经过Spectrum的独立计算层，从而消除了Spectrum原本收取的$5/TB扫描费。查询现在完全在用户的VPC边界内执行，并使用现有的IAM角色。
迁移路径包括Elastic Resize（10-15分钟停机）和Snapshot and Restore。现有外部表、schema和查询语法（包括Spectrum查询）无需修改。AWS特别指出，该引擎非常适合处理由AI代理驱动的高并发、低延迟查询，以应对其带来的激增查询量。
重要性说明
表面上看，这是一次性能与成本的优化，但其真实意图是将数据湖查询的控制权和计费点从独立的Spectrum层，彻底转移到Redshift集群的实例生命周期内。这是在防守Snowflake和Databricks的跨云/跨引擎数据湖查询能力。过去，用户使用Spectrum查询S3数据湖，至少理论上可以迁移到其他引擎；现在，查询逻辑和性能优化完全绑定在RG实例的Graviton计算节点上，形成了新的硬件+软件锁定。
AWS刻意淡化了计算与存储耦合的隐性成本。虽然消除了$5/TB扫描费，但用户现在必须为所有数据湖查询支付RG实例的计算费用。对于低频、大批量的历史数据湖扫描，这种模式可能比按需付费的Spectrum更昂贵。此外，Elastic Resize的10-15分钟停机时间对于需要99.99%+可用性的现代化AI推理管道是不可接受的。
原文未提及的是，内嵌引擎的性能优势高度依赖于S3 Express One Zone或S3 Gateway Endpoint等优化，否则数据湖查询的尾部延迟可能成为瓶颈。将查询执行与仓库计算节点合并，也意味着数据湖查询会与原仓库工作负载争抢内存和CPU资源，在混合负载场景下可能导致不可预测的性能抖动。这一架构本质上是在合围那些试图用开放表格式（如Apache Iceberg）实现引擎无关的数据湖方案，剥夺用户的引擎选择权。
PRO 决策建议
【Vendors/竞争对手】Snowflake和Databricks应立即发起针对性的性能基准测试，重点展示在混合工作负载（数据仓库+数据湖并发查询）场景下，其独立计算架构相比Redshift RG实例的资源隔离性和性能可预测性优势。攻击点：Redshift RG实例无法避免数据湖查询与仓库查询争抢CPU和内存导致的性能抖动。同时，应大力推广开放表格式（如Apache Iceberg）的引擎无关性，强调用户可以随时切换引擎，而不会被锁定在单一实例族上。
【Enterprises/企业】CIO和架构师必须进行零信任审计。不要被“消除Spectrum扫描费”的表面优惠所迷惑。请计算你的数据湖查询密度：如果高频、低延迟查询为主，RG实例可能划算；如果低频、大批量历史扫描为主，务必对比按需计算成本。要求AWS提供RG实例在混合负载下的性能隔离SLA，并测试Elastic Resize对生产环境的实际影响。评估跨云可移植性：一旦深度使用此内嵌引擎，将你的数据湖查询逻辑与Redshift实例强绑定，迁移至其他平台的成本将急剧上升。
【Investors/投资者】看穿此发布背后的供应商集中度风险。AWS正试图通过消除Spectrum这一“准第三方”服务，将所有数据湖分析收入完全内部化。此举短期内利好AWS财报，但长期看，它将加剧与Snowflake和Databricks的竞争，并可能因锁定效应引发大型企业客户的反弹。关注Apache Iceberg社区的进展：如果Iceberg社区成功推广引擎无关的查询优化器，AWS这一策略的锁定性将大打折扣。
觉得这篇分析有用？
每周收到3-5条AI基础设施关键信号 →
💬 评论 (0)