赖教授在英语教学方面的特色，就是“解析”两个字，他知道自己学英文的难处，所以他写的书或讲的课，都会把读者与学生当作是从头学起的对象，做非常详细与完整的系统化解析，让学习者读他的书，一看就会；听他的课，一听就懂。赖世雄在两岸英文教育界中，是一位传奇性的人物，他学习英文的成长历程与心得诀窍，带给大家一些启迪与引领。现在他更将精心制作的图书，及讲解录音放在网站上，供读者免费阅读听讲，他的期望，就是能扮演一盏明灯，指引大家都能顺利学好英文。

文件：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知道，该用户是否在文件所属组中，如果文件所属组，在用户的组列表中，说明该用户拥有文件的组权限。