Redshift RG 实例实战：Graviton 驱动下查询性能 2.4 倍提升全记录
每月 Redshift 账单又涨了。RA3 集群跑了两年，数据量从 5TB 涨到 40TB，查询性能肉眼可见地下降。加节点？预算不批。换方案？迁移成本太高。
亚马逊云科技上周发布了 Redshift RG 实例——Graviton 芯片驱动，性能比 RA3 快 2.4 倍，每 vCPU 价格还降了 30%。说白了，又快又便宜。我花了两天做完迁移测试，这篇记录全过程。
RG vs RA3：到底快在哪
| 对比项 | RA3 | RG | 变化 |
|---|---|---|---|
| 芯片架构 | x86 (Intel) | ARM (Graviton) | 换代 |
| 数据仓库查询性能 | 基准 | 2.4x | +140% |
| 每 vCPU 价格 | 基准 | -30% | 降价 |
| 数据湖查询引擎 | 需 Spectrum 外挂 | 内置矢量化引擎 | 集成 |
| Iceberg 支持 | Spectrum 有限支持 | 原生集群节点处理 | 大幅增强 |
| Parquet 处理 | S3 扫描 | 集群节点本地处理 | 低延迟 |
核心变化两个：
- Graviton 芯片：ARM 架构本身能效比高，加上 AWS 针对分析场景做了向量化指令优化
- 内置数据湖引擎：以前查 S3 上的 Iceberg 表要走 Redshift Spectrum（另外计费），现在 RG 实例自己就能处理，不需要外部服务
创建 RG 集群
方式一：新建集群
aws redshift create-cluster \
--cluster-identifier my-analytics-rg \
--node-type rg.xlplus \
--number-of-nodes 3 \
--master-username admin \
--master-user-password 'YourStr0ngP@ss!' \
--db-name analytics \
--iam-roles "arn:aws:iam::123456789012:role/RedshiftS3Access" \
--encrypted \
--kms-key-id arn:aws:kms:us-east-1:123456789012:key/xxxxx
节点类型选 rg.xlplus，这是 RG 家族的起步规格。
方式二：从 RA3 快照恢复到 RG
# 先对现有 RA3 集群打快照
aws redshift create-cluster-snapshot \
--cluster-identifier my-old-ra3 \
--snapshot-identifier ra3-to-rg-migration
# 从快照恢复为 RG 集群
aws redshift restore-from-cluster-snapshot \
--cluster-identifier my-new-rg \
--snapshot-identifier ra3-to-rg-migration \
--node-type rg.xlplus \
--number-of-nodes 3
从快照恢复是最稳的迁移路径。数据不用重新导入，Schema、用户权限全部保留。恢复时间取决于数据量，40TB 大约 2-3 小时。
数据湖查询：告别 Spectrum
以前查 S3 上的 Iceberg 表，SQL 长这样：
-- 旧方式：通过 Spectrum external schema
CREATE EXTERNAL SCHEMA lake_spectrum
FROM DATA CATALOG
DATABASE 'my_lake_db'
IAM_ROLE 'arn:aws:iam::123456789012:role/RedshiftSpectrumRole';
SELECT * FROM lake_spectrum.orders
WHERE order_date > '2026-01-01';
RG 实例内置了矢量化数据湖引擎，Iceberg 表直接在集群节点处理：
-- RG 方式：直接查 Iceberg，无需 Spectrum
CREATE EXTERNAL SCHEMA lake_native
FROM DATA CATALOG
DATABASE 'my_lake_db'
IAM_ROLE 'arn:aws:iam::123456789012:role/RedshiftLakeRole'
CATALOG_TYPE ICEBERG;
-- 同样的查询，但数据在集群节点本地处理
SELECT
product_category,
SUM(amount) as total_sales,
COUNT(DISTINCT customer_id) as unique_customers
FROM lake_native.orders
WHERE order_date BETWEEN '2026-01-01' AND '2026-03-31'
GROUP BY product_category
ORDER BY total_sales DESC;
区别在哪？RA3 + Spectrum 是把 S3 数据拉到 Spectrum 层处理（网络开销大），RG 是直接在集群节点本地的矢量化引擎跑（低延迟）。
跨仓库 + 数据湖联合查询
RG 实例真正爽的是一条 SQL 跨两个数据源：
-- 数据仓库表 JOIN 数据湖 Iceberg 表
SELECT
w.customer_name,
w.tier,
l.event_type,
COUNT(*) as event_count
FROM warehouse_schema.customers w
JOIN lake_native.clickstream l
ON w.customer_id = l.user_id
WHERE l.event_date > CURRENT_DATE - INTERVAL '7 days'
GROUP BY 1, 2, 3
HAVING COUNT(*) > 100;
不需要 ETL 把数据湖的数据再导一份到仓库里。节省存储成本，数据也不会出现延迟不一致。
性能测试结果
我用团队实际的 15 条高频 SQL 做了 A/B 测试（相同数据集 40TB、相同节点数 3）：
| 查询类型 | RA3 (3节点) | RG (3节点) | 加速比 |
|---|---|---|---|
| 聚合报表（GROUP BY + HAVING） | 45s | 19s | 2.4x |
| 多表 JOIN（5张事实表） | 2m 10s | 55s | 2.4x |
| 数据湖 Iceberg 扫描 | 38s (Spectrum) | 14s (内置) | 2.7x |
| 窗口函数排名 | 22s | 10s | 2.2x |
| INSERT INTO SELECT (ETL) | 5m 30s | 2m 20s | 2.4x |
Iceberg 查询提升最明显（2.7x），因为省掉了 Spectrum 的网络往返。
迁移注意事项
1. 检查 SQL 兼容性
RG 和 RA3 的 SQL 语法完全兼容，不需要改代码。但有两个边界 case：
-- 检查是否有用到即将废弃的函数
SELECT DISTINCT querytxt
FROM stl_query
WHERE querytxt ILIKE '%CONVERT_TIMEZONE%'
AND starttime > CURRENT_DATE - 30;
2. JDBC/ODBC 驱动更新
<!-- Maven 依赖建议升级到最新 -->
<dependency>
<groupId>com.amazon.redshift</groupId>
<artifactId>redshift-jdbc42</artifactId>
<version>2.1.0.31</version>
</dependency>
3. 监控迁移后性能
-- 查看查询执行计划确认走了矢量化引擎
EXPLAIN VERBOSE
SELECT * FROM lake_native.orders WHERE order_date > '2026-01-01';
-- 监控集群资源使用
SELECT
query,
elapsed/1000000.0 as seconds,
aborted,
label
FROM stl_query
WHERE starttime > CURRENT_TIMESTAMP - INTERVAL '1 hour'
ORDER BY elapsed DESC
LIMIT 20;
成本对比
以 3 节点 ra3.xlplus → 3 节点 rg.xlplus 为例：
- RA3 按需价格：约 $1.086/节点/小时
- RG 按需价格：约 $0.76/节点/小时（估算，降 30%）
- 月度节省：3 × $0.326 × 720h ≈ $704/月
加上 Spectrum 查询费用省掉（之前每月约 $200），总计月省约 $900。
什么场景适合迁移
- ✅ 现有 RA3 集群，数据量 > 10TB
- ✅ 频繁查询 S3 数据湖（Iceberg/Parquet）
- ✅ 月度 Redshift 账单 > $3000，有降本需求
- ✅ 查询延迟是瓶颈（Dashboard 加载慢）
- ❌ 数据量 < 1TB，RA3 甚至 Serverless 就够了
- ❌ 刚建好 RA3 集群还在 Reserved Instance 合约期内
小结
RG 实例对数据团队来说是个"白捡"的升级——性能翻倍、价格下降、还内置了数据湖引擎。迁移路径就是从快照恢复，改个节点类型的事。
如果你的 RA3 集群跑了超过一年，强烈建议跑个 benchmark 测试。大概率能省钱又提速。
浙公网安备 33010602011771号