hadoop各组件详解

一、Hadoop三大组件

• 1.HDFS 分布式文件系统
• 2.MapReduce 分布式离线计算框架
• ​3.Yarn 资源调度

---

1.HDFS

管理者：NameNode

• 1）作用

  • 1.管理整个文件系统的元数据/名字空间/目录树
  • 2.管理每一个路径/文件所对应的block块信息
  • 3.管理DataNode的心跳日志

• 2）NameNode元数据持久化的2种形式

  • 1.EditLog（日志文件）对于文件系统的每一次更改，例如，增加文件，删除文件等操作都会被写入Edit Log
  • 2.FsImage（镜像文件） NameNode在启动时会加载镜像文件的信息
  • eg：持久化数据中不包括Block所在的节点列表，及文件的Block分布在集群中的哪些节点上，这些信息 是在系统重启的时候，在安全模式下重新构建（通过DataNode做心跳，汇报的Block信息）

• 3）NameNode启动过程发生了什么？

1. 从硬盘读取FsImage 和EditLog文件
2. 将EditLog文件中的所有操作信息写入FsImage中，产生一个新的FsImage文件，这一操作被称为 checkpoint
3. 产生一个新的空的EditLog文件

• 4）NameNode单点故障解决方案

在HDFS中，Namenode可能成为集群的单点故障，Namenode不可用时，整个文件系统是不可用的。 HDFS针对单点故障提供了以下2种解决机制：

1、备份持久化元数据

​ 将文件系统的元数据同时写到多个文件系统， 例如同时将元数据写到本地文件系统及NFS。这些备份操作都是同步的、原子的。

2、Secondary NameNode

​ Secondary节点定期合并主NameNode的namespace image和edit log， 避免edit log过大，通过创建检 查点checkpoint来合并。它会维护一个合并后的namespace image副本， 可用于在Namenode完全崩 溃时恢复数据。
        Secondary Namenode通常运行在另一台机器，因为合并操作需要耗费大量的CPU和内存。其数据落后 于Namenode，因此当Namenode完全崩溃时，会出现数据丢失。 通常做法是拷贝NFS中的备份元数据 到Second Namenode，将其作为新的主Namenode。
​        在HA（High Availability高可用性）中可以运行一个Hot Standby，作为热备份，在Active Namenode故障之后，替代原有Namenode成为Active Namenode。

工作者：DataNode

1）作用

 

1. 1.负责数据的存储与读写
2. 2.周期性的向NameNode做心跳报告（节点状态、数据的状态和校验和）
3. 3.执行数据的流水线复制​

辅助管理者：SecondaryNameNode

1）作用

• 1.合并NameNode的edit logs到fsimage文件中
• 2工作流程

日志与镜像的定期合并总共分五步：

• 1.SecondaryNameNode通知NameNode准备提交edits文件，此时主节点产生edits.new
• 2.SecondaryNameNode通过http get方式获取NameNode的fsimage与edits文件（在 SecondaryNameNode的current同级目录下可见到 temp.check-point或者previous-checkpoint目录，这些目录中存储着从namenode拷贝来的镜像文件）
• 3.SecondaryNameNode开始合并获取的上述两个文件，产生一个新的fsimage文件fsimage.ckpt
• 4.SecondaryNameNode用http post方式发送fsimage.ckpt至NameNode
• 5.NameNode将fsimage.ckpt与edits.new文件分别重命名为fsimage与edits，然后更新fstime，整个checkpoint过程到此结束。 在新版本的hadoop中（hadoop0.21.0）,SecondaryNameNode两个作用被两个节点替换， checkpoint node与backup node. SecondaryNameNode备份由三个参数控制fs.checkpoint.period控制周期，fs.checkpoint.size控制日志文件超过多少大小时合并， dfs.http.address表示http地址，这个参数在SecondaryNameNode为单独节点时需要设置。
• 3）触发secondarynameNode合并文件的条件

1、时间维度， 默认一小时合并一次 ； 自定义需要添加如下配置进行修改

    dfs.namenode.checkpoint.period
    3600


2、次数维度，默认100万次合并一次；自定义需要添加如下配置进行修改

    dfs.namenode.checkpoint.txns
    1000000

---

HDFS副本机制：

eg： Hadoop 视硬件设备经常损坏为常态，为了防止硬件损坏导致系统不可用，所以构建多副本机制

• 1、第一份数据来源于用户的客户端所在节点，如果客户端在集群外，则按照一定的机制（cpu、内存、IO 使用率和节点磁盘剩余容量）随机选择一个节点

• 2、第二份数据存放在与第一份副本在同一个机架，不同的节点，按照一定的机制选取一个节点进行存放

• 3、第三份副本存放在与第一、第二副本不在同一机架，且逻辑距离最近的机架上，按照一定的机制，选择一个节点进行存放

---

HDFS高级命令：

特定文件夹下的副本数可以设置、存储容量可以设置，存储的文件个数可以设置

• 设置文件夹内文件的个数: hdfs dfsadmin -setQuota 50 /test（test本身算一个 所以test文件夹内最多有49个）
• 清除文件数量限制 hdfs dfsadmin -clrQuota /test
• 限制空间大小 hdfs dfsadmin -setSpaceQuota 100M /test (最多可以存储100M)
• 清除空间限额 hdfs dfsadmin -clrSpaceQuota /test
• 查看hdfs文件限额数量 hdfs dfs -count -q -h /test

---

如何将FsImage和Edits Log文件转换成XML进行查看？

FsImage数据的存放路径 :

     dfs.namenode.name.dir
    FsImage存放路径


Edits Log数据的存放路径 :

     dfs.namenode.edits.dir
    Edits Log存放路径


将edits文件转换成XML
hdfs oev -i edits_0000000000000000416-0000000000000000418 -p XML -o test001.xml
将Fsimage文件转换成XML
hdfs oiv -i fsimage_0000000000000000418 -p XML -o test002.xml

---

HDFS写入数据流程

步骤：

• 1.客户端通过调用FileSystem对象的create()来创建文件

• 2.客户端发起文件写入请求，通过RPC与NameNode建立通讯，NameNode检查目标文件，返回是否可以上传

• 3.client请求第一个block该传输到哪些DataNode服务器上

• 4.NameNode根据配置文件中指定的备份数量及机架感知原理进行文件分配，返回可用的DataNode的地址

• 5.Client 端和NameNode分配的多个DataNode构成pipeline管道

• 6.Client 调用FSDataOutputStream的write方法往pipeline管道里写packet数据，packet数据通过pipeline管道不断流向对应的DataNode节点上进行存储

• 6.当一个block块写入完成之后，客户端继续向NameNode获取下一个block块的位置信息，继续写入

• 7.当把所有块写入完成后，Client调用FSDataOutputStream.close()方法，关闭输出流

• 8.最后调用FileSystem.complete()方法，告诉NN节点写入成功

---

HDFS读取数据流程

步骤：

• 1.客户端通过调用FileSystem对象的open()来读取希望打开的文件

• 2.客户端向NameNode发起RPC请求，来确定请求文件block所在的位置

• 3.NameNode会视情况返回文件的部分或者全部block列表，对于每个block，NameNode 都会返回含有该 block副本的 DataNode 地址； 这些返回的 DN 地址，会按照集群拓扑结构得出 DataNode 与客户端的距离，然后进行排序，排序两个规则：网络拓扑结构中距离 Client 近的排靠前；心跳机制中超时汇报的 DN 状态为 STALE，这样的排靠后

• 4.Client调用FSDataInputStream的read方法读取数据，进行读取数据的的Client 选取排序靠前的 DataNode 来读取 block，如果客户端本身就是DataNode,那么将从本地直接获取数据(短路读取特性)

• 5.当读完一批的 block块后，若文件读取还没有结束，客户端会继续向NameNode 获取下一批的 block 列表，继续读取

• 6.所有block块读取完成后，Client调用FSDataInputStream.close()方法，关闭输入流，并将读取来所有的 block块合并成一个完整的最终文件

---

读写过程，数据完整性如何保持？

• 通过校验和。因为每个chunk中都有一个校验位，一个个chunk构成packet，一个个packet最终形成 block，故可在block上求校验和。

• HDFS 的client端即实现了对 HDFS 文件内容的校验和 (checksum) 检查。当客户端创建一个新的HDFS文件时候，分块后会计算这个文件每个数据块的校验和，此校验和会以一个隐藏文件形式保存在同一个 HDFS 命名空间下。当client端从HDFS中读取文件内容后，它会检查分块时候计算出的校验和（隐藏文件里）和读取到的文件块中校验和是否匹配，如果不匹配，客户端可以选择从其他 DataNode 获取该数据块的副本。

• 数据写入之后进行数据首次校验，文件系统周期性进行校验，防止数据丢失。

• 读取数据之前进行数据校验，若两个校验相同，那么表示数据没有丢失，开始读取数据。

• 若两个校验不相同，那么表示数据有部分丢失，换到其他节点（相同副本的节点）读取数据。

---

HDFS优点

• 1.高容错性

  • a.数据自动保存多个副本；通过增加副本的形式，提高容错性
  • b.某一个副本丢失以后，可以自动恢复，这是由 HDFS 内部机制实现的
• 2.适合批处理
  • a.计算向数据移动
  • b.数据位置暴露给计算框架
• 3.适合大数据处理
  • a.处理数据达到 GB、TB、甚至PB级别的数据
  • b.能够处理百万规模以上的文件数量
  • c.能够处理10K节点的规模
• 4.流式文件访问
  • a.一次写入，多次读取；文件一旦写入不能修改，只能追加
  • b.能保证数据的一致性
• 5.可构建在廉价机器上
  • a.通过多副本机制，提高可靠性
  • b.提供了容错和恢复机制

---

HDFS缺点

• 1.不擅长低延时数据访问

由于hadoop针对高数据吞吐量做了优化，牺牲了获取数据的延迟，所以对于低延迟访问数据的业务需求不适合HDFS。

• 2.不擅长小文件存储

存储大量小文件的话，它会占用 NameNode大量的内存来存储文件、目录和块信息。这样是不可取的，因为NameNode的内存总是有限的。

• 3.不支持并发写入

同一时间内，只能有一个用户执行写操作

• 4.不支持文件随机修改

仅支持数据末尾 append（追加），不支持文件的随机修改。

---

HDFS的安全模式

安全模式是HDFS的一种工作状态，处于安全模式的状态下，只向客户端提供文件的只读视图，不接受对命名空间的修改；同时NameNode节点也不会进行数据块的复制或者删除，如：副本的数量小于正常水平。

NameNode启动时，首先fsimage载入内存，并执行编辑日志中的操作。一旦文件系统元数据建立成功，便会创建一个空的编辑日志。此时，NameNode开始监听RPC和Http请求。但是此时NameNode处于安全模式，只接受客户端的读请求。

在安全模式下，各个DataNode会向NameNode发送自身的数据块列表，当NameNode有足够的数据块信息后，便在30秒后退出安全模式，若NameNode发现数据节点过少会启动数据块复制过程(基本不会)

当hadoop的NameNode节点启动时，会进入安全模式阶段。在此阶段，DataNode会向NameNode上传他们数据块的列表，让NameNode得到数据块的位置信息，并对每个文件对应的数据块副本进行统计。当最小副本条件满足时，即：一定比例的数据块都到达最小副本数，系统会退出安全模式。而这需要一定的延迟时间。当最小的副本条件未达到要求时，就会对副本数不足的数据块安排DataNode进行复制，直到达到最小的副本数。而在安全模式下，系统会处于只读装态，NameNode不会处理任何数据块的复制和删除命令。

在启动一个刚刚格式化的HDFS时系统不会进入安全模式，因为没有数据块。

HDFS安全模式相关的命令

hadoop dfsadmin -safemode leave   强制NameNode退出安全模式
hadoop dfsadmin -safemode enter   进入安全模式
hadoop dfsadmin -safemode get     查看安全模式状态
hadoop dfsadmin -safemode wait    等待一直到安全模式结束

---

2.MapReduce

待更新

3.Yarn

待更新

 

二、Hadoop1.0到Hadoop2.0的改进

Hadoop2.0主要添加了HA高可用和Federation联邦机制

 

1.HDFS HA

对于分布式文件系统HDFS ，NN是系统的核心节点，存储了各类元数据信息，并负责管理文件系统的命名空间和客户端对文件的访问。但是，在HDFS1.0中，只存在一个NN，一旦发生“单点故障”，就会导致整个系统失效。虽然有个SNN，但是它并不是NN的热备份，SNN主要功能在于周期性的从NN中获取FsImage和EditLog，进行合并后再发送给NN，替换掉原来的FsImage，以防止EditLog文件过大，导致NN失败恢复时消耗太多时间。合并后的FsImage在SNN中也保存一份，当NN失效时，可以利用SNN中的FsImage进行恢复。

由于SNN无法提供“热备份”功能，在NN发生故障时，无法立即切换到SNN对外提供服务，仍需要停机恢复。HDFS2.0采用了HA（High Availability）架构。在HA集群中，一般设置两个NN，其中一个处于“活跃（Active）”状态，另一个处于“待命（Standby）”状态。处于Active状态的NN负责对外处理所有客户端的请求，处于Standby状态的NN作为热备份节点，保存了足够多的元数据，在Active节点发生故障时，立即切换到活跃状态对外提供服务。

由于Standby NN是Active NN的“热备份”，因此Active NN的状态信息必须实时同步到StandbyNN。针对状态同步，可以借助一个共享存储系统来实现，如NFS(NetworkFile System)、QJM(Quorum Journal Manager)或者Zookeeper。Active NN将更新数据写入到共享存储系统，Standby NN会一直监听该系统，一旦发现有新的写入，就立即从公共存储系统中读取这些数据并加载到自己内存中，从而保证与Active NN状态一致。

此外，NN保存了数据块到实际存储位置的映射信息，即每个数据块是由哪个DN存储的。当一个DN加入到集群中时，它会把自己所包含的数据块列表给NN，定期通过心跳方式，以确保NN中的块映射是最新的。因此，为了实现故障时的快速切换，必须保证StandbyNN中也包含最新的块映射信息，为此需要给DN配置Active和Standby两个NN的地址，把块的位置和心跳信息同时发送到两个NN上。为了防止出现“两个管家”现象，还要保证在任何时刻都只有一个NN处于Active状态，需要Zookeeper实现。
 

2.HDFS Federation

在HDFS联邦中，设计了多个相互独立的NameNode，使得HDFS的命名服务能够水平扩展，这些NameNode分别进行各自命名空间和块的管理，不需要彼此协调。每个DataNode要向集群中所有的NameNode注册，并周期性的发送心跳信息和block块信息，报告自己的状态。

HDFS联邦机制拥有多个独立的命名空间，其中，每一个命名空间管理属于自己的一组块，这些属于同一个命名空间的块组成一个“块池”。每个DataNode会为多个块池提供块的存储，块池中的各个块实际上是存储在不同DataNode中的。