1-Hadoop基础概念

Apache Hadoop有2个核心的组件，他们分别是：

HDFS： HDFS是一个分布式文件系统集群，它可以将大的文件分裂成块并将他们冗余地分布在多个节点上，HDFS是运行在用户空间的文件系统

MapReduce： MapReduce是函数式编程领域分布式计算中的一个编程模型，这个模型是专门用于查询/处理存储在HDFS中的大量数据

 

HDFS

NameNode

namenode将整个源数据维护在内存中，这有助于客户端接收快速响应读取请求。因此运行namenode的机器需要很大的内存。文件的数量越多，内存消耗的越多
namenode也维护存储在磁盘上的持久元数据，称为 fsimage
当在集群中 placed/deleted/updated文件时，这些操作会在edits文件中更新，更新edits日志后，在内存中的元数据也相应更新
每次写入操作都不会更新fsimage

重启namenode会发生以下事件:

1. 从磁盘读取fsimage文件加载到内存中
2. 读取edits日志文件中的每个操作，并把这些操作在内存中应用到fsimage
3. 把fsimage持久化到磁盘

 

Secondary namenode

因为fsimage文件并不会更新每次操作，而edits 日志文件可能会变得非常大，当namenode需要重启的时候，edits日志文件需要合并到fsimage,这会使得重启变得非常慢，而secondary namenode可以解决这个问题

secondary namenode负责定期执行合并来自namenode的edits日志文件和fileimage

如果namenode进程失败，可以利用secondary namenode合并的数据重建文件系统元数据，因为secondary namenode是定时 checkpoint数据，因此会存在一些数据丢失的情况

注意：secondary namenode并不是故障转移节点

1. 从namenode获取edits日志文件
2. 从namenode获取 fsimage文件
3. 将eidts日志中的所有操作应用到fsimage中
4. 把fsimage推送到namenode

上面的操作是周期性的执行，因此无论何时重启namenode，它都会有一个相对较新的fsimage,这样启动时间就会快很多

 

DataNode

datanode是负载存储实际文件的节点，这些文件作为数据块在集群中进行分割，通常是128MB大小的块，块的大小是可以配置的。Hadoop集群中文件块还会将自己复制到其他的datanode冗余，以便在datanode进程失败的时候不会丢失数据，datanode向namenode发送存储在该节点的文件块的信息，并响应所有的namenode文件系统的操作

 上图示例，文件A、B和C文件块被复制到集群多个节点上冗余，这确保了即使其中一个节点故障，数据仍然可用。这个集群的复制因子为3，表示文件文件块被复制了3次。namenode维护文件在集群中的位置列表，当有客户端需要访问一个文件，namenode会向客户端提供文件在哪个数据节点上，然后客户端会直接从数据节点访问文件

 

YARN

YARN是在Hadoop集群中处理数据的一个通用的分布式应用程序管理框架, YARN解决了一下两个重要问题：

• 支持大的集群（4000+节点）
• 能够运行MapReduce之外的其他应用程序已经存储在HDFS中的数据，例如MPI和Apache Giraph

YARN 资源管理框架包括 ResourceManager（资源管理器）、Applica-tionMaster、NodeManager（节点管理器）。各个组件描述如下

（1）ResourceManager
ResourceManager 是一个全局的资源管理器，负责整个系统的资源管理和分配。它主要由两个组件构成：调度器（Scheduler）和应用程序管理器（ApplicationManager，AM）。
Scheduler 负责分配最少但满足 Application 运行所需的资源量给 Application。Scheduler 只是基于资源的使用情况进行调度，并不负责监视/跟踪 Application 的状态，当然也不会处理失败的 Task。
ApplicationManager 负责处理客户端提交的 Job 以及协商第一个 Container 以供 App-licationMaster 运行，并且在 ApplicationMaster 失败的时候会重新启动 ApplicationMaster（YARN 中使用 Resource Container 概念来管理集群的资源，Resource Container 是资源的抽象，每个 Container 包括一定的内存、IO、网络等资源）。

（2）ApplicationMaster
ApplicatonMaster 是一个框架特殊的库，每个 Application 有一个 ApplicationMaster，主要管理和监控部署在 YARN 集群上的各种应用。

（3）NodeManager
主要负责启动 ResourceManager 分配给 ApplicationMaster 的 Container，并且会监视 Container 的运行情况。在启动 Container 的时候，NodeManager 会设置一些必要的环境变量以及相关文件；当所有准备工作做好后，才会启动该 Container。启动后，NodeManager 会周期性地监视该 Container 运行占用的资源情况，若是超过了该 Container 所声明的资源量，则会 kill 掉该 Container 所代表的进程。

提交作业给YARN一系列步骤

1. 当作业提交的集群，Client第一个接收到来自ResourceManager的应用程序ID
2. 接下来，Client将作业资源复制到HDFS中的一个位置
3. 然后，ResourceManager启动第一个容器NodeManager管理调出ApplicationMaster
4. ApplicationMaster基于要执行的作业，请求资源来自ResourceManager
5. 一旦ResourceManager调度具有请求的容器资源，ApplicationMaster联系NodeManager启动容器并执行任务。 在MapReduce作业的情况下，该任务将是一个map或reduce任务。
6. 客户端检查ApplicationMaster以获取状态更新提交的工作

 

The read/write operational flow in HDFS

为了更好的理解HDFS，我们需要知道 HDFS是如何进行以下操作的

• A file is written to HDFS
• A file is read from HDFS

HDFS uses a single-write, multiple-read model, where the files are writtern once and read several time.The data cannot be altered once written. However, data can be appended to the file by reopening it(只能追加，不能修改).All files in the HDFS are saved as data blocks.

 Writing files in HDFS

1.  client 告知namenode它想要write a file, namenode检查该文件是否已经存在
2.  如果存在，将会返回一个消息给client，如果不存在，namenode会给这个新文件创建一个metadata(元数据)
3.  client会将文件分成数据包并建立数据队列，然后将队列中的数据包以流的形式发送给集群中的datanode
4.  namenode维护了datanode信息列表，并且配置好了数据副本因子，namenode 提供datanode构建管道执行写入
5.  然后将来自数据队列中的第一个数据包传输到第一个datanode，第一个datanode存储了该数据block,然后复制给管道的下一个datanode，这个过程将一直持续到数据包被写入最后一个datanode
6.  每一个写在databode上的数据包，会进行确认发送给client
7.  如果数据包无法写入其中一个datanode,那么该datanode会从管道中 删除，并且把其余的数据包写入到正常的datanode. namenode意识到副本数不足，会安排另一个datanode进行复制
8.  写入所有数据包后，client执行关闭操作，指示数据队列中的数据包已完全传输
9. client通知namenode写操作已经完成了

 Reading files in HDFS

1. client连接namenode获取要读取的文件数据块的位置
2. namenode返回数据块所在datanode地址列表
3. 对于任何读取操作，HDFS会尝试使用datanode网络最接近client的数据返回
4. client有了列表后，就会连接datanode然后以流式进行读取数据块
5. 在一个datanode读取完块后，终止该datanode连接并与承载序列中下一个块的datanode进行数据块传输。这个过程将持续到该文件的最后一个块被读取完

 

HDFS高可用

使用hdfs高可用意味着它必须一直可用。因此，我们可以通过使用NameNode高可用来实现HDFS HA，以便它可以随时处理与hdfs相关的请求和查询。

再hadoop版本1和2中，有不同的方法来实现NameNode高可用：

　　hadoop版本1.x

       为了实现NameNode高可用性，有一个NameNode和一个Secondary NameNode。Secondary NameNode备份hdfs元数据，并在NameNode节点出现故障的情况下代理NameNode，但是有一个问题！Secondary NameNode不会自动代理NameNode。我们必须手动设置。因此，这会花费时间并降低生产率，并且在此期间，没有可用的NameNode来处理hdfs相关的请求。

　　hadoop版本2.x

　　有2个NameNode节点，其中一个处于Active状态，另一个处于Standy状态。Active状态的NN节点处理所有请求，NN(Standy)节点不断监视NN(Active)并同步hdfs edit日志。加入NN(Active)节点发生故障，那么NN(Standy)将立即变为NN(Active)，从上一个NN(Active)节点读取它同步的所有edit 日志，以保持最新状态，然后继续为客户端提供服务。

 　　为了保证数据的同步，加入了JournalNodes(JN)。两个NN节点都与一组JN的单独守护进程进行通信。当NN(Active)执行任何nameapce修改时，它会持久地将修改记录到这些JN中。Standy节点能够从JN读取edit内容，并不断的监视edit日志的修改并应用到自己的nameapce。发生故障转移时，standy将确保将自身升级为Active状态之前，已从JN完全同步edit内容。

　　JouralNode守护程序相对轻量级，并且必须至少包含3个JournalNode守护程序，因此必须将修改日志写入大多数JN。这将允许容忍单个节点的故障。但为了实际增加系统可以容忍的故障数量，我们应该运行奇数个（3,5,7等）。请注意，当与N个JournalNode一起运行时，系统最多可以容忍（N - 1） / 2  个故障，并继续正常运行。

 

 

HDFS HA - Automatic Failover（自动故障转移）

故障转移有两种类型：正常故障转移和自动故障转移。在正常故障转移中，我们必须手动启动故障转移以进行日常维护。

在自动故障转移的情况下，可通过zookeeper来实现。在两个namenode中，都有一个运行的客户端，简称为ZkFc，称为Zookeeper故障转移控件。ZkFc进程在Zookeeper中维护一个持久会话，并且还监视其namnode的运行状况。Active namenode zkfc进程通过zookeeper持有一个特殊的锁。如果Active NameNode发生故障，则zkfc会告诉Zookeeper，然后所有的namenode机器的zkfc进程都参与选举以获取Active NameNode的状态，称为Active NameNode。

 我们应该知道任何时间点必须仅有一个Active NameNode，并且仅允许Active NameNode写入到JN节点中。因此，有可能在选择了新的Active NameNode节点之后，先前的NameNode突然变为Active，并且可能处理过时的读取请求。因此这种情况下，JN节点需要一种防护方法。

JN有两种方法来防止自己为多个Active NameNode提供服务：

　　1、SSH Fence

在ssh fence方法中，它将SSH到先前的活动namenode并终止该进程。sshfence选项SSH到目标节点，并使用熔凝器杀死监听该服务的TCP端口的进程。为了使该防护选项起作用，它必须能够在不提供密码的情况下SSH到目标节点。因此，还必须配置一个名为的属性dfs.ha.fencing.ssh.private-key-files，该属性是一个用逗号分隔的SSH私钥文件列表

　　2、shell方法

在shell方法中，我们运行一个任意的shell命令来隔离活动的namenode。您必须配置该属性dfs.ha.fencing.methods，其值是Shell脚本的路径。如果shell命令返回退出代码0，则确定防护成功。如果返回任何其他退出代码，则防护不成功，并且将尝试列表中的下一个防护方法

 

HDFS Federation

我们知道，HDFS是主从的架构。NameNode 是leader，而DataNode是followers。将数据放入或移动到HDFS中之前，它必须首先通过NameNode进行索引。HDFS中的DataNode存储数据块，但是DataNode不了解其他DataNode或数据块。因此，如果NameNode发生故障，则它们将无法使用没有索引的数据块。

随着数据增长，NameNode存储的元数据越来越大，它不像DataNode一样可以缩放。为了解决这个问题，引入了HDFS Federation。

在当前的hdfs架构中，只有一个nameservice(命名空间)和一个blockstorage(块存储)。nameservice管理目录，文件和块。它支持文件系统操作，例如创建，修改，删除和列出文件和目录。blockstorage分为Block Manager和physical storage两部分。Block Manager维护集群中的DataNode成员资格。它支持与块相关的操作，如创建、删除和获取块的位置，并且还负责副本的放置和复制。physical storage存储块，并提供对它们读写访问。

在当前的架构中，nameservice和blockstorage紧密结合在一起，因此限制了其他人直接使用块存储或数据节点，这也限制了在单个NameNode节点中内存中容纳文件系统上支持的块，文件和目录的数量。下面让我们来看看HDFS Federation。

 在HDFS Federation架构中，我们可以通过引入多个NameNode来水平扩展NameNode，并且所有的NameNode彼此独立。它们具有自己的nameservice，也不需要彼此协调。所有的NamNode将DataNode用于块存储，每个DataNode向集群中的NameNode注册。DataNode定期发送心跳并报告，它们还处理来自Namenodes的命令。

有多个nameservice（NS1，NS2，…，NSn），每个nameservice均由其各自的NameNode进行管理。每个nameservice都有其自己的块池（NS1具有池1，NSk具有池k，依此类推）。从图中可以看到，池1中的块存储在DataNode 1，DataNode 2等上。同样，每个块池中的所有块都将驻留在所有DataNode上。块池实际上是一组属于单个nameservice的块。数据节点存储集群中所有块池的块。每个块池都是独立管理的。因此，它允许nameservice为新块生成块ID，而无需与其他NameNode进行协调。NameNode故障不会阻止数据节点为群集中的其他NameNode提供服务。

因此，该架构具有一些好处，例如可伸缩性，性能和隔离性，文件系统的吞吐量不受单个Namenode的限制。向群集添加更多Namenodes可以扩展文件系统的读/写吞吐量。很好地解决隔离问题。单个Namenode在多用户环境中不提供隔离。例如，实验性应用程序可能会使Namenode过载，并减慢生产关键型应用程序的速度。通过使用多个Namenode，可以将不同类别的应用程序和用户隔离到不同的nameservice。就像那里有一个devop的分离namenode和一个用于生产目的的分离namenode。它还具有设计上的好处，例如，它的设计和实现非常简单。namenode和nameservice彼此独立，对现有namenode的更改几乎不需要。Federation还保留了配置的向后兼容性。

 

YARN HA

YARN ResourceManage是调度应用程序并跟踪集群中的资源。在Hadoop2.4之前，只有单个ResourceManage，这是单点故障，因此在YARN HA特性中消除了这种隐患。

YARN HA可用性类似于HDFS高可用。Resource Manager HA是通过主/备架构实现的–在任何时间，RM之一都处于Active状态，并且一个或多个RM处于备用模式，等待活动发生任何事情来接管。启用自动故障转移后，从管理员（通过CLI）或通过集成的故障转移控制器触发向活动过渡的触发。如果未启用自动故障转移，则管理员必须手动将其中一个RM转换为Active。要从一个RM到另一个RM进行故障转移，他们应该首先将Active-RM转换为Standby，然后将Standby-RM转换为Active。所有这些都可以使用“ yarn rmadmin” CLI完成。

RM可以选择嵌入基于Zookeeper的ActiveStandbyElector，以确定哪个RM应该是Active。当Active发生故障或无响应时，另一个RM将自动被选为Active，然后接管。请注意，无需像HDFS那样运行单独的ZKFC守护程序，因为嵌入在RM中的ActiveStandbyElector充当故障检测器和领导者选举者，而不是单独的ZKFC守护进程。

当有多个RM时，预期客户端和节点使用的配置（yarn-site.xml）会列出所有RM。客户端，ApplicationMaster（AM）和NodeManager（NM）尝试以循环方式连接到RM，直到它们到达活动RM。如果活动服务器出现故障，他们将继续轮询，直到命中“新”活动服务器为止。此默认重试逻辑实现为org.apache.hadoop.yarn.client.ConfiguredRMFailoverProxyProvider。您可以通过实现org.apache.hadoop.yarn.client.RMFailoverProxyProvider并将yarn.client.failover-proxy-provider的值设置为类名来覆盖逻辑。

 

 

从图中可以看到，有两个资源管理器，一个是活动的，另一个是处于待机模式。活动资​​源管理器将其当前状态写入Zookeeper，如果活动资源管理器发生故障，则备用资源管理器将变为活动RM