成一个排序文件。这个部分可以调的参数挺多,但是一般都是不要调整的,不必重点关注。
Spill与Sort
在Spill阶段,由于内存不够,数据可能没办法在内存中一次性排序完成,那么就只能把局部排序的文件先
保存到磁盘上,这个动作叫Spill,然后Spill出来的多个文件可以在最后进行merge。如果发生Spill,可以通
过设置io.Sort.mb来增大Mapper输出buffer的大小,避免Spill的发生。另外合并时可以通过设置
io.Sort.factor来使得一次性能够合并更多的数据。调试参数的时候,一个要看Spill的时间成本,一个要看
merge的时间成本,还需要注意不要撑爆内存(io.Sort.mb是算在Map的内存里面的)。Reduce端的merge
也是一样可以用io.Sort.factor。一般情况下这两个参数很少需要调整,除非很明确知道这个地方是瓶颈。
Copy
copy阶段是把文件从Map端copy到Reduce端。默认情况下在5%的Map完成的情况下Reduce就开始启动
copy,这个有时候是很浪费资源的,因为Reduce一旦启动就被占用,一直等到Map全部完成,收集到所有
数据才可以进行后面的动作,所以我们可以等比较多的Map完成之后再启动Reduce流程,这个比例可以通
Mapred.Reduce.slowstart.completed.Maps去调整,他的默认值就是5%。如果觉得这么做会减慢Reduce端
copy的进度,可以把copy过程的线程增大。tasktracker.http.threads可以决定作为server端的Map用于提供
数据传输服务的线程,Mapred.Reduce.parallel.copies可以决定作为client端的Reduce同时从Map端拉取数据
的并行度(一次同时从多少个Map拉数据),修改参数的时候这两个注意协调一下,server端能处理client
端的请求即可。
文件格式的优化
文件格式方面有两个问题,一个是给输入和输出选择合适的文件格式,另一个则是小文件问题。小文件问
题在目前的Hive环境下已经得到了比较好的解决,Hive的默认配置中就可以在小文件输入时自动把多个文件
合并给1个Map处理,输出时如果文件很小也会进行一轮单独的合并,所以这里就不专门讨论了。相关的参
数可以在这里找到。
关于文件格式,Hive0.9版本有3种,textfile,sequencefile和rcfile。总体上来说,rcfile的压缩比例和查询时
间稍好一点,所以推荐使用。
关于使用方法,可以在建表结构时可以指定格式,然后指定压缩插入:
[js]viewplaincopy
1.createtablerc_file_test(colint)storedasrcfile;
2.setHive.exec.compress.output=true;
3.insertoverwritetablerc_file_test
4.select*fromsource_table;
另外时也可以指定输出格式,也可以通过Hive。default。fileformat来设定输出格式,适用于createtableas
select的情况: