现状描述

1、业务历史数据可以变更
2、拉链表按天打宽
3、拉链表模型分区字段设计不合理，通用的过滤字段没有作为分区分桶字段
4、拉链表表数据量略大、模型数据分区不合理和服务器资源限制，计算任务执行超时【3-4年，用户数：132W】
5、基于拉链表打宽后的天表行转列【最多列达到300列】，sum(case when … end)，没有提前过滤数据

优化

1、完善模型设计，设计主键和分桶字段

1）在单表计算：若大表存放多种类型数据，数据分类字段要做为分区或分桶字段，可以实现数据快速过滤
2）多表关联：在大表合理设置了主键、分区或分桶的前提下，建议把关联字段做份分区或分桶字段【要综合考虑验证，设置过多分区分桶字段可能也会影响数据性能】

2、提前进行数据过滤和分级分类计算
前提：拉链表数据量较大或打宽后数据量较大

1）若拉链表数据量较大且包含多种类型数据，需要进行打宽表处理【一条打宽成多条】，那么打宽表后的数据量会翻几倍甚至更多从而导致性能很慢或者执行超时；
》》》建议1：在打宽的过程中按类别均匀拆分数据打宽到多个临时表
》》》建议2：增加任务并行度【在资源允许的前提下，大部分任务提高并发度可以解决性能问题：set parallel_fragment_exec_instance_num=8;】

2）若拉链表数据量较大【同一种类型数据】，需要进行打宽表处理【一条打宽成多条】，那么打宽表后的数据量会翻几倍甚至更多从而导致性能很慢或者执行超时；
》》》建议1：在打宽的过程中可以按时间拆分为当前和历史数据表【数据归档处理】
》》》建议2：增加任务并行度【在资源允许的前提下，大部分任务提高并发度可以解决性能问题：set parallel_fragment_exec_instance_num=8;】

3）若拉链表打宽后不同类型数据在下游计算逻辑不一致，建议根据数据类型或其他类型拆分数据

3、根据指标需求进行热点数据特殊优化
前提：资源有限，1个并发度运行

1）拉链表按分类拆分【过滤】后再按天打宽到多个宽表；
2）计算逻辑：计算第1-150天和150+的数据，打宽成151行；
》》》可以分两类计算：第一类计算第1-150天【150列】再关联计算150+列
3）若按以上逻辑计算任务还是执行超时，把数据拆分当前表和历史表，使用两个insert