Hadoop原理解析..docxVIP

HadoopHDFS设计原则硬件错误是常态而不是异常流式数据访问大规模数据集简单的一致性模型“移动计算比移动数据更划算” 异构软硬件平台间的可移植性特性容灾大容量/大吞吐量（水平扩展能力）为mapreduce计算设计的数据本地化能力系统结构名称节点（NameNode）管理元数据和文件块管理元数据指管理元数据信息。元数据信息包括名字空间、文件到文件块的映射、文件块到数据节点的映射三部分。管理文件块包括创建新文件块、文件复制、移除无效文件块以及回收孤立文件块等内容。（1）字空间或者文件到文件快的映射的任何修改，HDFS都会通过EditLog记录下来。保存到本地磁盘中。通过这种方式可以提高系统的可靠性，并凭借EditLog日志，误中恢复而不必担心数据的一致性问题。（2）块存放的位置信息并不固定而是经常发生变化，因此系统并没有将其持久化到本地中。NameNode启动后并不需要对DataNode进行维护，DataNode会周期性地向NameNode发生心跳响应汇报其文件块信息。（3）所有信息都保存在内存中，所以NameNode可以周期性快速地扫描元数据的状态，然后确定出哪些文件块由于DataNode宕机而需要重新复制，哪些件块需要被回收，哪些文件块需要在DataNode间进行迁移来保证系统的负载均衡等元数据元数据一般有三种类型，都会被保存在NameNode内存中文件（包括目录）的名称空间，如：/user/hongzhen.lm/search4tag/full/文件到文件块的映射，如：那个文件由几个文件块（Block）组成文件块的位置信息，组成Block的文件块持久化在那几个DataNode中。EditLog主要保存了元数据更改的历史信息（执行写操作，如新建文件或移动文件），因此具有非常重要的作用。EditLog不仅持久化记录了元数据信息，也记录了元数据修改顺序的逻辑时间线，而逻辑时间是对文件和文件块进行查找确认的唯一标识。因此，必须保证EditLog存储的安全性与可靠性。为了防止丢失整个文件系统或者客户端最近的几次操作记录，系统应保证在客户端对元数据的修改操作还没记录到EditLog之前，使该操作对其是不可见的。FsImageFsImage 文件是文件系统元数据的持久化检查点，磁盘上的元数据信息。当NameNode出现问题，是可以根据FsImage和EditLog 快速从错误中进行数据恢复，从而保存数据一致性fsImage文件不会更新文件系统的每个写操作，但是不影响系统的弹性，因为如果名称节点失败，其元数据的最新状态可以被重建，具体方式是从磁盘中将FsImage加载到内存，然后将此应用于编辑日志（EditLog）中的每个操作Secondary NameNode如前所述，editLog文件会无限增大，虽然在名称节点运行期间不会对系统产生影响，但如果名称节点发生重新启动，会发很长时间来运行editLog中的每个操作，所以将导致NameNode启动过慢情况。解决方案：并不是NameNode出现问题时候的备用节点，它和NameNode负责不同时期，主要功能是周期性将NameNode的元数据信息FsImage和EditLog合并，防止日志文件EditLog过大。合并后FsImage会在NameNode保存一份，保证NameNode失败可以进行恢复。二级NameNode通知NameNode生成新的EditLog，以后的日志都写到新的日志文件中，然后二级NameNode用那http get从NameNode获得FsImage以及旧的EditLog，然后二级NameNode将FsImage加载到内存中，并执行日志文件中的操作，然后生成新的FsImage.ckpt 再次二级NameNode将旧的FsImage以及旧的EditLog换为新的FsImage和新的EditLog,更新Fstime写入此次检查点发生的时间。这样NameNode中的FsImage保持了最新的checkPoint的元数据信息，日志文件也重新开始写入，保证了大小。管理员可以手工使用命令：hadoop dfsadmin –saveNamespace;大型集群。二级节点是需要专用机器的，因为需要将fsimage加载到内存中。内存成为瓶颈管理命名空间NameNode管理文件系统的命名空间。任何对文件系统元数据产生修改的操作，NameNode都会使用事务日志记录(下称EditLog)来表示；同样地，修改文件的副本系数也将往Editlog插入一条记录，NameNode将Editlog存储在本地操作系统的文件系统中。同时，文件系统的命名空间被存储在一个称为Fslmage的文件中，包括文件的属性、文件块到文件的映射以及文件块到数据节点的映射等内容，FsImage文件也是放在NameNode所在的本地