首页 > 其他分享 >大数据学习之HDFS

大数据学习之HDFS

时间:2022-11-28 22:12:39浏览次数:41  
标签:HDFS 文件 hadoop 学习 DataNode NameNode 数据 客户端

HDFS是一个分布式文件存储系统,适合一次写入,多次写出,且不支持文件修改     结构:         NameNode(NN):就是master 他是一个管理者             1、管理HDFS的命名空间             2、配置副本策略             3、管理数据块映射信息             4、处理客户端读写请求         DataNode(DN):就是salve NameNode下达命令 DataNode执行实际的操作             1、存储实际的数据块             2、执行数据块的读写操作             3、NameNode为了提高速率 所有的操作都是在内存中完成的                 1)运行速度快                 2)不和磁盘做交互                 3)无法进行数据的持久化 数据保存在内存中断电即丢失             4、启动时会先验证block块是否损坏然后想NameNode汇报当前DataNode上block快的信息         SecondaryNameNode(SNN):并非是NameNode的热备 当NameNode挂掉的时候 他并不能马上替换         NameNode并提供服务             1、辅助NameNode 分担其工作量 定期合并Fsimage和Edits 并推送给NameNode             2、在紧急情况下可以辅助恢复NameNode             3、可以对数据进行持久化                 让日志大小可控                 快照需要定时保存                 日志+快照的方式
    优点:         1、高容错性->数据自动保存多个副本 通过增加副本的方式增加容错性 丢失一个副本之后会自动恢复         2、适合处理大数据 GB TB级别的数据         3、可构建在廉价的机器上 通过多副本机制提高可靠性     缺点:         1、不适合低延时数据访问         2、无法高校的对小文件进行存储             存储小文件会占用NameNode大量的内存来存储文件目录和快信息 因为NameNode的内存术有限的             小文件的寻址时间会超过读取时间         3、不支持高并发写入 文件随即修改             一个文件只能有一个写 不允许多个线程同时写             仅支持数据的追加             HDFS文件快的大小(可通过配置参数来规定)         hadoop1.x默认64M hadoop2.x默认128M         寻址时间为传输时间的1%时为最佳状态
        太小:会增加寻址时间 程序一直在找块的起始位置         太大:从磁盘传输的时间会明显大于定位块开始位置所需的时间 导致程序在处理这个块时会非常慢
        块的大小设置主要取决于磁盘的传输速率         HDFS的shell操作 hadoop fs 具体的命令         启动hadoop集群:start-all.sh         关闭hadoop集群:stop-all.sh
        显示目录信息         hadoop fs -ls 目录         在HDFS上创建目录 创建多级文件夹用-p         hadoop fs -mkdir /目录         从本地剪切文件到HDFS中         hadoop fs -moveFromLocal 本地目录 HDFS中的目录         追加文件到已近存在的文件的末尾         hadoop fs -appendToFile 本地文件 HDFS中的文件         显示文件信息         hadoop fs -cat 文件         修改文件所属权限         hadoop fs -chmod 权限级别 目标文件         hadoop fs -chwon 用户组名 目标文件的用户祖名         从本地文件拷贝到HDFS文件中去         hadoop fs -copyFromLocal 本地文件 目标文件         从HDFS拷贝到本地         hadoop fs -copyToLocal HDFS中的文件 本地文件         从HDFS中的一个路劲拷贝到另一个路径         hadoop fs -cp 原路径 目标路径         在HDFS中移动文件         hadoop fs -mv 原文件 目标文件         从HDFS下载到本地         hadoop fs -get HDFS中的文件 本地文件         合并并下载多个文件         hadoop fs -merge HDFS中的文件最后一级目录加*表示全部 本地目录         从本地上传到HDFS中         hadoop fs -put 本地文件 HDFS中的文件         显示文件末尾         hadoop fs -tail 文件         删除文件 强制删除         hadoop fs -rm -rf 目标文件         统计文件大小         hadoop fs -du 目标文件         设置HDFS文件的副本         hadoop fs -setrep 副本数 目标文件             这里设置的副本只是记录在NameNode的元数据中 实际的副本还得看DataNode的数量    

HDFS写数据流程

    将客户端上的数据写进hdfs中     宏观状态下         1、客户端向hdfs发送操作数据的请求         2、文件系统通过RPC来调用NameNode的put方法对文件进行切分         3、NameNode通过校验之后在元数据中建立起映射关系并返回给客户端可以上传文件         4、客户端向NameNode询问将block块上传到那几个DataNode服务器上         5、NameNode返回几个DataNode结点 dn1 dn2 dn3         6、客户端通过调用FSDataOutputStream来向dn1中传数据 然后dn1收到请求后调用dn2 紧接着 dn2调用dn3            随后dn3 dn2 dn1逐级应答返回给客户端 这样DataNode之间就建立起了pipeline管道         7、客户端将数据以packet包的方式进行传输(默认64K)给dn1 dn1拷贝一份之后传送给dn2 同理传送给dn3            每传输到一个DataNode会留下一个ack状态等待后边进行反馈 当ack状态为true时表示该packet传输成功            当最后一个packet传输成功后客户端传输完毕 此时的pipeline管道断开 FSDataOutPutStream释放资源         8、当第一个block块传输完毕之后,客户端请求NameNode上传第二个block的客户端 然后重复以上操作 指导把            所有block块传输到hdfs上为止     微观状态下         1、客户端先将文件从磁盘读取到缓存中         2、将缓存中的数据一packet包的形式进行封装(默认64K)         3、当每一个packet满的时候将它放入dataQueue队列中         4、客户端开始发送第一个packet时 通过FSDataOutPutStream将packet放入pipeline管道中 而此时             也会将packet放入ackQueue队列中         5、客户端发送一个packet包后会开始接受一个ack 如果DataNode返回的ack状态true 则从ackQueue中            删除这个packet 如果返回的是false那么将ackQueue队列中所有的packet重新挂载到dataQueue队列中去            重新发送         注意:             一个packet包由两部分组成 一个是实际的数据包 另一个是head包             head包中包含判断最后一个packet的信息

HDFS读数据流程

    1、客户端通过文件系统向NameNode发送下载数据请求 随后NameNode通过查询元数据找到block块的DataNode地址     2、挑选一台DataNode(就近原则 随机)服务器 请求读取数据     3、DataNode开始传输数据给客户端(从磁盘上读取数据输入流 一packet为单位做检验)     4、客户端以packet为单位接受 先缓存到本地 在写入目标文件
  1、hdfs高可用(HA) 即7*24小时内不间断服务 2、实现高可用最关键的策略是消除单点故障 HA分为各个组件的高可用机制 HADF的(HA) YARN的(HA) 3、Hadoop2.0之前NameNode存在单点故障 NameNode主要在一下两个方面影响HDFS集群     1)NameNode机器发生意外 如宕机 集群无法使用     2)NameNode机器升级 集群无法使用     hdfs高可用功能配置active/standby两个NameNode结点实现对集群中NameNode的热备来解决     上述问题。如果出现故障可以利用这种方法将NameNode切换到另一台机器上     其中standby NameNode是用来合并日志文件和镜像文件的 并把合并的新的镜像文件拷贝一份给active NameNode    
HA组织架构(同一时刻只允许一个活跃结点)     1、Active NameNode         其功能和作用和NameNode是一样的         1、存储元数据信息             1)数据文件与block块的信息             2)block块与DataNode的映射信息         2、接受客户端请求,操作DataNode中的数据         3、接受DataNode的汇报,和DataNode建立连接机制(ping-pong)     2、Standby NameNode         备用节点 主要功能和主节点相同         唯一的不同就是:不能接受客户端发来的请求 不能发出任何操作指令
高可用的工作机制是通过两个NameNode来消除单点故障
自动故障转移机制     自动故障转移机制为hdfs提供了两个新组件Zookeeper和zkfc     Zookeeper维护少量协调数据 通知客户端这些数据的改变和监事客户端故障     功能:         为主备切换控制器提供主备选举支持。         辅助投票         和 ZKFC 保持心跳机制,确定 ZKFC 的存活         做选举作用 帮助集群判断NameNode是否宕机     ZKFC的作用是用来完成主备切换的 每一个NameNode都会有一个ZKFC         当集群启动时,主备节点的概念是很模糊的         当ZKFC只检查到一个节点是健康状态,直接将其设置为主节点         当zkfc检查到两个NN节点是的健康状态,发起投票机制         选出一个主节点,一个备用节点,并修改主备节点的状态
    启动后由ZKFailoverController、HealthMonitor 和 ActiveStandbyElector 这 3 个组件来协同实现主备切换         ZKFailoverController启动的时候会创建 HealthMonitor 和 ActiveStandbyElector 这两 个主要的内部组件         HealthMonitor 主要负责检测 NameNode 的健康状态         ActiveStandbyElector 主要负责完成自动的主备选举,内部封装了 Zookeeper 的处理逻辑
脑裂     就是在集群实际运行时可能会出现两个活跃的NameNode服务与集群 成为脑裂     解决方法:隔离    
NameNode和SecondaryNameNode工作机制     NameNode元数据存储在哪里?         元数据存储在内存中 效率较高         但是一但断电 数据即丢失 集群无法工作         所以在磁盘中产生了备份元数据的Fsimage文件         但是当在内存中更新元数据是又会产生新的Fsimage文件 导致效率过低         因此 需要用Edits文件(只进行追加操作) 当元数据更新或者添加时修改内存中的元数据并追加到Edits中         这样当断电时 就可以通过Fsimage和Edits文件合并 和成元数据     SecondaryNameNode专门用来合并Fsimage和Edits文件 并将合并的文件返回给NameNode
NameNode和SecondaryNameNode的工作步骤     首先启动hadoop集群     1、第一次启动NameNode格式化后 在/usr/local/soft/hadoop-2.7.6/tmp/dfs/name/current目录下         创建Fsimage和Edits文件 如果不是第一次创建 系统会把编辑日志和镜像文件加载进内存     2、NameNode接受客户端的操作请求 记录操作日志并更新日志 在内存中对数据进行操作     3、将更新前的编辑日志和镜像文件拷贝到SecondaryNameNode中     4、SecondaryNameNode加载日志文件和镜像文件进内存并合并 生成新的镜像文件Fsimage 并将合并的文件返回给NameNode     DataNode的工作机制     1、数据块在DataNode上以文件的形式存储在磁盘上         数据本身         元数据(数据块的长度 块数据的校验和 时间戳)     2、DataNode启动后向NameNode注册 通过后 周期性的向NameNode上报所有的快信息     3、心跳每三秒一次 返回结果带有NameNode给该DataNode的操作信息         (十分钟30秒没有收到信息说明该节点不可用)     集群的安全模式     1、NameNode启动         首先将镜像文件加载进内存,并执行编辑日志中的各项操作,当在内存中成功建立文件系统元数据的映像         则创建一个新的Fsimage文件和一个空的Edits文件,此时NameNode开始监听DataNode请求 在这个期间         NameNode一致处于安全模式 即NameNode文件系统对客户端来说是只读的     2、DataNode启动         系统中的数据块的位置并不是有NameNode来维护的,而是以快列表的形式存储在DataNode中,在系统的         正常操作期间,NameNode会在内存中保留所有块的映射信息,在安全模式下各个DataNode会向NameNode         发送最新的块列表信息,NameNode了解到足够多的列表信息后,既可高效的运行文件系统     3、安全模式退出         如果满足最小副本条件 NameNode会在30秒后退出安全模式 在启动一个刚刚格式化后的集群之后         因为系统中没有任何块 所以NameNode不会进入安全模式
机架感知     为了保证副本在集群中的安全性     需要将block块存放在不同的DataNode节点上     第一个节点         集群内部:优先考虑和客户端相同的节点作为第一节点         集群外部:选择资源丰富且不繁忙的结点作为第一节点     第二个节点         选择与第一个节点不同机架的其他节点     第三个节点         选择与第二结点相同机架的其他节点     第n各节点         选择与前面不重复的其他节点

hdfs存储小文件的弊端     每个文件均按块存储 每个块的元数据存储在NameNode的内存中 因此hdfs存储小文件的效率非常低,因为有     大量的小文件会耗尽NameNode中的大部分内存。但是注意存储小文件所需的磁盘容量和数据块大小无关 解决方法:     HDFS存档文件     具体来说,hdfs存档文件对内还是一个一个的独立的小文件 对NameNode而言却是一个整体,减少了NameNode的     内存     命令:hadoop archive -archiveName 文件的名称 -p 本地文件夹 目标文件夹    
共享存储系统 一个独立的小集群 NameNode通过共享存储系统实现日志数据的同步 Active NameNode会将新增的日志文件同步添加到JournalNode Standby NameNode会从该节点上将日志文件 拉取下来,和本地的镜像文件合并成新的镜像文件并同步一份给Active NameNode 注意:     JournalNode不要求所有的结点都收到日志文件 只要有半数的结点收到日志那么该条日志就生效
同一节点上:distance=0 同一机架上不同节点:distance=2 统一数据中心不同机架上:distance=4 不同数据中心的结点:distance=6
       

标签:HDFS,文件,hadoop,学习,DataNode,NameNode,数据,客户端
From: https://www.cnblogs.com/lkd0910/p/16933774.html

相关文章