提示:文章写完后,目录可以自动生成,如何生成可参考右边的帮助文档
文章目录
HDFS详细介绍
提示:这里可以添加本文要记录的大概内容:
HDFS在大数据的应用场景中有这很重要的作用,通常被用于处理大文件的存储,下面我将对HDFS进行详细的解释。
提示:以下是本篇文章正文内容,下面案例可供参考
一、HDFS架构
(1) NameNode(NN) : 存储文件的元数据,比如文件名,目录结构文件的属性(权限,创建时间啥的),以及每个文件的块列表和所在的DateNode.其中元数据大概类似于修饰文件属性的属性.
(2) DataNode(DN) : 本地文件系统存数据的地方并且负责数据块的校验
(3)Secondary NameNode(2NN) : namenode的助手,监控HDFS的后台辅助程序,每隔一段时间获取HDFS元数据的快照
二、分块的大小如何设置?
(1) HDFS的块设置太小,**会增加程序的寻址时间,**降低效率,程序会一直寻找块开始的位置.
(2) 如果快设置的太大,程序在处理这个快的时候会非常慢,降低了性能从而并没有达成我们启用分布式的初衷,因为磁盘的开始时间会明显大于定位这个快所需要的时间.
综上所述快的大小取决于我们磁盘的性能,并不是绝对的可以进行块大小的修改
三、HDFS写入数据的流程?
HDFS再写入数据是大家要先明白什么是HDFS的客户端,千万不要吧客户端和HDFS和我们的Windows操作系统混淆,在正常安装的情况下客户端一般存在于我们的hadoop文件夹里面有一个hadoop-client.他会处理我们文件的分块和namenode的通信.
详细步骤解析
客户端要想HDFS写数据,首先要跟namenode通信确认可以写文件并且获得可以接受文件的block和DataNode,然后客户端按照顺序逐个block传递给相应的DataNode,并且由接收到的DataNode和block负责向其他DataNode复制block副本
1 根据NN通信请求上传文件,NN会检查目标文件是否存在(上传的文件),父目录是否存在(上传的目录)以及是否具有用户权限
2 NN返回是否可以上传
3 客户端请求第一个块该传输到那些DataNode服务器上
4 NN返回3个DataNode的服务器A B C
5 客户端请求3台dn中的一台A上传数据,启用rpc调用建立pipeline管道连接,当A收到请求后会继续调用B以此类推,直到整个管道建立为完成任何逐级返回客户端
6 客户端开始往A上传第一个block(先从磁盘读取数据到一个本地内存缓存),以packet为单位,A收到一个packet就会传给B,B再传给C,A每次传一个packet都会放入一个答应队列等待应答
7 当块的传输完成后,客户端再次请求NN上传第二个块的服务器以此类推.
四、HDFS读数据的流程?
详细步骤解析
客户端吧要读取的文件路径发送给NN,NN获取文件的元信息(主要是块的存放位置信息)返回给客户端,客户端根据返回的信息找到DN逐个获取文件对应的block并且灾厄客户端本地进行数据追加合并从而获取整个文件夹
1 和NN查询元数据信息,找到文件所在的DN的节点
2 挑选一台DN服务器,请求建立socket流(副本存储策略,先就近在随机保证安全和效率)
4 客户端已packet接收,现在本地缓存在写入目标文件.
五、HDFS联邦架构?
这玩意网上说的太复杂甚至还有介绍联邦的,其实很简单就以下几点,
主要解决 :
(1) NameSpace命名空间的限制,支持扩展
(2) 隔离问题 : 由于HDFS只有一个NN,无法隔离每个程序,因为一个HDFS上的一个实验程序就很有可能会影响整个HDFS的进程
(3) 性能瓶颈 : 由于是单个NN的HDFS架构,因此整个HDFS文件的吞吐量受限于单个NN的吞吐量
缺点 :
(1) 交叉访问问题 : 由于Namespace被拆分成多个,且互相独立,一个文件路径只允许存在一个Namespace中,如果应用程序要访问多个文件路径,那么不可避免的会产生交叉访问Namespace的情况,比如MR、Spark任务,都会存在此类问题
(2) 管理问题 : 启用Federation后,HDFS很多管理命令都会失效,比如“hdfs dfsadmin、hdfs fsck”等,除此之外,“hdfs dfs cp/mv”命令同样失效,如果要在不同Namespace间拷贝或移动数据,需要使用distcp命令,指定绝对路径
在绝大部分时候HDFS联邦架构优点还是大于缺点的
版权归原作者 Jessica925 所有, 如有侵权,请联系我们删除。