为什么要分布式存储
解决单机存储容量有限的问题, 采用横向扩展的方式(加机器), 来通过分布式的方式实现跨机存储, 且可以提高传输效率。
HDFS简介, 及其架构组成
HDFS全称是Hadoop Distributed File System, Hadoop的分布式文件存储系统, 就是用来实现分布式(跨机)存储的.
它(HDFS)由三种角色组成, 分别是: namenode, SecondaryNameNode, datanode, 作用如下:
namenode: 它是HDFS集群的主节点
1. 管理整个HDFS集群.
2. 维护和管理元数据(描述数据的数据)
SecondaryNameNode: 辅助节点
辅助namenode维护和管理元数据的.
datanode: 从节点
1. 负责存储具体的数据.
2. 负责数据的读写操作.
HDFS是如何存储文件的?
为了统一管理, 会按照 128MB/块 将文件切割成N个块, 为了提高容错, 每个块的副本数默认是 3.
即: 副本机制是 3, 每个块默认大小: 128MB,实际开发中,建议副本数为 2或5.
副本数越高:
好处是: 数据的容错率越高, 安全性越高.
弊端是: 磁盘的利用率降低了.
(每个)块的大小, 越大: (例如: 把块的大小从默认的 128MB => 256MB)
好处是: 相同文件大小的情况下, 块的数量减少了, 元数据也会降低, 减少内存空间占用, 提高效率.
弊端是: 如果操作的是大量的小文件, 块越大, 效率越低.
namenode如何管理元数据?
1. namenode是通过Edits文件和FsImage文件来维护和管理HDFS的元数据的.
2. 当用户操作HDFS文件的时候(写,改,删), 相应的元数据就会发生变化, 然后会实时写入到Edits文件中.Edits文件相较于FsImage文件, 比较小, 所以修改起来速度比较快, 记录的是 HDFS集群的最新的(最近一段时间的)元数据.
3. 当Edits文件达到一定的阈值(1个小时 或者 100W次), 就会将其和FsImage文件合并, 形成新的FsImage文件.FsImage文件相对较大, 记录的是HDFS集群所有的元数据(不包括最新的元数据).
4. 对Edits文件 和 FsImage文件合并的动作是由 SecondaryNameNode来完成的, 全程namenode不参与.
5. 当我们启动Hadoop集群的时候, namenode会去加载FsImage文件 和 最新的那个Edits文件内容到内存, 并启动自检程序,此时HDFS集群会强制进入到安全模式, 自检没问题后, 会自动退出安全模式.
SecondaryNameNode如何辅助namenode管理元数据?
1. SecondaryNameNode会间隔一定的时间(60秒)检测namenode的Edits文件的状态.
2. 当其(Edits文件)达到一定的阈值(1个小时或者100W次), 就会通知namenode形成新的Edits文件, 并禁用之前旧的Edits文件.
3. SecondaryNameNode会通过Http协议将namenode的 最近的 Edits文件 和 FsImage文件拉取到本地进行合并, 全程namenode不参与.
4. SecondaryNameNode将合并后的新的FsImage文件推送给namenode.
5. namenode不会立即删除旧的Edits文件和FsImage文件, 而是在重启服务器集群或者达到一定阈值的时候才会自动删除.
namenode如何管理datanode?
副本机制, 心跳机制, 负载均衡.
HDFS的写数据流程和读数据流程
写数据流程:
1. Client(客户端)请求namenode, 进行文件上传.
2. namenode校验该客户端对此文件是否有写权限, 且文件是否存在, 合法后, 会告知该客户端可以上传.
3. Client对HDFS文件进行切块(默认: 128MB/块).
4. Client重新请求namenode, 第1个Block的上传位置.
5. namenode接收到请求后, 会根据副本机制, 负载均衡, 机架感知原理, 返回给该客户端1个datanode列表. 例如: node1, node2, node3
6. Client于datanode列表的, 第1个datanode进行连接(最近的datanode节点)
7. Client依次和其它的datanode进行连接, 形成传输管道(pipeline), 并建立反向应答机制(ACK机制)
8. 采用数据报包(每个包不超过64KB)的形式发送数据, 根据传输管道依次发送, 并给出Ack回执信息.
9. 重复此步骤, 直至第1个Block块的数据上传完毕.
10. Client重新请求namenode, 第2个块的上传路径, 然后返回第4步, 重新往下执行, 直至所有的Block块传输完毕, 至此, HDFS写数据流程结束.
读数据流程:
1. 客户端请求namenode, 读取文件数据.
2. namenode接收到客户端请求后, 会校验该客户端对此文件是否有读权限, 且文件是否存在,校验合法后, namenode会返回给客户端 该文件的 全部或者部分的块的地址(datanode列表), 这些地址都是鲜活的.
3. 客户端根据上述的datanode列表, 进行连接, 并行的从中读取数据.
4. 当上述的Block读取完毕后, 客户端会重新请求namenode获取剩下的部分或者全部的块信息, 然后重复上述步骤, 直至所有的块数据读取完毕.
5. 客户端按照Block块的编号, 把这些块数据拼接到一起, 就得到了最终的完整文件, 至此, HDFS读数据流程完毕.
HDFS的垃圾桶(Trash)机制
HDFS默认情况下, 删除文件是永久删除的, 为了提高容错性, 我们可以开启HDFS的垃圾桶机制, 将永久删除改为 放文件到 垃圾桶中(类似于windows系统的 回收站)
小结
HDFS作为Hadoop生态系统的核心组件，提供了可靠的、高吞吐量的分布式存储解决方案，适合于大规模数据的存储和处理。
扫一扫
1749
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
