hadoop集群

Hadoop 底层结构说明

• Hadoop 底层结构说明
  • hadoop
  • HDFS
  • NameNode
    • NameNode何时修改edits
    • NameNode fsimage
  • secondaryNameNode（本文中简写为sNameNode）
    • sNameNode工作原理
    • 恢复NameNode数据
  • YARN
    • YARN 核心思想
    • ResourceManager
      • Scheduler
      • ApplicationManager
    • NodeManager
      • NodeManager职责
    • Container
    • ApplicationMaster
  • HA（High Availability）
    • HA解决方案
      • HA-Active和standby
    • HA如何工作
  • QJM（quorum Journal Manager）
    • QJM-EpochNumber
    • in-process恢复
  • DataNode
  • hadoop的组成

hadoop

Hadoop是由java语言编写的,在分布式服务器集群上存储海量数据并运行分布式分析应用的开源框架,其核心部件是HDFS与MapReduce。

HDFS

HDFS是一个分布式文件系统: 引入存放文件元数据信息的服务器NameNode和实际存放数据的服务器Datanode,对数据进行分布式储存和读取。

NameNode

将对文件系统的改动追加保存到本地文件系统上的一个日志文件（edits）。
当一个NameNode启动时，它首先从一个映像文件（fsimage）中读取HDFS的状态，接着应用日志文件中的edits操作。
然后它将新的HDFS状态写入（fsimage）中，并使用一个空的edits文件开始正常操作。
因为NameNode只有在启动阶段才合并fsimage和edits，所以久而久之日志文件可能会变得非常庞大，特别是对大型的集群。
日志文件太大的另一个副作用是下一次NameNode启动会花很长时间，因为出现了sNameNode。

NameNode何时修改edits

这个操作实际上是由DataNode的写操作触发的，当我们往DataNode写文件时，DataNode会跟NameNode通信
告诉NameNode什么文件的第几个block放在它那里，NameNode这个时候会将这些元数据信息写到edit logs文件中。

NameNode fsimage

NameNode启动时整个文件的快照。

secondaryNameNode（本文中简写为sNameNode）

定期合并fsimage和edits日志，将edits日志控制在一定的大小。
由于内存需求和NameNode在一个量级，一个量级的意思是，他们有相同的最新检查点目录，所以它一般会和NameNode运行在不同机器。
在需要时NameNode可以读取sNameNode的检查点镜像。
它是通过bin/start-dfs.sh脚本读取conf/master中指定的节点上启动。
它的检查点配置是由：
    1. fs.checkpoint.period 指定连续两次检查点最大时间间隔，默认1小时
    2. dfs.namenode.checkpoint.txns 定义NameNode上强制执行未检查事物的最大数量，默认100万。
       以上两个参数的意思是：先到先执行，即1小时到了执行合并，1小时未到但txns到100万了，立即执行。

sNameNode工作原理

1. 通知NameNode准备提交edit文件，此时主节点生成新的edit.new
2. 通过http get获取NameNode的fsimage和edit文件。（在sNameNode的current同级目录下存在temp.check-point或previous-checkpoint目录，
   这些就是NameNode copy过来的镜像文件）
3. 合并两个文件为fsimage.ckpt。（我理解这个后缀是check point的缩写）
4. 利用post请求将合并后的文件发送到NameNode。
5. NameNode将新文件和edit.new重命名为fsimage和edits，更新fstime。

恢复NameNode数据

NameNode上除了最新的检查点以外，假设NameNode上的历史fsimage和edit都丢失了。
1. 在配置参数dfs.name.dir指定的位置建立一个`空文件夹`。
2. 把检查点目录的位置赋值给配置参数fs.checkpoint.dir。
3. 启动NameNode，并加上-importCheckpoint。
NameNode从fs.checkpoint.dir目录读取检查点，并把它保存在dfs.name.dir目录下，如果dfs.name.dir目录下有合法的镜像文件，
NameNode启动失败，NameNode会检查fs.checkpoint.dir目录下镜像文件的一致性，但是不会去改动它。

YARN

在hadoop 2.0中引入的资源管理系统，由MR1（MapReduce）演化.

YARN 核心思想

将MR1的jobTracker的资源管理和任务调度分离。分别由ResourceManager资源管理和ApplicationManager任务调度进程实现。

ResourceManager

Yarn的Master进程，主要负责集群资源和任务分配。它又包括了Scheduler和ApplicationManager，一个负责调度，一个负责管理作业。

Scheduler

纯粹的资源调度器，不关心应用程序的任何状态，只受资源容量，队列等因素的影响。调度策略：FIFO,Fair scheduler,Capacity scheduler

ApplicationManager

负责接收job的提交请求，为应用分配第一个Container来运行ApplicationMaster,并监控ApplicationMaster，在出现错误时重启Container。

NodeManager

Yarn的slave进程，主要负责所在节点的资源和任务管理。会不断给ResourceManager发送Container的使用情况。

NodeManager职责

1. 接收RS的请求，分配Container给ApplicationMaster任务
2. 和RS通信确保集群健康，
3. 管理Container的生命周期
4. 管理节点上的日志
5. 执行Yarn的一些额外任务

Container

Yarn的计算单元，一个Container不能跨节点，但是一个节点会有多个Container，它由NodeManger监控，RS调度。

ApplicationMaster

主要是向ResourceManager的Schedueler申请资源（Container）和NodeManger交互来执行和监控task。

HA（High Availability）

这里指hadoop的NameNode的高可用。
在hadoop2.0之前NameNode是存在单点故障，如果NameNode宕机或者升级，整个集群将都不可用。

HA解决方案

HDFS HA功能通过配置Active/Standby两个NameNodes实现在集群中对NameNode的热备来解决上述问题。
如果出现故障，如机器崩溃或机器需要升级维护，这时可通过此种方式将NameNode很快的切换到另外一台机器。

HA-Active和standby

工作的NameNode，因任何原因导致不可用，将从standby选用一个顶上。

HA如何工作

1. 多台NameNode都保存一份元数据，但是只有active由写操作，其他的standby只有读权限。Edits放在一个共享存储中管理（QJM和NFS两个主流实现)
2. 每个NameNode都有一个zkfailover来管理自己，标识，并将标识注册到zookeeper，当需要切换时，由zkfailover复杂。
   但是在切换中要防止脑裂，也就是多个zkfailover同时切换。
3. 保证NameNode能够ssh无密登陆，多个节点能随时通信。

QJM（quorum Journal Manager）

QJM中主要包含JournalNode cluster-JNs，它是一致性存储系统，也是HDFS NameNode高可用的核心组件。
当两个缓冲区bufferCurrent和bufferReady，到达条件时就会触发交换操作.
如bufferCurrent在达到阈值时同时bufferRead的数据同步完成时，就会交换两者的指针。
当真的写入logSync同步成功后才会返回到成功码。
当在JournalNode接收到数据后，会判断跟随的EpochNumber是否合法，再判断日志事务ID是否合法，然后返回是否成功。

QJM-EpochNumber

epochNumber其实就是在一个NameNode成为active时得到的一个唯一且有序的id，每次切换NameNode就会+1。
当QJM得到一个新的id时，会发送到所有journalNode。
每个journalNode只会接受来自EpochNumber最大的消息，并且将消息保存到lastPromisedEpoch，并持久化。

in-process恢复

1. QJM 向所有JournalNode发送getJournalState
2. 所有JournalNode返回最新的lasPromisedEpoch
3. QJM收到大多数的Epoch后，选择其中最大的值+1，然后向JournalNode发送新的newEpoch请求
4. JournalNode收到新的Epoch后，开始和自己的lastPromisedEpoch比对，如果大于自己则返回EditLogSegment事物id，不大于则报错。
5. ActiveNameNode收到事物id后，使用最大的事物id进行数据恢复。向JournalNode发起预恢复的RPC请求，如多数JournalNode响应，则预恢复成功。
6. ActiveNameNode选择同步数据源，向JournalNode发送同意恢复的RPC请求，并将数据源作为参数传递。
7. JournalNode收到同意恢复的请求后，会从JournalNodeHttpServer下载EditLogSegment并替换，完成后返回成功。
8. ActiveName收到大多数JournalNode返回的成功后，会向JournalName发送FinalizedLogSegment来标识成功，更新自己的in-process为finalized。

DataNode

数据节点，一个数据块在DateNode以文件形式存储，一个数据文件，一个元数据文件。元数据主要存放数据文件长度，校验和时间戳。

DateNode工作流程

1. DataNode向NameNode注册，成功后会1小时上报一次所有的块信息
2. 心跳是每3秒一次，心跳返回中包含了NameNode给DataNode的命令。如删除某块或者迁移。如果10分钟+30秒没有收到心跳，则认为不可用。

<!-- 
    10'30'' = 2*dfs.namenode.heartbeat.recheck-interval + 10 * dfs.heartbeat.interval
    dfs.namenode.heartbeat.recheck-interval 单位：毫秒
    dfs.heartbeat.interval 单位：秒
 -->
<property>
    <name>dfs.namenode.heartbeat.recheck-interval</name>
    <value>300000</value>
</property>
<property>
    <name>dfs.heartbeat.interval</name>
    <value>3</value>
</property>

数据完整性保证

1. DataNode读取块时，会checkSum。
2. checkSum和块创建时值不一样，则认为块有损坏。
3. Client读取其他DataNode的块。
4. 文件创建后会周期性校验checkSum

crc（循环冗余校验）

发送方通过公示算出唯一值，附加在数据的最后传输，接收方进行相同计算，如果值不一致说明出错，接收方就可要求发送方重新发送。

配置目录说明

路径

cd 安装目录/etc/hadoop

配置分类

1. 只读配置 core,hdfs,yarn,mapred 已default结尾的文件。如: core-default.xml
2. 自定义配置 已site结尾，这也是搭环境需要关注和修改的配置。如: core-site.xml
3. 环境配置 以env结尾。如：hadoop-env.xml。启动参数都会在这里面配置