语法:赖氏经典英语语法.docx
作者:互联网
赖教授在英语教学方面的特色,就是“解析”两个字,他知道自己学英文的难处,所以他写的书或讲的课,都会把读者与学生当作是从头学起的对象,做非常详细与完整的系统化解析,让学习者读他的书,一看就会;听他的课,一听就懂。赖世雄在两岸英文教育界中,是一位传奇性的人物,他学习英文的成长历程与心得诀窍,带给大家一些启迪与引领。现在他更将精心制作的图书,及讲解录音放在网站上,供读者免费阅读听讲,他的期望,就是能扮演一盏明灯,指引大家都能顺利学好英文。
文件:590m.com/f/25127180-488082479-19d0aa(访问密码:551685)
以下内容无关:
-------------------------------------------分割线---------------------------------------------
搭建安装#
三个核心组件#
一个hadoop基本集群,牵涉三个组件:
hdfs 负责分布式的文件存储
yarn 负责分布式的资源管理
mr 负责分布式计算
安装#
配置环境变量#
配置etc/hadoop/hadoop-env.sh、etc/hadoop/hadoop-env.sh、etc/hadoop/yarn-env.sh 这三个脚本来配置三个组件执行的环境变量
当然,机器特定的环境变量可以放在 /etc/profile.d 中
最重要的是在上述三个shell脚本的最后,配置JAVA_HOME。
上述三个shell中,有大量环境变量KEY可以配置,他们一般见名知意。可以使用一些带OPTS后缀的配置,去覆盖那些特定配置。带OPTS的后缀有
file
比如HADOOP_HEAPSIZE_MAX=1g 可以被HADOOP_NAMENODE_OPTS="-Xmx5g" 所覆盖
配置各上述三组件守护进程的相关属性#
上述环境变量配置好后,就要配置hdfs, yarn, mr三者的进程,即程序执行的行为属性。其分别对应的配置文件为
etc/hadoop/core-site.xml 、etc/hadoop/hdfs-site.xml 用于给hdfs配置
etc/hadoop/yarn-site.xml 用于给yarn配置
etc/hadoop/mapred-site.xml 用于给mr配置
具体看文档即可,这里对一些有意思的配置单列说明
hdfs的配置
dfs.namenode.name.dir namenode的数据存储路径,多个文件,表示数据存多份,提高冗余
yarn的配置
yarn.log-aggregation-enable 启动log aggregation,这会将yarn集群中执行应用的本地日志,复制到hdfs集群中进行高可用管理
启停#
可以针hdfs,mr,yarn三个组件的各角色进行启动。
其中Hdfs的各角色,可以使用etc/hadoop/workers配置,通过$HADOOP_HOME/sbin/start-dfs.sh批量启动。
具体启停看文档
监控和性能#
Hadoop Rack Awareness#
Hadoop Rack Awareness,启用该特性,让Hadoop集群感知物理存储拓扑,从而更好的提高数据分片性能,具体看文档
yarn的NodeManagers监控#
可以指定一些监控nodeManager状态的脚本给NodeManager, NodeManager会周期性的调用,检查自己的状态,yarn则会收集该状态,然后不会将程序分发到这些异常NodeManager上执行
命令#
文档地址:https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/FileSystemShell.html
hdfs的命令#
如果hadoop操作的是hdfs,那么下面两种命令格式等效
bin/hadoop fs
hdfs dfs
hadoop fs的相关命令支持多种文件系统
hdfs hadoop自己的分布式文件系统
Local FS 本地文件系统,即为当前机器的文件系统
WebHDFS
S3 FS 亚马逊的分布式文件系统
hadoop fs命令一般操作的文件系统路径格式URI为scheme://authority/path,比如hdfs举例hdfs://namenodehost/parent/child
appendToFile#
将本地单个文件或多个文件,或则本机的标准输入中的内容,拷贝到目标文件系统
用法:hadoop fs -appendToFile …
Copy
hadoop fs -appendToFile localfile /user/hadoop/hadoopfile
hadoop fs -appendToFile localfile1 localfile2 /user/hadoop/hadoopfile
hadoop fs -appendToFile localfile hdfs://nn.example.com/hadoop/hadoopfile
hadoop fs -appendToFile - hdfs://nn.example.com/hadoop/hadoopfile Reads the input from stdin.
Returns 0 on success and 1 on error.
cat#
将文件系统中指定文件内容输出到终端
用法:hadoop fs -cat [-ignoreCrc] URI [URI …]
Copy
hadoop fs -cat hdfs://nn1.example.com/file1 hdfs://nn2.example.com/file2
hadoop fs -cat file:///file3 /user/hadoop/file4
Returns 0 on success and -1 on error
checksum#
对指定文件生成checksum值
用法:hadoop fs -checksum URI
Copy
hadoop fs -checksum hdfs://nn1.example.com/file1
hadoop fs -checksum file:///etc/hosts
file
chgrp#
改变文件的组
用法:hadoop fs -chgrp [-R] GROUP URI [URI …]
其中-R是表示将该路径下的所有文件组都修改
GROUP是要修改成的组
URI是文件或文件夹的路径
该命令只有管理员或当前文件的拥着才能执行
chmod#
改变文件的读写执行模式
用法:hadoop fs -chmod [-R] <MODE[,MODE]… | OCTALMODE> URI [URI …]
其中-R是表示将该路径下的所有文件组都修改
该命令只有管理员或当前文件的拥着才能执行
todo:具体mod详情,需要再查阅
chown#
改变文件的拥有者
用法:hadoop fs -chown [-R] [OWNER][:[GROUP]] URI [URI ]
其中-R是表示将该路径下的所有文件组都修改
该命令只有管理员或当前文件的拥着才能执行
copyFromLocal#
将当前机器本地文件,拷贝到分布式文件系统
用法:hadoop fs -copyFromLocal [args] URI
其中命令参数有以下几个,都是可选
-p复制到分布式文件系统的文件保留原文件的修改时间、权限、所有者信息
-f 如果分布式文件系统已经存在该文件,则覆盖
-l 允许DataNode延迟持久化该文件,replication factor 是1. 也即这种方式不会要去数据马上落地和写副本,具有丢数据的风险,但是写入速度可能会很快
-d 文件复制过程中,将不会创建后缀为._COPYING_格式的文件
copyToLocal#
将分布式文件系统中的文件拷贝到本地
count#
同进指定路径的文件、文件夹个数、当前文件占用量大小、指定路径允许创建的文件、文件夹个数,以及允许的最大文件、文件容量
用法:hadoop fs -count [-q] [-h] [-v] [-x] [-t []] [-u] [-e]
如果只用quota,而不加任何以下且与参数,则输出的统计项有
Copy
DIR_COUNT(当前路径的文件夹个数), FILE_COUNT(文件个数), CONTENT_SIZE(容量占用大小), PATHNAME(当前统计的路径)
-h 将容量以人方便读的方式展示,建议开启
-v 对统计的内容,输出表头,方便用户知道统计中某列是什么含义,建议开启
-q 代表quota, 能够统计出指定路径的name quota和space quota。 输出的列有QUOTA(总的name quota的大小), REMAINING_QUOTA(还剩name quota的大小), SPACE_QUOTA(space quota的大小), REMAINING_SPACE_QUOTA(还剩的space quota的大小), DIR_COUNT, FILE_COUNT, CONTENT_SIZE, PATHNAME
-u 跟-q一样,也是统计容量配合总计和剩余配合,只是不再输出-count默认的那些项。-u的输出列为:QUOTA, REMAINING_QUOTA, SPACE_QUOTA, REMAINING_SPACE_QUOTA, PATHNAME
-e hadoop3.0引入的,文件擦除策略,需要再查资料解读
demo举例
Copy
hadoop fs -count hdfs://nn1.example.com/file1 hdfs://nn2.example.com/file2
hadoop fs -count -q hdfs://nn1.example.com/file1
hadoop fs -count -q -h hdfs://nn1.example.com/file1
hadoop fs -count -q -h -v hdfs://nn1.example.com/file1
hadoop fs -count -u hdfs://nn1.example.com/file1
hadoop fs -count -u -h hdfs://nn1.example.com/file1
hadoop fs -count -u -h -v hdfs://nn1.example.com/file1
hadoop fs -count -e hdfs://nn1.example.com/file1
对于quota(配额)的说明:
name quota 以指定路径做为根路径的整颗文件树上允许创建的文件、文件夹名称的总体个数
space quota 以指定路径做为根路径的整颗文件树上允许创建的文件、文件夹的总体字节数
使用hadoop fs -count -q命令查询配合时,如果配额没有设置,会显示none 或inf
可以使用hdfs dfsadmin命令对某个指定路径设置配额
cp#
将一个文件或多个文件拷贝到另一个地方。
拷贝当个文件时,目的地可以是另一个文件,也可以是文件夹
拷贝多个文件时,目的地必须是文件夹
用法:hadoop fs -cp [-f] [-p | -p[topax]] URI [URI …]
-f参数加上时,目的地有该文件,则会将其覆盖
df#
查询某个指定路径的剩余容量
用法:hadoop fs -df [-h] URI [URI …]
-h是人可读的形式
df是看的整个文件系统的使用情况和可用空间
而-count是计算指定目录的空间占用情况,以及管理员给分配的配合使用情况
du#
查看指定路径的文件和文件夹大小汇总
find#
查找指定路径下,名字满足表达式的文件,并打印到终端
hadoop fs -find / -name test -print
-name 对文件名大小写敏感
-iname 文件名大小写不敏感
get#
将hdfs中的文件拷贝到本地
getfacl#
返回文件的访问控制列表
getfattr#
将指定文件夹中的所有文件合并后,生成到目标文件中
用法:hadoop fs -getmerge [-nl]
Copy
hadoop fs -getmerge -nl /src /opt/output.txt //将src文件夹下的所有文件合并到output.txt
hadoop fs -getmerge -nl /src/file1.txt /src/file2.txt /output.txt//将file1.txt和file2.txt合并到output.txt
head#
将指定文件头一千行数据输出到终端
hadoop fs -head pathname
tail#
将指定文件尾部一千行数据输出到终端
Copy
hadoop fs -tail [-f] URI
help#
hadoop fs -help
所有fs命令的帮助手册
usage#
hadoop fs -usage command 查看单个命令的使用手册
truncate#
删减指定文件的指定行数
touchz#
创建一个文件,就像Linux的touch命令
Copy
hadoop fs -touchz pathname
touch#
不存在则创建文件,存在则更新文件的更新时间
text#
以文本形式输出一个指定文件
test#
测试指定路径是否存在,是否是文件或文件夹
setrep#
设置文件或文件夹的副本数。如果是文件夹,则会将该文件夹下的所有文件副本数一并设置
hadoop fs -setrep -w 3 /user/hadoop/dir1
-w表示命令是否等待所有操作完成
setfattr#
对指定文件设置附加属性。一个文件固有的属性有其Permission,和modifytime。用户可以选择添加一些附加属性
setfacl#
设置指定文件或文件夹的访问控制列表
rmdir 删除一个文件夹#
hadoop fs -rmdir /user/hadoop/emptydir
rm#
删除一个指定文件。如果回收垃圾桶功能有的话,删除操作会将将文件移动到垃圾桶trash
hadoop fs -rm hdfs://nn.example.com/file /user/hadoop/emptydir
put#
将本地的一个或多个文件复制到分布式文件系统中的指定路径
Copy
hadoop fs -put localfile /user/hadoop/hadoopfile
hadoop fs -put -f localfile1 localfile2 /user/hadoop/hadoopdir
hadoop fs -put -d localfile hdfs://nn.example.com/hadoop/hadoopfile
hadoop fs -put - hdfs://nn.example.com/hadoop/hadoopfile Reads the input from stdin.
moveFromLocal#
将本地文件移动到文件系统,注意是移动,移动后,本地文件将被删除
Copy
hadoop fs -moveFromLocal
mv#
文件移动,要是移动多个文件的话,目的地必须为一个文件夹
Copy
hadoop fs -mv /user/hadoop/file1 /user/hadoop/file2
hadoop fs -mv hdfs://nn.example.com/file1 hdfs://nn.example.com/file2 hdfs://nn.example.com/file3 hdfs://nn.example.com/dir1
mkdir#
创建文件夹
用法:hadoop fs -mkdir [-p]
-p参数表示文件夹的父文件夹也会被创建
Copy
hadoop fs -mkdir /user/hadoop/dir1 /user/hadoop/dir2
hadoop fs -mkdir hdfs://nn1.example.com/user/hadoop/dir hdfs://nn2.example.com/user/hadoop/dir
ls#
用法:hadoop fs -ls [-C] [-d] [-h] [-q] [-R] [-t] [-S] [-r] [-u] [-e]
参数列表如下
Copy
-C: Display the paths of files and directories only.
-d: Directories are listed as plain files.
-h: Format file sizes in a human-readable fashion (eg 64.0m instead of 67108864).
-q: Print ? instead of non-printable characters.
-R: Recursively list subdirectories encountered.
-t: Sort output by modification time (most recent first).
-S: Sort output by file size.
-r: Reverse the sort order.
-u: Use access time rather than modification time for display and sorting.
-e: Display the erasure coding policy of files and directories only.
HDFS基本知识#
HDFS是一个分布式文件系统。其中有两种类型的组件
name node, 管理整个系统的文件目录,以及每个其下的每个文件有多少个块block,他们存储的机器,以及副本位置。
data node,实际的数据存储节点。数据的直接读写,都是在这上面进行的
file
HDFS Snapshots#
HDFS Snapshots用来做数据备份,或者灾难恢复。
HDFS Snapshots创建的耗时很低,几乎是瞬间创建。
之所以快的原因是,集群没有数据移动。
Snapshots创建后,只记录其对应真实文件路径下发生的变化。
当你要恢复数据时,hdfs是通过当前的数据减去Snapshots记录的至snapshot创建以来,发生变化的数据,就等于snapshot备份初始时,对应的数据状态。
这个思想很棒,创建备份很快的同时,备份所要求的存储空间也很少
Snapshots的创建#
一个文件夹想要使用Snapshots备份,首先该文件夹需要被设置成snapshottable(可备份)
Copy
hdfs dfsadmin -allowSnapshot
然后对该文件夹创建备份
Copy
hdfs dfs -createSnapshot
path为可备份的文件夹路径
snapshotName 为备份文件的名字,可以不填,默认为’s’yyyyMMdd-HHmmss.SSS 格式的命名
创建备份后,备份本身放在在备份文件夹下的.snapshot文件夹内
Snapshots的使用#
比如现在有个文件夹/foo/bar
我对foo文件夹创建一个备份s0, 那么该备份的路径为/foo/.snapshot/s0
我要查看所有foo的所有备份
Copy
hdfs dfs -ls /foo/.snapshot
查找备份中的文件
Copy
hdfs dfs -ls /foo/.snapshot/s0
将备份中的文件恢复到某个目录
Copy
hdfs dfs -cp -ptopax /foo/.snapshot/s0/bar /tmp
数据复写#
hdfs中存储的文件都很大,所以一个大文件,会被拆分成很多block. 而为了保证数据的可靠性,这些block会被以副本形式存放在多个data node.
file
该图上半部分,显示的是文件在Namenode中存储的元数据信息,其中包含了(以第一行为例)
文件名/users/sameerp/data/part-0
文件块利弊 block-ids (1,3),表示该文件有两个块
文件块副本个数 r:2 ,表示每个块会被存储两份
该图下半部分,则是上半部分描述的两个文件,在datanode中的实际存储情况,可以看到第二个文件有三个快,并且每个块有三个副本
副本的存放机制#
一个大的HDFS集群,往往跨多个机架的服务器。如果副本放一个机架,那这个机架挂了,数据就全无法访问。如果副本分散到多个机架,那么每次写数据会很慢,并且会占用大量跨机架的带宽,且一般跨机架带宽,没有机架内的带宽大。
所以副本策略需要权衡上述两点,实现数据的可靠性存储的同时,能保证读写性能。
namenode通过Hadoop Rack Awareness机制,去获知每个datanode 对应的机架。
如果副本为3的话,且有多个机架的话,hdfs的会将两个副本放在同一个机架上,另一个放在另外一个机架。这样保证多数副本处于同一机架,提高读写速度。而单独放置一个机架的副本,能保证前一个机架挂掉后,集群的高可用
如果副本超过4个的话,hdfs会随机的找另外的机架来放,最终保证每个机架上的副本小于等于(replicas - 1) / racks + 2)
hdfs不会允许一个block的多个副本放在同一个datanode
副本的读取机制#
hdfs会采用就近原则,来保证读取的高效性。就近是指看跟读取客户端相近
安全模式#
hdfs刚启动时,出于安全模式,在该模式下,集群不会发生数据复制的行为。namenode会接收,datanode发送来的数据block的情况(这被称为block report,由datanode主动上报),并进行检查。当一个在多个datanode上的同一个bock副本存活数,达到指定的最小副本数时,该block才被认为是安全可用的。当整个集群的可用block数达到一定百分比时,HDFS才认为集群可用,退出安全模式,并把安全检查过程中发现的不安全的block,replication其副本到其它可用的datanode ,从而实现集群整体的高可用。
文件系统元数据的持久化#
fsImage namenode中,存放了文件系统命名空间和block对应datanode映射关系数据的文件叫 fsImage, 他是一个物理机文件,存放在namenode对应的宿主操作系统中
EditLog 我们对文件系统每一次修改,如果直接在fsImage上进行,效率会很低,因为fsImage会很大。所以namenode中还有一个文件叫EditLog,专门记录我们对文件系统的修改
checkpoint EditLog总有要在一个时间点,将数据合并到fsImage中,这个点叫checkpoint 。 这个时间点可以是指定的时间间隔到了dfs.namenode.checkpoint.period,或者EditLog积累了指定的变更事务数dfs.namenode.checkpoint.txns。当合并后,editLog将被删除
fsImage和Editlog的内存存放 我们要查找一个文件系统信息,如果到硬盘上找fsImage和EditLog,势必会很慢,所以当NameNode启动时,或checkpoint发生时,namenode会将fsImage和Editlog加载到内存
查询顺序 显然我们要查一个文件系统时,会先去editlog中找,然后去fsImage,由于editLog和fsImage本身会先落盘,我们也不用担心对文件系统的操作丢失
通信协议#
hdfs节点间通信协议是架设在tcp/ip上的,namenode只响应客户端或datanode发送的请求,namenode不会主动的发起任何请求
健壮性#
被动健壮性#
namenode会基于datanode上报的心跳,blockreport去及时的把不可用的datanode下线,并有必要的增加将副本数不足的block副本
主动健壮性#
往hdfs中文件的时候,存一份chcksum, 读文件时,校验checksum
fsImage和editLog非常重要,即便写磁盘,都有可能损坏,为了保证其可用性,多写几个副本
namenode本身配置高可用
定时使用snapshot备份集群数据,使得数据可恢复
数据的组织#
hdfs中将文件默认拆分为 128 MB的block
当像hdfs中写一个需副本文件时,namenode首选选取一组datanode给到客户端,客户端将数据写第一个datanode, 第一个datanode写完后,将该数据分发给第二个datanode ,依次类推,像一个链式管道
数据的访问#
支持以命令、api、web浏览器的方式访问hdfs文件系统
空间回收#
以下两种回收方式,都是有一定延迟的,不是操作后,就能看到多出的空间。
删除文件#
如果垃圾桶功能开启后,删除的文件会先到/user//.Trash,每个用户都有一个自己的垃圾桶。
用户最近删除的文件在/user//.Trash/Current中
当到了一定时间后,垃圾桶中的文件会被彻底删除。这个时候,hdfs会真正回收这部分空间
减少副本#
将副本个数减少,也会促使集群回收对应文件的空间
editLog和fsImage的高可用#
https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HdfsUserGuide.html#Secondary_NameNode
namenode存储了整个分布式文件系统的信息,它一旦数据丢失,那么整个hdfs相当于文件丢失。
而namenode的文件系统实际存储,依赖editLog和fsImage两个文件,所以保证namenode的数据不丢失,关键就是要保证editLog和fsImage两个文件的不丢失。下述三种Node,就是在做这个事情
Secondary NameNode#
前面讲namenode的editLog和fsImage的合并,只会在namenode启动时进行。这样到namenode下次启动时,可能editlog已经非常大了,合并会很耗时。Secondary NameNode就是用来去name node上拉取editLog和fsImage,然后进行合并。然后对namenode文件系统查询,会路由到secondary NameNode上
checkpoint1 定时 dfs.namenode.checkpoint.period
checkpoint2 事务数dfs.namenode.checkpoint.txns
当然Secondary NameNode,只是做editLog和FsImage的合并,并提供查询副本,他不并不能完全替代namenode工作。也即在Namenode挂后,集群是不可用的
Checkpoint Node#
同Checkpoint Node功能类似,要去namenode上拉取,editlog和fsImage ,只是checkpoint node会将合并后的内容,上传至Namenode。这样Namenode 不至于去查checkpoint node
Backup Node#
同Secondary NameNode和Checkpoint Node不一样,他不会用每次都去namenode拉取editLog和fsImage。其本身就会以物理落盘的方式,存储editLog和fsImage。由于这个特点,nameNode在启动时,可以使用-importCheckpoint 选项,是的Namenode本身不存储editLog和fsImage,转而将所有将所有的存储,代理给backup node
下下策Recovery Mode#
如果editLog和fsImage实在丢失了,请用Recovery Mode
HDFS高可用HA#
前面的Secondary NameNode、Checkpoint Node,Backup Node,都只是为了以某种形式备份editLog和fsImage数据。真正NameNode挂了后,集群还是需要人工干预。
这里介绍整个NameNode的高可用方式。(再次强调Secondary NameNode并不是HA,这个命名让人容易误解)
正在的高可用HA需要实现两个方面
editLog和fsImage文件不会出现单点故障丢失
namenode本身不会出现单点故障,挂掉后,能快速有备选的namenode起来干活
两种HA模式#
两种HA模式在namenode实例高可用上,都依赖zookeeper实现。只是在保证editLog和fsImage的高可用和一致性上有差异
使用Quorum Journal Manager,依托三个Journal Manager实例,去保证editLog和fsImage的在多个namenode之间的分布式一致性同步。
使用NFS,让多个namenode读写editLog和fsImage的实际存储在NFS,也即网络共享文件系统中,使得两个namenode能够共享editLog和fsImage数据。一般的NFS可选择NAS。
使用上述HA中的任意一种,我们都可以不再配置Secondary NameNode、Checkpoint Node,Backup Node
以下主要介绍基于Quorum Journal Manager的高可用
通过Journal Manager实现HA#
file
从上可以看到。为了保证fsImage和Editlog的高可用。每次namenode在发生文件系统变更时,会将其写到Journal Manager(后续简称JM),JM想Zookeeper一样,会部署奇数个节点,只有想JM半数以上的节点写editLog和fsImage成功后,才算成功。
使用zookeeper保证主namenode挂后,standby的namenode能够快速成为主namenode.
zookeeper本身在写数据时,也是半数成功才算成功,为什么不用用zookeeper一并代理JM 来存储editLog和fsImage呢。因为editLog和fsImage的文件可能很大,zookeeper本身适合做轻量级的元数据管理,不适合做这个
配置部署#
以下各种组件部署,最好使用不同的linux用户。hadoop官方推荐的用户跟Hadoop组件的对应关系为
file
配置Journal Manager#
主要配置
hdfs-site.xml
如果将多个Namenode整体看做一个分布式服务的话,首先要给这个service取个名字
Copy
dfs.nameservices
mycluster
将其对应的一组namenode的声明id
Copy
dfs.ha.namenodes.mycluster
nn1,nn2, nn3
配置namenode id对应的具体机器端口信息
Copy
dfs.namenode.rpc-address.mycluster.nn1
machine1.example.com:8020
dfs.namenode.rpc-address.mycluster.nn2
machine2.example.com:8020
dfs.namenode.rpc-address.mycluster.nn3
machine3.example.com:8020
配置这组namenode,对应的http地址、端口信息
Copy
dfs.namenode.http-address.mycluster.nn1
machine1.example.com:9870
dfs.namenode.http-address.mycluster.nn2
machine2.example.com:9870
dfs.namenode.http-address.mycluster.nn3
machine3.example.com:9870
配置journalnode存储editLog和fsImage文件的路径
Copy
dfs.journalnode.edits.dir
/path/to/journal/node/local/data
配置多台JournalNode组成的服务连接地址,他们相当于组成了一个分布式的文件目录
Copy
dfs.namenode.shared.edits.dir
qjournal://node1.example.com:8485;node2.example.com:8485;node3.example.com:8485/mycluster
为了防止脑裂致使多个Namenode都在写数据,可以配置一些当出现脑裂时,去杀死Namenode进程的命令,如果默认不指定命令,也需要做shell(/bin/true)。他的实现原理是,standby的namenode,准备成为active时,先通过ssh登录到原来的active namenode 的机器上,尝试以命令的形式杀死原来的namenode进程,保证自己启动起来不出现脑裂。所以这一步的关键配置是多个namenode之前,要实现ssh免密登录。ssh免密登录的配置参考:https://www.cnblogs.com/niceshot/p/13019823.html
Copy
dfs.ha.fencing.methods
sshfence shell(/bin/true)
dfs.ha.fencing.ssh.private-key-files
/home/vagrant/.ssh/id_rsa
dfs.ha.fencing.ssh.connect-timeout
30000
还可以配置客户端连接namenode时,出现故障的转移策略
Copy
dfs.client.failover.proxy.provider.mycluster
org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider
配置自动故障转移#
上述所有配置,能保证editLog和fsImage文件不丢。但nameNode挂后,还是需要通过haadmin命令手动干预去启动新备选nameNode。
下面的一系列配置用来使用zookeeper实现namenode的自动故障转移
首先启动自动转移开关
在hdfs-site.xml 中配置
Copy
dfs.ha.automatic-failover.enabled
true
在core-site.xml 配置zk的链接信息
Copy
ha.zookeeper.quorum
zk1.example.com:2181,zk2.example.com:2181,zk3.example.com:2181
Copy
fs.defaultFS
hdfs://mycluster
完成启动部署#
先启动所有的JournalNodes
Copy
./hdfs --daemon start journalnode
初始化主namenode
Copy
//如果集群是新集群
hdfs namenode -format
//如果是对已经存在很久的集群,进行高可用改造,下面的命令,是把已经存在的editLog和fsImage数据同步到journalnode
hdfs namenode -initializeSharedEdits
启动主namenode
Copy
./hdfs --daemon start namenode
初始化从namenode
Copy
hdfs namenode -bootstrapStandby
启动从namenode
Copy
sbin/hadoop-daemon.sh start namenode
在namenode所在机器,执行下述命令,初始化其在zk的节点信息
Copy
$HADOOP_HOME/bin/hdfs zkfc -formatZK
在所有namenode所在机器上启动zkfc进程
Copy
$HADOOP_HOME/bin/hdfs --daemon start zkfc
上述所有的这些命令中的初始化动作,只在第一次配置HA时需要。后续通过 start-dfs.sh 就可以直接启动所有相关实例
hadoop集群的升级回滚#
https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HdfsUserGuide.html#Secondary_NameNode
对DataNode添加、更换磁盘#
image.png
https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HdfsUserGuide.html
Hadoop Rack Awareness#
是一些列配置,是的hadoop集群能够感知到当前集群的机架情况,从而应用到副本分布策略中,以提高数据的高可用。
需要在hadoop的xml中配置基于域名或ip查找机架id的实现类。实现类必须继承org.apache.hadoop.net.DNSToSwitchMapping 接口。
实现类通过net.topology.node.switch.mapping.impl进行配置,默认的实现为org.apache.hadoop.net.ScriptBasedMapping
ScriptBasedMapping会去调用脚本,来获取所在集群的机架信息,具体的所调的脚本通过net.topology.script.file.name来配置,该配置没有默认值。
hadoop文档中有实现样例,可参考
hdfs整个集群相关命令#
https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HDFSCommands.html
参考资料
https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/RackAwareness.html
集群监控要点#
ZKFC 监控ZKFC是否ok
监控zookeeper状态
安装部署要点#
zookeeper的安装#
建议的安装方式,zookeeper三个节点分别放Namenode、standyNamenode、ResourceManager这三台机器上。
zookeeper自己的文件目录所在磁盘,同hdfs namenode所在磁盘分开
高效能集群启停#
hdfs本身由多个组件组成,且有些组件还有多个节点,比如journalnode, datanode,一次启动去到多个机器上执行是件很繁琐的事情。hadoop发型包,提供了sbin/start-dfs.sh 和 sbin/stop-dfs.sh两个脚本去启停hdfs相关的所有组件:比如namenode、datanode、journalnode, zkfc 。
他实现的原理是,基于hadoop安装包中的/opt/hadoop-3.2.1/etc/hadoop/workers文件,去登录到相应的机器,完成组件的执行。workers中定义了所有datanode的机器host。 登录方式是基于SSH的免密登录方式,具体配置参见:https://www.cnblogs.com/niceshot/p/13019823.html
如果发起脚本执行的机器,本身也需要部署一个datanode。那么他需要配置自己对自己的SSH免密登录
通过core-site.xml和hdfs-site.xml , 脚本已经可以知道namenode, Journalnode,Zkfc的组件机器。所以workers文件中,只需要设置所有的datanode的机器host。
hdfs权限控制#
同linux权限的比较#
hdfs的权限模型,同linux类似,只是去掉了setuid和setgid两位。也支持acl,stickybit位。但同linux不同的是,hdfs本身只管理文件的权限控制。并没有账号体系,比如像linux一样有/etc/passwd存储所有的用户列表。也即hdfs只提供文件权限控制。并不提供用户管理和认证管理,这两者都交由外部系统来实现。linux权限模型参考资料
https://www.cnblogs.com/niceshot/p/12901539.html
谁是管理员#
谁启动的namenode ,那启动namenode进程的用户,就是namenode 的管理员。所以namenode的管理员是会变化的,下次换个linux用户启动,就会导致变化
怎么找当前操作的用户#
通过hadoop.security.authentication配置,操作用户识别机制,有以下两种
simple#
使用发起操作的宿主机中,当前发起操作的用户,作为本次请求hdfs的用户。比如当前发起hdfs dfs -ls 命令的是linux的ops用户,那么hdfs后续的权限控制都会基于ops用户去判断。判断其是否有指定路径的读权限
kerberos#
在kerberos的配置文件中配置,auth_to_local是一个principal访问某个service时,这个service虽然知道这个Principal是KDC认证过的合法用户
但授权怎么做,该Principal具有什么样的权限?这个需要service自己来做。
一般linux自己的授权控制是通过posix模式,加ACL的方式进行的。本质来讲,都是针对当前linux本身的用户进行授权。
比如owner,group,others,分别定义他们能做什么和不能做什么。
所以部署在Linux上的service,往往需要将请求过来的principal映射成本地的用户,然后对本地的用户进行授权检测。这么一看,auth_to_local这个命名还是比较直白的
auth_to_local = {
RULE:2:1s/.∗/guest/
RULE:[2:
1
;
2
]
(
.
∗
;
a
d
m
i
n
)
s
/
;
a
d
m
i
n
1;2](.∗;admin)s/;admin
1;2](.∗;admin)s/;admin//
RULE:2:2s/.∗/root/
DEFAULT
}
}
上述这个demo配置,其实就是将johndoe/* 形式的principal会被映射成本地的guest用户,而形如*/admin@TEST.COM 的principal会被映射成本地的admin账号
https://ssimo.org/blog/id_016.html
怎么找到指定用户的组#
上述方式只是找到操作对应的用户。如果操作的用户不是对应文件、文件夹的owner, 那么需要判断该用户是否拥有指定文件、文件夹的组权限。
那首先,我们要知道该用户的有哪些组,以便让hdfs知道,该用户是否在文件所属组中,如果文件所属组,在用户的组列表中,说明该用户拥有文件的组权限。
标签:hdfs,docx,fs,文件,hadoop,赖氏,英语语法,namenode,com 来源: https://blog.csdn.net/xiaoyuanicom/article/details/115419806