目录
第八章 数据调优及其原理11/15
8.1 小问题问题
8.1.1 小文件的危害
8.1.2 小文件的产生原理
8.1.3 小文件的治理方案
8.2 数据倾斜问题
8.3 减少数据量
8.4 参数优化
8.5 企业级调优
第八章 数据调优及其原理11/15
8.1 小问题问题
小文件过多会占用大量内存，且在初始化时会占用大量计算资源，严重影响性能。对于已经存在的小文件，建议把小文件进行归档；重建表，建表的时候减少reduce数量；通过参数调节，设置map/reduce端的相关参数，在文件生产中，减少reduce的数量，少用动态分区。
8.1.1 小文件的危害
-
对于HDFS来说，文件越多的时候，读写文件的时候由于要和namenode进行通信，在namenode压力大且文件过多的时候，会极大的消耗时间；从namenode元数据存储角度，文件数量越多，namenode存储的元数据就越大。
-
对于下游流程，不论是MR，Hive,Spark，在划分分片的时候，都需要从namenode获取文件信息。这个过程与文件数量成正比，同时受namenode压力的影响，在namenode压力大，上游文件多的情况下，下游的getSplit操作就会比较慢。
8.1.2 小文件的产生原理
如何定义小文件呢？有些公司的标准是：当天生产的数据中，平均文件大小低于1M且文件总数超过1000的表数量。
治理思路：
-
阶段1：map合并，发生在split操作，可以解决输入小文件的合并（也可以解决只有map阶段的输出小文件合并），方式是把多个小文件合并成一个数据分片（split），进而交给一个map task进行计算。
-
阶段2：reduce合并，发生在shuffle阶段，可以解决输出小文件的合并，方式是减少reduce task数量，减少小文件的形成。
-
阶段3:写入hdfs之后，可以解决输出小文件的合并，方式是额外启动一个job，根据用户设置的阈值来合并已经生产的小文件。
8.1.3 小文件的治理方案
1）参数调优
-
map合并：当执行的作业没有shuffle阶段，只有map task,没有reduce task,或者希望每个map task能够处理更大的数据量的时候，可以设置参数。
-
reduce合并：当执行作业存在shuffle阶段，即存在reduce task，希望最后输出的文件数比较少，或者每个reduce task写的单个文件更大的时候可以设置相关参数。
2）代码逻辑优化（distribute by）
-
说明：控制map的输出在reduce是如何划分的，该方案多增加了一轮shuffle操作，任务的执行时间和资源消耗会增加一些。但是因为是重新分区，不涉及计算，而且时间不长，并行度不高，所以资源开销的增长并不多，执行时间虽然有少量增长，但是文件数减少会让提交时间大幅减少.而且由于partition数量和最终落表文件没有了关系，可以通过增加partition数量提供任务的执行速度。
-
使用方式：在SQL代码最后面加上distribute by column
-
注意：distribute by column， column的值相同的数据分发到同一个partition.这样会出现有几个key值，就有几个落表文件的情况。所以如果字段key指不均匀，就容易导致数据倾斜。
-
具体实现：distribute by id%20
8.2 数据倾斜问题
请参考上面第七章，需要反复思考，深入理解。
8.3 减少数据量
-
fetch抓取：HIve中对某些情况的查询可以不必使用MapReduce计算。例如select * from employee;
-
行列过滤：在select中，只拿需要的列，少用select *.
-
谓词下推：能够过滤的数据越早越好。
-
分区：应该尽量使用分区过滤
-
优化业务逻辑，选择最合理的业务逻辑，减少不必要的数据量
-
优化SQL写法：
学习 from…....insert into方法。
insert into table stu partition(tp)
select s_age,max(s_birth) stat,'max' tp
from stu_ori
group by s_age
union all
insert into table stu partition(tp)
select s_age,min(s_birth) stat,'min' tp
from stu_ori
group by s_age;
我们简单分析上面的 SQl 语句，就是将每个年龄的最大和最小的生日获取出来放到同一张表中，union all 前后的两个语句都是对同一张表按照 s_age 进行分组，然后分别取最大值最小值。对同一张表相同的字段进行两次分组，这造成了极大浪费，我们能不能改造下呢，当然是可以的，为大家介绍一个语法： from ...insert into ... ，这个语法将 from 前置，作用就是使用一张表，可以进行多次插入操作：
from stu_ori
insert into table stu partition(tp)
select s_age,max(s_birth) stat,'max' tp
group by s_age
insert into table stu partition(tp)
select s_age,min(s_birth) stat,'min' tp
group by s_age;
上面的 SQL 就可以对 stu_ori 表的 s_age 字段分组一次而进行两次不同的插入操
作。
8.4 参数优化
-
map数量：当input的文件都很大，任务逻辑复杂，map执行非常慢的时候，可以考虑增加Map数量，使得每个map处理的数据量减少，从而提高任务的执行效率，map数量的计算公式：
Math.max(minSize, Math.min(maxSize,blocksize))
-
Reduce数量：每个Reduce处理的数据量默认是256M；每个任务最大的reduce数量默认为1009；reduce数的计算公式：min(参数2，总输入数据量/参数1)
-
参数设置开启负载均衡：skywindate,aggr参数。
8.5 企业级调优
-
本地模式：当Hive的输入数据量是非常小的时候，这种情况下，为查询触发执行任务消耗的时间可能会比实际Job的执行时间要多的多。对于大多数这种情况，HIve可以通过本地模式在单台机器上处理所有的任务。对于小数据集来说，执行时间可以明显被缩短。
-
尽量避免笛卡尔积
-
采用分桶
-
选择合理的压缩方式和存储方式。
-
使用order by的时候需要设置limit过滤。
-
JVM重用
-
并行执行，如果有更多的阶段可以并行执行，那么Job可能就越快完成。
-
对于HDFS来说，文件越多的时候，读写文件的时候由于要和namenode进行通信，在namenode压力大且文件过多的时候，会极大的消耗时间；从namenode元数据存储角度，文件数量越多，namenode存储的元数据就越大。
-
对于下游流程，不论是MR，Hive,Spark，在划分分片的时候，都需要从namenode获取文件信息。这个过程与文件数量成正比，同时受namenode压力的影响，在namenode压力大，上游文件多的情况下，下游的getSplit操作就会比较慢。
8.1.2 小文件的产生原理
阶段1：map合并，发生在split操作，可以解决输入小文件的合并（也可以解决只有map阶段的输出小文件合并），方式是把多个小文件合并成一个数据分片（split），进而交给一个map task进行计算。
阶段2：reduce合并，发生在shuffle阶段，可以解决输出小文件的合并，方式是减少reduce task数量，减少小文件的形成。
阶段3:写入hdfs之后，可以解决输出小文件的合并，方式是额外启动一个job，根据用户设置的阈值来合并已经生产的小文件。
map合并：当执行的作业没有shuffle阶段，只有map task,没有reduce task,或者希望每个map task能够处理更大的数据量的时候，可以设置参数。
reduce合并：当执行作业存在shuffle阶段，即存在reduce task，希望最后输出的文件数比较少，或者每个reduce task写的单个文件更大的时候可以设置相关参数。
说明：控制map的输出在reduce是如何划分的，该方案多增加了一轮shuffle操作，任务的执行时间和资源消耗会增加一些。但是因为是重新分区，不涉及计算，而且时间不长，并行度不高，所以资源开销的增长并不多，执行时间虽然有少量增长，但是文件数减少会让提交时间大幅减少.而且由于partition数量和最终落表文件没有了关系，可以通过增加partition数量提供任务的执行速度。
使用方式：在SQL代码最后面加上distribute by column
注意：distribute by column， column的值相同的数据分发到同一个partition.这样会出现有几个key值，就有几个落表文件的情况。所以如果字段key指不均匀，就容易导致数据倾斜。
具体实现：distribute by id%20
-
fetch抓取：HIve中对某些情况的查询可以不必使用MapReduce计算。例如select * from employee;
-
行列过滤：在select中，只拿需要的列，少用select *.
-
谓词下推：能够过滤的数据越早越好。
-
分区：应该尽量使用分区过滤
-
优化业务逻辑，选择最合理的业务逻辑，减少不必要的数据量
-
优化SQL写法：
-
map数量：当input的文件都很大，任务逻辑复杂，map执行非常慢的时候，可以考虑增加Map数量，使得每个map处理的数据量减少，从而提高任务的执行效率，map数量的计算公式：
Math.max(minSize, Math.min(maxSize,blocksize))
-
Reduce数量：每个Reduce处理的数据量默认是256M；每个任务最大的reduce数量默认为1009；reduce数的计算公式：min(参数2，总输入数据量/参数1)
-
参数设置开启负载均衡：skywindate,aggr参数。
8.5 企业级调优
-
本地模式：当Hive的输入数据量是非常小的时候，这种情况下，为查询触发执行任务消耗的时间可能会比实际Job的执行时间要多的多。对于大多数这种情况，HIve可以通过本地模式在单台机器上处理所有的任务。对于小数据集来说，执行时间可以明显被缩短。
-
尽量避免笛卡尔积
-
采用分桶
-
选择合理的压缩方式和存储方式。
-
使用order by的时候需要设置limit过滤。
-
JVM重用
-
并行执行，如果有更多的阶段可以并行执行，那么Job可能就越快完成。
本地模式：当Hive的输入数据量是非常小的时候，这种情况下，为查询触发执行任务消耗的时间可能会比实际Job的执行时间要多的多。对于大多数这种情况，HIve可以通过本地模式在单台机器上处理所有的任务。对于小数据集来说，执行时间可以明显被缩短。
尽量避免笛卡尔积
采用分桶
选择合理的压缩方式和存储方式。
使用order by的时候需要设置limit过滤。
JVM重用
并行执行，如果有更多的阶段可以并行执行，那么Job可能就越快完成。
