hadoop相关

NameNode：

NameNode 在整个HDFS中处于关键的位置，它保存了全部文件系统的元数据信息用来监控每一个DataNode的健康状态。只有NameNode知道数据从那里来，将要分配到哪里去，最后返回给谁。

DataNode会每3秒钟一次经过TCP 9000端口发送心跳给NameNode。每10次心跳生成一个健康报告，心跳数据都会包含相关该DataNode所拥有的数据块信息。该报告让NameNode知道不一样的机架上不一样的DataNode上存在的数据块副本，并为此创建元数据信息。

Name Node的重要性不言而喻，没有它，客户端将不知道如何向HDFS写入数据和读取结果，就不可能执行 Map Reduce 工做，所以，Name Node 所在的服务器应当是一个比较牛逼的服务器（热插拔风扇、冗余网卡链接、双电源等）。

若是 Name Node 没有接收到 Data Node 发送过来的心跳，那么它将会假定该 Data Node 已经死亡。由于有前面的心跳报告，所以 Name Node 知道该死亡的 Data Node 目前的工做内容以及进度，它将会将该 Data Node 所负责的内容分发给其余的 Data Node去完成。（一样根据机架意识来分发该任务）。

 

Secondary NameNode：

Secondary Name Node 在国内一般被称为辅助 Name Node 由于它并非一个完整备份， Secondary Name Node 的存在虽然是为了确保 Name Node 在宕机后可以接手其职责，可是它与 Name Node 之间的元数据交互不是实时的。默认为每隔 一小时，Secondary Name Node 会主动请求 Name Node，并从 Name Node 中拿到文件系统的元数据信息（同步）。这个间隔能够经过配置项来设置。

所以，若是万一 Name Node 宕机，虽然 Secondary Name Node 可以接手参加工做，可是依然会形成部分的数据丢失。所以，若是数据很是重要，默认的一小时同步一次可能远远不足以保护数据的计算进度，咱们能够缩短其同步时间来增长数据的安全性例如： 每分钟同步一次。

 

机架位感知：

因为hadoop的HDFS对数据文件的分布式存放是按照分块block存储，每一个block会有多个副本（默认是3），而且为了数据的安全和高效，因此hadoop默认对3个副本的存放策略为：

第一个block副本放在和client所在的node里（若是client不在集群范围内，则这第一个node是随机选取的）。

第二个副本放置在第一个节点不一样的机架中的node中（随机选择）、

第三个副本彷佛放置在与第一个副本所在节点同一机架的另外一个节点上

 

NameNode：存储元数据，元数据保存在内存中，保存文件block，DataNode之间的映射关系

DataNode：存储文件内容，文件内容保存在磁盘，维护了block id 到DataNode本地文件的映射关系

 

NameNode挂了怎么办，持久化元数据，操做日志（edit log）记录文件建立，删除，修改文件属性等操做。Fsimage:包含完整的命名空间，file->Block的映射关系 ，文件的属性（ACL，quota，修改时间等）

 

hadoop2.0的特性

支持CPU和内存两种资源调度方式，容许配置每一个节点、  每一个任务可用的CPU和内存资源总量
• 能够根据实际须要和CPU性能将每一个物理CPU划分红若干个  虚拟CPU。管理员可为每一个节点单独配置可用的虚拟CPU个数，用户程序也可指定每一个任务须要的虚拟CPU个数
• 可为每一个节点单独配置可用内存，采用线程监控的方案控制内存使用，发现任务超过约定的资源量会将其杀死
• Mesos等资源管理软件

基于zookeeper的HA原理和相关知识

非HA弊端
HDFS集群的分布式存储是靠namenode节点（namenode负责响应客户端请求）来实现。在非HA集群中一旦namenode宕机，虽然元数据不会丢失，但整个集群将没法对外提供服务，致使HDFS服务的可靠性不高，这在实际应用场景中显然是不可行的。
HA机制
已知致使服务可靠性不高的缘由是namenode节点宕机，那么怎么才能避免这个namenode节点宕机呢？一个容易想到的解决方案是部署两台namenode节点，造成主备模式（active/standby模式），这样一旦active节点宕机，standby节点当即切换到active模式。事实上HA机制就是采起的这种方案。要想实现该机制，须要解决如下问题：
1.为何选择主备模式，而不是主主模式（active/active模式），也即让两个namenode节点都响应客户端的请求
        一个显然的前提是，两台namenode节点须要保存一致的元数据。
        咱们知道namenode节点是用来管理这些元数据的，响应客户端请求时（上传）须要增长元数据信息，若是使用主主模式，那么两个节点都将对元数据进行写操做，怎么同步是个很困难的问题。所以，只能有一台机器响应请求，也即处在active状态的节点（可称为主节点），而另外一台namenode在主节点正常工做状况下仅用来同步active节点的元数据信息，这个namenode称为备用节点（处在standby状态），可见，要解决的问题主要是怎么同步active节点的元数据信息。

2.怎么同步两个namenode节点的元数据
      响应客户端请求的是active节点，所以只有active节点保存了最新的元数据。元数据分为两部分，一部分是刚写入新的元数据（edits），另外一部分是合并后的较旧的（fsimage）。HA机制解决同步问题的方法是将active节点新写入的edits元数据放在zookeeper集群上（zookeeper集群主要功能是实现少许数据的分布式同步管理），standby节点在active节点正常状况下只须要将zookeeper集群上edits文件同步到本身的fsimage中就能够。

       Hadoop框架为这个集群专门写了个分布式应用qjournal（依赖zookeeper实现），实现qjournal的节点称为journalnode。

3.怎么感知active节点是否宕机，并将standby节点快速切换到active状态？
        解决方案是专门在namenode节点上启动一个监控进程，时刻监控namenode的状态。对于处在active状态的namenode，若是发现不正常就向zookeeper集群中写入一些数据。对于处在standby状态的namenode，监控进程从zookeeper集群中读数据，从而感知到active节点是否正常。若是发现异常，监控进程负责将standby状态切换到active状态。这个监控进程在hadoop中叫作zkfc（依赖zookeeper实现）。

4.如何在状态切换时避免brain split(脑裂)？
        脑裂：active namenode工做不正常后，zkfc在zookeeper中写入一些数据，代表异常，这时standby namenode中的zkfc读到异常信息，并将standby节点置为active。可是，若是以前的active namenode并无真的死掉，出现了假死（死了一下子后又正常了，哈哈，是否是很搞笑），这样，就有两台namenode同时工做了。这种现象称为脑裂。

        解决方案：standby namenode感知到主用节点出现异常后并不会当即切换状态，zkfc会首先经过ssh远程杀死active节点的 namenode进程（kill -9 进程号）。可是（这样还不行，惊讶），若是kill指令没有执行成功咋办？？若是在一段时间内没有收到执行成功的回执，standby节点会执行一个自定义脚本，尽可能保证不会出现脑裂问题！这个机制在hadoop中称为fencing（包括ssh发送kill指令，执行自定义脚本两道保障）