| 小 CU 场 景 分 析 | ||||
| 基础概念 | 什么叫小CU？ | DWS的列存表最小存储单元是CU（Compress Unit），每个CU的大小为8KB的整数倍（需要注意的是，CU并不是由页组成的，它是一个独立的存储单元），最多存储1列60000行数据。同一列的多个CU连续存放在一个数据文件中，当数据文件的大小超过1G，会自动切换到新的文件中。 | ||
| CU更新机制 | 在列存表上进行delete时，首先会根据删除条件找到需要删除的行ctid（cu_id,offset）,然后对需要删除的行ctid去重（每420万行排序去重），最后在行对应的VCU的delete map上打上删除标记。至于update操作，实际上是一个delete+insert（append）操作。首先根据更新条件找到更新的行，打上删除标记（ctid需去重），然后将原来整行更新相应数据后，插入到新CU中。因此列存表更新/删除时对于CU上原始位置的数据没有被清理，还占用实际的磁盘空间 | |||
| 小CU的危害 | 1.压缩率低 2.空间膨胀 |
|||
| 如何判断小CU？ | DWS提供接口函数get_col_cu_info做单表的CU中的数据量的统计，默认情况下单个CU中的可见记录数小于2000条就被认为是小CU get_col_cu_info(schema_name text, table_name text, row_count int8)   |
|||
| 场景 | 场景编号 | 场景简述 | 详述 | 处理方案 |
| 数据导入 | I-1 | 单条导入 | 此场景主要是因为前段使用单条INSERT语句插入数据，导致每个INSERT语句在某一个DN上产生一个CU，每个CU里面只有一条数据，CU空间严重浪费，导致表的size变大。 注意：JDBC等驱动模式下的batch INSERT底层还是执行的单条INSERT语句，因此也在此场景之列 |
A-1 |
| I-2 | COPY | 此场景主要是业务侧通过数据同步工具进行COPY微批导入，业务侧为了控制数据导入延迟，或者避免单次导入数据量过大对数据导入工具的内存占用，一般都会控制单次COPY的数据量。控制的方法为设置单批次导入的数据量上限(一般不会太大，都是几百到几千条)，或者设置单批次导入数据的积累时间(比如接受前端给数据同步工具发送的10s内的数据)上限。 DWS为分布式数据库，数据会被打散分布到各个DN，每批次的数据分配到每个DN上的数据量可能只有几十条，导致形成小CU |
A-1 | |
| 数据加工 | M-1 | 不下推的批量导入 | 此场景主要出现在批量加工场景时，往目标表进行INSERT INTO SELECT操作。这种场景一般不会形成小CU。但是如果这个语句是不下推的，那么就会导致小CU。这种语句的执行计划一般有如下特征 1. INSERT算子在计划的最上层 2. INSERT算子的Targetlist Information里面有Remote query:信息，且此部分信息为带$的INSERT INTO语句
| A-1 |
| M-2 | 频繁更新 | 更新（UPDATE/DELETE/MERGE）频繁的表，导致已有CU的数据不断删除，最终导致每个CU里面的数据量变小 | A-2 | |
不同场景对应的解决方案
| 场景编号 | 处理方案 | 具体方案 |
| I-1 I-2 |
方案1 | 1.目标表修改为hstore，具体语法参见 https://support.huaweicloud.com/devg-820-dws/dws_04_1029.html |
| 方案2 | 把数据导入分拆为两个步骤 1.把数据导入一个普通行存表A 2.当表A的数据量积累到一定程度，把行存表A的数据导入最终目标表 |
|
| 方案3 | 如果目标表是分区表，且最新导入的数据总是在最新目标表中，建议在数据导入完成后对最新的分区最VACUUM FULLL操作 | |
| M-1 | 方案1 | 解决INSERT语句中的不下推因素 |
| M-2 | 方案1 | 如果目标表是分区表，且更新操作总是在最新分区上进行，建议抽取时机（无数据访问，且小CU积累的足够多）对分区做VACCUM FULL |
| 方案2 | 如果目标表是普通表，建议抽取时机（无数据访问，且小CU积累的足够多）对表做VACCUM FULL |
原创文章，作者：奋斗，如若转载，请注明出处：https://blog.ytso.com/tech/bigdata/317383.html