分享一波排序算法的知识点,闲暇时间可以看看：https://blog.csdn.net/Mirror_w/article/details/89286497

hadoop核心思想：分而治之，计算向数据移动

一、HDFS分布式文件系统

hdfs(hadoop distributed file system)是hadoop核心子项目，是分布式计算中数据储存管理的基础，是基于流式数据模式访问和处理超大数据集而开发的，高容错、高可靠性、高扩展性、高吞吐率等特征为海量数据提供了不怕故障的储存，为超大数据集的遍历提供了很大的遍历。
来源：来源于google的三篇论文之一Google file system。
Google的三篇论文：
Google file system
MapReduce
BigTable

二、.HDFS的特点：

1.适合大数据处理

能够处理大数据集，处理达到GB、TB、PB级别的数据
能够处理10k节点的规模

2.适合批处理

大数据计算的核心思想之一，计算向数据移动，移动计算而不是移动数据。
会把数据位置暴露给计算框架

3、高容错率

由于hdfs中的数据在储存时会采用副本容错机制。当数据上传时，默认会将副本数自动复制三分放在不同的节点之上，当其中某些节点出现故障宕机时，不会担心数据的丢失，只要采用副本机制。而副本数也是可以通过参数来设置的。

4、流式文件的访问方式

一次写入，多次读取。hdfs中文件一旦写入，不能修改，只能追加
保证了数据的一致性

5.可以构建在多台廉价的机器上

用于副本的容错机制，所以不害怕出现数据的丢失，可以通过设置副本数来保证数据的安全性。

以上都是hdfs的优点，一下谈谈它的劣势。

1.低延迟的数据处理

毫秒级的数据处理他是做不到的，
它适合高吞吐量的的数据处理场景，比如一次写入大量的数据。

2.小文件存储

储存了大量的小文件，这里的小文件是指在比默认一个block块的大小（默认：128M：2.7.3版本开始，官方关于Data Blocks 的说明中，block size由64 MB变成了128 MB的），由于namenode会储存大量的小文件的元信息，而namenode节点的内存储存空间是有限的，所以会占用很大的内存空间，

三、HDFS中角色的介绍

1.client:也就是客户端

-client提交客户端的请求，提交作业
-hdfs在进行文件上传的时候，对文件进行数据切分
-client用于和namenode进行通信，获取datanode上数据块的元数据
-clinet获取到namenode上的数据之后进行与datanode进行通信。

2.namenode元数据存储节点:

-储存datanode上数据块的元数据信息，元数据信息：文件名，文件大小，储存的位置。
-与client客户端进行交互，当client提交请求时，进行响应，提供相应的元数据
-与datenode进行数据交互，当节点服务器进行启动时，每个datanode会向namenode进行注册自己的位置信息

namenode的目录信息：
在这里插入图片描述
目录：如果属性dfs.namenode.name.dir指定了多个路径，则每个路径中的内容是一样的，in_use.lock文件用于NameNode锁定存储目录。这样就防止了其他同时运行的namenode实例使用相同的储存目录
seen_txid:在合并edit文件和fsimage文件时需要更新其中的值
总体描述：当文件系统客户端进行了写操作时，这个事务首先在edits.log文件中记录了下来。NameNode在内存中有文件系统的元数据，edits.log记录结束后，就更新内存中的元数据，内存中的原数据用于响应客户端的读请求。 edits.log在磁盘上表现为一定数量的文件，每个文件成为片段，前缀"edits",后缀是包含的事务ID，每个写数据仅仅都打开一个文件，写完后冲刷缓冲区同步到磁盘才返回success的状态码。这样就保证了在宕机时没有事务数据的丢失。

3.datanode数据存储节点:

-用于储存数据
-相当于一个磁盘
-存储client用户上传的数据，
-datanode上储储存的数据都会有自己的备份，默认是3，用户可以自定义。有自己的副本储存机制。
datanode数据节点目录
在这里插入图片描述
目录：1.HDFS中的数据块储存于blk_前缀的文件中，包含了被存储文件原始数据的一部分。2.每个block文件都有对应的一个.meta后缀的元数据文件关联。该文件包含了一个版本和类型信息的头部，后接每个block快中的每个部分的校验和。3，每个block属于一个block池，每个block池有自己的存储目录，该目录的名称就是该池子的ID（跟NameNode的VERSION文件中记录的block池ID一样）

4.secondarynamenode（fsimage和edit.log的数据合并）：

用于namenode上的fdimage和edits.log两个文件的合并。edits.log文件会持久化到磁盘，当nameNode宕机时可以做备份恢复。

四、文件的上传—hdfs写流程

文件上传流程图
在这里插入图片描述
当服务启动时，首先namenode先将自己的元数据进行加载到内存，这份元数据的加载会有一定的加载机制（此处涉及secondarynomenode上的fismage和edit.log文件的文件合并操作，下面会讲述的），当元数据加载到内存后，datanode启动后会与namenode进行建立心跳连接，然后将自己节点上的数据位置信息，进行注册（汇报）给namenode，namenode会加载自己的数据信息和datanode汇报的数据的位置信息。，等待client客户端使用。到这里datanode和namenode的初始化工作完毕。
client在进行上传数据时候（利用DistributeFileSystem这个类的对象的进程进行执行），首先会对文件进行切分，切分成不同的小文件块，然后client将这些数据的信息进行与namenode进行rpc(远程过程调用)通信并提交请求，当client客户端进行提交请求，上传文件的时，首先client先与namenode进行通信，获取datanode的节点信息，以及自己上传的数据信息，然后namenode会根据请求分配节点用于客户端上传数据，client获取到节点信息后，就会拿着节点信息去指定的节点上传数据。在数据上传的时候，client和datanode之间上传的的时候.会有一个数据传输队列，和一个数据确认队列，开始的时候两个队列中的数据是一样的。数据队列中的数据向datanode上进行上传，当向第一个datanode上进行上传成功后，这个进程会继续上传数据队列中的下一份数据，直至上传完成。但是对于datanode，当第一份数据上传完毕的时候，由于副本机制（默认是3，可以设置），三台datanode之间会形成管线，用于数据的输出，创建副本，这里采用datanode上的过半原则，当上传成功的副本数大于所要求的（默认的或者设置的）一般时，表示这个数据块上传成功，则向外通知，当确认队列收到对应数据块上传成功的响应后，会将确认队列中的对应数据删除，这样当确认队列中的数据为空时，则client客户端完成数据上传的任务返回客户端数据上传完毕的响应并且向namenode进行反馈。但是当datanode之间进行数据传输时，出现节点的宕机造成未达到副本数时，这样意味着这份数据上传失败，当数据失败时，这个进程会将告知namenode,这样namenode会分配一个新的datanode节点，用于数据储存。并且会将确认队列中对应传输失败的个数据块向数据队列发送一份，用于重新上传。直至数据上传成功。

五、文件的读取—hdfs的读流程

与文件的写流程相似，客户端进行提交文件的读请求的时候，首先先通过rpc通信，与namenode进行建立连接，当nomenode和client客户端建立连接后，namenode会将客户端的请求的元数据进行响应回去，当客户端获取到元数据时，客户端上的进程对象会根据元数据信息，到hdfs分布式文件系统上进行获取数据。并且进行返回数据。
文件的读取流程图
在这里插入图片描述

六、secondaryNamenode文件的合并

日志文件的合并流程图
在这里插入图片描述

当集群进行启动时，namenode会加载edit.log和fsimage文件，将两个文件进行合并，fdimage中记录的时数据的元数据，edits.log中记录的是client客户端的操作日志。当在namenode工作期间，达到checkpoint检查点时（1.到达一个小时，2，事务到达100万）时，secondarynamenode进行将namenode上的fsimage和edits.log两个文件进行拉取，在拉取之前创建一个新的edit.log文件（新的肯定是很小的）用于合并过程中client客户端操作的信息，当secondarynamenode拉取到两个文件之后则进行文件的合并，并且合并后的名称为fsimage，并且将它持久化到磁盘上，用于备份并且向namenode发送一份合并后的fsimage文件，这样，namenode具有的fsimage镜像文件和edits.log操作日志文件。
注意：
checkpoint检查点：1.一个小时（dfs.namenode.checkpoint.period）
2.事务达到100万（dfs.namenode.checkpoint.period）
补充：