数仓任务优化

提示：上游任务优化、当前任务优化、下游任务优化和相关环境优化，全链路优化任务。

一、模型优化

合理的需求、合理的表结构。

'

1. 字段优化

1 精简字段

1）删除没有用途的字段；

2) 中英文都有的字段, 只保留英文;

3) 删除不常用且可以通过现有字段关联得到的字段;

'

2 字段类型

1）选择合适的数据类型，尽量选择低存储的；

2）尽量不要为了方便，都选择string类型；

'

3 字段值

1）选择存储简洁的代码，需要真实值时通过码表获取；

2）列式存储时，用null填充空值；

'

2. 存储类型

1 存储格式

1）最好列式存储（parquet、orc），压缩比高、读取性能好；

2）最好选计算引擎默认的存储格式，性能最优；

2 压缩格式

1）查询较多表，要求高处理性能，可选低压缩率的；

2）查询较少表，要求低存储的，可选高压缩率的；

3）不同的层采取不同的压缩格式；

3 分层存储

1）数据冷热分层

4 文件均匀度

1）最好大小均匀

2）小文件合并

3. 维表字段

尽量在数据量小的一步关联码表

1）聚合完成后，再关联出所需要的维度；

4. 全量表优化

1 增量数据并入

历史数据一般比较多，增量数据如何高效并入合成全量表；

2 过滤无效数据

1）过滤失活数据;

2）过滤不再使用的数据；

5. 添加索引

分区很多的表，查询元数据缓慢时，可以增加分区索引；

'

二、逻辑优化

1. 顺序优化

1）多表关联时，能减少数据量的表先关联；

2）join语句的关联键区分度大的在左边；

3）where语句先分区过滤再字段过滤，区分度大的字段在左边；

4）窗口键的顺序: 区分度大的放在前面;

5）数据先关联，后膨胀数据；

2 hint优化

1）显示指明广播join

2）控制写出文件数

3 主键过滤

关联主键(为空为null和异常处理)，能降低关联的数据量和避免数据倾斜
1）id = '异常主键'
2)  id is null
3)  id = ''

4 近似计算

要求不精确的统计，可以近似计算；

1）对表进行抽样

2）近似计算算子

5 高效方法

广播join

json解析方式优化

6 数据倾斜

数据倾斜增加资源用途不大, 不要求时效可以减低资源增大并行度, 使其它节点运行更多小任务, 从而充分利用资源.

通过工具诊断

统计表最新分区文件信息, 文件数/文件大小(总量/最小/均值/最大)

7 读文件优化

1）读取海量小文件优化

'

8 参数优化

set spark.sql.adaptive.enabled=false; -- 关闭AQE, 优化的执行计划不合理(没有广播,并行降低)

set spark.decommission.enabled=false; -- 节点被标记回收时, 可以继续执行完上面的任务

9 过滤失效

无用数据没有过滤: 不起作用, 后面会过滤掉的;

分区过滤失效: 用子查询限制分区

10 数据复用

不同任务多次使用的数据加工成中间表;

同个任务中多次使用的数据进行缓存, 若果缓存数据过大先写到临时表;

11 避免无用操作

• distinct: 是否有必要去重
• first_value: 主键是否已经唯一,是否有必要开窗取值
• count(distinct ) : 统计键唯一, 可省略distinct
• union : 合并的数据是否需要去重

100 其它优化

1. union all

连接的数据集都比较大时, 可以拆分开分别写出到表

2. grouping sets

这个操作会先膨胀数据, 然后再分组聚合, 数据量很大时, 可以细拆成几组减少计算压力

3. group by性能优化

一般group by的字段越多性能越差

spark sql group by multiple columns performance-掘金

三、环境优化

1. 硬件资源

1）CPU

2）内存

a. spark.shuffle.spill.numElementsForceSpillThreshold数据更多的溢写到磁盘；

b. 性能更好的磁盘，数据更快的写到磁盘；

3）磁盘

a. shuffle read 和 shuffle write慢，磁盘iops可能达到上限；

b. 在单个节点上配置更多的卷

使得所有卷的总大小和以前单个卷的大小一样，以增加单个任务节点的总磁盘读写吞吐量。

比如，对于集群的任务 Spot 实例组，您可以使用 4 个 EBS 卷，每个 1TB 大小，而不是 1 个 4TB 大小的卷。

4）网络带宽

网络带宽是否达到了上线

5）桶带宽

桶带宽是否达到上限

2. 打散任务

任务越集中，整体的性能越差，尽量均匀布置任务；集群越庞大，整体性能越差；

1）实效性不强的任务，可以迁移到低峰区；

2）需要多天回溯的，是否可以延时执行只运行一次；

3）价值高的优先执行，价值低的低峰执行；

4）重点任务在稳定集群运行任务，避免宕机或资源回收导致的任务重试影响实效性；

5）集群拆分：重要程度、区域；

3. spot集群

执行时间短，shuffle过程少

5. 保证driver稳定

1）driver最好运行在core节点

driver启动在非core节点上，节点被回收会导致任务失败无法进行重试。

2）非driver任务不要运行在core节点

避免资源紧张，无法启动driver。

3） driver分配充足的资源

避免driver出现性能瓶颈，导致调度不及时造成的整体资源利用率低
 

6. 对象存储

• 对象存储的流控与频控；
• 对象存储的多版本；
• 数据的分层存储；

四、调度优化

1. 同时调度的任务不能过多（调度并行度限制）

2. 高频转低频（小时到天，天到周）

五、外部优化

上下游任务的调整，是否可以减低本任务处理的复杂度；

上游模型调整, 适用于下游多个任务;

只是对外控制权限的表视图化, 避免计算和存储成本;

六、优化后工作

1. 测试数据清理
2. 下游任务定时前调

---