Amazon Redshift 上的 Iceberg 物化视图

概述与核心价值

物化视图 (Materialized View, MV) 是 Amazon Redshift 的一项核心优化能力——它将复杂查询的结果预计算并持久化存储在 Redshift 本地，后续查询直接读取预计算结果，跳过昂贵的扫描和聚合。

自 2024 年 10 月 GA 起，Amazon Redshift 支持在 Apache Iceberg 外部表上创建物化视图，并支持增量刷新 (Incremental Refresh)——Redshift 能够利用 Iceberg 的 snapshot 机制，只读取自上次刷新后发生变化的数据，而非全表扫描，大幅降低刷新成本和时间。

* 基准: AWS 官方 TPC-DS 3TB 测试，Iceberg CoW 模式，ra3.4xl × 4 节点，34 个物化视图，1% 数据变更

适用场景

• BI Dashboard 加速：将频繁运行的仪表盘聚合查询物化，用户查询直接命中 MV
• 跨数据湖-数仓查询加速：Iceberg 外表数据留在 S3，Redshift MV 本地缓存聚合结果
• 实时 ETL 中间层：对 Flink/Spark 持续写入的 Iceberg 表建立增量 MV，替代定时全量 ETL
• 多引擎共享数据：底层 Iceberg 表由 Athena/EMR/Spark 共同操作，Redshift MV 为分析层提速

架构原理

增量刷新的工作机制

Iceberg 的 snapshot-based 事务管理是增量刷新的关键。当 Redshift 刷新 MV 时：

1. 对比 Snapshot：Redshift 记录上次刷新时的 Iceberg snapshot ID，刷新时读取当前最新 snapshot
2. 差异计算：通过对比两个 snapshot 之间的 manifest 差异，精确定位新增/删除/修改的 data files
3. 增量读取：仅从 S3 读取变化的 data files（而非全表扫描）
4. 本地更新：将增量数据合并到 Redshift 本地存储的 MV 数据中

支持的操作与增量刷新范围

MV 创建（初始化）的增量支持

MV 刷新的增量支持（基于 Iceberg 表）

SQL 构造的增量刷新支持

前置条件与权限配置

环境要求

• Amazon Redshift Provisioned 集群或 Redshift Serverless 工作组
• Iceberg 表已注册在 AWS Glue Data Catalog 中
• IAM Role 挂载到 Redshift 集群，具备 Spectrum 最小权限

IAM 最小权限策略

-- Redshift 需要的 IAM 权限（用于访问 Glue Catalog + S3 数据）
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "GlueCatalogAccess",
      "Effect": "Allow",
      "Action": [
        "glue:GetDatabase",
        "glue:GetDatabases",
        "glue:GetTable",
        "glue:GetTables",
        "glue:GetPartition",
        "glue:GetPartitions",
        "glue:BatchGetPartition"
      ],
      "Resource": [
        "arn:aws:glue:<REGION>:<ACCOUNT_ID>:catalog",
        "arn:aws:glue:<REGION>:<ACCOUNT_ID>:database/*",
        "arn:aws:glue:<REGION>:<ACCOUNT_ID>:table/*/*"
      ]
    },
    {
      "Sid": "S3DataAccess",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket",
        "s3:GetBucketLocation"
      ],
      "Resource": [
        "arn:aws:s3:::<YOUR_BUCKET>",
        "arn:aws:s3:::<YOUR_BUCKET>/*"
      ]
    }
  ]
}

设置默认 IAM Role

-- 在 Redshift 中设置默认 IAM Role
ALTER CLUSTER SET DEFAULT IAM_ROLE 'arn:aws:iam::<ACCOUNT_ID>:role/<ROLE_NAME>';

完整动手实践（Step-by-Step）

步骤一：在 Athena / EMR 中创建 Iceberg 表并写入数据

-- 在 Athena 中操作
CREATE DATABASE iceberg_demo;

CREATE TABLE iceberg_demo.sales (
  sale_id     BIGINT,
  sale_date   DATE,
  region      STRING,
  product     STRING,
  quantity    INT,
  amount      DECIMAL(12,2)
)
PARTITIONED BY (region, bucket(16, sale_id))
LOCATION 's3://your-bucket/iceberg/sales/'
TBLPROPERTIES (
  'table_type' = 'iceberg',
  'write_compression' = 'snappy',
  'format' = 'parquet'
);

-- 插入初始数据
INSERT INTO iceberg_demo.sales VALUES
(1, DATE '2024-01-15', 'APAC', 'Laptop',    10, 9500.00),
(2, DATE '2024-01-15', 'APAC', 'Monitor',    5, 2500.00),
(3, DATE '2024-01-16', 'EMEA', 'Laptop',    15, 14250.00),
(4, DATE '2024-02-01', 'AMER', 'Keyboard',  30, 1800.00),
(5, DATE '2024-02-01', 'AMER', 'Mouse',     50, 1250.00);

步骤二：在 Redshift 中创建外部 Schema

-- 在 Redshift Query Editor v2 中执行
CREATE EXTERNAL SCHEMA iceberg_schema
FROM DATA CATALOG
DATABASE 'iceberg_demo'
REGION 'us-east-1'
IAM_ROLE DEFAULT;

步骤三：验证外部表可查询

SELECT * FROM iceberg_schema.sales LIMIT 10;

步骤四：创建物化视图

-- 创建带聚合的物化视图
CREATE MATERIALIZED VIEW mv_sales_summary
AS
SELECT
    region,
    product,
    COUNT(*) AS order_count,
    SUM(quantity) AS total_qty,
    SUM(amount) AS total_amount,
    AVG(amount) AS avg_amount
FROM iceberg_schema.sales
GROUP BY region, product;

步骤五：在基表中插入新数据（模拟增量）

-- 回到 Athena 插入增量数据
INSERT INTO iceberg_demo.sales VALUES
(6, DATE '2024-02-15', 'APAC', 'Laptop',     8, 7600.00),
(7, DATE '2024-02-15', 'EMEA', 'Monitor',   12, 6000.00);

步骤六：增量刷新物化视图

-- 在 Redshift 中执行增量刷新
REFRESH MATERIALIZED VIEW mv_sales_summary;

步骤七：验证增量刷新状态

-- 查看刷新历史
SELECT
    mv_name,
    status,
    refresh_type,   -- 'Incremental' 表示增量刷新成功
    start_time,
    end_time,
    rows_inserted,
    rows_deleted
FROM SYS_MV_REFRESH_HISTORY
WHERE mv_name = 'mv_sales_summary'
ORDER BY start_time DESC
LIMIT 5;

步骤八：测试 DELETE / UPDATE 后的增量刷新

-- 在 Athena 中执行 DELETE
DELETE FROM iceberg_demo.sales WHERE sale_id = 4;

-- 在 Athena 中执行 UPDATE
UPDATE iceberg_demo.sales
SET amount = 10000.00
WHERE sale_id = 1;

-- 回到 Redshift 刷新
REFRESH MATERIALIZED VIEW mv_sales_summary;

-- 验证数据已更新
SELECT * FROM mv_sales_summary ORDER BY region, product;

自动刷新 (Auto Refresh) 配置

创建时启用自动刷新

CREATE MATERIALIZED VIEW mv_sales_summary
AUTO REFRESH YES
AS
SELECT
    region,
    product,
    SUM(amount) AS total_amount
FROM iceberg_schema.sales
GROUP BY region, product;

对已有 MV 开启自动刷新

ALTER MATERIALIZED VIEW mv_sales_summary AUTO REFRESH YES;

自动刷新行为说明

确定性刷新（替代方案）

如果需要严格的刷新周期，可使用 Redshift Scheduler API 或 Amazon EventBridge 定时触发：

-- 使用 Redshift Data API + EventBridge 实现定时刷新
-- EventBridge Rule: 每小时执行一次
-- Target: Redshift Data API → ExecuteStatement

-- SQL Statement:
REFRESH MATERIALIZED VIEW mv_sales_summary;

与 Amazon S3 Tables 结合使用

Amazon S3 Tables 提供完全托管的 Iceberg 表体验，自带自动 compaction 和 snapshot 管理。结合 Redshift MV 使用时，架构如下：

配置步骤

-- Redshift 中创建指向 S3 Tables 的外部 Schema
CREATE EXTERNAL SCHEMA salesdb
FROM DATA CATALOG DATABASE 'salesdb'
IAM_ROLE 'arn:aws:iam::<ACCOUNT_ID>:role/<ROLE_NAME>'
REGION '<REGION>'
CATALOG_ID '<ACCOUNT_ID>';

-- 物化视图可存储在 S3 Tables 中或普通 S3 Bucket 中
-- 取决于你的访问模式和成本考量

性能基准与优化建议

官方 TPC-DS 基准测试结果

测试条件：3TB TPC-DS，Iceberg Copy-on-Write，ra3.4xl × 4 节点，34 个 MV，1% 数据变更

优化建议

1. 优先使用 Copy-on-Write 模式：CoW 模式下增量刷新效率更高，避免 delete files 累积
2. 定期 Compaction：如果使用 Merge-on-Read (如 Flink upsert 写入)，定期执行 rewrite_data_files 避免 delete files 过多
3. 控制 Snapshot 保留：确保 Redshift 上次刷新对应的 snapshot 未被过期清理，否则退化为全量刷新
4. 选择合适的 MV 粒度：MV 聚合粒度越粗，增量刷新的效率优势越大
5. 利用分布键 (DISTKEY) 和排序键 (SORTKEY)：为 MV 指定与查询模式匹配的分布和排序
6. 监控单文件删除位置数：Iceberg 表单个 data file 中被删除位置不能超过 400 万个

-- 为 MV 指定分布和排序策略
CREATE MATERIALIZED VIEW mv_sales_optimized
DISTSTYLE KEY
DISTKEY(region)
SORTKEY(sale_date)
AUTO REFRESH YES
AS
SELECT
    region,
    sale_date,
    SUM(amount) AS total_amount,
    COUNT(*) AS order_count
FROM iceberg_schema.sales
GROUP BY region, sale_date;

监控与运维

关键系统视图

常用监控查询

-- 查看所有 MV 的刷新历史和类型
SELECT
    mv_name,
    status,
    refresh_type,
    start_time,
    end_time,
    DATEDIFF(second, start_time, end_time) AS duration_sec,
    rows_inserted,
    rows_deleted
FROM SYS_MV_REFRESH_HISTORY
ORDER BY start_time DESC
LIMIT 20;

-- 查看 MV 当前状态（是否过期、刷新类型）
SELECT
    name,
    state,           -- 1=up-to-date, 0=stale
    autorewrite,     -- 是否支持自动重写
    autorefresh      -- 是否启用自动刷新
FROM STV_MV_INFO;

-- 确认查询是否被重写为使用 MV
EXPLAIN
SELECT region, SUM(amount)
FROM iceberg_schema.sales
GROUP BY region;
-- 如果看到 "Seq Scan on mv_tbl__..." 则表示查询已被重写

告警建议

• 监控 SYS_MV_REFRESH_HISTORY 中 status = 'Failed' 的记录
• 监控刷新类型：如果频繁出现全量刷新 (Full)，需排查 snapshot 过期或数据变更模式
• 监控刷新耗时：设置阈值告警，超过预期时间说明数据变化量异常

限制与注意事项

增量刷新会退化为全量刷新的场景

• Iceberg 表的 required snapshot 已过期（如果 MV 包含聚合操作）
• 多个基表同时有变更，且 MV 包含 JOIN（系统评估全量刷新更快时）
• 单个 data file 中超过 400 万个位置被删除

功能限制

• Iceberg 外表上的 MV 不支持 Concurrency Scaling
• 不支持 Automated MV (AutoMV) —— 系统不会自动为你创建 MV
• 不支持自动查询重写 (AQMV) —— 需显式查询 MV 名称
• 不能在 MV 定义中使用 ORDER BY、LIMIT、OFFSET
• 不能在 MV 定义中使用标准视图 (VIEW)、UDF、系统表
• Lake Formation 权限变更不会传播到已创建的 MV（安全考量）

MaxMessageSize 问题（delete files 过多）

最佳实践总结

参考文档

• Materialized views on external data lake tables in Amazon Redshift Spectrum — 官方文档
• Incremental refresh for Amazon Redshift materialized views on data lake tables — AWS Blog (2024-11)
• CREATE MATERIALIZED VIEW — SQL 参考
• Refreshing a materialized view — 刷新策略详细文档
• Automatic query rewriting to use materialized views — 自动查询重写
• Streamlined permissions for S3 Tables and Iceberg materialized views — AWS Blog (2026-05)
• Amazon Redshift now supports incremental refresh on MVs for data lake tables — GA 公告 (2024-10)