Hadoop2.0

学习的时候没有太过注意Shuffle这个概念，以至于还认为是不是漏掉了什么知识点，前面看了一些帖子才发现Shuffle原来是map()办法执行完结到reduce()办法执行这么一大段过程....小声BB：本质上该过程蕴含许多环节，不晓得为啥就统称Shuffle了...... 1. Mapper的写出图见意现 -- 间接上图： 须要明确的点： 在环形缓冲区触发溢写时，进行的排序是先依据每个键值对的分区进行排序，而后再依据key进行排序每次写出实际上包含两个文件，一个是meta数据写出造成的index文件，另一个则是排序后的data文件在溢写时产生一次排序，为疾速排序算法；在最初合并为一个整体文件时，因为各小文件已有序，间接归并排序即可Reducer从Mapper节点的最终文件file.out读取数据，依据index文件只读取对应分区的数据2. Mapper的分区分区的作用是将Mapper阶段输入的后果分为不同的区域，并传送给不同的ReduceTask，因而分区数和Reduce的并行度是互相决定的，即 Num Of Partitions = Num Of ReduceTask 设置ReduceTask数量：job.setNumReduceTasks(n) 分区形式： 默认形式：hash(key) % Num of ReduceTask -- 键值哈希取模自定义分区类：定义类继承Partitioner类，并重写getPartition()办法留神： 在没有设置ReduceTask数目的状况下，MR默认只调配一个ReduceTask，即不论自定义分区办法须要分几个区，最初的后果都只会进入这一个Reducer，最终生成一个后果文件；如果设置了ReduceTask数量大于1，但该数量小于自定义的分区数，则运行MR程序会报错，因为会产生一些Mapper的后果数据没有Reducer来获取的状况如果设置的分区数 < ReduceTask的数量，那么程序会失常执行，最初也会生成和ReduceTask数相等的后果文件，但其中有 (ReduceTask数 - 分区数) 个空文件，因为这部分的Reducer没有输出3. Mapper的排序比较简单，溢写时疾速排序，合并时归并排序；排序规范为对key进行字典排序可自定义排序(在自定义Bean对象时应用)，须要让自定义的Bean类实现WritableComparable接口并重写compareTo办法，实际上和Java中的Comparable根本一样4. Reducer的读入须要明确的点： 一个ReduceTask只会读取每个Mapper后果的同一个分区内的数据拷贝到Reducer节点先是保留在内存中，如果内存不够就刷写到磁盘所有数据拷贝实现后，对内存和磁盘(如果产生了刷写)进行Merge && Sort，这里排序也是默认依据Key进行字典排序，目标是让数据中key雷同的KV对排列在一起，不便reduce办法的调用。【reduce办法调用前会将所有key雷同的value封装为iterator迭代器对象，对于一个key调用一次reduce办法】5. Reducer的排序Reduce端的排序同样也是利用于应用了自定义Bean对象的场景，通过自定义的排序形式让Reducer把咱们指定的keys判断为同样的key(在默认reduce排序中会被断定为非同key) 留神！留神！留神！此处有坑！！！ Reducer端的自定义排序须要自定义排序类，继承WritableComparator并重写compare办法，并在Driver中关联咱们自定义的排序类Mapper端的自定排序须要在咱们定义Bean对象的时候让Bean对象继承WritableComparable类并重写办法CompareTo

学习的时候没有太过注意Shuffle这个概念，以至于还认为是不是漏掉了什么知识点，前面看了一些帖子才发现Shuffle原来是map()办法执行完结到reduce()办法执行这么一大段过程....小声BB：本质上该过程蕴含许多环节，不晓得为啥就统称Shuffle了...... 1. Mapper的写出图见意现 -- 间接上图： 须要明确的点： 在环形缓冲区触发溢写时，进行的排序是先依据每个键值对的分区进行排序，而后再依据key进行排序每次写出实际上包含两个文件，一个是meta数据写出造成的index文件，另一个则是排序后的data文件在溢写时产生一次排序，为疾速排序算法；在最初合并为一个整体文件时，因为各小文件已有序，间接归并排序即可Reducer从Mapper节点的最终文件file.out读取数据，依据index文件只读取对应分区的数据2. Mapper的分区分区的作用是将Mapper阶段输入的后果分为不同的区域，并传送给不同的ReduceTask，因而分区数和Reduce的并行度是互相决定的，即 Num Of Partitions = Num Of ReduceTask 设置ReduceTask数量：job.setNumReduceTasks(n) 分区形式： 默认形式：hash(key) % Num of ReduceTask -- 键值哈希取模自定义分区类：定义类继承Partitioner类，并重写getPartition()办法留神： 在没有设置ReduceTask数目的状况下，MR默认只调配一个ReduceTask，即不论自定义分区办法须要分几个区，最初的后果都只会进入这一个Reducer，最终生成一个后果文件；如果设置了ReduceTask数量大于1，但该数量小于自定义的分区数，则运行MR程序会报错，因为会产生一些Mapper的后果数据没有Reducer来获取的状况如果设置的分区数 < ReduceTask的数量，那么程序会失常执行，最初也会生成和ReduceTask数相等的后果文件，但其中有 (ReduceTask数 - 分区数) 个空文件，因为这部分的Reducer没有输出3. Mapper的排序比较简单，溢写时疾速排序，合并时归并排序；排序规范为对key进行字典排序可自定义排序(在自定义Bean对象时应用)，须要让自定义的Bean类实现WritableComparable接口并重写compareTo办法，实际上和Java中的Comparable根本一样4. Reducer的读入须要明确的点： 一个ReduceTask只会读取每个Mapper后果的同一个分区内的数据拷贝到Reducer节点先是保留在内存中，如果内存不够就刷写到磁盘所有数据拷贝实现后，对内存和磁盘(如果产生了刷写)进行Merge && Sort，这里排序也是默认依据Key进行字典排序，目标是让数据中key雷同的KV对排列在一起，不便reduce办法的调用。【reduce办法调用前会将所有key雷同的value封装为iterator迭代器对象，对于一个key调用一次reduce办法】5. Reducer的排序Reduce端的排序同样也是利用于应用了自定义Bean对象的场景，通过自定义的排序形式让Reducer把咱们指定的keys判断为同样的key(在默认reduce排序中会被断定为非同key) 留神！留神！留神！此处有坑！！！ Reducer端的自定义排序须要自定义排序类，继承WritableComparator并重写compare办法，并在Driver中关联咱们自定义的排序类Mapper端的自定排序须要在咱们定义Bean对象的时候让Bean对象继承WritableComparable类并重写办法CompareTo

YARN是做什么的YARN在Hadoop中的功能作用有两个，第一是负责Hadoop集群中的资源管理(resource management)，第二是负责对任务进行调度和监控(scheduling/monitoring)。YARN分别提供了相应的组件完成这两项工作。如何管理资源YARN在管理资源上采用的是master/slave架构。在整个YARN集群中，在其中一个节点上运行ResourceManager进程作为master，其余每个节点上都运行一个NodeManager进程作为slave。ResourceManager负责对集群中的所有资源进行统一的管理和调度。NodeManager进程负责单个节点上的资源管理，它监控一个节点上的资源使用情况(如cpu，内存，硬盘，网络等)并将其report给ResourceManager。ResourceManager有两个主要的组件：Scheduler和ApplicationsManager。其中的Scheduler就负责为集群中运行的各个application分配所需要的资源。Scheduler只负责资源的调度，它不做任何对application监控或跟踪的工作，此外，在任务由于各种原因执行失败时，它也不负责对任务进行重启。Scheduler根据application对资源的需求执行其资源调度功能。它将cpu、内存、硬盘、网络等资源合并成一个整体，抽象成Container进行资源分配。Container就是Scheduler进行资源分配的一个单位，也是运行在slave节点上的一个组件。此外，Scheduler是一个可插拔的组件，用户可根据自己的需要设计新的Scheduler，YARN提供了多种可直接使用的调度器，比如Fair Scheduler和Capacity Scheduler等。如何调度/监控任务ApplicationMaster组件负责跟踪和管理一个application，它负责为application向ResourceManager中的Scheduler组件申请资源，并通过NodeManger启动和监控一个任务。当向ResourceManager提交一个application时，必须为其指定一个ApplicationMaster组件。ResourceManager中的ApplicationsManager组件会对所有应用程序的ApplicationMaster进行管理，它首先会为ApplicationMaster组件分配资源，使其运行在一个slave节点的Container中。并负责监控ApplicationMaster的运行状态，在Container出现异常时对ApplicationMaster进行重启。ApplicationsManager负责管理整个集群中的所有application，包括application提交、与Scheduler协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重新启动它等。