《Hadoop篇》------HDFS与MapReduce

一、HDFS角色职责总结

Namenode：接受客户端的请求，维护整个HDFS集群目录树，元数据信息的存储由namenode负责

Datanode：主要是负责数据块的存储，定期向namenode汇报block

SecondaryNamenode：SecondaryNamenode不是第二个namenode，当namenode宕机时，不能由SecondaryNamenode顶替

二、CheckPoint机制

dfs.namenode.checkpoint.period=3600 #两次checkpoint的时间间隔

dfs.namenode.checkpoint.txns=1000000 #两次checkpoint之间最大的操作记录

dfs.namenode.checkpoint.check.period=60 #检测的触发条件是否满足60s

dfs.namenode.checkpoint.max-retries=3 #最大的重试次数

上面配置只要有一个满足条件就会触发checkpoint机制

三、Mapreduce序列化

“将一个对象编码成一个字节流”称为序列化该对象（Serializing）；相反的处理过程称为反序列化（Deserializing）。

自定义bean对象想要序列化传输，必须实现序列化接口，注意反序列化的顺序和序列化的顺序完全一致。

四、Mapper

4.1、官方介绍

one map task for each InputSpilt

每个切片都是由一个mapTask处理

4.2、Split计算

切片数量决定了MapTask的数量

4.3、Split和block对应关系

假设切片是跨block的，也就是说maptask读取数据的时候，会出现以下几种情况

1、最理想的情况：有数据低负载（最佳本地化读取）

2、折中的情况：没数据（本节点没有所需的数据，这个时候就需要跨节点读取，这个所跨的节点是同一机架的，换句话说，如果本节点没有数据，你就需要看同一个机架的其他节点是否有需要的数据）

3、最差的情况，带宽占有率会很高，尽量避免：跨机架（不要跨数据中心，如果同一个机架没有所需要的数据，那只能跨机架读取其他节点的数据）

4.4、启发式算法

假设Hadoop的拓扑结构如下：

1、HDFS的block3个

2、某个InputSplit包含3个block，大小分别是100，150和75

3、准备4个机架，每个机架2个节点，数据的分布如下图所示

** 按机架排序（rack2>rack1>rack3>rack4）**

按机架内部的节点的数据量排（rack2:node4>node3）(rack1:node1>node2)

得出：node4>node3>node1>node2....

最佳的host列表{node4，node3，node1}

结论：当使用基于FileInputFormat实现InputFormat的时候，为了提高mapTask本地化读取数据，应该尽量使得InputSplit的大小和block相等。

五、MapTask整体的流程

1、Read阶段：MapTask通过用户编写的RecodReader去读取数据，从输入的InputSplit中解析出key/value键值对

2、Map阶段：这个阶段将解析的key/value交给用户编写的map()函数处理，并产生一系列的key/value键值对

3、Collect阶段：当用户编写的map()函数，处理完成之后，会调用OutputCollector.collect()输出结果，在该函数内部，它会生成key/value分片，并且写入到一个环形缓冲区，将来缓冲区的数据达到溢出值，内存中的数据就会刷入到磁盘。

4、Spill阶段：溢出阶段，当环形缓冲区满了，数据溢出到磁盘生成一些小文件。数据写入磁盘之前，先要对数据进行一次本地化的排序操作，分区操作，并且必要的时候，还要对数据进行合并、压缩操作

5、Combine阶段：当所有的数据处理完成之后，mapTask对所有的临时文件进行一次合并，以确保最终只会生成一个数据文件。

六、压缩算法

压缩可以说是mapreduce一种优化的策略

6.1、压缩算法适用场景

1、数据进入到map端的时候可以进行压缩

2、Map端的数据传输到reduce端的时候可以进行压缩

3、Reduce端将数据输出的时候可以选择压缩

6.2、压缩算法选择

1、Bzip2压缩率是最高的，这种压缩算法比较适合IO密集型的Job

2、在运算密集型的job的时候，优先考虑lzo

6.2.1、Gzip压缩

优点：压缩比比较高，而且解压和压缩速度也比较快，hadoop本身也是支持这种压缩算法，在应用处理当中，gzip格式文件就和处理普通文件是一样的，大部分的Linux系统都是自带gzip命令，使用方便

缺点：不支持切分（split逻辑切分）

应用场景：当你的文件压缩之后可以到（或者是小于等于一个blocksize大小）blocksize可以考虑使用它（或者说如果你的文件用gzip压缩之后文件大小在128M，我们就可以考虑使用这个gzip算法）

6.2.2、Bzips压缩

优点：支持split，具有很高的压缩比，hadoop本身也是支持这种算法，在linux系统里面，自带bzip2，使用方便。

缺点：压缩速度和解压速度都是很慢的，不支持native本地

应用场景：使用的场景针对那种速度要求不高、对压缩比要求高、对冷数据进行持久化存储的场景，即IO密集型场景

6.2.3、Lzo压缩

优点：压缩、解压缩速度都是比较快的，压缩率不会很高。本身不支持split，给Lzo压缩的文件加上索引，就支持分片了，它是hadoop当中较为流行的压缩格式，注意的是，linux服务器默认是不支持这个压缩格式，需要单独的安装

缺点：压缩比比gzip更低，hadoo本身不支持这个格式，需要额外的安装。代码还需要做特殊处理

应用场景：用于这种运算密集型的job

七、ResourceManager

ResourceManager有两个重要的组件：Scheduler，Application Manager

八、Yarn角色

Yarn结构里的核心角色ResourceManager，Application，Nodemanager

九、任务调度策略

9.1、FIFO Scheduler（先进先出调度器）

先进先出的策略，简单来说按照提交作业的先后顺序运行。Hadoop1.x默认的资源调度器是FIFO的方式。它按照作业的优先级高低，再按照到达时间的先后选择被执行的作业

9.2、Capacity Scheduler（容量调度器）

支持多个队列，每个队列可配置一定的资源量，每个队列采用FIFO调度策略，为了防止同一个用户的作业独占队列中的资源，该调度器会对同一用户提交的作业所占资源量进行限定

9.3、Fair Scheduler（公平调度器）

公平调度是一种赋予作业（job）资源的方法，它的目的是让所有的作业随着时间的推移，都能平均的获得等同的共享资源。所有的job具有相同的资源，当单独一个作业在运行时，它将使用整个集群。