回顾Hadoop重点知识
我们先来回顾一下Hadoop的一些重要的知识点，虽然在工作中几乎没啥用，但是这些知识点我们需要知道，有助于我们对Hadoop认识。他山之石，可以攻玉，很多知识点都是互相借鉴的。
HDFS 读流程
1.Client通过Distributed FileSystem模块的open(filePath)向NameNode请求下载文件。
2.NameNode检查文件是否存在,该用户是否有权限查看，如果没有返回错误信息，否则返回该文件的部分或全部的block列表。（FSDataInputStream对象）
3.Client调用FSdataInputStream对象的read()方法。
4.就近去Block1的所在的DataNode进行read，读取完后，会校验。假如成功，会关闭与当前DN的通信。假如check fail，会记录失败的快+DN信息，下次就不会再去读取。
5.然后去最近的DataNode读取Block2的数据，同步骤4一样，如果失败就会去Block2的第二个DN上读取。
6.去第二个DN获取Block2数据。
7.Client调用FSDataInputStream.close()，关闭输入流。
整个流程是无感知。
HDFS写流程
1.Client通过Distributed FileSystem模块的create向NameNode请求写操作。
2.NameNode会检查该路径下的文件是否已经存在，用户是否用权限去写。假如检查失败，会抛出失败信息，否则就创建一个新文件，但是不关联任何Block，返回一个FSDataOutputStream对象。
3.Client调用FSDataOutputStream对象的write方法。
4.FSDataOuputStream对象将第一个块信息写入第一个DataNode，DataNode1写完就传输给DataNode2，DataNode2写完就传输给DataNode3.
5.当DataNode3写完就返回一个 act packet给DataNode2,DataNode2接受DataNode 3的act packet，就发送act packet给DataNode1，当DataNode1 接受到DataNode2 的act packet就会向FSDataOutputStream发送act packet，表示第一个块的 三个副本写完，其他块也依次这样写入。
6.当全部文件写完，Client调取对象FSDataOutputStream的close方法，关闭输出流。Flush缓存区的数据包。
7.Client会再次调取Distributed FileSystem的complete方法，告诉NameNode写入成功。
YARN的工作流程
- 1.用户向Yarn提交应用程序，首先找Resource Manager 分配资源，ResourceManager开启一个container，在container中运行一个Application Manager
- 2.Application Manager找一台Nodemanager启动Application master，计算任务所需的资源
- 3.Application Master首先向ResourceManager注册，这样用户就可以通过ResourceManager查询应用程序的运行状态。然后Application将为各个任务申请资源并监控任务的运行状态，知道任务结束。即重复4-7
- 4.ApplicationMaster采用轮询的方式通过RPC协议向ResourceScheduler申请资源和领取资源
- 5.一旦ApplicationMaster申请到资源后，便和它对应的NodeManager通信，将资源分配给NodeManager并要求NodeManager启动任务。
- 6.NodeManager为任务设置好运行环境（包括环境变量、JAR包、二进制程序等）后，将任务启动命令写到一个脚本中并通过运行该脚本来启动任务。
- 7.各个任务通过某个RPC协议向ApplicationMaster汇报自己的状态和进度，以让ApplicationMaster随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。在应用程序运行过程中，用户可以随时通过RPC向ApplicationMaster查询应用程序的当前运行状态
- 应用程序运行完后，ApplicationMaster想ResourceManager注销并关闭自己。
HDFS的HA
HDFS HA的角色说明
HDFS HA架构说明
- 使用2n+1台JN存储editlog，每次写书操作有大多数(大于N+1)返回成功，认为该次写成功，数据不会丢失。（Pasxo算法）
- 在HA架构里面的Secondary NameNode这个角色已经不存在了，为了使standyby NN实时与Active NN元数据保持一致，他们之间交互通过一系列的轻量级进程JournalNode
- 任何操作在Active NN上执行的，JN进程同时也会记录editlog到至少半数以上的JN中，这时Standy NN检测到JN里面的同步log发生了变化，会读取JN里面的editlog,然后同步到自己的目录镜像书里面。
- 当Active NN发生故障的时，Standy NN会在它成为Active NN之前，会同步一次JN里面的editlog，这样就能保持与挂了的Active NN的fsimage一致。然后无缝切换，成为Active NN。达到高可用的目的
- DataNode的fencing:确保只有NN能命令DN。
- 每个NN改变状态的时候，想DN发送自己的状态和一个序列号
- DN在运行过程中维护此序列号，当failover时，新的NN在返回DN心跳时会返回自己的active状态和一个更大的序列号。DN接受到这个返回则认为该NN为新的Active
- 如果此时原来的active NN恢复，返回给DN的心跳信息包含active状态和原来的序列号，此时DN会拒绝这个NN的命令
- 客户端的fencing：确保只有一个NN能响应客户端请求，让访问Standby NN的客户端直接失败。在RPC层封装了一层，通过FailoverProxyProvider以重试的方式连接NN。通过若干次连接一个NN失败后尝试连接新的NN，对客户端的影响是重试的时候增加一定的延迟。客户端可以设置重试次数和时间。
ZKFC架构说明
- Hadoop提供了ZKFailoverControllor角色，部署在每个NameNode节点上，作为一个Deamon进程，简称ZKFC。它订阅HealthMonitor 和ActiveStandbyElector的事件，并管理NameNode的状态,如下图所示
ZKFailoverController主要包括三个组件：
- 1.HealthMonitor：监控NameNode是否处于unavailable或者unhealthy状态，当前通过RPC调用NN相应的方法完成。
- ActiveStandbyElector：管理和监控自己在ZK中的状态
ZKfailoverController主要职责：
- 健康监测：周期性的向它监控的NN发送健康探测命令，从而来确定某个NameNode是否处于健康状体，如果机器宕机，心跳失败，那么zkfc会标记它处于一个不健康状态。
- 会话管理：如果NN是健康的，zkfc就会在zookeeper中保持一个打开的会话，如果NameNode同时还是Active状态，那么zkfc还会在Zookeeper中华专有一个类型为EPHEMERAL_SEQUENTIAL（临时顺序）的znode，当这个NN挂掉，那么这个znode会被删掉，然后备用的NN的znode会得到这个锁，升级为主NN，同时标记为Active
- 当宕机的NN重新启动，它会再次zookeeper上注册一个znode，排队等待得到锁，然后自动变成Standby站台，如此往复循环，保证高可靠。
- active选举：如上所述，会在zookeeper维持一个znode，来实现抢占式的锁机制，判断哪个NN为Active。
HDFS的Federation
- 单Active NN的架构使得HDFS在集群扩展和性能上都有潜在的问题，当集群大到一定程度后，NN进程使用的内存可能会达到上百G，NN成为了性能瓶颈。
- 常用的估算公司为1G对应一百万个块，按缺省大小计算的话，大概是64T（这个估算比例是比较大 的富裕的，其实即使每个文件只有一个块，所有元数据信息也不会有1kb/block）
- 为了解决这个问题，Hadoop 2.x提供了HDFS Federation
- 多个NN共用一个集群的存储资源，每个NN都可以单独对外提供服务
- 每个NN都会定义一个存储池，有单独的id，每个DN都为所有存储池提供存储
- DN会按照存储Id向其对应的NN汇报块信息，同时，DN会向所有NN汇报本地存储可用资源情况。
- 如果需要在客户端方便的访问若干个NN上的资源，可以使用客户端挂载表，把不同的目录映射到不同的NN，但是NN上必须存在相应的目录
- 设计优势
- 改动最小，向前兼容，现有的NN无需任何配置改动；如果现有的客户端只连某台NN的话，代码和配置也无需改动
- 分离命名空间管理和块管理
- 客户端挂载表：通过路径自动对应NN，是Federation配置改动对应用透明
YARN 的HA
YARN HA的角色说明
- 1.ZKFC:只作为RM进程的一个线程（与HDFS的不一样，HDFS的ZKFC是以一个轻量级守护进程运行的）
- 2.RMStateStore:
- a.Rm把Job作业信息存储在ZK里面的/rmstore下，RM Active会向这个目录写App信息
- b.当RM(active)挂了，例外的一个RM(standby)成功切换active状态，会从ZK这个/rmstore里面读取相应的作业信息，重新构建作业内存信息，启动内部服务，开始接受NodeManager的心跳，构建集群资源信息，并接受用户的作业提交请求。
- 3.RM
- a. 启动的时候会向ZK注册一个Znode并申请一个分布式锁，如果成功，就会成为active，否则就是standby。
- b. standby会一直监控这个分布式锁，一旦锁释放(RM active挂了或者运行不良)就会去竞争这个锁，假如成功就成为新的active。
- c. 启动和监控ApplicationMaster on NodeManager的container
- NM
- 节点资源管理
- 启动container运行task计算
- 上报资源
- 汇报task给ApplicationMaster
YARN的HA架构
注意：
- NM只向RM(active)节点汇报心跳和汇报资源情况(与HDFS不同，HDFS是DN会向NN(active & standby)都汇报)