quancuizuishuai的博客

yarn中资源调度器共分为三种 1.FIFO调度器  优点是简单易懂而且不需要配置， 但是它不适合共享集群：    在FIFO调度器中只有一个队列，而且同一时刻只能有一个作业执行，就会出现有一个大作业A一直在运行，而小文件B要阻塞到作业A执行完毕才能运行的情况 2.容量调度器  1.它是yarn默认使用的调度器，如果不指定队列，那么应用都会被放在default的默认队列中（就和FIFO没区别了），  2.如果在配置文件capacity-scheduler.xml中设置了队列（同时可以指定每个队列的最大容量

压缩文件的好处  1.减小文件存储所占空间  2.加快文件传输效率，从而提高系统的处理速度  3.降低IO读写的次数 压缩文件的坏处  1.使用数据时先对文件解压，加重CPU负荷，压缩越狠，解压时间越长 Snappy<LZ4<LZO<GZIP<BZIP2 //开启map压缩******************************************************** configuration.setBoolean(Job.MAP_OUTPUT_COMPRE

join 1.map 端 join  应用于一个大文件和一个小文件的场景，小文件可以直接读取到内存中，这样每个mappertask都可以有一份小文件的数据，每次map处理数据从大文件中读取一条数据跟小文件中比对，如果有key与之对应，那么相连之后输出  下面是一个简单案例部分代码 小文件的路径需要在驱动类中指定 map中具体实现的业务逻辑 2.reduce端join  应用于两个大文件的场景，在map阶段对两个文件同时进行读取，在获得数据的同时为其打上“标签”（用来区分两个不同的文件中的数据），然后co

Combiner 实现原理（个人理解）：  溢写前的快速排序后或者归并排序后对数据进行一次合并(相当于一次reduce处理数据)  或者说在mapper和reducer之间多了一次reducer 代码实现方法：  1.添加一个实现类继承reducer<key,value，key,value>接口,前面的key，value是map的输出，后面的key，value是redece的输出，   2.然后重写reduce方法(实际上就是另一个reduce)，   3.然后在Driver中指定combine

下面是我一些对流程源码的理解 还是WordCount案例，进入到context.write()方法 进入到mapContext.write()方法 进入到write方法 在进入到write方法 可以看到有一个collectorc.collect()方法 其中getPartition()作用是获得当前数据的分区号 我们进入这个方法 因为我自定义了partition并指定了分区类 所以执行的是我重写过的getPartition方法 如果没有重写或者指定分区类，那么就会执行默认的getPartition.

MR 分区：    1.在MR中partitioner将Mapper产生的中间结果进行分区，然后将同一组数据提交给一个Reducer中处理    2.partitioner默认调用的是Hashpartitioner，用它来把数据分组然后发送给不同的reducer    3.计算公式：(key.hashCode() & Integer.MAX_VALUE) % numReduceTasks 实现分区：   1.继承Partitioner<key, value>，泛型为mapper输出

这里用的WordCount案例 运行debug模式，F5进入waitForComplent()方法 可以看到它调用了submit（）方法，进入这个方法 可以看到又有四个方法，下面一个个看 1.进入