hadoop杂记

hadoop中的job schedule
1. 默认是FIFO
先按照按照优先级，后按照时间顺序进行执行
JobTracker没有什么负担，调度方法很简单。但是忽略了不同作业之间的需求差异，很可能造成一定程度的调度倾斜。
2. 公平调度器
基于队列方式阻止作业。可以设置最小的task slot，称为miniShare.
支持优先级，优先级高的占领的资源多。按缺额排序，资源优先给缺额大的。每个队列内部可能会有多个task同时运行。

3. 计算能力调度器（容量调度器）
队列方式存储作业，每个队列分配一定比例的资源，配置可运行的task数。每个队列中使用FIFO。允许管理员使用的资源量。多个队列同时运行。

调度器	多用户	多队列	平分	队列分类	抢占	资源池	最小额度	最大额度	机理
公平	是	是	按优先级	用户	饿极了就上	用户	可以更少被人瓜分	不够就用闲置资源	基于slot
容量	是	是	按指派的最小	组织	眼瞅着饿死	无	不会更少只会更多	根据队列用户个数	基于内存
FIFO	否	否	优先级	。。。。。	。。。。。	。。。。	。。。	。。。。。	队列排队

（如有错误，请提出来，谢谢教导）

常见问题：
1. combiners是在map端处理的，使用combanner要小心，比如在求平均值的时候会出现比较大的数据差。
2. partitioner，分区，如数据列数有区别时，如下：
name1 12 43
name2 dsf
name3 32 45
name4 sdf sdf
这就是三种不同的情况，需要三种不同的reduce进行处理，之后有三个输出文件，但是可能只有一个是期望的。
3. secondarynamenode的作用：提高NN启动速度，帮助它合并edits和fsimage；冷备份；
4. 机架感知的四种策略：
5. HDFS阻止好人做坏事，但是不能防止坏人做坏事儿。
6. namenode的启动过程：
a. 将fsimage载入内存，执行edits的内容；
b. 一旦内存中成功建立文件系统元数据的映射，就自主建立一个新的fsimage和一个空的edits；
c. 监听RPC和HTTP端口 
7. 实现map输出的压缩
a. 代码写
//设定map的输出是压缩的
conf.setCompressMapOutput(true);
conf.setMapOutputCompressorClass(GzipCodec.class);
//下面是设定整个mapreduce过程的输出是压缩的
conf.setBoolean("mapred.output.compress", true);
        conf.setClass("mapred.output.compression.codec", GzipCodec.class,
          CompressionCodec.class);
// 等同于上面的代码
    FileOutputFormat.setCompressOutput(job, true);
    FileOutputFormat.setOutputCompressorClass(job,  GzipCodec.class);
b. mapred-site.xml中配置
压缩后 的是.gz文件，需要用-text才能查看，-cat就不行了。








优化参数
jvm的重用；
mapred.reduce.parallel.copies（并行拷贝）；
使用combiner；
调整mapper\reducer的数量；
根据需求编写自己的最合适和简洁的Writable类型 
对输出结果进行压缩，压缩的时候，大的话用lzo，小的话就gz。（lzo最常用）


单元测试：MRUnit——————————MapDriver、ReduceDriver、MapReduceDriver、PipelineMapReduceDriver(多个mr)
测试包在contrib里面
j2ee的单元测试：mockito


注意；reducer中的迭代器最好抽出来，不要在循环里面再使用迭代