1.Hadoop编译

总结一下在开发机上编译源码的小问题：
1.maven的setting.xml的配置

<mirror>
     <id>nexus-aliyun</id>
     <mirrorOf>central</mirrorOf>
     <name>Nexus aliyun</name>
     <url>http://maven.aliyun.com/nexus/content/groups/public</url>
</mirror>
<mirror>
     <id>cloudera</id>
     <mirrorOf>central</mirrorOf>
     <name>cloudera</name>
     <url>https://repository.cloudera.com/artifactory/cloudera-repos/</url>
</mirror>

2.编译源码里的pom.xml文件里的cloudera-repos的url去掉https的s

<repositories>
  <repository>
    <id>cloudera</id>
    <name>cloudera</name>
    <url>http://repository.cloudera.com/artifactory/cloudera-repos/</url>
  </repository>
</repositories>

注意：idea开发的时候s是不去掉也ok(好像去不去掉都ok 都可以打开url提供的页面)

3.由于网络问题有些 .pom、.jar下载不完整，决解办法：去maven本地仓库先删掉对应文件，然后wget 文件的url。

扩展小知识：
	   org/apache/avro/avro-parent/1.7.6-cdh5.15.1
	   对应maven的坐标是：g：a：v
	   即：org.apache.avro  ： avro-parent ： 1.7.6-cdh5.15.1

2.大数据的理解

1.存储（HDFS、Hive、HBase、Kudu）
2.计算 (Hive、sql、Spark、Flink)
3.资源作业调度（Yarn）
这三个方面，个人认为存储是最重要的，存储涉及到：同步设计、小文件、监控等。如果存储做的不好，计算写的天花乱坠也是没有用的。

3.HDFS HA & 伪分布式

对比较伪分布式再来引出HDFS的HA：

伪分布式：进程
   HDFS：namenode、snn、dn
   Yarn：rm、nm

企业里用的绝对是HDFS的HA，伪分布式的snn无法做到实时checkpoint，snn只是一个冷备。
那么企业是是需要是一个热备，做实时备份的：

nn节点挂掉，就不能提供对外服务，所以需要两个nn (active、standby)，任何时候只有1台 active的nn对外
另一台是standby 做实时的备份(热备) ，随时准备有standby-->active的状态，对外提供服务。外界是无感知的。

扩展小知识：

`客户端是通过什么同时对接两个nn呢？===》命名空间  （在配置文件里的）
命名空间：挂载着nn1、nn2，client读写操作就可以通过命名空间操作。

4.HDFS HA 机器进程（emmm以三台开发机为例）

首先去hadoop.apache.org官网查看，配置HA有两种QJM、NFS(类似百度网盘，百度一下nfs概念就明白了)，国内大部分是用QJM做HA的。下面的HA也是使用QJM做讲解。

1.HDFS HA 三台机器的进程

doublehappy001:  ZK  NN   zkfc(zookeeperFailoverControl)     jn(JournalNode)              DN 
doublehappy002:  ZK  NN   zkfc			                     jn                           DN
doublehappy003:  ZK                                          jn                           DN

jn：日志节点记录请求的记录

企业里：
		zk最好单独机器部署，不要和其他的进程放在一块，由于企业某些压力 进程放在一块可能（会造成）造成nn挂掉之后
		standby的nn切换active的时候切换不了。
		zk不是越多越好，多了选举的时候会相应慢。

经验：

jn: >=3台 2n+1
zk: 2n+1  投票选举
zk的台数设置：
    <=20节点 : 5台  
    20~100节点: 7/9/11台
     >100节点: 11台

2.Yarn HA 三台机器的进程

doublehappy001: ZK        NN          zkfc(zookeeperFailoverControl)        jn(JournalNode)  DN    RM   NM
doublehappy002: ZK        NN          zkfc			                        jn               DN    RM   NM
doublehappy003: ZK                                                          jn               DN         NM

Yarn HA它没有用jn ，这是HDFS HA & Yarn HA 的所有进程

扩展小知识：

主从架构 master --》slave 
    1.DN NM部署在同一个机器上  为了数据本地化  （spark那块，就是数据本地计算，不用经过网路传输到别的机器去算） 
    2.大数据生态圈 大部分组件都是主从架构  
    hbase组件 master regionserver  （这块注意hbase读写流程  一般的主从架构读写是要访问master的 而HBase不访问master）

5.HDFS HA架构图

HA使用active NN, standby NN两个节点解决单点问题。两个NN节点通过JN集群，共享状态，通过ZKFC选举active，监控状态，自动备援DN会同时向两个NN节点发送心跳。

扩展小知识：

双写
     生产上案例：
       1.结果双写
           spark-->hbase（所有的） + es（对外 2个月数据 ttl）
       2. 数据同步双写  
           A线(延迟了 半小时) B线(没有延迟 )   电商节假日 （开启ab线，如果只开a线，在重要节日数据激增情况下数据会延迟）

在这里插入图片描述

active nn：

接收client的rpc请求并处理，同时自己editlog写一份，也向JN的共享存储上的editlog写一份。
也同时接收DN的block report，block location updates 和 heartbeat

standby nn:

同样会接受到从JN的editlog上读取并执行这些log操作，使自己的NN的元数据和activenn的元数据是同步的，
所以说standby是active nn的一个热备。一旦切换为active状态，就能够立即马上对外提供NN角色的服务。
也同时接收DN的block report，block location updates 和 heartbeat

jn：

用于active nn,standby nn的同步数据，本身由一组的JN节点组成的集群，奇数，3台(CDH)，是支持Paxos协议。
保证高可用。

ZKFC：

监控NN的健康状态
向ZK集群定期发送心跳  ，让自己被选举，当自己被ZK选举为主时，zkfc进程通过rpc调用让nn转换为active状态

在这里插入图片描述

6.Yarn HA架构图

在这里插入图片描述
RM:

a.启动时会通过向ZK的/hadoop-ha目录写一个lock文件，写成功则为active，否则standby。
  standby RM会一直监控lock文件的是否存在，如果不存在就会尝试去创建，争取为active rm。
b.会接收客户端的任务请求，接收和监控nm的资源的汇报，负责资源的分配与调度，启动和监控 ApplicationMaster（AM）

NM:

节点上的资源的管理，启动container 容器 运行task的计算，上报资源，container情况汇报给RM和任务的处理情况汇报给 
ApplicationMaster（AM）

ApplicationMaster（AM）driver :

nm机器上的container
单个application(job)的task的管理和调度，并向rm进行资源的申请，
向nm发出 launch container指令，接收NM的task的处理状态信息。

RMstatestore:

a.RM的作业信息存储在ZK的/rmstore下，active RM向这个目录写app信息
b.当active rm挂了，另外一个standby rm成功转换为active rm后，会从/rmstore目录读取相应的作业信息，
重新构建作业的内存信息。然后启动内部服务，开始接收NM的心跳，构建集群资源的信息，并接收客户端的提交作业的请求等。

ZKFC:

自动故障转移 只作为RM进程的一个线程  而非独立的守护进程来启动

7.HDFS &Yarn HA架构区别

ZKFC：

   Yarn：只作为RM进程的一个线程，而非独立的守护进程来启动
HDFS：作为一个进程来启动

从节点心跳接收：

Yarn: 只有active的rm接受nm的心跳 standby不接受nm的心跳。
HDFS：active和standby 都接受dn心跳

active->standby切换：

Yarn：
     当active rm挂了，另外一个standby rm成功转换为active rm后，会从/rmstore目录读取相应的作业信息，
     重新构建作业的内存信息。然后启动内部服务，开始接收NM的心跳，构建集群资源的信息，并接收客户端的提交作业的请求。

HDFS：
    active nn 自己写editlog写一份，也向JN的共享存储上的editlog写一份，standby nn 同样会接受到从JN的editlog上
    读取并执行这些log操作，使自己的NN的元数据和activenn的元数据是同步的，所以说standby是active nn的一个热备。
    一旦切换为active状态，就能够立即马上对外提供NN角色的服务。

总结：

Yarn是active挂了之后去RMstatestore读取作业信息
HDFS是standby实时的去JN上读取editlog 使自己的NN的元数据和activenn的元数据是同步的。

体现出HDFS比Yarn的HA重要性，也体现出存储比计算重要。