Hadoop学习笔记—HDFS Hadoop学习笔记—HDFS

[TOC]

上一份工作主要负责大数据平台的建设，在这个过程中积累了一些Hadoop生态组件的搭建和使用笔记，由于时间关系，不打算去修改其中的错别字和排版问题，直接释出原始笔记。

搭建安装三个核心组件
一个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 ...

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 ...]

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

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] 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，而不加任何以下且与参数，则输出的统计项有

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举例

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]

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 将指定文件尾部一千行数据输出到终端

hadoop fs -tail [-f] URI

help hadoop fs -help
所有fs命令的帮助手册
usage hadoop fs -usage command 查看单个命令的使用手册
truncate 删减指定文件的指定行数
touchz 创建一个文件，就像Linux的touch命令

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 将本地的一个或多个文件复制到分布式文件系统中的指定路径

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 将本地文件移动到文件系统，注意是移动，移动后，本地文件将被删除

hadoop fs -moveFromLocal

mv 文件移动，要是移动多个文件的话，目的地必须为一个文件夹

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参数表示文件夹的父文件夹也会被创建

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]
参数列表如下

-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（可备份）

hdfs dfsadmin -allowSnapshot

然后对该文件夹创建备份

hdfs dfs -createSnapshot []

path为可备份的文件夹路径
snapshotName 为备份文件的名字，可以不填，默认为's'yyyyMMdd-HHmmss.SSS 格式的命名

创建备份后，备份本身放在在备份文件夹下的.snapshot文件夹内
Snapshots的使用比如现在有个文件夹/foo/bar
我对foo文件夹创建一个备份s0, 那么该备份的路径为/foo/.snapshot/s0
我要查看所有foo的所有备份

hdfs dfs -ls /foo/.snapshot

查找备份中的文件

hdfs dfs -ls /foo/.snapshot/s0

将备份中的文件恢复到某个目录

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取个名字

dfs.nameservices mycluster

将其对应的一组namenode的声明id

dfs.ha.namenodes.mycluster nn1,nn2, nn3

配置namenode id对应的具体机器端口信息

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地址、端口信息

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文件的路径

dfs.journalnode.edits.dir /path/to/journal/node/local/data

配置多台JournalNode组成的服务连接地址，他们相当于组成了一个分布式的文件目录

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

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时，出现故障的转移策略

dfs.client.failover.proxy.provider.mycluster org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider

配置自动故障转移上述所有配置，能保证editLog和fsImage文件不丢。但nameNode挂后，还是需要通过haadmin命令手动干预去启动新备选nameNode。
下面的一系列配置用来使用zookeeper实现namenode的自动故障转移
首先启动自动转移开关
在hdfs-site.xml 中配置

dfs.ha.automatic-failover.enabled true

在core-site.xml 配置zk的链接信息

ha.zookeeper.quorum zk1.example.com:2181,zk2.example.com:2181,zk3.example.com:2181

fs.defaultFS hdfs://mycluster

完成启动部署先启动所有的JournalNodes

./hdfs --daemon start journalnode

初始化主namenode

//如果集群是新集群 hdfs namenode -format//如果是对已经存在很久的集群，进行高可用改造，下面的命令，是把已经存在的editLog和fsImage数据同步到journalnode hdfs namenode -initializeSharedEdits

启动主namenode

./hdfs --daemon start namenode

初始化从namenode

hdfs namenode -bootstrapStandby

启动从namenode

sbin/hadoop-daemon.sh start namenode

在namenode所在机器，执行下述命令，初始化其在zk的节点信息

$HADOOP_HOME/bin/hdfs zkfc -formatZK

在所有namenode所在机器上启动zkfc进程

$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添加、更换磁盘

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:/guest/
RULE:[2:2](^.*; admin//
RULE:[2:/root/
DEFAULT
}
}
上述这个demo配置，其实就是将johndoe/* 形式的principal会被映射成本地的guest用户，而形如*/admin@TEST.COM 的principal会被映射成本地的admin账号
https://ssimo.org/blog/id_016.html
怎么找到指定用户的组
上述方式只是找到操作对应的用户。如果操作的用户不是对应文件、文件夹的owner, 那么需要判断该用户是否拥有指定文件、文件夹的组权限。
那首先，我们要知道该用户的有哪些组，以便让hdfs知道，该用户是否在文件所属组中，如果文件所属组，在用户的组列表中，说明该用户拥有文件的组权限。
那么怎么找到用户所属的组列表呢？
配置hadoop.security.group.mapping具体的mapping来找，可以配置的mapping有

org.apache.hadoop.security.JniBasedUnixGroupsMappingWithFallback
org.apache.hadoop.security.JniBasedUnixGroupsNetgroupMappingWithFallback
org.apache.hadoop.security.ShellBasedUnixGroupsMapping
org.apache.hadoop.security.ShellBasedUnixGroupsNetgroupMapping
org.apache.hadoop.security.LdapGroupsMapping
org.apache.hadoop.security.CompositeGroupsMapping

具体每个mapping的mapping策略，可看文档和具体的hadoop源码实现：https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/GroupsMapping.html#Composite_Groups_Mapping
静态mapping 还可以通过hadoop.user.group.static.mapping.overrides来静态指定一个用户对应的group list。如果一个用户在静态mapping中找到对应的组，就不会走上述的动态mapping
hadoop整体的安全模式 kerberos认证
采用kerberos作为hadoop各组件之间的权限认证。首先在部署的时候，将hadoop的各组件采用不同的linux用户和组进行部署。

文章图片
file hdfs文件系统，推荐的posix权限限制

文章图片
file 配置core-site.xml
配置如何映射一个用户

文章图片
file 配置整个集群启用kerberos权限认证。其中auth_to_local表示，当有其它组件请求当前服务时，如何将其映射成为本地的用户某个用户。一个demo配置为

hadoop.security.auth_to_local RULE:[2:$1/$2@$0]([ndj]n/.*@REALM.\TLD)s/.*/hdfs/ RULE:[2:$1/$2@$0]([rn]m/.*@REALM\.TLD)s/.*/yarn/ RULE:[2:$1/$2@$0](jhs/.*@REALM\.TLD)s/.*/mapred/ DEFAULT

其中，来至于namenode、datanode、journal node的请求，会被映射成为hdfs用户
来至于resource manger、node manager的请求，会被映射成本地的yarn用户
来至于job history server的请求，会被映射成为mapred用户
配置如何知道一个用户对应的分组文档前面有提到，有哪几种基于用户找到分组的方式。一般配安全集群，都会跟公司的LDAP整合起来，这里就以使用LDAP来找组为例看配置

hadoop.security.group.mapping.ldap.url ldap://server1,ldap://server2,ldap://server3 The URL of the LDAP server(s) to use for resolving user groups when using the LdapGroupsMapping user to group mapping. Supports configuring multiple LDAP servers via a comma-separated list. hadoop.security.group.mapping.ldap.num.attempts 6 This property is the number of attempts to be made for LDAP operations. If this limit is exceeded, LdapGroupsMapping will return an empty group list. hadoop.security.group.mapping.ldap.num.attempts.before.failover 2 This property is the number of attempts to be made for LDAP operations using a single LDAP instance. If multiple LDAP servers are configured and this number of failed operations is reached, we will switch to the next LDAP server. The configuration for the overall number of attempts will still be respected, failover will thus be performed only if this property is less than hadoop.security.group.mapping.ldap.num.attempts.

配置各组件自己的配置文件比如hdfs-site.xml , yarn-site.xml , mapred-site.xml 前面是配置整个集群服务，再接受到请求后，怎么辨别这个请求是哪个用户的，该用户属于哪个组的。而这里的配置，主要用来指定该组件自己的凭证文件也即kerberos的keytab存在什么地方，以及使用其中哪个principal作为当前组件的principal(一个keytab文件中，可以存储多个principal的认证信息)
下面以namenode为例，看其需要的配置

文章图片
file
其余各组件的相关配置大体类似。参考链接：
https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/SecureMode.html
授权 kerberos只是提供集群互访的认证，具体到认证用户的授权，又得单独配置。hadoop自己支持在 $HADOOP_CONF_DIR下配置hadoop-policy.xml文件来指定访问控制列表，实现授权控制。而我们准备使用ranger来做授权控制，所以这里不再对这种方式赘述
一些错误错误1
在某台机器上，以命令行查询文件系统是报错-ls: java.net.UnknownHostException: 具体的集群名称
这个错误是由于对应的机器上的hdfs-site.xml高可用配置没有配置连接namenode失败后的失败策略。
解决办法是在该机器的hdfs-site.xml中加入对应配置

dfs.client.failover.proxy.provider.haixue-hadoop org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider

重启该机器的组件，如果该机器只有datanode，那重启datanode即可
一些冷门知识如何将hdfs做成任意路径敲击皆可执行的命令

update-alternatives --install \ /usr/bin/hdfs \ hdfs \ /opt/hadoop-3.2.1/bin/hdfs \ 100

hdfs相关文档
datanode 的管理可以将指定datanode进行下线，维护
https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HdfsDataNodeAdminGuide.html
使用Erasure Coding对存储进行优化有些冷门的数据，存三个副本，有些浪费
https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HDFSErasureCoding.html
对namenode性能进行压测Synthetic Load Generator https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/SLGUserGuide.html
将数据写入暂存内存，提高数据写入速度数据写入内存，再异步写磁盘，有丢数据的风险
https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/MemoryStorage.html
Centralized Cache Management in HDFS 让datanode缓存部分热数据，来提升数据读取速度
https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/CentralizedCacheManagement.html
hdfs的两种web访问方式

HttpFS 单独搭一套web server，http请求打到它，他再去代理到hdfs。httpFs是单点，读写性能会瓶颈在这个单点
WebHDFS hdfs namenode内置的访问服务，实际访问是直接达到某台具体的datanode，没有性能瓶颈，具体缺点再调研

怎么知道一个具体的配置该放到哪个xml

文章图片
file
hadoop的文档左侧，有一个configuration 列表，其中有所有配置项对应的xml，以及其默认值和释义
参考资料 https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/ClusterSetup.html
https://data-flair.training/blogs/hadoop-hdfs-namenode-high-availability/