Hadoop

hadoop官网：

http://hadoop.apache.org/

Hadoop的思想之源：Google

面对的数据和计算难题
   大量的网页怎么存储
   搜索算法

带给我们的关键技术和思想

   GFS
   Map-Reduce

Hadoop创始人介绍

Hadoop作者Doug cutting，

就职Yahoo期间开发了Hadoop项目，

目前在Cloudera 公司从事架构工作

Hadoop简介

名字来源于Doug Cutting儿子的玩具大象

1> 2003~2004年，Google公开了部分GFS和MapReduce思想的细节，

以此为基础Doug Cutting等人用了2年业余时间实现了DFS和MapReduce机制，一个微缩版：Nutch

2> Hadoop于2005年秋天作为Lucene的子项目Nutch的一部分正式引入Apache基金会。2006年3月份，MapReduce

和Nutch Distributed File System(NDFS)分别被纳入成为Hadoop的项目中

分布式存储系统HDFS(Hadoop Distriuted File System)

   分布式存储系统

   提供了高可靠性、高拓展性和高吞吐率的数据存储服务

分布式计算框架MapReduce

   分布式计算框架

   具有已与编程、高容错性和高拓展性等优点

HDFS优点：

1> 高容错性：

   数据自动保存多个副本

   副本丢失后，自动恢复

2> 适合批处理：

   移动计算而非数据

   数据位子暴露给计算框架

3> 适合大数据处理：

   GB、TB、甚至PB级数据

   百万规模以上的文件数量

   10K+ 节点

4> 可构建在廉价机器上：

   通过多副本提供可靠性

   提供了容错和恢复机制

HDFS缺点：

1> 低延时数据访问

   比如毫秒级

   低延时与高吞吐率

2> 小文件存取

   占用NameNode大量内存

   寻道时间超过读取时间

3> 并发写入、文件随机修改

    一个文件只能有一个写者

    仅支持append

HDFS架构

HDFS架构-文件

1> 文件切分成块(默认大小128M)，以块为单位，每个块有多个副本存储在不同的机器上，副本数可在文件生成时指定(默认3)

2> NameNode是主节点，存储文件的元数据如文件名，文件目录结构，文件属性(生成时间、副本数、文件权限)，以及每个文件的块列表

以及块所在的DataNode等等

3> DataNode在本地文件系统存储文件块数据，以及块数据的校验和 ，可以创建、删除、移动或重命名文件，当文件创建、写入和关闭之后不能修改文件内容

HDFS架构-组件功能

HDFS架构-可靠性

1> 一个名字节点和多个数据节点

2> 数据复制(冗余机制)
    存放的位置(机架感知策略)

3> 故障检测
    数据节点
        心跳点(检测是否宕机)
        块报告(安全模式下检测)
        数据完整性检测(校验和比较)
    名字节点(日志文件，镜像文件)

4> 空间回收机制

HDFS数据存储单元(block)

文件被切分成固定大小的数据块

     默认数据块大小为64MB，可配置

     若文件大小不到64MB，则单独存成一个block

     Hadoop2.x，默认数据块大小为128MB

一个文件存储方式

     按大小被切分成若干个block，存储到不同节点上

     默认情况下每个block都有三个副本

Block大小和副本数通过Client端上传文件时设置，文件上传成功后副本数可以

变更，Block Size不可变更

HDFS设计思想：

NameNode(NN)

NameNode：中心服务器，负责文件元数据的操作，跟文件内容相关的数据流不经过NameNode,只会询问它跟哪个DataNode

联系，否则NameNode会成为系统的瓶颈

NameNode全权管理数据块的复制，它周期性地从集群中的每个DataNode接受心跳信号和块状态报告(Blockreport)。

接收到心跳信号意味着该DataNode节点工作正常。块状态报告包含了一个该DataNode上所有数据块的列表

NameNode主要功能：接受客户端的读写服务

NameNode保存：metadate信息包括

     文件owership和permissions

     文件包括哪些块

     Block保存在哪个DataNode(由DataNode启动时上报)

NameNode的metadate信息在启动后会加载到内存

     metadata存储到磁盘文件名为"fsimage"

     Block的位置信息不会保存到fsimage

     edits记录对metadata的操作日志

Hadoop NameNode元数据主要是两个文件edits和fsimage

fsimage文件是HDFS的最新状态(截止到fsimage文件创建时间的最新状态)文件

edits是自fsimage创建后的namespace操作日志

NameNode每次启动的时候，都要合并两个文件，按照edits的记录，把fsimage文件更新到最新

如果是一个大的、比较繁忙的集群，他的edits文件增长会非常快，这样下次NameNode重启的过程会非常慢，因为它要进行

大量的操作

SecondaryNameNode

它并不是NN的备份(但可以做备份)，他的主要工作是帮助NameNode合并edits log，减少NN启动时间

SNN执行合并时间

   根据配置文件设置的时间间隔fs.checkpoint.period 默认3600秒/(1个小时)

   根据配置文件设置edits log大小fs.checkpoint.size规定edits文件的最大值默认是64MB

Secondary NameNode操作流程：

1> Secondary NameNode定期地从NameNode上获取元数据。当它准备获取元数据的时候，就通知NameNode暂停写入edits文件

2> NameNode收到请求后停止写入edits文件，之后的log记录写入一个名为edits.new的文件

3> Secondary NameNode获取到元数据以后，把edits文件和fsimage文件在本机进行合并，创建出一个新的fsimage文件，

然后把新的fsiamge文件发送会NameNode

4> NameNode收到Secondary NameNode发回的fsimage后，就拿它覆盖掉原来的fsimage文件，并删除edits文件，把

edits.new重命名为edits

SNN(Secondary NameNode)合并流程

DateNode(DN)

DataNode负责处理文件内容的读写请求

存储数据(Block)

启动DataNode线程的时候会向NameNode汇报block信息

通过向NameNode发送心跳保持与联系(3秒一次)，如果NameNode10分钟没有收到DataNode的心跳，

则认为其已经lost，并copy其上的block到其他DN

1> 一个数据块在DataNode以文件存储在磁盘上，包括两个文件，一个是数据本身，一个是元数据包括数据块长度，

块数据的校验和，以及时间戳

2> DataNode启动后向NameNode注册，通过后，周期性(1小时)的向NameNode上报所有块信息

3> DataNode在本地文件系统存储文件块数据，以及块数据的校验和

4> 可以创建、删除、移动或重命名文件，当文件创建、写入和关闭之后不能修改文件内容

HDFS副本放置策略

HDFS写流程

HDFS读流程

HDFS文件权限

与Linux文件权限类似

r:read;w:write;x:execute,权限x对于文件忽略，对于文件夹表示是否允许访问其内容

如果Linux系统用户zhangsan使用hadoop命令创建一个文件，那么这个文件在HDFS中owner就是zhangsan。

HDFS的权限目的：阻止好人错错事，而不是阻止坏人做坏事。

HDFS相信，你告诉我你是谁，我就认为你是谁。

不安全的好处：速度快

安全模式

namenode启动的时候，首先将映像文件(fsimage)载入内存，并执行编辑日志(edits)中的各项操作。

1> 一旦在内存中成功建立文件系统元数据的映射，则创建一个新的fsimage文件(这个操作不
需要SecondaryNameNode)和一个空的编辑日志。

2> 此刻namenode运行在安全模式。即namenode的文件系统对于客服端来说是只读的。(显示
目录，显示文件内容等。写、删除、重命名都会失败)。

3> 在此阶段Namenode收集各个datanode的报告，当数据块达到最小副本数以上时，会被认
为是“安全”的， 在一定比例（可设置）的数据块被确定为“安全”后，再过若干时间，安
全模式结束

4> 当检测到副本数不足的数据块时，该块会被复制直到达到最小副本数，系统中数据块的位
置并不是由namenode维护的，而是以块列表形式存储在datanode中

NameNode启动时间取决于：

1> DataNode的数量

2> fsimage文件的大小->文件的大小很大、文件的数量很多

解决很多小文件问题：将这些小文件进行压缩，这样空间会大量的减少，但是你解压的时间会变长(没人这么做，都是用空间换时间)

一般情况下将小文件合成大文件

SNN恢复NN

模拟NameNode故障以从SecondaryNameNode恢复

场景假设：如果NameNode上除了最新的检查点以外，所有的其他的历史镜像和edits文件都丢失了，NameNode

可以引入这个最新的检查点以恢复。

具体模拟步骤如下：

1> 在配置参数dfs.name.dir指定的位置建立一个空文件夹
2> 把检查点目录的位置复制给配置参数fs.checkpoint.dir
3> 启动NameNode，并加上-importCheckpoint

NameNode会从fs.checkpoint.dir目录读取检查点，并把它保存在dfs.name.dir目录下。

如果dfs.name.dir目录下有合法的镜像文件，NameNode会启动失败

NameNode会检查fs.checkpoint.dir目录下镜像文件的一致性，但是不会去改动它

Backup Node

Secondary NameNode 和 CheckPoint Node都只是提供一个fsimage更新和检查点备份(备份数据较旧，数据不一致)，

并不提供NameNode服务

Backup Node工作原理：

1> Backup Node在内存中维护了一份从NameNode同步过来的fsimage，同时它还从NameNode接受edits文件的日志流，

并把它们持久化硬盘

2> Backup Node把收到的这些edits文件和内存中的fsimage文件进行合并，创建一份元数据备份 

3> Backup Node高效的秘密就在这儿，它不需要从NameNode下载fsimage和edit，把内存中的元数据持久化到磁盘然后

进行合并即可

Hadoop集群只支持一个Backup Node，如果Backup Node出了问题，元数据的备份机制也就失效了