大数据Hadoop运维应用实践——通过Ambari自动化部署hadoop集群下文章浏览阅读29次。本文是关于安装部署完成Ambari Server后使用Ambari Web管理界面实现hadoop集群的安装部署操作详细讲解了初始化一个hadoop集群的实践操作步骤可视化的操作与配置极大提升了hadoop集群的搭建操作最后还讲解了使用Ambari Web管理界面对hadoop集群添加节点进行扩容、添加服务进行了详细的说明。https://coffeemilk.blog.csdn.net/article/details/163087528一、HDFS的基础架构原理解析1.0、HDFS的基础架构原理HDFS基础架构内容说明NameNodeNameNode是HDFS分布式存储的管理节点专门用来存储元数据的相关信息所谓的“元数据”是指文件内容之外的数据【如文件的存储位置、文件信息、文件大小、文件名称等】这些与文件属性相关的信息也可以简单的类比为现实书籍中的目录【记录了内容章节、位置等信息】是十分重要的一旦元数据丢失那么文件内容就很难找回来了因此对元数据的保护尤其重要。元数据首先是保存在内存中的而对元数据的各种增删改查都是在内存中完成内存中操作后的元数据会定时持久化到磁盘上。当NameNode启动时会从磁盘上加载元数据到内存中后续对元数据的操作都是在内存中完成。DataNodeDataNode是HDFS分布式存储的数据节点是真正存储数据的部分。而HDFS分布式存储数据都是以数据块(data block)的方式保存在DataNode节点服务器的本地磁盘的文件系统上同时DataNode也做了数据块到本地文件系统的映射即每个数据块都有具体的标识id或名称每个数据块对应哪个文件数据块与文件的映射关系都是在DataNode上保存的。ClientClient是HDFS分布式存储的客户端用来与HDFS进行交互的。SecondaryNameNodeSecondaryNameNode是NameNode的备份节点主要是用来备份NameNode的元数据。需要注意的是SecondaryNameNode是对NameNode的异地冷备份而不是热备份。热备份是指服务在正常运行的过程中不用重启服务或关闭启动服务就能够对服务的元数据进行备份并且是可以做到实时无差别的备份。冷备份是指定时的备份且备份的数据是不完整的与主体的数据是不一致的。StandbyNameNode是NameNode的热备份节点实现对NameNode元数据的实时备份确保元数据的一致性。注意StandbyNameNode不能对外提供服务但是可以通过JournalNode集群实时拉取NameNode的元数据到自己中当NameNode发生故障时StandbyNameNode会第一时间发现并自己切换为主节点激活对外提供服务而NameNode就转为备节点了即StandbyNameNode与NameNode是通过zookeeper集群进行双方的状态监控一旦一方故障另一方就会第一时间发现进行角色的切换然后另一方就会转为主节点激活对外提供服务了。JournalNode只在HDFS的HA模式下出现JournalNode作为一个守护进程实现了元数据在主、备节点的共享。1.1、NameNode的工作原理解析NameNode是HDFS分布式存储的心脏它管理和维护着整个HDFS文件系统主要功能作用如下表NameNode的主要功能作用《1》负责接收用户的操作请求。《2》负责管理文件系统命名空间namespace、集群配置信息以及存储块的复制等。《3》负责文件目录树的维护以及文件对应block列表的维护。《4》负责管理block与DataNode之间的关系。在HDFS分布式存储中【FsImage】与【Edit Log】是NameNode两个非常重要的文件。它们存储在NameNode节点的本地磁盘上这就是NameNode的元数据信息。NameNode的元数据组成说明FsImageFsImage文件用来记录数据块到文件的映射、目录或文件的结构、属性等信息里面记录了自最后一次检查点之前HDFS文件系统中所有目录和文件的信息。Edit LogEditLog文件记录了对文件的创建、删除、重命名等操作日志也就是自最后一次检查点之后所有针对HDFS文件系统的操作都会记录在EditLog文件中如在HDFS中创建一个文件 Namenode就会在EditLog中插入一条记录同样地修改文件的副本系数也会在EditLog中插入一条记录。检查点当NameNode启动时首先会将元数据加载到内存中即将磁盘上的FsImage与EditLog数据加载到内存中FsImage作为文件系统的基础镜像而EditLog内容会回放一遍到FsImage中合并形成一份新的FsImage文件新的FsImage文件会保存一份到磁盘中同时会删除旧的EditLog文件其中EditLog内容会回放一遍到FsImage中合并形成一份新的FsImage文件的过程就称为一个检查点。检查点就是为了解决EditLog文件不断变大的问题即当NameNode启动后会形成一个检查点之后对于元数据的所有操作都会记录到EditLog文件中正常来说NameNode启动后半年或几年都不会重启一次的这样EditLog文件就会变得十分庞大【即NameNode启动的时间越长EditLog文件也会越大】虽然对于我们使用HDFS分布式存储来说并没有什么问题但是若当NameNode服务器故障后【如突然断电、宕机】恢复后再次重启NameNode时EditLog文件十分庞大【如几百几千GB】此时元数据加载到内存中进行FsImage与EditLog合并时就会需要花费几个或几十个小时的时间合并完不成NameNode也无法启动这样在生产环境下是绝对无法忍受的在NameNode正常运行的时候就多产生几次检查点这样就能够平衡元数据(FsImage与EditLog文件了)有两种方法可以多产出检查点通过配置两次检查点的时间间隔【dfs.namenode.checkpoint.period 默认是3600秒1小时】来实现通过配置EditLog中的事务数量达到的阈值【dfs.namenode.checkpoint.txns 默认是1000000100万】时自动触发创建检查点操作。这两个创建检查点的操作是不冲突的只要任意一个达到都会触发检查点产生。注意检查点是不能随意触发的因为每次检查点执行的过程会消耗大量的CPU、IO与内存资源且检查点执行时是会阻塞HDFS对外的读写操作即无法接收外部的读写等请求导致无法对外提供服务因此检查点是不会在主节点NameNode触发HDFS给出了几种方案在SecondaryNameNode节点触发检查点若启用了HA模式则会在StandbyNameNode备用节点触发检查点1.2、SecondaryNameNode工作原理解析SecondaryNameNode的工作原理解析《1》SecondaryNameNode节点会定期和NameNode通信请求其停止使用EditLog暂时将新的写操作转到一个新的文件edit.new上来这个操作是瞬间完成的。《2》SecondaryNameNode 通过HTTP Get方式从NameNode上获取元数据FsImage和EditLog文件并下载到本地目录。《3》将下载下来的元数据FsImage和EditLog文件加载到内存中即使用FsImage为基础镜像逐一读取EditLog内容加入直到两者合并完成合并完成后会产生一个新的FsImage文件这个过程就是检查点checkpoint。《4》合并成功之后会通过post方式将新的FsImage文件发送NameNode上。《5》Namenode会将新接收到的FsImage替换掉旧的即将旧的重命名同时用edit.new替换EditLog这样EditLog就会变小。#1-【轮询间隔】SecondaryNameNode多久向NameNode发起一次轮查询【EditLog文件中未执行检查点的累计事务数量上限】【距离上一次检查点的时长】 #单位秒默认值60秒1分钟 dfs.namenode.checkpoint.check.period #2-【时间阈值】连续两次检查点的最大时间阈值超过该阈值就立刻触发检查点 #单位秒默认值3600秒 1小时 dfs.namenode.checkpoint.period #3-【事务阈值】EditLog文件中的累计的未执行检查点的事务数量上限达到阈值就立刻触发检查点 # 默认值1000000 100万条事务 dfs.namenode.checkpoint.txns #应用在【hdfs-site.xml】配置文件中 configuration !-- 【轮询间隔】SecondaryNameNode/CheckpointNode多久向NameNode发起一次轮询查询待合并事务数 单位秒默认值60秒 -- property namedfs.namenode.checkpoint.check.period/name value60/value /property !-- 【时间阈值】两次检查点之间的最大时间间隔超过该时长触发checkpoint 单位秒默认值3600秒 1小时 -- property namedfs.namenode.checkpoint.period/name value3600/value /property !-- 【事务阈值】未执行checkpoint的累积事务数量上限达到阈值立即触发checkpoint 默认值1000000 100万条事务 -- property namedfs.namenode.checkpoint.txns/name value1000000/value /property /configurationSNN的核心执行逻辑✅SNN/CheckpointNode每 dfs.namenode.checkpoint.check.period 秒询问 Active NN当前未 checkpoint 事务数量、距离上一次 checkpoint 时长✅满足任一条件立刻执行 checkpoint距离上次 checkpoint ≥ dfs.namenode.checkpoint.period未 checkpoint 事务 ≥ dfs.namenode.checkpoint.txns✅HA 集群中Standby NameNode 承担原来 SecondaryNameNode 的 checkpoint 逻辑参数完全复用这套配置。1.3、NameNode的元数据存储解析元数据在Namenode中有3种存储形式分别是【内存】、【EditLog文件】与【FsImage】文件最完整、最新的元数据一定是内存中的这一部分。可在NameNode服务器的【/etc/hadoop/conf/hdfs-site.xml】文件的【dfs.datanode.data.dir】节点下获取到元数据的存储路径或者在Ambari Web管理界面的【Services--HDFS--CONFIGS--SETTINGS】下查看到元数据的存储路径如/data/hadoop/dfs/data,/data1/hadoop/dfs/data这两个路径存储的内容是一样的随便进入一个路径下查看即可HDFS分布式存储元数据内容说明Edit Log格式edits_事务的开始ID-事务的结束ID示例edits_0000000000000001026-0000000000000001027edits_inprogress_0000000000000001058是当前正在写入的事务日志seen_txid保存着最后一次检查点的事务IDfsimage格式fsimage_事务的结束ID示例fsimage_0000000000000001027从fsimage的示例中的事务ID可以判断后续若要手动清理Edit Log文件则可以将事务ID为1027之前的EditLog文件都删除掉因为fsimage_0000000000000001027文件已经包含了。VERSION文件是记录着当前HDFS的版本信息1.4、StandbyNameNode下JournalNode的元数据管理StandbyNameNode下JournalNode的元数据管理也就是说必须是双NameNode的Hadoop集群【即激活的NameNode是主节点、standby的NameNode节点是备用节点】。大数据Hadoop运维应用实践——双NameNode高可用Hadoop集群架构上https://coffeemilk.blog.csdn.net/article/details/162849636StandbyNameNode下JournalNode的元数据管理解析JournalNode只在HDFS的HA模式下出现JournalNode作为一个守护进程实现了元数据在主、备节点的共享。JournalNode的元数据目录在hdfs-site.xml文件中通过【dfs.journalnode.edits.dir】参数指定。JournalNode的元数据包含【一个VERSION文件】、【多个edits_xx文件】与【一个edits_inprogress_xxx文件】还包含一些与HA实现相关的文件这些文件主要是为了防止脑裂但JournalNode中并不包含fsimage和seen_txid文件。在HA模式下StandbyNameNode会周期的让主NameNode对Edit Log文件进行回滚间隔周期由dfs.ha.log-roll.period指定默认是120sStandbyNameNode之所以周期性的让主NameNode回滚Edit Log是因为StandbyNameNode不会读取inprogress的Edit Log文件它只会周期性dfs.ha.tail-edits.period默认是60s的去检测已经完成的Edit Log文件然后将该Edit Log文件通过JournalNode读取到内存进而更新fsimage在内存中的状态。在达到checkpoint触发条件后新的fsimage文件会在StandbyNameNode上生成接着StandbyNameNode会删除自己磁盘上保留的陈旧的fsimage文件然后将新的fsimage文件上传给主NameNode。Edit Log文件的生成时每2分钟生成一个edits_xxx-xxx文件是由【dfs.ha.log-roll.period】参数控制默认是120秒2分钟。JounalNode的元数据目录下只有Edit Log文件没有fsimage文件如下图所示StandbyNameNode备用NameNode节点的元数据目录下是只有【edits_inprogress_xxx】与【fsimage】文件如下图所示二、HDFS读取、写入数据流程解析2.1、HDFS分布式存储特点HDFS分布式存储的特点《1》一次写入多次读取不可修改只可追加。《2》文件由数据块block组成数据块大小默认是128MB若文件大小不足128M则也会单独存成一个块一个块只能存一个文件的数据即使一个文件不足128M也会占用一个块块是一个逻辑空间并不会占磁盘空间。《3》默认情况下每个块都有三个副本三个副本会存储到不同的节点上。副本越多磁盘利用率越低但是数据的安全性越高。可以通过修改hdfs-site.xml的【dfs.replication】属性设置副本的个数。《4》文件按大小被切分成若干个块存储到不同的节点上块大小可通过配置文件进行配置或修改。2.2、客户端读取HDFS分布式存储数据流程客户端读取HDFS分布式存储数据流程如上图所示《1》客户端向Namenode请求读取一个文件Namenode通过查询元数据找到请求文件对应的数据块所在的位置也就是块文件对应的datanode节点地址。《2》Namenode返回自己查询到的元数据信息给客户端。《3》客户端挑选一台Datanode根据就近原则然后随机原则服务器开始请求读取数据。《4》datanode开始传输数据给客户端从磁盘里面读取数据放入流以packet为单位来做校验。《5》客户端以packet为单位接收先在本地缓存然后写入目标文件。2.3、客户端写入数据到HDFS分布式存储流程客户端写入数据到HDFS分布式存储流程如上图所示《1》客户端(Client)对Namenode发起上传文件的请求Namenode接到请求后马上检查请求文件是否已存在上级目录是否存在。《2》Namenode检查发现请求的文件如果不存在那么就响应客户端请求可以上传文件。《3》客户端(Client)首先对文件进行切分假定HDFS的一个块(block)大小是128M如果写入的文件大小有300M那么此文件就会被切分成3个块分别是两个128M和一个44M接着客户端向Namenode发起请求第一个block该传输到哪些datanode服务器上。《4》Namenode返回信息给客户端(Client)告知可以上传到哪些datanode服务节点上这里假定有三个副本所以一个块需要上传到三个节点上这里设定上传到A、B、C三个datanode节点。《5》Client开始和Datanode建立传输通道首先请求datanode A节点上传数据本质上是一个RPC调用建立pipelineDatanode A收到请求后会继续调用Datanode B然后Datanode B再去调用第三个datanode C将整个pipeline建立完成逐级返回Client。《6》Client开始往A上传第一个block先从磁盘读取数据放到一个本地内存缓存以packet为单位一个packet为64kbDatanode A收到一个packet就会传给Datanode BDatanode B接着传给Datanode CDatanode A每传一个packet会放入一个应答队列等待应答。《7》当一个block传输完成之后Client再次请求Namenode开始上传第二个block上传过程重复上面4-6步骤。三、HDFS Shell操作3.1、查看HDFS文件系统上文件#查看HDFS文件系统上文件 su - hadoop hadoop fs -ls / hadoop fs -ls /user hadoop fs -cat /logs/coffeemilk/test.txt #通过-text可查看压缩文件的内容支持场景的zip、gzip、bzip2等压缩格式 hadoop fs -text /logs/coffeemilk/nginx-1.28.0.tar.gz3.2、HDFS文件系统中增加文件#HDFS文件系统中增加文件 hadoop fs -mkdir -p /logs/coffeemilk hadoop fs -touch /logs/coffeemilk/text.txt #将本地的/data/nginx-1.28.0.tar.gz文件上传到HDFS分布式存储下的/logs/coffeemilk目录 hadoop fs -put /data/nginx-1.28.0.tar.gz /logs/coffeemilk #将HDFS分布式存储下的/logs/coffeemilk/nginx-1.28.0.tar.gz文件拉取到本地的/home/hadoop目录下 hadoop fs -get /logs/coffeemilk/nginx-1.28.0.tar.gz /home/hadoop3.3、HDFS文件系统中移动文件#HDFS文件系统中移动文件 #移动文件可以实现本地磁盘文件移动到HDFS、HDFS上各个路径直接的移动、文件改名等操作 #1-两个路径均为HDFS上路径 hadoop fs -mv /logs/coffeemilk/nginx-1.28.0.tar.gz /tmp #将本地/data/mysql-8.4.5-linux-glibc2.28-x86_64.tar.xz文件上传到HDFS的/tmp目录下 hadoop fs -moveFromLocal /data/mysql-8.4.5-linux-glibc2.28-x86_64.tar.xz /tmp3.4、HDFS文件系统中删除文件#HDFS文件系统中删除文件 #1-无论是文件或者目录都可以通过如下命令进行删除 hadoop fs -rm -r /logs/coffeemilk/text.txt #2-如果你确定这个某个文件可以删除不需要进入回收站的话可以执行如下命令 hadoop fs -rm -r -skipTrash /tmp/nginx-1.28.0.tar.gz #-只看HDFS回收站可恢复文件 hdfs dfs -ls /user/hadoop/.Trash/Current # 递归查看所有文件 hdfs dfs -ls -R /user/hadoop/.Trash/Current #3-要清空HDFS回收站可执行如下命令 hadoop fs -expunge3.5、HDFS文件系统中追加文件内容#HDFS文件系统中追加文件内容 #HDFS上的文件不能修改但可以在文件最后追加内容要对一个已经存在的文件追加内容 #1-将本地coffeemilk.log文件的内容追加到HDFS的/logs/coffeemilk.log文件的最后 echo this is append info test 666coffeemilk.log hadoop fs -appendToFile coffeemilk.log /logs/coffeemilk.log #2-管道直接追加不产生本地文件 echo direct add info 777 | hdfs dfs -appendToFile - /logs/coffeemilk.log3.6、HDFS文件系统中对文件进行授权#HDFS文件系统中对文件进行授权 #对文件或目录进行授权主要使用了linux上的两个命令chown和chmodhdfs上授权文件的用法如下 hadoop fs -chown -R hadoop:hadoop /logs/coffeemilk.log hadoop fs -chmod 744 /logs/coffeemilk.log