关于hadoop: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 的后缀有

比方 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/doc…

hdfs 的命令

如果 hadoop 操作的是 hdfs, 那么上面两种命令格局等效

• bin/hadoop fs <args>
• hdfs dfs <args>

hadoop fs 的相干命令反对多种文件系统

• hdfs hadoop 本人的分布式文件系统
• Local FS 本地文件系统，即为以后机器的文件系统
• WebHDFS
• S3 FS 亚马逊的分布式文件系统

hadoop fs 命令个别操作的文件系统门路格局 URI 为scheme://authority/path，比方 hdfs 举例hdfs://namenodehost/parent/child

appendToFile

将本地单个文件或多个文件，或则本机的规范输出中的内容，拷贝到指标文件系统
用法：hadoop fs -appendToFile <localsrc> ... <dst>

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

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] <localsrc> URI
其中命令参数有以下几个，都是可选

• - p 复制到分布式文件系统的文件保留原文件的批改工夫、权限、所有者信息
• -f 如果分布式文件系统曾经存在该文件，则笼罩
• -l 容许 DataNode 提早长久化该文件，replication factor 是 1. 也即这种形式不会要去数据马上落地和写正本，具备丢数据的危险，然而写入速度可能会很快
• -d 文件复制过程中，将不会创立后缀为 ._COPYING_ 格局的文件

copyToLocal

将分布式文件系统中的文件拷贝到本地

count

同进指定门路的文件、文件夹个数、以后文件占用量大小、指定门路容许创立的文件、文件夹个数，以及容许的最大文件、文件容量
用法：hadoop fs -count [-q] [-h] [-v] [-x] [-t [<storage type>]] [-u] [-e] <paths>
如果只用 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 ...] <dest>

• - 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] <src> <localdst>

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 <localsrc> <dst>

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

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

-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，理论的数据存储节点。数据的间接读写，都是在这下面进行的
  

HDFS Snapshots

HDFS Snapshots 用来做数据备份，或者劫难复原。
HDFS Snapshots 创立的耗时很低，简直是霎时创立。
之所以快的起因是，集群没有数据挪动。
Snapshots 创立后，只记录其对应实在文件门路下产生的变动。
当你要复原数据时，hdfs 是通过以后的数据减去 Snapshots 记录的至 snapshot 创立以来，发生变化的数据，就等于 snapshot 备份初始时，对应的数据状态。

这个思维很棒，创立备份很快的同时，备份所要求的存储空间也很少

Snapshots 的创立

一个文件夹想要应用 Snapshots 备份，首先该文件夹须要被设置成 snapshottable（可备份）

hdfs dfsadmin -allowSnapshot <path>

而后对该文件夹创立备份

hdfs dfs -createSnapshot <path> [<snapshotName>]

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

该图上半局部，显示的是文件在 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 正本

被动健壮性

1. 往 hdfs 中文件的时候，存一份 chcksum, 读文件时，校验 checksum
2. fsImage 和 editLog 十分重要，即使写磁盘，都有可能损坏，为了保障其可用性，多写几个正本
3. namenode 自身配置高可用
4. 定时应用 snapshot 备份集群数据，使得数据可复原

数据的组织

hdfs 中将文件默认拆分为 128 MB 的 block

当像 hdfs 中写一个需正本文件时，namenode 首选选取一组 datanode 给到客户端，客户端将数据写第一个 datanode, 第一个 datanode 写完后，将该数据分发给第二个 datanode , 顺次类推，像一个链式管道

数据的拜访

反对以命令、api、web 浏览器的形式拜访 hdfs 文件系统

空间回收

以下两种回收形式，都是有肯定提早的，不是操作后，就能看到多出的空间。

删除文件

如果垃圾桶性能开启后，删除的文件会先到 /user/<username>/.Trash，每个用户都有一个本人的垃圾桶。
用户最近删除的文件在 /user/<username>/.Trash/Current 中

当到了肯定工夫后，垃圾桶中的文件会被彻底删除。这个时候，hdfs 会真正回收这部分空间

缩小正本

将正本个数缩小，也会促使集群回收对应文件的空间

editLog 和 fsImage 的高可用

https://hadoop.apache.org/doc…

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

从上能够看到。为了保障 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 组件的对应关系为

配置 Journal Manager

次要配置
hdfs-site.xml
如果将多个 Namenode 整体看做一个分布式服务的话，首先要给这个 service 取个名字

<property>
  <name>dfs.nameservices</name>
  <value>mycluster</value>
</property>

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

<property>
  <name>dfs.ha.namenodes.mycluster</name>
  <value>nn1,nn2, nn3</value>
</property>

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

<property>
  <name>dfs.namenode.rpc-address.mycluster.nn1</name>
  <value>machine1.example.com:8020</value>
</property>
<property>
  <name>dfs.namenode.rpc-address.mycluster.nn2</name>
  <value>machine2.example.com:8020</value>
</property>
<property>
  <name>dfs.namenode.rpc-address.mycluster.nn3</name>
  <value>machine3.example.com:8020</value>
</property>

配置这组 namenode，对应的 http 地址、端口信息

<property>
  <name>dfs.namenode.http-address.mycluster.nn1</name>
  <value>machine1.example.com:9870</value>
</property>
<property>
  <name>dfs.namenode.http-address.mycluster.nn2</name>
  <value>machine2.example.com:9870</value>
</property>
<property>
  <name>dfs.namenode.http-address.mycluster.nn3</name>
  <value>machine3.example.com:9870</value>
</property>

配置 journalnode 存储 editLog 和 fsImage 文件的门路

<property>
  <name>dfs.journalnode.edits.dir</name>
  <value>/path/to/journal/node/local/data</value>
</property>

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

<property>
  <name>dfs.namenode.shared.edits.dir</name>
  <value>qjournal://node1.example.com:8485;node2.example.com:8485;node3.example.com:8485/mycluster</value>
</property>

为了避免脑裂以致多个 Namenode 都在写数据，能够配置一些当呈现脑裂时，去杀死 Namenode 过程的命令，如果默认不指定命令，也须要做 shell(/bin/true)。他的实现原理是，standby 的 namenode，筹备成为 active 时，先通过 ssh 登录到原来的 active namenode 的机器上，尝试以命令的模式杀死原来的 namenode 过程，保障本人启动起来不呈现脑裂。所以这一步的要害配置是多个 namenode 之前，要实现 ssh 免密登录。ssh 免密登录的配置参考：https://www.cnblogs.com/nices…

<property> 
    <name>dfs.ha.fencing.methods</name>  
    <value>sshfence shell(/bin/true)</value> 
  </property>  
  <property> 
    <name>dfs.ha.fencing.ssh.private-key-files</name>  
    <value>/home/vagrant/.ssh/id_rsa</value> 
  </property>  
  <property> 
    <name>dfs.ha.fencing.ssh.connect-timeout</name>  
    <value>30000</value> 
  </property>  

还能够配置客户端连贯 namenode 时，呈现故障的转移策略

<property>
  <name>dfs.client.failover.proxy.provider.mycluster</name>
  <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
</property>

配置主动故障转移

上述所有配置，能保障 editLog 和 fsImage 文件不丢。但 nameNode 挂后，还是须要通过 haadmin 命令手动干涉去启动新备选 nameNode。

上面的一系列配置用来应用 zookeeper 实现 namenode 的主动故障转移
首先启动主动转移开关
在 hdfs-site.xml 中配置

<property>
   <name>dfs.ha.automatic-failover.enabled</name>
   <value>true</value>
 </property>

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

<property>
   <name>ha.zookeeper.quorum</name>
   <value>zk1.example.com:2181,zk2.example.com:2181,zk3.example.com:2181</value>
 </property>

<property>
  <name>fs.defaultFS</name>
  <value>hdfs://mycluster</value>
</property>

实现启动部署

先启动所有的 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/doc…

对 DataNode 增加、更换磁盘

https://hadoop.apache.org/doc…

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/doc…

参考资料
https://hadoop.apache.org/doc…

集群监控要点

• 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/nices…

如果发动脚本执行的机器，自身也须要部署一个 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/nices…

谁是管理员

谁启动的 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:$1](johndoe)s/^.*$/guest/
                  RULE:[2:$1;$2](^.*;admin$)s/;admin$//
                  RULE:[2:$2](^.*;root)s/^.*$/root/
                  DEFAULT
                  }
              }
              

上述这个 demo 配置，其实就是将 johndoe/ 模式的 principal 会被映射老本地的 guest 用户，而形如/admin@TEST.COM 的 principal 会被映射老本地的 admin 账号

https://ssimo.org/blog/id_016…

怎么找到指定用户的组

上述形式只是找到操作对应的用户。如果操作的用户不是对应文件、文件夹的 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/doc…

动态 mapping

还能够通过 hadoop.user.group.static.mapping.overrides 来动态指定一个用户对应的 group list。如果一个用户在动态 mapping 中找到对应的组，就不会走上述的动静 mapping

hadoop 整体的平安模式

kerberos 认证

采纳 kerberos 作为 hadoop 各组件之间的权限认证。首先在部署的时候，将 hadoop 的各组件采纳不同的 linux 用户和组进行部署。

hdfs 文件系统，举荐的 posix 权限限度

配置 core-site.xml

配置如何映射一个用户

配置整个集群启用 kerberos 权限认证。其中 auth_to_local 示意，当有其它组件申请以后服务时，如何将其映射成为本地的用户某个用户。一个 demo 配置为

<property>
  <name>hadoop.security.auth_to_local</name>
  <value>
    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
  </value>
</property>

其中，来至于 namenode、datanode、journal node 的申请，会被映射成为 hdfs 用户
来至于 resource manger、node manager 的申请，会被映射老本地的 yarn 用户
来至于 job history server 的申请，会被映射成为 mapred 用户

配置如何晓得一个用户对应的分组

文档后面有提到，有哪几种基于用户找到分组的形式。个别配平安集群，都会跟公司的 LDAP 整合起来，这里就以应用 LDAP 来找组为例看配置

<property>
  <name>hadoop.security.group.mapping.ldap.url</name>
  <value>ldap://server1,ldap://server2,ldap://server3</value>
  <description>
    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.
  </description>
</property>

<property>
  <name>hadoop.security.group.mapping.ldap.num.attempts</name>
  <value>6</value>
  <description>
    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.
  </description>
</property>

<property>
  <name>hadoop.security.group.mapping.ldap.num.attempts.before.failover</name>
  <value>2</value>
  <description>
    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.
  </description>
</property>

配置各组件本人的配置文件比方 hdfs-site.xml , yarn-site.xml , mapred-site.xml

后面是配置整个集群服务，再承受到申请后，怎么分别这个申请是哪个用户的，该用户属于哪个组的。而这里的配置，次要用来指定该组件本人的凭证文件也即 kerberos 的 keytab 存在什么中央，以及应用其中哪个 principal 作为以后组件的 principal(一个 keytab 文件中，能够存储多个 principal 的认证信息)
上面以 namenode 为例，看其须要的配置

其余各组件的相干配置大体相似。参考链接：
https://hadoop.apache.org/doc…

受权

kerberos 只是提供集群互访的认证，具体到认证用户的受权，又得独自配置。hadoop 本人反对在 $HADOOP_CONF_DIR 下配置 hadoop-policy.xml 文件来指定访问控制列表，实现受权管制。而咱们筹备应用 ranger 来做受权管制，所以这里不再对这种形式赘述

一些谬误

谬误 1

在某台机器上，以命令行查问文件系统是报错-ls: java.net.UnknownHostException: 具体的集群名称

这个谬误是因为对应的机器上的 hdfs-site.xml 高可用配置没有配置连贯 namenode 失败后的失败策略。

解决办法是在该机器的 hdfs-site.xml 中退出对应配置

    <property>
        <name>dfs.client.failover.proxy.provider.haixue-hadoop</name>
        <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
    </property>

重启该机器的组件，如果该机器只有 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/doc…

应用 Erasure Coding 对存储进行优化

有些冷门的数据，存三个正本，有些节约
https://hadoop.apache.org/doc…

对 namenode 性能进行压测 Synthetic Load Generator

https://hadoop.apache.org/doc…

将数据写入暂存内存，进步数据写入速度

数据写入内存，再异步写磁盘，有丢数据的危险
https://hadoop.apache.org/doc…

Centralized Cache Management in HDFS

让 datanode 缓存局部热数据，来晋升数据读取速度
https://hadoop.apache.org/doc…

hdfs 的两种 web 拜访形式

• HttpFS 独自搭一套 web server，http 申请打到它，他再去代理到 hdfs。httpFs 是单点，读写性能会瓶颈在这个单点
• WebHDFS hdfs namenode 内置的拜访服务，理论拜访是间接达到某台具体的 datanode，没有性能瓶颈，具体毛病再调研

怎么晓得一个具体的配置该放到哪个 xml

hadoop 的文档左侧，有一个 configuration 列表，其中有所有配置项对应的 xml，以及其默认值和释义

参考资料

https://hadoop.apache.org/doc…

https://data-flair.training/b…

欢送关注我的集体公众号 ” 东南偏北 UP”，记录代码人生，行业思考，科技评论