如何合并小文件，减少map数？
假设一个 SQL 任务：
Select count(1) from popt_tbaccountcopy_mes where pt = ‘2012-07-04’;
该任务的 inputdir /group/p_sdo_data/p_sdo_data_etl/pt/popt_tbaccountcopy_mes/pt=2012-07-04
共有 194 个文件，其中很多是远远小于 128m 的小文件，总大小 9G ，正常执行会用 194 个 map 任务。
Map 总共消耗的计算资源： SLOTS_MILLIS_MAPS= 623,020
我通过以下方法来在 map 执行前合并小文件，减少 map 数：
set mapred.max.split.size=100000000;
set mapred.min.split.size.per.node=100000000;
set mapred.min.split.size.per.rack=100000000;
set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;
再执行上面的语句，用了 74 个 map 任务， map 消耗的计算资源： SLOTS_MILLIS_MAPS= 333,500
对于这个简单 SQL 任务，执行时间上可能差不多，但节省了一半的计算资源。
大概解释一下， 100000000 表示 100M, set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat; 这个参数表示执行前进行小文件合并，
前面三个参数确定合并文件块的大小，大于文件块大小 128m 的，按照 128m 来分隔，小于 128m, 大于 100m 的，按照 100m 来分隔，把那些小于 100m 的（包括小文件和分隔大文件剩下的），
进行合并 , 最终生成了 74 个块。
如何适当的增加 map 数？
当 input 的文件都很大，任务逻辑复杂， map 执行非常慢的时候，可以考虑增加 Map 数，来使得每个 map 处理的数据量减少，从而提高任务的执行效率。
假设有这样一个任务：
Select data_desc,
count(1),
count(distinct id),
sum(case when …),
sum(case when ...),
sum(…)
from a group by data_desc
如果表 a 只有一个文件，大小为 120M ，但包含几千万的记录，如果用 1 个 map 去完成这个任务，肯定是比较耗时的，这种情况下，我们要考虑将这一个文件合理的拆分成多个，
这样就可以用多个 map 任务去完成。
set mapred.reduce.tasks=10;
create table a_1 as
select * from a
distribute by rand(123);
这样会将 a 表的记录，随机的分散到包含 10 个文件的 a_1 表中，再用 a_1 代替上面 sql 中的 a 表，则会用 10 个 map 任务去完成。
每个 map 任务处理大于 12M （几百万记录）的数据，效率肯定会好很多。
看上去，貌似这两种有些矛盾，一个是要合并小文件，一个是要把大文件拆成小文件，这点正是重点需要关注的地方，
根据实际情况，控制 map 数量需要遵循两个原则：使大数据量利用合适的 map 数；使单个 map 任务处理合适的数据量；
假设一个 SQL 任务：
Select count(1) from popt_tbaccountcopy_mes where pt = ‘2012-07-04’;
该任务的 inputdir /group/p_sdo_data/p_sdo_data_etl/pt/popt_tbaccountcopy_mes/pt=2012-07-04
共有 194 个文件，其中很多是远远小于 128m 的小文件，总大小 9G ，正常执行会用 194 个 map 任务。
Map 总共消耗的计算资源： SLOTS_MILLIS_MAPS= 623,020
我通过以下方法来在 map 执行前合并小文件，减少 map 数：
set mapred.max.split.size=100000000;
set mapred.min.split.size.per.node=100000000;
set mapred.min.split.size.per.rack=100000000;
set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;
再执行上面的语句，用了 74 个 map 任务， map 消耗的计算资源： SLOTS_MILLIS_MAPS= 333,500
对于这个简单 SQL 任务，执行时间上可能差不多，但节省了一半的计算资源。
大概解释一下， 100000000 表示 100M, set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat; 这个参数表示执行前进行小文件合并，
前面三个参数确定合并文件块的大小，大于文件块大小 128m 的，按照 128m 来分隔，小于 128m, 大于 100m 的，按照 100m 来分隔，把那些小于 100m 的（包括小文件和分隔大文件剩下的），
进行合并 , 最终生成了 74 个块。
如何适当的增加 map 数？
当 input 的文件都很大，任务逻辑复杂， map 执行非常慢的时候，可以考虑增加 Map 数，来使得每个 map 处理的数据量减少，从而提高任务的执行效率。
假设有这样一个任务：
Select data_desc,
count(1),
count(distinct id),
sum(case when …),
sum(case when ...),
sum(…)
from a group by data_desc
如果表 a 只有一个文件，大小为 120M ，但包含几千万的记录，如果用 1 个 map 去完成这个任务，肯定是比较耗时的，这种情况下，我们要考虑将这一个文件合理的拆分成多个，
这样就可以用多个 map 任务去完成。
set mapred.reduce.tasks=10;
create table a_1 as
select * from a
distribute by rand(123);
这样会将 a 表的记录，随机的分散到包含 10 个文件的 a_1 表中，再用 a_1 代替上面 sql 中的 a 表，则会用 10 个 map 任务去完成。
每个 map 任务处理大于 12M （几百万记录）的数据，效率肯定会好很多。
看上去，貌似这两种有些矛盾，一个是要合并小文件，一个是要把大文件拆成小文件，这点正是重点需要关注的地方，
根据实际情况，控制 map 数量需要遵循两个原则：使大数据量利用合适的 map 数；使单个 map 任务处理合适的数据量；
本文转自 yntmdr 51CTO博客，原文链接：http://blog.51cto.com/yntmdr/1740587，如需转载请自行联系原作者
