Redshift 副本从分析创建不同的压缩编码

Posted 2023-03-31

【中文标题】Redshift 副本从分析创建不同的压缩编码

【英文标题】：Redshift copy creates different compression encodings from analyze

【发布时间】：2017-07-14 01:38:16

【问题描述】：

我注意到 AWS Redshift 推荐的列压缩编码与其在将数据（通过 COPY）加载到空表时自动创建的编码不同。

例如，我创建了一个表并从 S3 加载数据如下：

CREATE TABLE Client (Id varchar(511) , ClientId integer , CreatedOn timestamp, 
UpdatedOn timestamp ,  DeletedOn timestamp , LockVersion integer , RegionId 
varchar(511) , OfficeId varchar(511) , CountryId varchar(511) ,  
FirstContactDate timestamp , DidExistPre boolean , IsActive boolean , 
StatusReason integer ,  CreatedById varchar(511) , IsLocked boolean , 
LockType integer , KeyWorker varchar(511) ,  InactiveDate timestamp , 
Current_Flag varchar(511) );

Table Client 创建执行时间：0.3s

copy Client from 's3://<bucket-name>/<folder>/Client.csv' 
credentials 'aws_access_key_id=<access key>; aws_secret_access_key=<secret>' 
csv fillrecord truncatecolumns ignoreheader 1 timeformat as 'YYYY-MM-
DDTHH:MI:SS' gzip acceptinvchars compupdate on region 'ap-southeast-2';    

警告：加载到表“客户端”已完成，24284 条记录 加载成功。加载到表“客户端”完成，6 记录已加载了为 ACCEPTINVCHARS 所做的替换。查看 'stl_replacements' 系统表了解详情。

0 行受影响的 COPY 成功执行

执行时间：3.39s

完成此操作后，我可以查看 COPY 应用的列压缩编码：

select "column", type, encoding, distkey, sortkey, "notnull" 
from pg_table_def where tablename = 'client';

给予：

╔══════════════════╦═════════════════════════════╦═══════╦═══════╦═══╦═══════╗
║ id               ║ character varying(511)      ║ lzo   ║ false ║ 0 ║ false ║
║ clientid         ║ integer                     ║ delta ║ false ║ 0 ║ false ║
║ createdon        ║ timestamp without time zone ║ lzo   ║ false ║ 0 ║ false ║
║ updatedon        ║ timestamp without time zone ║ lzo   ║ false ║ 0 ║ false ║
║ deletedon        ║ timestamp without time zone ║ none  ║ false ║ 0 ║ false ║
║ lockversion      ║ integer                     ║ delta ║ false ║ 0 ║ false ║
║ regionid         ║ character varying(511)      ║ lzo   ║ false ║ 0 ║ false ║
║ officeid         ║ character varying(511)      ║ lzo   ║ false ║ 0 ║ false ║
║ countryid        ║ character varying(511)      ║ lzo   ║ false ║ 0 ║ false ║
║ firstcontactdate ║ timestamp without time zone ║ lzo   ║ false ║ 0 ║ false ║
║ didexistprecirts ║ boolean                     ║ none  ║ false ║ 0 ║ false ║
║ isactive         ║ boolean                     ║ none  ║ false ║ 0 ║ false ║
║ statusreason     ║ integer                     ║ none  ║ false ║ 0 ║ false ║
║ createdbyid      ║ character varying(511)      ║ lzo   ║ false ║ 0 ║ false ║
║ islocked         ║ boolean                     ║ none  ║ false ║ 0 ║ false ║
║ locktype         ║ integer                     ║ lzo   ║ false ║ 0 ║ false ║
║ keyworker        ║ character varying(511)      ║ lzo   ║ false ║ 0 ║ false ║
║ inactivedate     ║ timestamp without time zone ║ lzo   ║ false ║ 0 ║ false ║
║ current_flag     ║ character varying(511)      ║ lzo   ║ false ║ 0 ║ false ║
╚══════════════════╩═════════════════════════════╩═══════╩═══════╩═══╩═══════╝

我可以这样做：

analyze compression client;

给予：

╔════════╦══════════════════╦═══════╦═══════╗
║ client ║ id               ║ zstd  ║ 40.59 ║
║ client ║ clientid         ║ delta ║ 0.00  ║
║ client ║ createdon        ║ zstd  ║ 19.85 ║
║ client ║ updatedon        ║ zstd  ║ 12.59 ║
║ client ║ deletedon        ║ raw   ║ 0.00  ║
║ client ║ lockversion      ║ zstd  ║ 39.12 ║
║ client ║ regionid         ║ zstd  ║ 54.47 ║
║ client ║ officeid         ║ zstd  ║ 88.84 ║
║ client ║ countryid        ║ zstd  ║ 79.13 ║
║ client ║ firstcontactdate ║ zstd  ║ 22.31 ║
║ client ║ didexistprecirts ║ raw   ║ 0.00  ║
║ client ║ isactive         ║ raw   ║ 0.00  ║
║ client ║ statusreason     ║ raw   ║ 0.00  ║
║ client ║ createdbyid      ║ zstd  ║ 52.43 ║
║ client ║ islocked         ║ raw   ║ 0.00  ║
║ client ║ locktype         ║ zstd  ║ 63.01 ║
║ client ║ keyworker        ║ zstd  ║ 38.79 ║
║ client ║ inactivedate     ║ zstd  ║ 25.40 ║
║ client ║ current_flag     ║ zstd  ║ 90.51 ║
╚════════╩══════════════════╩═══════╩═══════╝

即完全不同的结果。

我很想知道为什么会这样？我知道 ~24K 记录少于 AWS specifies 作为有意义的压缩分析样本所需的 100K，但是 COPY 和 ANALYZE 为同一个 24K 行表给出不同的结果似乎仍然很奇怪。

【问题讨论】：

我也经常看到这种情况，即使有超过 10 万条记录。

【参考方案1】：

COPY 目前不推荐 ZSTD，这就是推荐的压缩设置不同的原因。

如果您希望在希望最大化压缩（使用最少的空间）的永久表上应用压缩，则全面设置 ZSTD 将使您接近最佳压缩。

RAW 重新出现在某些列上的原因是，在这种情况下，应用压缩没有任何优势（压缩和不压缩的块数相同）。如果您知道表会增长，那么对这些列也应用压缩是有意义的。