使用AWS Glue将RDS数据导入Redshift后表体积异常增大求助

1. 数据类型不匹配（最常见诱因） #

• 核对RDS源表和Redshift目标表的字段类型：比如RDS里的VARCHAR(255)在Redshift被定义成VARCHAR(65535)，每条记录的字符串字段会占用更多冗余空间；或是RDS的INT被映射成BIGINT，单条记录的整数存储成本直接翻倍。
• 解决：严格对齐源表与目标表的数据类型，比如源表是VARCHAR(100)就把目标表对应列设为VARCHAR(100)，整数类型选最小适配的（能用INT就别用BIGINT）。

2. 未启用Redshift列存储压缩 #

• Redshift默认对新表开启自动压缩，但如果是手动建表没指定压缩规则，或是Glue自动建表时未触发压缩配置，列存储的优势就发挥不出来，体积会暴涨。
• 解决：
  • 建表时明确指定压缩编码：字符串列用LZO或ZSTD，数值列用DELTA或BYTEDICT；
  • 对已存在的表执行ANALYZE COMPRESSION命令，Redshift会给出针对性的压缩优化建议，再用ALTER TABLE修改对应列的压缩编码；
  • 配置Glue作业连接Redshift时，在连接选项里设置compression为zstd这类高效压缩算法。

3. Glue输出格式选择不当 #

• 如果Glue默认用CSV格式写入S3再COPY到Redshift，CSV的存储空间远大于Parquet、ORC这类列式存储格式，而且Redshift处理CSV时的存储效率极低。
• 解决：
  • 把Glue作业的输出格式改成Parquet或ORC，先写入S3；
  • COPY命令里加上FORMAT AS PARQUET，利用列式存储的压缩特性大幅缩减体积。

4. 分布键与排序键设置不合理 #

• 分布键选得不好会导致数据倾斜，部分节点存储过多数据；排序键不合理会影响存储的紧凑性，尤其是需要范围过滤的场景。
• 解决：
  • 选基数适中的列当分布键（比如主键、频繁关联的列），避免数据集中在少数节点；
  • 根据日常查询模式设置排序键，比如按时间或常用过滤列排序，既提升存储效率又优化查询速度。

5. 重复加载或冗余数据写入 #

• 检查是否存在重复加载：比如Glue作业重复运行导致Redshift表有大量重复行；或是COPY命令没加TRUNCATECOLUMNS参数，过长的字符串被完整写入占用额外空间。
• 解决：
  • 全量加载前清空目标表，或改用增量加载逻辑；
  • COPY命令添加TRUNCATECOLUMNS参数，截断超过目标列长度的字符串，避免冗余存储。

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