大数据学习笔记之Hadoop的一些机制

作业调度机制

作业调度有3个调度方式：

①FIFO（先进先出） ：每个作业都会使用整个集群，只有轮到自己猜能享受服务

②容量调度：每个队列采用的调度策略是FIFO算法，默认情况下不支持优先级抢占。

③公平调度 ：公平调度器按作业池来组织作业，会按照提交作业的用户数将资源公平地分到作业池。默认情况下，每一个用户游泳一个独立的作业池，而不会管他们提交了多少作业。在每一个资源池里，会用公平共享的方法在作业之间共享容量。可设置最少共享资源。当作业所需的全部资源小于最小资源时，额外的资源会被其他作业池间进行切分。公平调度支持作业抢占，抢占也不会导致被抢占的作业失败，只是会让运行时间变长。

 

错误处理机制

硬件故障

①JobTracker故障。在Hadoop集群中，JobTracker只有一个，是所有错误中最严重的（在2.x版本，JobTracker分解为ResourceManager和ApplicationMaster），无相应的解决方法

②TaskTracker故障。TaskTracker通过心跳与JobTracker通信，如果JobTracker一段时间内没有收到心跳，则会移除该TaskTracker的任务，并把任务分给其他的TaskTracker。

③任务失败。对于失败的任务（死循环，因代码缺陷崩溃，运行时间过长），TaskTracker会通过心跳向JobTracker汇报，并JobTracker会重新分配任务，当失败次数达到一定的阈值，整个作业将失败。

 

作业推测性执行

当JobTracker检测到任务中存在运行的特别慢的任务时，会启动另一个相同的任务做备份，两个任务只要有一个完成，即会kill掉另一个任务。默认开启作业推测性执行策略。

注意：①对于由代码缺陷导致任务执行慢的，启动备份并不能解决问题

②在推测性执行下，会有两个任务向同一个文件进行写操作，而且任务失败时，也会存在一个旧文件（Hadoop不支持多用户向同一个文件进行写操作，并且MR程序中的设置输出文件不能存在）。Hadoop会通过将输出写到临时文件夹来解决。如果任务失败了，则会先删除旧的输出文件。如果任务成功了，则再将临时文件内容复制到输出目录。

 

JVM重用（略）

跳过坏记录（略）

 

数据备份与恢复

NameNode在内存中保存着整个文件系统的名字空间和文件数据块的地址映射(Blockmap)。如果NameNode宕机，那么整个集群就瘫痪了。

元数据信息

文件名，文件目录结构，文件属性(生成时间，副本数，权限)每个文件的块列表。
以及列表中的块与块所在的DataNode之间的地址映射关系
在内存中加载文件系统中每个文件和每个数据块的引用关系(文件、block、datanode之间的映射信息)
数据会定期保存到本地磁盘，但不保存block的位置信息而是由DataNode注册时上报和在运行时维护

NameNode的文件结构

${dfs.name.dir}/current/VERSION

                                    /edits

                                    /fsimage

                                    /fstime

VERSION文件包含namespaceID，layoutVersion等信息，其中在文件系统第一次被格式化的时候会创建namespaceID，而DataNode中的VERSION文件中的namespaceID，layoutVersion等信息和NameNode的一样。DataNode不需要进行格式化，namespaceID会在第一次连接NameNode时，从中获取。所以多次格式化可能导致NameNode和DataNode的版本号不一致错误。各个节点的版本号要一致，否则系统无法正常运行。

edis文件

当客户端执行写操作的时候，NameNode会先再编辑日志写下记录，然后对元数据进行更新，并刷新和同步所有副本。

fsimage文件

fsimage文件是文件系统元数据的永久性检查点，包含文件系统中的所有目录和文件inode的序列化信息。如果NameNode失败，可以通过读取fsimage文件，然后重新执行编辑日志中的操作进行数据恢复。（inode表示一个文件或者目录的信息，以及文件副本数，修改和访问时间等）

 

如果不分开fsimage和edits，那么每次操作都要修改fsimage。当fsimage很大时，每次进行写操作的时候就会很慢。所以需要将元数据和操作日志分开，并且通过secondary NameNode来进行fsimage和edits的合并（在2.x版本中，有Active NameNode和Standby NameNode来保证高可用性），同时合并也能防止edits文件越来越大，防止NameNode启动太慢。合并过程称为checkpoint。

 

checkpoint过程

①secondary NameNode请求NameNode停止使用edits文件。将新的记录写到一个新的文件。

②secondary NameNode从NameNode中通过http get方法获取fsimage和edits。

③secondary NameNode读取fsimage到内存，并执行edits中的每个操作，创建新的fsimage

④secondary NameNode通过http post将新的fsimage传回给NameNode

⑤NameNode用新的fsimage替换旧的fsimage，新的edits替换旧的edits。同时更新fstime文件来记录检查点执行的时间。

 

Import Checkpoint（恢复数据） （摘抄于https://www.cnblogs.com/xd502djj/p/4425990.html）

如果主节点挂掉了，硬盘数据需要时间恢复或者不能恢复了，现在又想立刻恢复HDFS，这个时候就可以import checkpoint。

①拿一台和原来机器一样的机器，包括配置和文件，部分配置要改成NameNode的配置

②创建一个空的文件夹，该文件夹就是配置文件中dfs.name.dir所指向的文件夹。

③拷贝你的secondary NameNode checkpoint出来的文件，到某个文件夹，该文件夹为fs.checkpoint.dir指向的文件夹

④执行命令bin/hadoop namenode -importCheckpoint

 

Hadoop2.x HA(摘抄于https://my.oschina.net/u/189445/blog/661561）

在hadoop2.X中通常由两个NameNode组成，一个处于active状态，另一个处于standby状态。Active NameNode对外提供服务，而Standby NameNode则不对外提供服务，仅同步active namenode的状态，以便能够在它失败时快速进行切换。

两个NameNode为了数据同步，会通过一组称作JournalNodes的独立进程进行相互通信。当active状态的NameNode的命名空间有任何修改时，会告知大部分的JournalNodes进程。standby状态的NameNode有能力读取JNs中的变更信息，并且一直监控edit log的变化，把变化应用于自己的命名空间。standby可以确保在集群出错时，命名空间状态已经完全同步了。

为了确保快速切换，standby状态的NameNode有必要知道集群中所有数据块的位置。为了做到这点，所有的datanodes必须配置两个NameNode的地址，发送数据块位置信息和心跳给他们两个。 

对于HA集群而言，确保同一时刻只有一个NameNode处于active状态是至关重要的。否则，两个NameNode的数据状态就会产生分歧，可能丢失数据，或者产生错误的结果。为了保证这点，JNs必须确保同一时刻只有一个NameNode可以向自己写数据。 

JournalNode服务器：运行的JournalNode进程非常轻量，可以部署在其他的服务器上。注意：必须允许至少3个节点。当然可以运行更多，但是必须是奇数个，如3、5、7、9个等等。当运行N个节点时，系统可以容忍至少(N-1)/2(N至少为3)个节点失败而不影响正常运行

在HA集群中，standby状态的NameNode可以完成checkpoint操作，因此没必要配置Secondary NameNode、CheckpointNode、BackupNode。如果真的配置了，还会报错。