Hadoop学习总结

HDFS YARN MapReduce关系

HDFS （分布式文件系统）

优缺点

优点

1. 高容错性：副本丢失，可以自动回复。
2. 适合处理大数据
3. 可以构建在廉价的机器上，通过对多副本机制，提高可靠性

缺点

1. 不适合低延时数据访问，比如毫秒级的存储数据，做不到
2. 无法高效的对大量小文件进行存储： 存储大量小文件，会占用NameNode大量的内存来存储文件目录和块信息。NameNode内存有限。小文件存储的寻址时间会超过读取时间。
3. 不支持并发写入，文件随机修改。 
        a. 一个文件只能由一个写，不允许多个线程同时写。
        b. 仅支持数据append，不支持文件的随机修改。

组成

NameNode(nn)

存储文件的元数据，如文件名，文件目录结构，文件属性（生成时间 ，副本数，文件权限），以及每个文件的块列表和块所在的DataNode等。
1. Fsimage文件：HDFS文件系统元数据的一个永久性检查点，其中包含了HDFS文件系统的所有目录和文件inode的序列化信息。
2. Edits文件：存放HDFS文件系统的所有更新操作的路径，文件系统客户端执行的所有写操作首先会被记录到此。
3. seen_txid文件保存了一个数字，就是最后一个edits_的数字。最新的edits文件。

DataNode(dn)

在本地文件系统存储文件块数据，以及块数据的校验和。

工作机制

DataNode数据的完整性

1. 当DataNode读取Block时候，会计算CheckSum.
2. 如果计算后的CheckSum和Block创建的时候值不一样，说明Block已经损坏。
3. Client回去读取其他DataNode上的Block
4. 常见的校验算法：crc(32) ,md5(128),shal(160)
5. DataNode在其文件创建后周期性验证CheckSum.

Secondary NameNode(2nn)

每隔一段时间对NameNode元数据备份

工作流程

引入2NN的原因

1. NameNode中的元数据需要放到内存中，这样效率高，但是断电后，元数据丢失。因此产生在磁盘中备份元数据的FsImage。
2. 引入Edits文件（只进行追加操作，效率很高）。每当元数据有更新或者添加元数据时，修改内存中的元数据并追加到Edits中。
3. 长时间添加数据到Edits中，会导致该文件数据过大，效率降低，而且一旦断电，恢复元数据需要的时间过长。因此需要定期进行FsImage和Edits的合并，如果这个操作由NameNode节点完成，又会效率过低。因此，引入一个新的节点SecondaryNamenode，专门用于FsImage和Edits的合并。
    

其中edits_oo1是拉取之前的操作edits_inprogress_002是拉取之后进行的操作，因此从2NN更新完以后到NN上的数据结合002是最新的数据

读流程

（1）客户端通过DistributedFileSystem向NameNode请求下载文件，NameNode通过查询元数据，找到文件块所在的DataNode地址。
（2）挑选一台DataNode（就近原则，然后随机）服务器，请求读取数据。
（3）DataNode开始传输数据给客户端（从磁盘里面读取数据输入流，以Packet为单位来做校验）。
（4）客户端以Packet为单位接收，先在本地缓存，然后写入目标文件。

写流程

（1）客户端通过Distributed FileSystem模块向NameNode请求上传文件，NameNode检查目标文件是否已存在，父目录是否存在。
（2）NameNode返回是否可以上传。
（3）客户端请求第一个 Block上传到哪几个DataNode服务器上。
（4）NameNode返回3个DataNode节点，分别为dn1、dn2、dn3。
（5）客户端通过FSDataOutputStream模块请求dn1上传数据，dn1收到请求会继续调用dn2，然后dn2调用dn3，将这个通信管道建立完成。
（6）dn1、dn2、dn3逐级应答客户端。
（7）客户端开始往dn1上传第一个Block（先从磁盘读取数据放到一个本地内存缓存），以Packet为单位，dn1收到一个Packet就会传给dn2，dn2传给dn3；dn1每传一个packet会放入一个应答队列等待应答。
（8）当一个Block传输完成之后，客户端再次请求NameNode上传第二个Block的服务器。（重复执行3-7步）

YARN（资源调度器）

组成

1. ResourceManager(RM) 主要作用(整个集群资源（cpu,内存）老大)

        a. 处理客户端请求

        b.监控NodeManager

        c.启动或监控ApplicationMaster

        d.资源的分配和调度

2. NodeManager（NM)主要作用（单个节点服务器资源的老大）
        a. 管理单个节点上的资源
        b.处理来自ResourceManager的命令
        c.处理来自ApplicationMaster的命令
 3. ApplicationMaster（AM) 作用（单个任务运行的老大）
        a. 为应用程序申请资源并分配给内部的任务
        b. 任务的监控与容错
 4. Container（相当于一台独立的服务器）
        YARN中的资源抽象，封装了某个节点上的多维度资源，如内存，CPU，磁盘，网络等。

工作机制

（1）MR程序提交到客户端所在的节点。
（2）YarnRunner向ResourceManager申请一个Application。
（3）RM将该应用程序的资源路径返回给YarnRunner。
（4）该程序将运行所需资源提交到HDFS上。
（5）程序资源提交完毕后，申请运行mrAppMaster。
（6）RM将用户的请求初始化成一个Task。
（7）其中一个NodeManager领取到Task任务。
（8）该NodeManager创建容器Container，并产生MRAppmaster。
（9）Container从HDFS上拷贝资源到本地。
（10）MRAppmaster向RM 申请运行MapTask资源。
（11）RM将运行MapTask任务分配给另外两个NodeManager，另两个NodeManager分别领取任务并创建容器。
（12）MR向两个接收到任务的NodeManager发送程序启动脚本，这两个NodeManager分别启动MapTask，MapTask对数据分区排序。
（13）MrAppMaster等待所有MapTask运行完毕后，向RM申请容器，运行ReduceTask。
（14）ReduceTask向MapTask获取相应分区的数据。
（15）程序运行完毕后，MR会向RM申请注销自己。

三种调度器的

先进先出调度器（FIFO）

单队列，根据提交作业的先后顺序，先来先服务。

容量调度器（Apache hadoop 默认）

特点

1. 多队列：每个队列可以配置一定的资源量，每个队列采用FIFO调度策略。
2. 容量保证：管理员可为每个队列设置资源最低保证和资源使用上限。
3. 灵活性：如果一个队列中资源有剩余，可以暂时共享给需要资源的队列，一旦该队列由新的应用提交，则其他队列要归还。
4. 多租户：
		支持多用户共享集群（如上图的SS和CLS用户）和多应用程序同时运行。
		对同一用户提交的作业所占资源量进行限定。

容量分配算法

1. 队列资源分配
	从root开始，使用深度优先算法，优先选择资源占用率最低的队列分配资源。
2. 作业资源分配
    默认按照提交作业的优先级和提交时间顺序分配资源
3. 容器资源分配
    按照容器的优先级分配资源，如果优先级相同，按照数据本地行原则：
    a.任务和数据在同一节点上
    b.任务和数据在同一机架上
    c.任务和数据不再同一节点也不在同一机架上

公平调度器（CDH默认）

特点

同容量调度器一样。

与容量调度器的不同点

1. 核心调度策略不同
   容量：优先选择资源利用率低的队列
   公平：优先选择对资源的缺额比例大的
2. 每个队列可以单独设置资源分配方式

缺额

1. 公平调度器设计的目标是：在时间尺度上，所有作业获得公平的资源。某一时刻的一个作业应获取资源和实际获取资源的差距叫缺额。
2. 调度器会优先为缺额大的作业分配资源

队列资源分配方式

Fair策略 （默认）