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指令，执行自定义脚本两道保障）