1.分布式
分布式存储解决了单机存储容量有限的问题, 且带来了比较高的性能提升. 例如: 3台服务器, 就是3倍的传输效率, 读写效率...
横向扩展 = 加机器, 纵向扩展 = 加配置(硬件)
2.架构
namenode: 主节点.
1. 管理整个HDFS集群.
2. 维护和管理元数据.
SecondaryNameNode: 辅助节点.
辅助namenode维护和管理元数据的.
datanode: 从节点.
1. 存储具体的数据.
2. 负责源文件的读写操作.
3. 定时和namenode发送心跳包.
3.分块存储
1. 分块存储是为了方便统一管理的, 默认的块大小为: 128MB. 细节: Hadoop2.X开始才是128MB, Hadoop1.X是: 64MB.
2. 副本机制是为了提高容错率, 副本数越多, 容错率越高. 带来的弊端是: 磁盘利用率下降了.
3. 实际开发中, 建议副本数为: 2 ~ 5
4. 如果要修改block块的大小 和 默认的副本数, 可以去: Hadoop的配置文件中修改.
4.namenode如何管理元数据
1. namenode是通过一批Edits(小) 和 1个FSImage(大)两类文件来维护和管理元数据的.
2. Edits文件相对较小, 操作起来速度相对较快, 它只记录HDFS最近一段状态的元数据信息.
阈值: 1个小时 或者 100W次
3. FSImage文件相对较大, 操作起来速度相对较慢, 它记录的是HDFS集群除最近状态外, 其它所有的元数据信息.
4. HDFS集群启动的时候, 会自动加载FSImage文件 和 最新的Edits文件进内存, 用于记录元数据.
整个过程称为HDFS的自检动作, 此状态下, HDFS集群会强制进入到安全模式, 只能读, 不能写.
5.SecondaryNameNode如何辅助namenode管理元数据
1. SecondaryNameNode会间隔60s(秒), 询问一次namenode, edits文件是否满足了阈值(1个小时, 或者100W次)
2. 如果满足条件, 就通知namenode创建新的Edits文件, 继续往里写入元数据信息.
3. 根据http协议, 从namenode上把要合并的edits文件 和 fsimage文件拉取到本地进行合并.
4. 将合并后的新的FSImage文件推送给namenode, 用来替换之前旧的FsImage文件.
细节: 旧的FSImage文件并不会被立即删除, 而是达到一定的阈值后, 才会被删除.
5. 对于Edits文件和FSImage文件的合并操作, 是由SecondaryNameNode独立完成的, 全程namenode不参与.
6. 实际开发中, namenode 和 SecondaryNameNode会被部署到不同的服务器上, 配置几乎一致, 只不过SecondaryNameNode的内存要稍大一些.
7. 在紧急情况下, SecondaryNameNode可以用来恢复namenode的元数据.
6.三大机制
心跳机制:
1.datanode会定时3秒向namenode发送心跳包,告知namenode我还活着
2.如果超过一定时间630秒,namenode没有收到datanode的心跳包,就会认为它宕机了,此时就会将该datanode的块信息交由给其他活跃的datanode来存储
3.所有的datanode会定时6小时,向namenode汇报一次自己完整的块信息,让namenode校验更新
负载均衡:
namenode会保证所有的datanode的资源使用率尽量保持一致
副本机制:
可以提高容错率,默认的副本数是3
如果当前副本总数>默认的副本数,namenode会自动删除某个副本
如果当前副本总数<默认的副本数,namenode会自动增加该副本
如果当前活跃的机器总数<默认的副本数,就会强制进入到安全模式,在安全模式下只能读不能写
7.HDFS写数据流程
1. Client(客户端)请求namenode, 上传文件.
2. namenode接收到客户端请求后, 会校验权限, 并告知客户端是否可以上传.
校验: 客户端是否有写的权限, 及文件是否存在.
3. 如果可以上传, 客户端会按照128MB(默认)对文件进行切块.
4. Client(客户端)再次请求namenode, 第1个Block块的上传位置.
5. namenode会根据副本机制, 负载均衡, 机架感知原理及网络拓扑图, 返回给客户端存储该Block块的DataNode列表.
6. Client(客户端)会先连接就近的datanode机器, 然后依次和其他的datanode进行连接, 形成: 传输管道(Pipeline)
7. 采用数据报包(DataPacket)的形式传输数据, 每个包的大小不超过: 64KB, 并建立: 反向应答机制(ACK机制)
8. 重复上述的步骤, 直至第1个Block块上传完毕.
9. 返回第4步, 客户端(Client)重新请求第2个Block的上传位置, 重复上述动作, 直至所有的Block块传输完毕.
8.HDFS读数据流程
1. Client(客户端)请求namenode, 读取文件.
2. namenode校验该客户端是否有读权限, 及该文件是否存在, 校验成功后, 会返回给客户端该文件的块信息.
3. Client(客户端)会连接上述的机器(节点), 并行的从中读取块的数据.
4. Client(客户端)读取完毕后, 会循环namenode获取剩下所有的(或者部分的块信息), 并行读取, 直至所有数据读取完毕.
5. Client(客户端)根据Block块编号, 把多个Block块数据合并成最终文件即可.
9.安全模式
HDFS适用于操作海量的大文件, 如果小文件过多, 就会占用多个Block块, 且也有多份元数据, 资源消耗比较大. 针对于这种该情况, 我们可以用 归档包 来解决它.
概述:
归档包类似于压缩包, 但是只有压, 没有缩, 相当于把多个文件合并成1个文件, 这样元数据就只有1份儿了.
格式:
hadoop archive -archiveName 归档包的名字 -p 要被归档的文件名 存储归档包的路径
11.垃圾桶机制
目前我们搭建的Hadoop集群, 默认没有开启垃圾桶机制, 每次删除文件, 都是永久删除的, 找不回来了.
这样做比较危险, 我们可以开启垃圾桶机制, 这样删除数据的时候, 就会自动放到垃圾桶中, 保存一定的时间, 超出时间后, 才会自动删除.