Redshift新手技术问询：何时及如何使用Redshift Spectrum？

1. 星型架构：事实表还是维度表放Spectrum？ #

• 优先迁移事实表：事实表普遍数据量庞大（比如日交易流水、用户行为日志，动辄几十TB级别），且大部分历史数据访问频率极低。把这类冷数据移到S3通过Spectrum查询，能大幅压缩Redshift本地存储成本，同时不影响实时/高频访问的近期事实表性能。
• 维度表建议留本地：维度表数据量通常较小（比如商品分类、用户基础属性，多为GB级），且查询时需要频繁与事实表关联，放在Redshift本地可避免跨层关联的性能损耗。仅当遇到极少被访问的超大维度表（比如包含全量用户多年行为标签的维度表）时，才考虑放到Spectrum。

真实案例：某电商平台的交易事实表按天分区，将超过6个月的历史分区迁移至S3存储并通过Spectrum挂载。日常业务报表仅查询近3个月数据（走Redshift本地），季度审计才会触发历史数据查询（走Spectrum），最终存储成本降低70%，核心业务查询性能无明显影响。

2. 数据仓库各层级是否适合放Spectrum？ #

• 着陆层/Staging层：完全适配。这类数据多为原始导入的全量数据，格式混杂（CSV、JSON、Parquet等），仅用于ETL转换，不会直接支撑业务查询。放在S3既节省Redshift存储，还能直接通过Spectrum读取转换，无需先导入Redshift本地。
• Data Vault层：按需选择。比如Vault中的原始卫星表（Satellite），数据量极大且多为历史快照，适合放Spectrum；而**链接表（Link）和中心表（Hub）**数据量小、关联频繁，建议留在Redshift本地。
• 星型架构层：仅迁移冷数据（低频访问的事实表分区）到Spectrum，核心热数据（近期事实表、维度表）保留在Redshift，确保业务查询的高效性。

真实案例：某零售企业的数据仓库，着陆层的每日原始销售日志直接存放在S3，通过Spectrum直接读取至Staging层做清洗转换，无需提前导入Redshift；Data Vault的用户行为卫星表（10TB+）放在S3，仅在做全量用户画像分析时才通过Spectrum关联查询，节省了大量Redshift存储资源。

3. S3追加写入是否需要Hudi/Delta Lake？ #

• 无需强制依赖：如果业务仅需追加数据（比如每日新增日志、交易流水），直接按分区（如日期）写入S3即可，Spectrum支持直接查询分区数据，完全满足需求。
• 需要的场景：当你需要更新/删除S3中的数据（比如修正历史订单错误、删除无效用户记录），或者需要ACID事务支持时，才需要用Hudi或Delta Lake管理S3数据。Redshift Spectrum原生支持查询这两种格式的表，可实现数据更新与版本管理。

真实案例：某金融机构的交易数据，前期仅追加每日交易记录，直接按日期分区存于S3，用Spectrum查询。后期需要修正历史错误交易数据，引入Delta Lake管理S3中的交易表，通过Delta Lake的ACID特性完成数据更新，再用Spectrum正常查询更新后的数据，无需将全量数据迁回Redshift。

内容的提问来源于stack exchange，提问作者Ryan