Hadoop学习笔记之HDFS

Hadoop简介

优点

1、高可靠性：可以将数据分发到多个副本上进行存储，并且在副本损坏的时候，及时将副本的数据同步到新的副本中
2、高扩展性：横向扩展，数以千计的节点
3、高效性：基于MapReduce，可以进行并行处理数据，最后再合并计算结果
4、高容错性：能够自动将失败的任务进行重新分配

组成

1.0

MR + HDFS +Common(辅助工具)

2.0

MR + HDFS + YARN + Common（辅助工具）

区别

1.0时，计算的资源分配也是由MR来进行调度的，2.0之后，增加了YARN，推荐使用YRAN对集群资源进行调度MR专注于运算任务

HDFS

简介：分布式文件系统，由多台机器组成
适用场景：一次写入，多次读取

优缺点

优点

1、高容错性：数据自动保存多个副本（可配置），当一个副本丢失（连接异常），会将数据恢复到一个新的副本中
2、适合处理大量数据
3、使用廉价机器：节约成本的同事提高数据的可靠性（不易丢失数据）

缺点

1、不适合低延时数据访问：因为处理需要一定时间，无法满足这种需求
2、不适合小文件存储：
1.因为文件的元数据和其他信息是存储在NameNode上的，这些信息会占据NameNode的内存空间，如果存储的都是小文件，而且还是很多的情况下，这会占据NameNode大量的内存，性价比很低。
2.查询文件是要一定的寻址时间，当寻址时间大于读取文件的时间的时候，违背了HDFS的设计原则，也是一种糟糕的应用
3、不支持并发写
4、只支持数据的append，不支持随机修改

HDFS架构

Client

1、文件切分：上传文件时，已经将文件按照块的大小进行切分（一般默认128M），然后分块进行上传
2、与NameNode进行交互，获取对应的文件信息（路径，在哪台DataNode上等）
3、与DataNode交互，进行读、写操作
4、提供了一些HDFS的管理命令，例如NameNode的格式化（hadoop namenode -format）
5、可以提供了一些命令对HDFS文件的增删改查

NameNode

1、管理HDFS的命名空间
2、配置副本策略
3、管理数据块的映射信息
4、处理Client的读写请求

SecondydaryNameNode

1、辅助NameNode，但是不能作为NameNode的备用机，主要还是分担NameNode的工作，合并Fsimages和Edits（加载数据时比较重要的两种文件，后面会讲到），并同步到NameNode上
2、可以帮助恢复NameNode

HDFS块大小的设计

1.0时的默认大小为64M，2.0默认为128M

为什么这么设计？

块大小的规则：必须是2的N次方（因为需要每64K进行数据检查一次）

最佳传输理论：当寻址时间 / 传输时间 = 1%时，文件查找的效率最高，性价比最高

现在一般的计算机寻址时间是10ms，
1.0时代的磁盘读写能力较弱（50M/S）,推算一下：
传输时间：10ms / 1% = 1000ms = 1s
所以传输的时间为1s时是效率最高的，然后结合磁盘的读写速度是50M/S
所以一次读写 1S * 50M/S = 50M 的时候，是效率最高的，
大于50M的最小的2的N次方就是64M了，所以默认使用64M

等到了2.0时代，磁盘的传输速率提高，达到了100M/S，所以我们用 1s * 100M/S = 100M，那离100M最近的2的N次方就是128M，所以2.0的默认块大小为128M

在未来，如果寻址时间和磁盘时间得到了响应的改善，我们依旧可以根据最佳传输理论根据我们集群资源的硬件情况去设置我们的默认块大小

块的设计原则

设置的太小：10M，我想要取一个100M的数据，那我要去找10个块，寻址10次，增加寻址的时间，并且块的映射信息（10份映射信息）都要存储到NameNode中，占用了NameNode的内存
设置的太大：一个块1T，当我只想拿这个块里的100M ~ 200M之间的文件，那我需要将整个T都下载下来，再去查找这1T中的100M ~ 200M，如果我设置了 128M或者256M，我其实只要下载1块或者2块就可以了，那就是最多下载256M数据就能拿到我想要的数据了，，减少网络IO的开销，所以要根据业务场景，如果你的场景每次都要拿去大量的数据，而且磁盘速率很快（固态），那你可以适当的设置的大一点，但是也要考虑网络传输异常中断导致重复上传的代价，结合集群的硬件设施和网络状态综合设置默认的块大小

HDFS读写流程

HDFS写流程

1. 客户端通过Distributed FileSystem 向NameNode请求上传文件ss.avi，NameNode检查文件是否存在（通过元数据），已经在则不可以上传（但是可以使用覆盖上传）
2. 将是否可以上传的结果告知客户端
3. 如果可以上传，客户端向NameNode请求询问第一个块要上传到哪几个DataNode上面（具体几个块取决于块的大小和文件的总大小，具体几个DataNode取决于配置的副本数量）
4. NameNode把可以上传的DataNode列表返回给客户端（dn1，dn2，dn3…）
5. 客户端通过FSDataOutPutStream向dn1请求建立传输通道，dn1收到请求后，会继续调用dn2，dn2再去调用dn3，
6. dn1，dn2，dn3逐级应答客户端，表示通信建立完成，可以开始传输数据了
7. 客户端开始正式传输数据，以packet为单位开始传输，按照顺序，先传给dn1，dn1收到后传给dn2，dn2再传给dn3，首个节点（dn1），每传出一个packet，就会将这个packet放入一个队列，直到确认所有的DataNode的数据落地后，就将对应的packet移出队列，在某个DataNode出现问题的时候，就可以根绝packet进行重试
   8.每个块传输完成，在进行3-7步骤

HDFS读流程

1. 客户端通过Distributed FileSystem向NameNode请求下载文件，NameNode通过查询元数据，找到文件块所在的DataNode地址
2. 挑选一台DataNode（就近原则，然后随机）服务器，请求读取数据。
3. DataNode开始传输数据给客户端（从磁盘里面读取数据输入流，以Packet为单位来做校验）。
4. 客户端以Packet为单位接收，先在本地缓存，然后写入目标文件。

NameNode、SecondaryNameNode工作机制

NameNode

NameNode启动：

1、NameNode首次启动需要进行格式化（hadoop namenode -format），格式化之后，会生成Fsimage和Edits文件，如果不是首次启动的话，会直接加载这两个文件进入内存
2、客户端对元数据进行增删改查
3、NameNode记录操作日志，并持续更新滚动日志
4、NameNode对内存中的数据进行增删改查

Secondary NameNode工作

1、Secondary NameNode询问NameNode是否需要CheckPoint（是否到了检查点），一旦到达定时时间，或者Edits中的数据写满了，就会带回检车结果
2、Secondary NameNode拿到结果后，开始请求执行CheckPoint
3、NameNode滚动正在写的Edits文件（把再次之前的操作打上标记，然后新建一个edits.inprogress的文件，在此之后的操作日志都会记录在edits.inprogress的文件中）
4、将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode
5、Secondary NameNode加载编辑日志和镜像文件到内存，进行合并
6、生成新的镜像文件fsimage.checkpoint
7、将新的镜像文件拷贝到NameNode，并重名名为fsimage，并将edits.inprogress文件重名为edits

通俗讲法：每次启动都会去拿fsimage镜像 + edits操作日志，加载到内存，就是最新的元数据信息，并生成最新的fsimgae和edits滚动，在这之间，NameNode开启安全模式（只读），直到集群中满足【最小副本条件】，30S后退出安全模式，然后client开始可以读写，每到检查点（默认一小时，可配置，或者hdfs操作次数达到100W次时），NameNode生成新的edits.inprogress文件，并滚动seen_txid文件（edits的序号+1），后续的操作日志会写到edits.inprogress文件中，NameNode将fsimage和edits文件通过httpPost传输给Secondary NameNode，Secondary NameNode接收到会将2者合并生成新的fsimage.checkpoint文件，并将这个文件通过httpPost发送给NameNode，Namenode将fsimage.checkpoint重命名为fsimage，替换成为最新的镜像

滚动

edits文件滚动就会生成新的文件名称xxxxx122，并且将seen_txid中的数值+1，每次重启NameNode，会根据seen_txid中的值去加载操作记录xxxxx1~xxxxx[seen_txid中的值]的这些edits的文件

集群安全模式

DataNode工作机制