十万个为什么（hadoop 1期）？

纳尼？纳尼？纳尼？

1.什么是map的数据本地化优化？

    Hadoop 在存储有输入数据(hdfs中的数据)的节点上运行map任务，可以获得最佳性能，因为他无需使用宝贵的集群带宽资源。这就是所谓的数据本地化优化，但是有时对于一个map任务的输入分片来说，存储该分片的hdfs数据块副本的所有节点可能正在运行其他map任务，此时作业调度需要从某一数据块所在的机架中的一个节点上寻找一个空闲的map槽(slot)来运行该map任务分片。仅仅在非常偶然的情况下，会使用其他机架中的节点运行该map 任务，这将导致机架与机架之间的网络传输。

2.为什么map最佳分片大小与块大小相同？

    因为它是确保可以存储在单个节点上的最大输入块的大小，如果分片跨越两个数据块，那么对于任何一个hdfs节点，基本上都不可能同时存储这两个数据块，因此分片中的部分数据需要通过网络传输到map任务运行的节点，与使用本地数据运行整个mao任务相比，这种方法显然效率更低。

3.map任务将其输入写入本地硬盘，而非hdfs,这是为什么？

    因为map的输出是中间结果，该中间结果由reduce任务处理后才产生最终输出结果，一旦完成，map的输出结果就可以删除。因此如果把他存储在hdfs中并实现备份，难免有些小题大做。如果运行map任务的节点在将map中间结果传送给reduce任务之前失败，hadoop 将在另一个节点上重新运行这个map以再次构建map中间结果。

    Hdfs 的块比磁盘的块大，其目的是为了最小化寻址开销。如果块足够大，从磁盘传输数据的时间会明显大于定位这个块开始位置所需的时间。因而，传输一个由多个块组成的大文件的时间取决于磁盘传输速率。

但是这个参数也不会设置的过大，mr中的map任务通常一次只处理一个块中的数据，因此如果任务数太少，作业的运行速度就会比较慢。 

5.hdfs 中块进行抽象的好处是什么?

 >1 一个文件的大小可以大于网络中任意一个磁盘的容量。文件的所有块并不需要存储在同一个磁盘上。

 >2 使用抽象块而非整个文件作为存储单元，大大简化了存储子系统的设计。对于故障种类繁多的分布式系统来说尤为重要

 >3 块还非常适合用于数据备份进而提供数据容错能力和提高可用性 

6.hadoop 对于namenode单点问题有哪些容错机制？

>1 备份那些组成文件系统运输局持久状态的文件，Hadoop 可以通过配置使namenode在多个文件系统上保存元数据的持久状态。这些写操作是实时同步的，且是原子操作。一般的配置是，将持久状态写入本地磁盘的同时，写入一个远程挂载的网络文件系统(NFS)。

 >2 运行一个辅助namenode,但它不能被用作namenode,这个辅助namenode的重要作用是定期合并编辑日志与命名空间镜像，以防止编辑日志过大。这个辅助namenode 一般在另一台单独的物理计算机上运行，因为他需要占用大量cpu时间，并且需要与namenode 一样多的内存执行合并操作。 

7.hadoop2 对hdfs 高可用(HA)是怎么做的？

    配置活动-备用(active-standby)namenode,当活动namenode失效，备用namenode就会接管他的任务并开始服务与来自客户端的请求，不会有任何明显中断。

    1.namenode之间通过高可用共享存储(NFS或QJM)实现编辑日志的共享，只有活动namenode才能对外提供读写服务，活动namenode把editlog写入JN中，备用namenode从JN中获取editlog合并到FsImage中，当备用的namenode接管工作之后，它将通读共享编辑日志直至末尾，以实现与活动namenode的状态同步，并继续读取由活动namenode写入的新条目。

    2.datanode同时向namenode发送数据块处理报告，因为数据块的映射信息存储在namenode的内存里，而非磁盘。

    3.客户端需要使用特定的机制来处理namenode的失效问题，这一机制对用户是透明的

    4.辅助namenode的角色被备用namenode所包含，备用namenode为活动namenode命名空间设置周期性检查点

    5.为了实现热备，增加FailoverController(故障转移控制器)和Zookeeper，FailoverController与Zookeeper通信，通过Zookeeper选举机制，FailoverController通过RPC让NameNode转换为Active或Standby。 

知识点：

NFS(Network File System 网络文件系统)

   NFS作为active namenode和standby namenode之间数据共享的存储。

   active namenode会把最近的edits文件写到NFS，而standby namenode从NFS中把数据读过来。

   这个方式的缺点是，如果active或standby有一个和NFS之间网络有问题，则会造成他们之前数据的同步出问题。并且不能保证同一时间只有一个namenode向NFS中写入数据

QJM(Quorum Journal Manager 群体日志管理器)【目前hadoop2.x使用】

   QJM是一个专用的HDFS实现，提供了一个高可用的编辑日志。这种方式可以解决上述NFS容错机制不足的问题。

   同一时间QJM仅允许一个namenode向编辑日志中写入数据。

故障转移控制器(failover controller)，管理着将活动namenode转移为备用namenode的转换过程。有多重故障转移控制器，但默认的一种是使用了zookeeper来确保有且仅有一个活动namenode。每一个namenode运行着一个轻量级的故障转移控制器。其工作就是监视宿主namenode是否失效(通过一个简单的心跳机制实现)并在namenode失效时进行故障转移管理员也可以手动发起故障转移，例如在日常维护时。

JN:active和standby之间是通过一组日志节点journal node(数量是奇数，可以是3,5,7...,2n+1)来共享数据。active把最近的edits文件写到2n+1个journal node上，只要有n+1个写入成功,就认为这次写入操作成功了。然后standby就可以从journalnode上读取了。QJM方式有容错的机制，可以容忍n个journalnode的失败。