大数据相关优化(4个方向)

大数据相关优化(4个方向)

脑图：https://kdocs.cn/l/cs9jSgbdppiF
本文梳理了大数据优化可以考虑的方向，其中有部分实现示例，更多示例及实现可自行网络检索

1.数仓模型优化(7个方向)

1.1 模型架构

- 3NF建模
- 维度建模(推荐)

1.2利用中间表

适用于数据量大，下游任务很多的表，应⽤好了可以节省很多的计算量和成本。'
也不建议使⽤太多的中间表，因为中间表越多，依赖的层级也会越多。

1.3拆表

个别字段产出极慢，字段拆分为单独的表，这样就可以避免因为两个过慢的字段影响其他业务

1.4合表

业务重叠或重复的表，进行任务和数据合并。
当使⽤数仓⼀段时间之后会发现A业务部门出了⼀些表，
B业务部门也出了⼀些表，⽽这些表或者数据可能是重叠的，
也可能业务含义是⼀样的，只不过字段不⼀样，对于这些表⽽⾔是可以进⾏合并的，
因为在合并之后可以做整体批量加⼯的SQL，这样要⽐多个表批量加⼯的SQL复杂度要低很多，⽽且性能要好很多

1.5分区

⼀级分区⼀般都是按照天划分的，建议⼀天⼀个增量或者⼀天⼀个全量来做。
⼆级分区的选择反⽽会多⼀些，⾸先可以选择是否建⽴⼆级分区，其次可以选择⼆级分区的建⽴⽅式。
⼆级分区⽐较适合于在where语句中经常使⽤到的字段，⽽且这个字段应该是可枚举的

1.6拉链表

适用于缓慢变化维，业务关心历史状态的场景

1.7数据格式

推荐Parquet 或者 ORC

2.SQL计算任务优化(4个方向)

2.1减少数据输入(3)

1.利用谓词下推规则，就是先过滤再JOIN，REDUCE，UDF

参考链接:https://mp.weixin.qq.com/s/feNdmzAcgBzoMaKBPDGbXQ

2.慎⽤SELECT*
3.利用分区过滤

2.2防止数据倾斜(2)

1.参数调优
set hive.map.aggr=true;  --map端聚合
set hive.groupby.skewindata = ture; --开启2个任务
2.倾斜值随机打散

--例子：null值打散
SELECT * FROM a 
LEFT JOIN b 
ON CASE WHEN a.user_id IS NULL THEN concat('hive_', rand())   
ELSE a.user_id  END = b.user_id;

2.3小文件优化(5种)

参考连接:https://mp.weixin.qq.com/s?__biz=Mzg2MzU2MDYzOA==&mid=2247483683&idx=1&sn=14b25010032bdf0d375080e48de36d7f&scene=21#wechat_redirect
小文件影响：

1.导致namenode元数据特别大, 占用太多内存，严重影响HDFS的性能
2.对 hive 来说，在进行查询时，每个小文件都会当成一个块，启动一个Map任务来完成，
而一个Map任务启动和初始化的时间远远大于逻辑处理的时间，就会造成很大的资源浪费。
而且，同时可执行的Map数量是受限的。

1.使用 hive 自带的 concatenate 命令，自动合并小文件
注意：

 1、concatenate 命令只支持 RCFILE 和 ORC 文件类型。
 2、使用concatenate命令合并小文件时不能指定合并后的文件数量，但可以多次执行该命令。 
 3、当多次使用concatenate后文件数量不在变化，
 这个跟参数 mapreduce.input.fileinputformat.split.minsize=256mb 的设置有关，可设定每个文件的最小size。
#对于非分区表
alter table A concatenate;
#对于分区表
alter table B partition(day=20201224) concatenate;

2.调整参数减少Map数量
设置map输入合并小文件的相关参数：

#执行Map前进行小文件合并
#CombineHiveInputFormat底层是 Hadoop的 CombineFileInputFormat 方法
#此方法是在mapper中将多个文件合成一个split作为输入
set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat; -- 默认
#每个Map最大输入大小(这个值决定了合并后文件的数量
)set mapred.max.split.size=256000000;   -- 256M
#一个节点上split的至少的大小(这个值决定了多个DataNode上的文件是否需要合并)
set mapred.min.split.size.per.node=100000000;  -- 100M
#一个交换机下split的至少的大小(这个值决定了多个交换机上的文件是否需要合并)
set mapred.min.split.size.per.rack=100000000;  -- 100M

设置map输出和reduce输出进行合并的相关参数:

#设置map端输出进行合并，默认为true
set hive.merge.mapfiles = true;
#设置reduce端输出进行合并，默认为false
set hive.merge.mapredfiles = true;
#设置合并文件的大小
set hive.merge.size.per.task = 256*1000*1000;   -- 256M
#当输出文件的平均大小小于该值时，启动一个独立的MapReduce任务进行文件merge
set hive.merge.smallfiles.avgsize=16000000;   -- 16M

启用压缩：

# hive的查询结果输出是否进行压缩
set hive.exec.compress.output=true;
# MapReduce Job的结果输出是否使用压缩
set mapreduce.output.fileoutputformat.compress=true;

3.减少Reduce的数量

#reduce 的个数决定了输出的文件的个数，所以可以调整reduce的个数控制hive表的文件数量，
#hive中的分区函数 distribute by 正好是控制MR中partition分区的，
#然后通过设置reduce的数量，结合分区函数让数据均衡的进入每个reduce即可。
#设置reduce的数量有两种方式，第一种是直接设置reduce个数
set mapreduce.job.reduces=10;
#第二种是设置每个reduce的大小，Hive会根据数据总大小猜测确定一个reduce个数
set hive.exec.reducers.bytes.per.reducer=5120000000; -- 默认是1G，设置为5G
#执行以下语句，将数据均衡的分配到reduce中
set mapreduce.job.reduces=10;
insert overwrite table A partition(dt)
select * from Bdistribute by rand();
#解释：如设置reduce数量为10，则使用 rand()， 随机生成一个数 x % 10 ，
#这样数据就会随机进入 reduce 中，防止出现有的文件过大或过小

4.使用hadoop的archive将小文件归档

建议：

如果是新集群，没有历史遗留问题的话，建议hive使用 orc 文件格式，以及启用 lzo 压缩。
这样小文件过多可以使用hive自带命令 concatenate 快速合并。

重新查询后插入

2.4并行执行优化

set hive.exec.parallel=true; //打开任务并行执行
set hive.exec.parallel.thread.number=16; //同一个sql允许最大并行度，默认为8。
--在系统资源比较空闲的时候才有优势，否则没资源，并行也起不来

3.作业调度优化(3个方面)

3.1定时时间提前

耗时长的大任务
关键业务节点

3.2任务隔离

生产与开发隔离
根据数仓分层隔离
根据业务/项目隔离

3.3减少依赖层级

4.同步任务优化(3个方面)

4.1核心任务优先

4.2网络优化

4.3资源优化