1.Hadoop历史

1.Hadoop要解决的问题

1.问题：1台内存只有1G的计算机，如何在1个1T的文件查找重复的两行？

解决办法：由于计算机内存不能放下全量数据，因此计算机每次处理1行，并求hash值，hash值相同则说明两行相同。 求hash半小时，排序半小时。
改进1：每次处理1万行（假设1万行的总大小还是小于1G），并求hash。假设每次处理时间为2秒，则总的处理时间为 2*(1T/1万行的文件大小)（相比前面减少IO次数）。
改进2-大数据的处理方法：使用一个(1T/1万行的文件大小)分布式集群进行处理，则耗时为2秒，时间大大减少。

2.总结

问题中涉及到的技术包括：1.并行-提升速度的关键。2.分布式。3.计算和数据在同一台机器。4.文件的切割管理。
Hadoop所要解决的就是：分布式文件管理、分布式计算、将算法向数据移动（相比要处理的数据，算法要小的多）、管理和规范化操作。

2.Hadoop存储模型

Hadoop的存储模型：字节。
Hadoop将文件线性的切割成块（block），block分散存储在不同的集群节点中，并通过偏移量（offset）即索引下标计算文件的位置。
特点：一个文件切割成的block块大小要相同（除最后一块外），不同的文件切割成的block块大小可以不一样。
block可以设置副本数，副本无序散列在不同的节点中（设置副本主要是为了安全，比如某个服务器挂了又不设置副本，就会造成在这个 节点上的block会永久的丢失）。注意副本数不要超过节点数量，原因：一个节点上放两个相同的block无意义。
文件上传可以设置block大小（系统默认1M~128M）和副本数）和副本数；已经上传的文件block副本数可以调整，但是 大小不能改变，大小改变会造成所有的索引都会变。
只支持一次写入多次读取，同一时刻只有一个写入者。
可以append追加数据。

3.hadoop架构模型-主从架构

文件元数据MetaData:文件数据本身的信息。
主节点：NameNode节点保存文件元数据(文件名、文件大小、偏移量等)：单节点、posix等。
从节点：DataNode节点保存文件Block数据（具体的数据）：多节点存储。
DataNode与NameNode保持心跳，DataNode向NameNode提交Block列表。
HdfsClient与NameNode交互元数据信息（数据在什么地方，数据大小等）。
HdfsClient与DataNode交互文件Block数据（cs模式）。
DataNode利用服务器本地文件系统存储数据块。

4.hadoop持久化

1.NameNode（NN）

NameNode是基于内存的存储（不会和磁盘发生交换（这里的交换是指双向的交换）），只存在于内存中。因此他需要进行持久化操作（和Redis类似）否则服务器 发生故障就会造成数据丢失。

2.NameNode主要功能

接收客户端的读写信息；收集DataNode汇报的Block列表信息（metadata信息），包括：文件owership、permissions、文件大小、时间、 Block列表：Block偏移量），位置信息（持久化不存，因为存了之后如果第一个发生变化会导致其它的都会发生变化， 持久化到内存的数据信息就不是准确的）、Block每副本位置（持久化不存，由DataNode上报）。

3.NameNode持久化过程

NameNode的metadata信息在启动后会加载到内存，metadata存储到磁盘文件名为”fsimage”（时点备份）即磁盘镜像文件，注意：Block的位置信息不会保存到fsimage 同时，edits文件记录用户对metadata的操作日志。具体是：当edits文件达到一定大小（fs.checkpoint.size，可配，默认64M） 或者达到一定间隔时间（fs.checkpoint.period，可配，默认3600秒）后，在SecondaryNameNode的帮助下合并fsimage和edits log。从而 达到减少NameNode的启动时间的作用。(相比加载edits log并执行，系统加载磁盘镜像文件会更快，因为磁盘镜像文件经过序列化处理。fsimage恢复快，edit log 写的快)

4.DataNode

以文件形式在本地磁盘目录存储数据（Block），同时存储Block的元数据信息文件。
启动DN时会向NN汇报block信息:通过向NN发送心跳保持与其联系（3秒一次），如果NN 10分钟没有收到DN的心跳，则认为其已经lost，并copy它的block到其它DN。

5.hdfs优缺点

1.优点

高容错性：数据自动保存在多个副本；副本丢失后，自动恢复。
适合批处理：移动计算而非数据;数据位置暴露给计算框架（Block偏移量）。
适合大数据处理：GB 、TB 、甚至PB 级数据；百万规模以上的文件数量; 单个节点的文件大小至少10k。
可构建在廉价机器上：通过多副本提高可靠性;提供了容错和恢复机制。

2.缺点

不支持低延迟数据访问：比如毫秒级（它的处理时间都是以秒为单位）、不支持低延迟与高吞吐率。
小文件存取：出现占用NameNode大量内存（NN要记录小文件的metadata）、小文件多寻道时间超过读取时间。
不支持并发写入、文件随机修改：一个文件只能有一个写者；仅支持append。

6.Block的副本放置策略

第一个副本：放置在上传文件的DN；如果是集群外提交，则随机挑选一台磁盘不太满，CPU不太忙的节点。
第二个副本：放置在与第一个副本不同的 机架的节点上。
第三个副本：放置在与第二个副本相同机架的不同节点。
更多副本：随机节点。

7.hadoop的读写流程

1.写流程

0）切分文件Block;按Block线性和NN获取DN列表（副本数）。
1）客户端通过Distributed FileSystem模块向namenode请求上传文件，namenode检查目标文件是否已存在，父目录是否存在。
2）namenode返回是否可以上传。
3）客户端请求第一个 block上传到哪几个datanode服务器上。
4）namenode返回3个datanode节点，分别为dn1、dn2、dn3。
5）客户端通过FSDataOutputStream模块请求dn1上传数据，dn1收到请求会继续调用dn2，然后dn2调用dn3，将这个通信管道建立完成。
6）dn1、dn2、dn3逐级应答客户端。
7）客户端开始往dn1上传第一个block（先从磁盘读取数据放到一个本地内存缓存），以packet为单位（大小为64k），dn1收到一个packet就会传给dn2，dn2传给dn3；dn1每传一个packet会放入一个应答队列等待应答。
8）当一个block传输完成之后，客户端再次请求namenode上传第二个block的服务器。（重复执行3-7步）。
。。。。。。
最终Client汇报完成。
NN会在写流程更新文件状态。

2.读流程

1）客户端通过Distributed FileSystem向namenode请求下载文件，namenode通过查询元数据，找到文件块所在的datanode地址。
2）挑选一台datanode（就近原则，然后随机）服务器，请求读取数据。
3）线性和DN获取Block，最终合并为一个文件。
4）MD5验证数据完整性。

8.hadoop的文件权限

与Linux文件权限类似:r: read; w:write; x:execute。 权限x对于文件忽略，对于文件夹表示是否允许访问其内容。
如果Linux系统用户zhangsan使用hadoop命令创建一个文件，那么这个文件在HDFS中owner就是zhangsan。
HDFS的权限目的：阻止误操作，但不绝对。HDFS相信，你告诉我你是谁，我就认为你是谁。

9.hadoop的安全模式

1）namenode启动的时候，首先将映像文件(fsimage)载入内存，并执行编辑日志(edits)中的各项操作。
2）一旦在内存中成功建立文件系统元数据的映射，则创建一个新的fsimage文件(这个操作不需要SecondaryNameNode)和一个空的编辑日志。
3）此刻namenode运行在安全模式。即namenode的文件系统对于客服端来说是只读的。(显示目录，显示文件内容等。写、删除、重命名都会失败，尚未获取动态信息)。
4）在此阶段Namenode收集各个datanode的报告，当数据块达到最小副本数以上时，会被认为是“安全”的， 在一定比例（可设置）的数据块被确定为“安全”后，再过若干时间，安全模式结束。
5）当检测到副本数不足的数据块时，该块会被复制直到达到最小副本数，系统中数据块的位置并不是由namenode维护的，而是以块列表形式存储在datanode中。