1. HDFS概述
Hadoop 分布式系统框架中,首要的根底性能就是文件系统,在 Hadoop 中应用 FileSystem 这个抽象类来示意咱们的文件系统,这个抽象类上面有很多子实现类,到底应用哪一种,须要看咱们具体的实现类,在咱们理论工作中,用到的最多的就是HDFS(分布式文件系统)以及LocalFileSystem(本地文件系统)了。
在古代的企业环境中,单机容量往往无奈存储大量数据,须要跨机器存储。对立治理散布在集群上的文件系统称为分布式文件系统。
HDFS(Hadoop Distributed File System)是 Hadoop 我的项目的一个子项目。是 Hadoop 的外围组件之一, Hadoop 十分适于存储大型数据 (比方 TB 和 PB),其就是应用 HDFS 作为存储系统. HDFS 应用多台计算机存储文件,并且提供对立的拜访接口,像是拜访一个一般文件系统一样应用分布式文件系统。
2. HDFS架构
HDFS是一个主/从(Mater/Slave)体系结构,由三局部组成: NameNode 和 DataNode 以及 SecondaryNamenode:
- NameNode 负责管理整个文件系统的元数据,以及每一个门路(文件)所对应的数据块信息。
- DataNode 负责管理用户的文件数据块,每一个数据块都能够在多个 DataNode 上存储多个正本,默认为3个。
- Secondary NameNode 用来监控 HDFS 状态的辅助后台程序,每隔一段时间获取 HDFS 元数据的快照。最次要作用是辅助 NameNode 治理元数据信息。
3. HDFS的个性
首先,它是一个文件系统,用于存储文件,通过对立的命名空间目录树来定位文件;
其次,它是分布式的,由很多服务器联结起来实现其性能,集群中的服务器有各自的角色。
- 1. master/slave 架构(主从架构)
HDFS 采纳 master/slave 架构。个别一个 HDFS 集群是有一个 Namenode 和肯定数目的 Datanode 组成。Namenode 是 HDFS 集群主节点,Datanode 是 HDFS 集群从节点,两种角色各司其职,独特协调实现分布式的文件存储服务。
- 2. 分块存储
HDFS 中的文件在物理上是分块存储(block)的,块的大小能够通过配置参数来规定,默认大小在 hadoop2.x 版本中是 128M。
- 3. 名字空间(NameSpace)
HDFS 反对传统的档次型文件组织构造。用户或者应用程序能够创立目录,而后将文件保留在这些目录里。文件系统名字空间的层次结构和大多数现有的文件系统相似:用户能够创立、删除、挪动或重命名文件。
Namenode 负责保护文件系统的名字空间,任何对文件系统名字空间或属性的批改都将被 Namenode 记录下来。
HDFS 会给客户端提供一个对立的形象目录树,客户端通过门路来拜访文件,形如:hdfs://namenode:port/dir-a/dir-b/dir-c/file.data。
- 4. NameNode 元数据管理
咱们把目录构造及文件分块地位信息叫做元数据。NameNode 负责保护整个 HDFS 文件系统的目录树结构,以及每一个文件所对应的 block 块信息(block 的 id,及所在的 DataNode 服务器)。
- 5. DataNode 数据存储
文件的各个 block 的具体存储管理由 DataNode 节点承当。每一个 block 都能够在多个 DataNode 上。DataNode 须要定时向 NameNode 汇报本人持有的 block 信息。 存储多个正本(正本数量也能够通过参数设置 dfs.replication,默认是 3)
- 6. 正本机制
为了容错,文件的所有 block 都会有正本。每个文件的 block 大小和正本系数都是可配置的。应用程序能够指定某个文件的正本数目。正本系数能够在文件创建的时候指定,也能够在之后扭转。
- 7. 一次写入,屡次读出
HDFS 是设计成适应一次写入,屡次读出的场景,且不反对文件的批改。
正因为如此,HDFS 适宜用来做大数据分析的底层存储服务,并不适宜用来做网盘等利用,因为批改不不便,提早大,网络开销大,老本太高。
4. HDFS 的命令行应用
如果没有配置 hadoop 的环境变量,则在 hadoop 的装置目录下的bin目录中执行以下命令,如已配置 hadoop 环境变量,则可在任意目录下执行
help
格局: hdfs dfs -help 操作命令作用: 查看某一个操作命令的参数信息
ls
格局:hdfs dfs -ls URI作用:相似于Linux的ls命令,显示文件列表
lsr
格局 : hdfs dfs -lsr URI作用 : 在整个目录下递归执行ls, 与UNIX中的ls-R相似
mkdir
格局 : hdfs dfs -mkdir [-p] <paths>作用 : 以<paths>中的URI作为参数,创立目录。应用-p参数能够递归创立目录
put
格局 : hdfs dfs -put <localsrc > ... <dst>作用 : 将单个的源文件src或者多个源文件srcs从本地文件系统拷贝到指标文件系统中(<dst>对应的门路)。也能够从规范输出中读取输出,写入指标文件系统中
hdfs dfs -put /rooot/bigdata.txt /dir1
moveFromLocal
格局: hdfs dfs -moveFromLocal <localsrc> <dst>作用: 和put命令相似,然而源文件localsrc拷贝之后本身被删除
hdfs dfs -moveFromLocal /root/bigdata.txt /
copyFromLocal
格局: hdfs dfs -copyFromLocal <localsrc> ... <dst>作用: 从本地文件系统中拷贝文件到hdfs门路去
appendToFile
格局: hdfs dfs -appendToFile <localsrc> ... <dst>作用: 追加一个或者多个文件到hdfs指定文件中.也能够从命令行读取输出.
hdfs dfs -appendToFile a.xml b.xml /big.xml
moveToLocal
在 hadoop 2.6.4 版本测试还未未实现此办法格局:hadoop dfs -moveToLocal [-crc] <src> <dst>作用:将本地文件剪切到 HDFS
get
格局 hdfs dfs -get [-ignorecrc ] [-crc] <src> <localdst>作用:将文件拷贝到本地文件系统。 CRC 校验失败的文件通过-ignorecrc选项拷贝。 文件和CRC校验能够通过-CRC选项拷贝
hdfs dfs -get /bigdata.txt /export/servers
getmerge
格局: hdfs dfs -getmerge <src> <localdst>作用: 合并下载多个文件,比方hdfs的目录 /aaa/下有多个文件:log.1, log.2,log.3,...
copyToLocal
格局: hdfs dfs -copyToLocal <src> ... <localdst>作用: 从hdfs拷贝到本地
mv
格局 : hdfs dfs -mv URI <dest>作用: 将hdfs上的文件从原门路挪动到指标门路(挪动之后文件删除),该命令不能跨文件系统
hdfs dfs -mv /dir1/bigdata.txt /dir2
rm
格局: hdfs dfs -rm [-r] 【-skipTrash】 URI 【URI 。。。】作用: 删除参数指定的文件,参数能够有多个。 此命令只删除文件和非空目录。如果指定-skipTrash选项,那么在回收站可用的状况下,该选项将跳过回收站而间接删除文件;否则,在回收站可用时,在HDFS Shell 中执行此命令,会将文件临时放到回收站中。
hdfs dfs -rm -r /dir1
cp
格局: hdfs dfs -cp URI [URI ...] <dest>作用: 将文件拷贝到指标门路中。如果<dest> 为目录的话,能够将多个文件拷贝到该目录下。-f选项将笼罩指标,如果它曾经存在。-p选项将保留文件属性(工夫戳、所有权、许可、ACL、XAttr)。
hdfs dfs -cp /dir1/a.txt /dir2/bigdata.txt
cat
hdfs dfs -cat URI [uri ...]作用:将参数所批示的文件内容输入到stdout
hdfs dfs -cat /bigdata.txt
tail
格局: hdfs dfs -tail path作用: 显示一个文件的开端
text
格局:hdfs dfs -text path作用: 以字符模式打印一个文件的内容
chmod
格局:hdfs dfs -chmod [-R] URI[URI ...]作用:扭转文件权限。如果应用 -R 选项,则对整个目录无效递归执行。应用这一命令的用户必须是文件的所属用户,或者超级用户。
hdfs dfs -chmod -R 777 /bigdata.txt
chown
格局: hdfs dfs -chmod [-R] URI[URI ...]作用: 扭转文件的所属用户和用户组。如果应用 -R 选项,则对整个目录无效递归执行。应用这一命令的用户必须是文件的所属用户,或者超级用户。
hdfs dfs -chown -R hadoop:hadoop /bigdata.txt
df
格局: hdfs dfs -df -h path作用: 统计文件系统的可用空间信息
du
格局: hdfs dfs -du -s -h path作用: 统计文件夹的大小信息
count
格局: hdfs dfs -count path作用: 统计一个指定目录下的文件节点数量
setrep
格局: hdfs dfs -setrep num filePath作用: 设置hdfs中文件的正本数量留神: 即便设置的超过了datanode的数量,正本的数量也最多只能和datanode的数量是统一的
expunge (慎用)
格局: hdfs dfs -expunge作用: 清空hdfs垃圾桶
5. hdfs的高级应用命令
5.1. HDFS文件限额配置
在多人共用HDFS的环境下,配置设置十分重要。特地是在 Hadoop 解决大量材料的环境,如果没有配额治理,很容易把所有的空间用完造成他人无奈存取。HDFS 的配额设定是针对目录而不是针对账号,能够让每个账号仅操作某一个目录,而后对目录设置配置。
HDFS 文件的限额配置容许咱们以文件个数,或者文件大小来限度咱们在某个目录下上传的文件数量或者文件内容总量,以便达到咱们相似百度网盘网盘等限度每个用户容许上传的最大的文件的量。
hdfs dfs -count -q -h /user/root/dir1 #查看配额信息
后果:
5.1.1. 数量限额
hdfs dfs -mkdir -p /user/root/dir #创立hdfs文件夹hdfs dfsadmin -setQuota 2 dir # 给该文件夹上面设置最多上传两个文件,发现只能上传一个文件
hdfs dfsadmin -clrQuota /user/root/dir # 革除文件数量限度
5.1.2. 空间大小限额
在设置空间配额时,设置的空间至多是 block_size * 3 大小
hdfs dfsadmin -setSpaceQuota 4k /user/root/dir # 限度空间大小4KBhdfs dfs -put /root/a.txt /user/root/dir
生成任意大小文件的命令:
dd if=/dev/zero of=1.txt bs=1M count=2 #生成2M的文件
革除空间配额限度
hdfs dfsadmin -clrSpaceQuota /user/root/dir
5.2. HDFS 的平安模式
平安模式是hadoop的一种爱护机制,用于保障集群中的数据块的安全性。当集群启动的时候,会首先进入平安模式。当零碎处于平安模式时会检查数据块的完整性。
假如咱们设置的正本数(即参数dfs.replication)是3,那么在datanode上就应该有3个正本存在,假如只存在2个正本,那么比例就是2/3=0.666。hdfs默认的正本率0.999。咱们的正本率0.666显著小于0.999,因而零碎会主动的复制正本到其余dataNode,使得正本率不小于0.999。如果零碎中有5个正本,超过咱们设定的3个正本,那么零碎也会删除多于的2个正本。
在平安模式状态下,文件系统只承受读数据申请,而不承受删除、批改等变更申请。在,当整个零碎达到平安规范时,HDFS主动来到平安模式。30s
平安模式操作命令
hdfs dfsadmin -safemode get #查看平安模式状态 hdfs dfsadmin -safemode enter #进入平安模式 hdfs dfsadmin -safemode leave #来到平安模式
6. HDFS 的 block 块和正本机制
HDFS 将所有的文件全副形象成为 block 块来进行存储,不论文件大小,全副厚此薄彼都是以 block 块的对立大小和模式进行存储,不便咱们的分布式文件系统对文件的治理。
所有的文件都是以 block 块的形式寄存在 hdfs 文件系统当中,在 Hadoop 1 版本当中,文件的 block 块默认大小是 64M,Hadoop 2 版本当中,文件的 block 块大小默认是128M,block块的大小能够通过 hdfs-site.xml 当中的配置文件进行指定。
<property> <name>dfs.block.size</name> <value>块大小 以字节为单位</value> //只写数值就能够</property>
6.1 形象为block块的益处
- 1) 一个文件有可能大于集群中任意一个磁盘
10T*3/128 = xxx块 2T,2T,2T 文件形式存—–>多个block块,这些block块属于一个文件 - 2) 应用块形象而不是文件能够简化存储子系统
- 3) 块非常适合用于数据备份进而提供数据容错能力和可用性
6.2 块缓存
通常 DataNode 从磁盘中读取块,但对于拜访频繁的文件,其对应的块可能被显示的缓存在 DataNode 的内存中,以堆外块缓存的模式存在。默认状况下,一个块仅缓存在一个DataNode的内存中,当然能够针对每个文件配置DataNode的数量。作业调度器通过在缓存块的DataNode上运行工作,能够利用块缓存的劣势进步读操作的性能。
例如:
连贯(join)操作中应用的一个小的查问表就是块缓存的一个很好的候选。 用户或利用通过在缓存池中减少一个cache directive来通知namenode须要缓存哪些文件及存多久。缓存池(cache pool)是一个领有治理缓存权限和资源应用的管理性分组。
例如:
一个文件 130M,会被切分成2个block块,保留在两个block块外面,理论占用磁盘130M空间,而不是占用256M的磁盘空间
6.3 hdfs的文件权限验证
hdfs的文件权限机制与linux零碎的文件权限机制相似
r:read w:write x:execute
权限x对于文件示意疏忽,对于文件夹示意是否有权限拜访其内容
如果linux零碎用户zhangsan应用hadoop命令创立一个文件,那么这个文件在HDFS当中的owner就是zhangsan
HDFS文件权限的目标,避免坏蛋做错事,而不是阻止好人做好事。HDFS置信你通知我你是谁,你就是谁
6.4 hdfs的正本因子
为了保障block块的安全性,也就是数据的安全性,在hadoop2当中,文件默认保留三个正本,咱们能够更改正本数以进步数据的安全性
、在hdfs-site.xml当中批改以下配置属性,即可更改文件的正本数
<property> <name>dfs.replication</name> <value>3</value></property>
7. HDFS 文件写入过程(十分重要)
- Client 发动文件上传申请,通过 RPC 与 NameNode 建设通信, NameNode 查看指标文件是否已存在,父目录是否存在,返回是否能够上传;
- Client 申请第一个 block 该传输到哪些 DataNode 服务器上;
- NameNode 依据配置文件中指定的备份数量及机架感知原理进行文件调配, 返回可用的 DataNode 的地址如:A, B, C;
Hadoop 在设计时思考到数据的平安与高效, 数据文件默认在 HDFS 上寄存三份, 存储策略为本地一份,同机架内其它某一节点上一份,不同机架的某一节点上一份。
- Client 申请 3 台 DataNode 中的一台 A 上传数据(实质上是一个 RPC 调用,建设 pipeline ),A 收到申请会持续调用 B,而后 B 调用 C,将整个 pipeline 建设实现, 后逐级返回 client;
- Client 开始往 A 上传第一个 block(先从磁盘读取数据放到一个本地内存缓存),以 packet 为单位(默认64K),A 收到一个 packet 就会传给 B,B 传给 C。A 每传一个 packet 会放入一个应答队列期待应答;
- 数据被宰割成一个个 packet 数据包在 pipeline 上顺次传输,在 pipeline 反方向上, 一一发送 ack(命令正确应答),最终由 pipeline 中第一个 DataNode 节点 A 将 pipelineack 发送给 Client;
- 当一个 block 传输实现之后,Client 再次申请 NameNode 上传第二个 block,反复步骤 2;
7.1 网络拓扑概念
在本地网络中,两个节点被称为“彼此近邻”是什么意思?在海量数据处理中,其次要限度因素是节点之间数据的传输速率——带宽很稀缺。这里的想法是将两个节点间的带宽作为间隔的衡量标准。
节点间隔:两个节点达到最近的独特先人的间隔总和。
例如,假如有数据中心d1机架r1中的节点n1。该节点能够示意为/d1/r1/n1。利用这种标记,这里给出四种间隔形容。
Distance(/d1/r1/n1, /d1/r1/n1)=0(同一节点上的过程)
Distance(/d1/r1/n1, /d1/r1/n2)=2(同一机架上的不同节点)
Distance(/d1/r1/n1, /d1/r3/n2)=4(同一数据中心不同机架上的节点)
Distance(/d1/r1/n1, /d2/r4/n2)=6(不同数据中心的节点)
7.2 机架感知(正本节点抉择)
1)低版本Hadoop正本节点抉择
第一个正本在client所处的节点上。如果客户端在集群外,随机选一个。
第二个正本和第一个正本位于不雷同机架的随机节点上。
第三个正本和第二个正本位于雷同机架,节点随机。
2) Hadoop2.7.2 正本节点抉择
第一个正本在client所处的节点上。如果客户端在集群外,随机选一个。
第二个正本和第一个正本位于雷同机架,随机节点。
第三个正本位于不同机架,随机节点。
8.HDFS 文件读取过程(十分重要)
- Client向NameNode发动RPC申请,来确定申请文件block所在的地位;
- NameNode会视状况返回文件的局部或者全副block列表,对于每个block,NameNode 都会返回含有该 block 正本的 DataNode 地址; 这些返回的 DN 地址,会依照集群拓扑构造得出 DataNode 与客户端的间隔,而后进行排序,排序两个规定:网络拓扑构造中距离 Client 近的排靠前;心跳机制中超时汇报的 DN 状态为 STALE,这样的排靠后;
- Client 选取排序靠前的 DataNode 来读取 block,如果客户端自身就是DataNode,那么将从本地间接获取数据(短路读取个性);
- 底层上实质是建设 Socket Stream(FSDataInputStream),反复的调用父类 DataInputStream 的 read 办法,直到这个块上的数据读取结束;
- 当读完列表的 block 后,若文件读取还没有完结,客户端会持续向NameNode 获取下一批的 block 列表;
- 读取完一个 block 都会进行 checksum 验证,如果读取 DataNode 时呈现谬误,客户端会告诉 NameNode,而后再从下一个领有该 block 正本的DataNode 持续读。
- read 办法是并行的读取 block 信息,不是一块一块的读取;NameNode 只是返回Client申请蕴含块的DataNode地址,并不是返回申请块的数据;
- 最终读取来所有的 block 会合并成一个残缺的最终文件。
从 HDFS 文件读写过程中,能够看出,HDFS 文件写入时是串行写入的,数据包先发送给节点A,而后节点A发送给B,B在给C;而HDFS文件读取是并行的, 客户端 Client 间接并行读取block所在的节点。
9. NameNode 工作机制以及元数据管理(重要)
9.1 namenode 与 datanode 启动
namenode工作机制
- 第一次启动namenode格式化后,创立fsimage和edits文件。如果不是第一次启动,间接加载编辑日志和镜像文件到内存。
- 客户端对元数据进行增删改的申请。
- namenode记录操作日志,更新滚动日志。
- namenode在内存中对数据进行增删改查。
secondary namenode
- secondary namenode询问 namenode 是否须要 checkpoint。间接带回 namenode 是否查看后果。
- secondary namenode 申请执行 checkpoint。
- namenode 滚动正在写的edits日志。
- 将滚动前的编辑日志和镜像文件拷贝到 secondary namenode。
- secondary namenode 加载编辑日志和镜像文件到内存,并合并。
- 生成新的镜像文件 fsimage.chkpoint。
- 拷贝 fsimage.chkpoint 到 namenode。
- namenode将 fsimage.chkpoint 重新命名成fsimage。
9.2 FSImage与edits详解
所有的元数据信息都保留在了FsImage与Eidts文件当中,这两个文件就记录了所有的数据的元数据信息,元数据信息的保留目录配置在了 hdfs-site.xml 当中
<!--fsimage文件存储的门路--> <property> <name>dfs.namenode.name.dir</name> <value>file:///opt/hadoop-2.6.0-cdh5.14.0/hadoopDatas/namenodeDatas</value> </property> <!-- edits文件存储的门路 --> <property> <name>dfs.namenode.edits.dir</name> <value>file:///opt/hadoop-2.6.0-cdh5.14.0/hadoopDatas/dfs/nn/edits</value> </property>
客户端对hdfs进行写文件时会首先被记录在edits文件中。
edits批改时元数据也会更新。
每次hdfs更新时edits先更新后客户端才会看到最新信息。
fsimage:是namenode中对于元数据的镜像,个别称为检查点。
个别开始时对namenode的操作都放在edits中,为什么不放在fsimage中呢?
因为fsimage是namenode的残缺的镜像,内容很大,如果每次都加载到内存的话生成树状拓扑构造,这是十分耗内存和CPU。
fsimage内容蕴含了namenode治理下的所有datanode中文件及文件block及block所在的datanode的元数据信息。随着edits内容增大,就须要在肯定工夫点和fsimage合并。
9.3 FSimage文件当中的文件信息查看
- 应用命令 hdfs oiv
cd /opt/hadoop-2.6.0-cdh5.14.0/hadoopDatas/namenodeDatas/currenthdfs oiv -i fsimage_0000000000000000112 -p XML -o hello.xml
9.4 edits当中的文件信息查看
- 查看命令 hdfs oev
cd /opt/hadoop-2.6.0-cdh5.14.0/hadoopDatas/dfs/nn/editshdfs oev -i edits_0000000000000000112-0000000000000000113 -o myedit.xml -p XML
9.5 secondarynameNode如何辅助治理FSImage与Edits文件
- secnonaryNN告诉NameNode切换editlog。
- secondaryNN从NameNode中取得FSImage和editlog(通过http形式)。
- secondaryNN将FSImage载入内存,而后开始合并editlog,合并之后成为新的fsimage。
- secondaryNN将新的fsimage发回给NameNode。
- NameNode用新的fsimage替换旧的fsimage。
实现合并的是 secondarynamenode,会申请namenode停止使用edits,临时将新写操作放入一个新的文件中(edits.new)。
secondarynamenode从namenode中通过http get取得edits,因为要和fsimage合并,所以也是通过http get 的形式把fsimage加载到内存,而后逐个执行具体对文件系统的操作,与fsimage合并,生成新的fsimage,而后把fsimage发送给namenode,通过http post的形式。
namenode从secondarynamenode取得了fsimage后会把原有的fsimage替换为新的fsimage,把edits.new变成edits。同时会更新fsimage。
hadoop进入平安模式时须要管理员应用dfsadmin的save namespace来创立新的检查点。
secondarynamenode在合并edits和fsimage时须要耗费的内存和namenode差不多,所以个别把namenode和secondarynamenode放在不同的机器上。
fsimage与edits的合并机会取决于两个参数,第一个参数是默认1小时fsimage与edits合并一次。
- 第一个参数:工夫达到一个小时fsimage与edits就会进行合并
dfs.namenode.checkpoint.period 3600
- 第二个参数:hdfs操作达到1000000次也会进行合并
dfs.namenode.checkpoint.txns 1000000
- 第三个参数:每隔多长时间查看一次hdfs的操作次数
dfs.namenode.checkpoint.check.period 60
9.6 namenode元数据信息多目录配置
为了保障元数据的安全性,咱们个别都是先确定好咱们的磁盘挂载目录,将元数据的磁盘做RAID1
namenode的本地目录能够配置成多个,且每个目录寄存内容雷同,减少了可靠性。
- 具体配置计划:
hdfs-site.xml
<property> <name>dfs.namenode.name.dir</name> <value>file:///export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/namenodeDatas</value> </property>
9.7 namenode故障复原
在咱们的secondaryNamenode对namenode当中的fsimage和edits进行合并的时候,每次都会先将namenode的fsimage与edits文件拷贝一份过去,所以fsimage与edits文件在secondarNamendoe当中也会保留有一份,如果namenode的fsimage与edits文件损坏,那么咱们能够将secondaryNamenode当中的fsimage与edits拷贝过来给namenode持续应用,只不过有可能会失落一部分数据。这里波及到几个配置选项
- namenode保留fsimage的配置门路
<!-- namenode元数据存储门路,理论工作当中个别应用SSD固态硬盘,并应用多个固态硬盘隔开,冗余元数据 --> <property> <name>dfs.namenode.name.dir</name> <value>file:///export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/namenodeDatas</value> </property>
- namenode保留edits文件的配置门路
<property> <name>dfs.namenode.edits.dir</name> <value>file:///export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/dfs/nn/edits</value></property>
- secondaryNamenode保留fsimage文件的配置门路
<property> <name>dfs.namenode.checkpoint.dir</name> <value>file:///export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/dfs/snn/name</value></property>
- secondaryNamenode保留edits文件的配置门路
<property> <name>dfs.namenode.checkpoint.edits.dir</name> <value>file:///export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/dfs/nn/snn/edits</value></property>
接下来咱们来模仿namenode的故障复原性能
- 杀死namenode过程: 应用jps查看namenode的过程号 , kill -9 间接杀死。
- 删除namenode的fsimage文件和edits文件。
根据上述配置, 找到namenode搁置fsimage和edits门路. 间接全副rm -rf 删除。
- 拷贝secondaryNamenode的fsimage与edits文件到namenode的fsimage与edits文件夹上面去。
根据上述配置, 找到secondaryNamenode的fsimage和edits门路, 将内容 应用cp -r 全副复制到namenode对应的目录下即可。
- 重新启动namenode, 察看数据是否存在。
10 datanode工作机制以及数据存储
- datanode工作机制
- 一个数据块在datanode上以文件模式存储在磁盘上,包含两个文件,一个是数据自身,一个是元数据包含数据块的长度,块数据的校验和,以及工夫戳。
- DataNode启动后向namenode注册,通过后,周期性(1小时)的向namenode上报所有的块信息。(dfs.blockreport.intervalMsec)。
- 心跳是每3秒一次,心跳返回后果带有namenode给该datanode的命令如复制块数据到另一台机器,或删除某个数据块。如果超过10分钟没有收到某个datanode的心跳,则认为该节点不可用。
- 集群运行中能够平安退出和退出一些机器。
- 数据完整性
- 当DataNode读取block的时候,它会计算checksum。
- 如果计算后的checksum,与block创立时值不一样,阐明block曾经损坏。
- client读取其余DataNode上的block。
- datanode在其文件创建后周期验证checksum。
- 掉线时限参数设置
datanode过程死亡或者网络故障造成datanode无奈与namenode通信,namenode不会立刻把该节点断定为死亡,要通过一段时间,这段时间暂称作超时时长。HDFS默认的超时时长为10分钟+30秒。如果定义超时工夫为timeout,则超时时长的计算公式为:
timeout = 2 dfs.namenode.heartbeat.recheck-interval + 10 dfs.heartbeat.interval。
而默认的dfs.namenode.heartbeat.recheck-interval 大小为5分钟,dfs.heartbeat.interval默认为3秒。
须要留神的是hdfs-site.xml 配置文件中的heartbeat.recheck.interval的单位为毫秒,dfs.heartbeat.interval的单位为秒。
<property> <name>dfs.namenode.heartbeat.recheck-interval</name> <value>300000</value></property><property> <name>dfs.heartbeat.interval </name> <value>3</value></property>
- DataNode的目录构造
和namenode不同的是,datanode的存储目录是初始阶段主动创立的,不须要额定格式化。
在/opt/hadoop-2.6.0-cdh5.14.0/hadoopDatas/datanodeDatas/current这个目录下查看版本号
cat VERSION #Thu Mar 14 07:58:46 CST 2019 storageID=DS-47bcc6d5-c9b7-4c88-9cc8-6154b8a2bf39 clusterID=CID-dac2e9fa-65d2-4963-a7b5-bb4d0280d3f4 cTime=0 datanodeUuid=c44514a0-9ed6-4642-b3a8-5af79f03d7a4 storageType=DATA_NODE layoutVersion=-56
具体解释:
storageID:存储id号。
clusterID集群id,全局惟一。
cTime属性标记了datanode存储系统的创立工夫,对于刚刚格式化的存储系统,这个属性为0;然而在文件系统降级之后,该值会更新到新的工夫戳。
datanodeUuid:datanode的惟一识别码。
storageType:存储类型。
layoutVersion是一个负整数。通常只有HDFS减少新个性时才会更新这个版本号。
- datanode多目录配置
datanode也能够配置成多个目录,每个目录存储的数据不一样。即:数据不是正本。具体配置如下:
- 只须要在value中应用逗号分隔出多个存储目录即可
cd /opt/hadoop-2.6.0-cdh5.14.0/etc/hadoop <!-- 定义dataNode数据存储的节点地位,理论工作中,个别先确定磁盘的挂载目录,而后多个目录用,进行宰割 --> <property> <name>dfs.datanode.data.dir</name> <value>file:///opt/hadoop-2.6.0-cdh5.14.0/hadoopDatas/datanodeDatas</value> </property>
10.1 退役新数据节点
需要阐明:
随着公司业务的增长,数据量越来越大,原有的数据节点的容量曾经不能满足存储数据的需要,须要在原有集群根底上动静增加新的数据节点。
10.1.1 环境筹备
- 复制一台新的虚拟机进去
将咱们污浊的虚拟机复制一台进去,作为咱们新的节点
- 批改mac地址以及IP地址
批改mac地址命令 vim /etc/udev/rules.d/70-persistent-net.rules批改ip地址命令 vim /etc/sysconfig/network-scripts/ifcfg-eth0
- 敞开防火墙,敞开selinux
敞开防火墙 service iptables stop敞开selinux vim /etc/selinux/config
- 更改主机名
更改主机名命令,将node04主机名更改为node04.hadoop.comvim /etc/sysconfig/network
- 四台机器更改主机名与IP地址映射
四台机器都要增加hosts文件vim /etc/hosts192.168.52.100 node01.hadoop.com node01192.168.52.110 node02.hadoop.com node02192.168.52.120 node03.hadoop.com node03192.168.52.130 node04.hadoop.com node04
- node04服务器关机重启
node04执行以下命令关机重启 reboot -h now
- node04装置jdk
node04对立两个门路 mkdir -p /export/softwares/ mkdir -p /export/servers/
而后解压jdk安装包,配置环境变量
- 解压hadoop安装包
在node04服务器下面解压hadoop安装包到/export/servers , node01执行以下命令将hadoop安装包拷贝到node04服务器 cd /export/softwares/ scp hadoop-2.6.0-cdh5.14.0-本人编译后的版本.tar.gz node04:$PWDnode04解压安装包 tar -zxf hadoop-2.6.0-cdh5.14.0-本人编译后的版本.tar.gz -C /export/servers/
- 将node01对于hadoop的配置文件全副拷贝到node04
node01执行以下命令,将hadoop的配置文件全副拷贝到node04服务器下面 cd /export/servers/hadoop-2.6.0-cdh5.14.0/etc/hadoop/ scp ./* node04:$PWD
10.1.2 退役新节点具体步骤
- 创立dfs.hosts文件
在node01也就是namenode所在的机器的/export/servers/hadoop-2.6.0-cdh5.14.0/etc/hadoop目录下创立dfs.hosts文件[root@node01 hadoop]# cd /export/servers/hadoop-2.6.0-cdh5.14.0/etc/hadoop[root@node01 hadoop]# touch dfs.hosts[root@node01 hadoop]# vim dfs.hosts增加如下主机名称(蕴含新退役的节点)node01node02node03node04
- node01编辑hdfs-site.xml增加以下配置
在namenode的hdfs-site.xml配置文件中减少dfs.hosts属性
node01执行以下命令 :cd /export/servers/hadoop-2.6.0-cdh5.14.0/etc/hadoopvim hdfs-site.xml# 增加一下内容 <property> <name>dfs.hosts</name> <value>/export/servers/hadoop-2.6.0-cdh5.14.0/etc/hadoop/dfs.hosts</value> </property> <!--动静高低线配置: 如果配置文件中有, 就不须要配置--> <property> <name>dfs.hosts</name> <value>/export/servers/hadoop-2.6.0-cdh5.14.0/etc/hadoop/accept_host</value> </property> <property> <name>dfs.hosts.exclude</name> <value>/export/servers/hadoop-2.6.0-cdh5.14.0/etc/hadoop/deny_host</value> </property>
刷新namenode
- node01执行以下命令刷新namenode
[root@node01 hadoop]# hdfs dfsadmin -refreshNodesRefresh nodes successful
更新resourceManager节点
- node01执行以下命令刷新resourceManager
[root@node01 hadoop]# yarn rmadmin -refreshNodes19/03/16 11:19:47 INFO client.RMProxy: Connecting to ResourceManager at node01/192.168.52.100:8033
- namenode的slaves文件减少新服务节点主机名称
node01编辑slaves文件,并增加新增节点的主机,更改完后,slaves文件不须要散发到其余机器下面去
node01执行以下命令编辑slaves文件 : cd /export/servers/hadoop-2.6.0-cdh5.14.0/etc/hadoop vim slaves 增加一下内容: node01node02node03node04
- 独自启动新增节点
node04服务器执行以下命令,启动datanode和nodemanager : cd /export/servers/hadoop-2.6.0-cdh5.14.0/ sbin/hadoop-daemon.sh start datanode sbin/yarn-daemon.sh start nodemanager
- 应用负载平衡命令,让数据平均负载所有机器
node01执行以下命令 : cd /export/servers/hadoop-2.6.0-cdh5.14.0/ sbin/start-balancer.sh
10.2 服役旧数据
- 创立dfs.hosts.exclude配置文件
在namenod所在服务器的/export/servers/hadoop-2.6.0-cdh5.14.0/etc/hadoop目录下创立dfs.hosts.exclude文件,并增加须要服役的主机名称
node01执行以下命令 : cd /export/servers/hadoop-2.6.0-cdh5.14.0/etc/hadoop touch dfs.hosts.exclude vim dfs.hosts.exclude增加以下内容: node04.hadoop.com特地留神:该文件当中肯定要写真正的主机名或者ip地址都行,不能写node04
- 编辑namenode所在机器的hdfs-site.xml
编辑namenode所在的机器的hdfs-site.xml配置文件,增加以下配置
cd /export/servers/hadoop-2.6.0-cdh5.14.0/etc/hadoopvim hdfs-site.xml#增加一下内容: <property> <name>dfs.hosts.exclude</name> <value>/export/servers/hadoop-2.6.0-cdh5.14.0/etc/hadoop/dfs.hosts.exclude</value> </property>
- 刷新namenode,刷新resourceManager
在namenode所在的机器执行以下命令,刷新namenode,刷新resourceManager : hdfs dfsadmin -refreshNodesyarn rmadmin -refreshNodes
- 节点服役实现,进行该节点过程
期待服役节点状态为decommissioned(所有块曾经复制实现),进行该节点及节点资源管理器。留神:如果正本数是3,退役的节点小于等于3,是不能服役胜利的,须要批改正本数后能力服役。
node04执行以下命令,进行该节点过程 : cd /export/servers/hadoop-2.6.0-cdh5.14.0 sbin/hadoop-daemon.sh stop datanode sbin/yarn-daemon.sh stop nodemanager
- 从include文件中删除服役节点
namenode所在节点也就是node01执行以下命令删除服役节点 : cd /export/servers/hadoop-2.6.0-cdh5.14.0/etc/hadoop vim dfs.hosts 删除后的内容: 删除了node04node01node02node03
- node01执行一下命令刷新namenode,刷新resourceManager
hdfs dfsadmin -refreshNodesyarn rmadmin -refreshNodes
- 从namenode的slave文件中删除服役节点
namenode所在机器也就是node01执行以下命令从slaves文件中删除服役节点 : cd /export/servers/hadoop-2.6.0-cdh5.14.0/etc/hadoop vim slaves删除后的内容: 删除了 node04 node01node02node03
- 如果数据负载不平衡,执行以下命令进行平衡负载
node01执行以下命令进行平衡负载 cd /export/servers/hadoop-2.6.0-cdh5.14.0/ sbin/start-balancer.sh
11 block块手动拼接成为残缺数据
所有的数据都是以一个个的block块存储的,只有咱们可能将文件的所有block块全副找进去,拼接到一起,又会成为一个残缺的文件,接下来咱们就来通过命令将文件进行拼接:
- 上传一个大于128M的文件到hdfs下面去
咱们抉择一个大于128M的文件上传到hdfs下面去,只有一个大于128M的文件才会有多个block块。
这里咱们抉择将咱们的jdk安装包上传到hdfs下面去。
node01执行以下命令上传jdk安装包
cd /export/softwares/hdfs dfs -put jdk-8u141-linux-x64.tar.gz /
- web浏览器界面查看jdk的两个block块id
这里咱们看到两个block块id别离为
1073742699和1073742700
那么咱们就能够通过blockid将咱们两个block块进行手动拼接了。
- 依据咱们的配置文件找到block块所在的门路
依据咱们hdfs-site.xml的配置,找到datanode所在的门路<!-- 定义dataNode数据存储的节点地位,理论工作中,个别先确定磁盘的挂载目录,而后多个目录用,进行宰割 --> <property> <name>dfs.datanode.data.dir</name> <value>file:///export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/datanodeDatas</value> </property> 进入到以下门路 : 此基础门路为 上述配置中value的门路cd /export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/datanodeDatas/current/BP-557466926-192.168.52.100-1549868683602/current/finalized/subdir0/subdir3
- 执行block块的拼接
将不同的各个block块依照程序进行拼接起来,成为一个残缺的文件cat blk_1073742699 >> jdk8u141.tar.gzcat blk_1073742700 >> jdk8u141.tar.gz挪动咱们的jdk到/export门路,而后进行解压mv jdk8u141.tar.gz /export/cd /export/tar -zxf jdk8u141.tar.gz失常解压,没有问题,阐明咱们的程序依照block块存储没有问题
作者简介:
园陌,目前就任于一家大而舒适的互联网公司,数据开发工程师
公众号【五分钟学大数据】的原创作者
本篇文章首发于公众号,版权归思否与公众号【五分钟学大数据】独特所有,转载请注明本申明!