文章目录
- HDFS介绍
- HDFS体系
- HDFS的Shell介绍
- HDFS的常见Shell操作
- HDFS案例实操
- Java操作HDFS
- 配置环境
- HDFS的回收站
- HDFS的安全模式
- 实战:定时上传数据至HDFS
- HDFS的高可用和高扩展
- HDFS的高可用(HA)
- HDFS的高扩展(Federation)
HDFS介绍
HDFS是一个分布式的文件系统
假设让我们来设计一个分布式的文件系统,我们该如何设计呢?
这个统一由文件系统进行管理,我们只需要和文件系统进行交互就可以了。
这样是不是就实现了分布式存储了,这种方案在实际应用中可行吗?
现在这种设计是,我们去找一个中介公司,这里的主节点就可以理解为一个中介公司
这里的从节点就可以理解为是房源,中介公司会在每块房源都安排一个工作人员,当我们找房子的时候,
先联系中介公司,中介公司会告诉我们哪里有房子,并且把对应工作人员的信息告诉我们,我们就可以直接去找对应的工作人员去租房子。这样对于中介公司而言,就没什么压力了。这个就是HDFS这个分布式文件系统的设计思想。
HDFS的全称是Hadoop Distributed File System ,Hadoop的 分布式 文件 系统。它是一种允许文件通过网络在多台主机上分享的文件系统,可以让多台机器上的多个用户分享文件和存储空间。其实分布式文件管理系统有很多。HDFS只是其中一种实现而已,还有 GFS(谷歌的)、TFS(淘宝的)、S3(亚马逊的)。
为什么会有多种分布式文件系统呢?这样不是重复造轮子吗?
不是的,因为不同的分布式文件系统的特点是不一样的,HDFS是一种适合大文件存储的分布式文件系统,不适合小文件存储,什么叫小文件,例如,几KB,几M的文件都可以认为是小文件。
HDFS体系
- HDFS支持主从结构,主节点称为 NameNode ,支持多个从节点称为 ,支持多个
- HDFS中还包含一个 进程
HDFS的Shell介绍
针对HDFS,我们可以在shell命令行下进行操作,就类似于我们操作linux中的文件系统一样,但是具体命
令的操作格式是有一些区别的格式如下:
使用hadoop bin目录的hdfs命令,后面指定dfs,表示是操作分布式文件系统的,这些属于固定格式。
如果在PATH中配置了hadoop的bin目录,那么这里可以直接使用hdfs就可以了
这里的xxx是一个占位符,具体我们想对hdfs做什么操作,就可以在这里指定对应的命令了
大多数hdfs 的命令和对应的Linux命令类似
HDFS的常见Shell操作
直接在命令行中输入hdfs dfs,可以查看dfs后面
- -ls:查询指定路径信息
- -put:从本地上传文件
- -cat:查看HDFS文件内容
- -get:下载文件到本地
- -mkdir [-p]:创建文件夹
- -rm [-r]:删除文件/文件夹
HDFS案例实操
需求:统计HDFS中文件的个数和每个文件的大小
1) 我们先向HDFS中上传几个文件,把hadoop目录中的几个txt文件上传上去
[root@bigdata01 hadoop-3.2.0]# hdfs dfs -put LICENSE.txt /
[root@bigdata01 hadoop-3.2.0]# hdfs dfs -put NOTICE.txt /
[root@bigdata01 hadoop-3.2.0]# hdfs dfs -put README.txt /
- 统计根目录下文件的个数
[root@bigdata01 hadoop-3.2.0]# hdfs dfs -ls / |grep /| wc -l
3/LICENSE.txt 150569
/NOTICE.txt 22125
/README.txt 1361
Java操作HDFS
shell中操作hdfs是比较常见的操作,但是在工作中也会遇到一些需求是需要通过代码操作hdfs的
配置环境
1)在这里我们使用apache-maven-3.0.5-bin.zip ,当然了,其它版本也可以,没有什么本质的区别
把apache-maven-3.0.5-bin.zip解压到某一个目录下面,在这里我解压到了D:\Program Files (x86)\apache-maven-3.0.5目录解压之后,建议修改一下maven的配置文件,把maven仓库的地址修改到其它盘,例如D盘,默认是在C盘的用户目录下修改D:\Program Files (x86)\apache-maven-3.0.5\conf下的settings.xml文件将localRepository标签从注释中移出来,然后将值改为 D:.m2 ,效果如下:
<localRepository>D:\.m2</localRepository>
这样修改之后,maven管理的依赖jar包都会保存到D:.m2目录下了。
2)接下来需要配置maven的环境变量,和windows中配置JAVA_HOME环境变量是一样的。
先在环境变量中配置M2_HOME=D:\Program Files (x86)\apache-maven-3.0.5
然后在PATH环境变量中添加%M2_HOME%\bin即可
环境变量配置完毕以后,打开cmd窗口,输入mvn命令,只要能正常执行就说明windows本地的maven环境配置好了。还需要在idea中指定我们本地的maven配置
点击idea左上角的File–>Settings,进入如下界面,搜索maven,把本地的maven添加到这里面即可。
3) 创建一个maven项目
在这里我们需要引入hadoop-client依赖包,到maven仓库中去找,添加到pom.xml文件中
<dependency><groupId>org.apache.hadoop</groupId><artifactId>hadoop-client</artifactId><version>3.2.0</version>
</dependency>
4) 编写代码
package com.imooc.hdfs;
import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.fs.FSDataOutputStream;
import org.apache.hadoop.fs.FileSystem;
import org.apache.hadoop.fs.Path;
import org.apache.hadoop.io.IOUtils;
import java.io.FileInputStream;
import java.net.URI;
/**
* Java代码操作HDFS
* 文件操作:上传文件、下载文件、删除文件
*/
public class HdfsOp {
public static void main(String[] args) throws Exception{
//创建一个配置对象Configuration conf = new Configuration();
//指定HDFS的地址conf.set("fs.defaultFS","hdfs://bigdata01:9000");
//获取操作HDFS的对象FileSystem fileSystem = FileSystem.get(conf);
//获取HDFS文件系统的输出流FSDataOutputStream fos = fileSystem.create(new Path("/user.txt"));
//获取本地文件的输入流FileInputStream fis = new FileInputStream("D:\\user.txt");
//上传文件:通过工具类把输入流拷贝到输出流里面,实现本地文件上传到HDFSIOUtils.copyBytes(fis,fos,1024,true);}
}
执行代码,发现报错,提示权限拒绝,说明windows中的这个用户没有权限向HDFS中写入数据
解决办法有两个
- 第一种:去掉hdfs的用户权限检验机制,通过在hdfs-site.xml中配置dfs.permissions.enabled为false即可
- 第二种:把代码打包到linux中执行
在这里为了在本地测试方便,我们先使用第一种方式
在主节点上操作:
[root@bigdata01 hadoop-3.2.0]# vi etc/hadoop/hdfs-site.xml<configuration><property><name>dfs.replication</name><value>2</value></property><property><name>dfs.namenode.secondary.http-address</name><value>bigdata01:50090</value></property><property><name>dfs.permissions.enabled</name><value>false</value></property>
</configuration>
同步到其他节点
[root@bigdata01 hadoop-3.2.0]# scp -rq etc/hadoop/hdfs-site.xml bigdata02:/d
[root@bigdata01 hadoop-3.2.0]# scp -rq etc/hadoop/hdfs-site.xml bigdata03:/d
重新启动集群:
[root@bigdata01 hadoop-3.2.0]# sbin/start-all.sh
Starting namenodes on [bigdata01]
HDFS的回收站
HDFS会为每一个用户创建一个回收站目录:/user/用户名/.Trash/,每一个被用户在Shell命令行删除的文件/目录,会进入到对应的回收站目录中,在回收站中的数据都有一个生存周期,也就是当回收站中的文件/目录在一段时间之内没有被用户恢复的话,HDFS就会自动的把这个文件/目录彻底删除,之后,用户就永远也找不回这个文件/目录了。
默认情况下hdfs的回收站是没有开启的,需要通过一个配置来开启,在core-site.xml中添加如下配置,value的单位是分钟,1440分钟表示是一天的生存周期
<property><name>fs.trash.interval</name><value>1440</value>
</property>
注意:如果删除的文件过大,超过回收站大小的话会提示删除失败。需要指定参数 -skipTrash ,指定这个参数表示删除的文件不会进回收站
HDFS的安全模式
平时操作HDFS的时候,有时候可能会遇到这个问题,特别是刚启动集群的时候去上传或者删除文
件,会发现报错,提示NameNode处于safe mode。
这个属于HDFS的安全模式,因为在集群每次重新启动的时候,HDFS都会检查集群中文件信息是否完整,例如副本是否缺少之类的信息,所以这个时间段内是不允许对集群有修改操作的,如果遇到了这个情况,可以稍微等一会,等HDFS自检完毕,就会自动退出安全模式。
通过hdfs命令也可以查看当前的状态:
[root@bigdata01 hadoop-3.2.0]# hdfs dfsadmin -safemode get
Safe mode is ON
如果想快速离开安全模式,可以通过命令强制离开,正常情况下建议等HDFS自检完毕,自动退出
[root@bigdata01 hadoop-3.2.0]# hdfs dfsadmin -safemode leave
Safe mode is OFF
实战:定时上传数据至HDFS
需求分析:
在实际工作中会有定时上传数据到HDFS的需求,我们有一个web项目每天都会产生日志文件,日志文件的格式为access_2020_01_01.log这种格式的,每天产生一个,我们需要每天凌晨将昨天生成的日志文件上传至HDFS上,按天分目录存储,HDFS上的目录格式为20200101
针对这个需求,我们需要开发一个shell脚本,方便定时调度执行
- 第一步:我们需要获取到昨天日志文件的名称
- 第二步:在HDFS上面使用昨天的日期创建目录
- 第三步:将昨天的日志文件上传到刚创建的HDFS目录中
- 第四步:要考虑到脚本重跑,补数据的情况
- 第五步:配置crontab任务
开始开发shell脚本,脚本内容如下:
[root@bigdata01 ~]# mkdir -p /data/shell
[root@bigdata01 ~]# cd /data/shell
[root@bigdata01 shell]# vi uploadLogData.sh
#!/bin/bash
# 获取昨天日期字符串
yesterday=$1
if [ "$yesterday" = "" ]
then
yesterday=`date +%Y_%m_%d --date="1 days ago"`
fi
# 拼接日志文件路径信息
logPath=/data/log/access_${yesterday}.log
# 将日期字符串中的_去掉
hdfsPath=/log/${yesterday//_/}
# 在hdfs上创建目录
hdfs dfs -mkdir -p ${hdfsPath}
# 将数据上传到hdfs的指定目录中
hdfs dfs -put ${logPath} ${hdfsPath}
生成测试数据,注意,文件名称中的日期根据昨天的日期命名
[root@bigdata01 shell]# mkdir -p /data/log
[root@bigdata01 shell]# cd /data/log
[root@bigdata01 log]# vi access_2020_04_08.log
log1
执行脚本
[root@bigdata01 log]# cd /data/shell/
[root@bigdata01 shell]# sh -x uploadLogData.sh
+ yesterday=
+ '[' '' = '' ']'
++ date +%Y_%m_%d '--date=1 days ago'
+ yesterday=2020_04_08
+ logPath=/data/log/access_2020_04_08.log
+ hdfsPath=/log/20200408
+ hdfs dfs -mkdir -p /log/20200408
+ hdfs dfs -put /data/log/access_2020_04_08.log /log/20200408
[root@bigdata01 shell]# hdfs dfs -ls /log/20200408
Found 1 items
-rw-r--r-- 2 root supergroup 15 2020-04-09 16:05 /log/20200408/acce
注意:如果想要指定日期上传数据,可以通过在脚本后面传递参数实现
这样后期如果遇到某天的数据漏传了,或者需要重新上传,就可以通过手工指定日期实现上传操作,在实际工作中这种操作是不可避免的,所以我们在开发脚本的时候就直接考虑好补数据的情况,别等需要用的时候了再去增加这个功能。
最后配置crontab定时任务,每天凌晨1点执行
[root@bigdata01 shell]# vi /etc/crontab
0 1 * * * root sh /data/shell/uploadLogData.sh >> /data/shell/uploadLogData.log
HDFS的高可用和高扩展
NameNode负责接收用户的操作请求,所有的读写请求都会经过它,如果它挂了怎么办?
这个时候集群是不是就无法正常提供服务了?是的,那现在我们这个集群就太不稳定了,因为NameNode只有一个,是存在单点故障的,咱们在现实生活中,例如,县长,是有正的和副的,这样就是为了解决当正县长遇到出差的时候,副县长可以顶上去。
所以在HDFS的设计中,NameNode也是可以支持多个的,一个主的 多个备用的,,当主的挂掉了,备用的可以顶上去,这样就可以解决NameNode节点宕机导致的单点故障问题了,也就实现了HDFS的高可用。
还有一个问题是,前面我们说了NameNode节点的内存是有限的,只能存储有限的文件个数,那使用一个主NameNode,多个备用的NameNode能解决这个问题吗? 不能!
一个主NameNode,多个备用的NameNode的方案只能解决NameNode的单点故障问题,无法解决单个NameNode内存不够用的问题,那怎么办呢?不用担心,官方提供了Federation机制,可以翻译为联邦,它可以解决单节点内存不够用的情况,具体实现思路我们稍后分析,这个就是HDFS的高扩展
HDFS的高可用(HA)
-
HDFS的HA,指的是在一个集群中存在多个NameNode,分别运行在独立的物理节点上。在任何时间点,只有一个NameNode是处于Active状态,其它的是处于Standby状态。 Active NameNode(简写为Active NN)负责所有的客户端的操作,而Standby NameNode(简写为Standby NN)用来同步ActiveNameNode的状态信息,以提供快速的故障恢复能力。
-
为了保证Active NN与Standby NN节点状态同步,即元数据保持一致。除了DataNode需要向这些NameNode发送block位置信息外,还构建了一组独立的守护进程”JournalNodes”(简写为JN),用来同步Edits信息。当Active NN执行任何有关命名空间的修改,它需要持久化到一半以上的JNs上。而Standby NN负责观察JNs的变化,读取从Active NN发送过来的Edits信息,并更新自己内部的命名空间。一旦Active NN遇到错误,Standby NN需要保证从JNs中读出了全部的Edits,然后切换成Active状态,如果有多个Standby NN,还会涉及到选主的操作,选择一个切换为Active 状态。
需要注意一点,为了保证Active NN与Standby NN节点状态同步,即元数据保持一致
这里的元数据包含两块,一个是静态的,一个是动态的
- 静态的是fsimage和edits,其实fsimage是由edits文件合并生成的,所以只需要保证edits文件内容的一致性。这个就是需要保证多个NameNode中edits文件内容的事务性同步。这块的工作是由JournalNodes集群进行同步的
- 动态数据是指block和DataNode节点的信息,这个如何保证呢?当DataNode启动的时候,上报数据信息的时候需要向每个NameNode都上报一份。这样就可以保证多个NameNode的元数据信息都一样了,当一个NameNode down掉以后,立刻从Standby NN中选择一个进行接管,没有影响,因为每个NameNode 的元数据时刻都是同步的。
注意:使用HA的时候,不能启动SecondaryNameNode,会出错。
之前是SecondaryNameNode负责合并edits到fsimage文件 那么现在这个工作被standby NN负责了。
NameNode 切换可以自动切换,也可以手工切换,如果想要实现自动切换,需要使用到zookeeper集群。
使用zookeeper集群自动切换的原理是这样的:当多个NameNode 启动的时候会向zookeeper中注册一个临时节点,当NameNode挂掉的时候,这个临时节点也就消失了,这属于zookeeper的特性,这个时候,zookeeper就会有一个watcher监视器监视到,就知道这个节点down掉了,然后会选择一个节点转为Active,把down掉的节点转为Standby。注意:下面的配置步骤建议大家有空闲时间了再来操作就行,作为一个课外扩展,因为在工作中这个配置是不需要我们做的,我们只需要知道这种特性即可
HDFS的高扩展(Federation)
HDFS Federation可以解决单一命名空间存在的问题,使用多个NameNode,每个NameNode负责一个命令空间
这种设计可提供以下特性:
1:HDFS集群扩展性。多个NameNode分管一部分目录,使得一个集群可以扩展到更多节点,不再因内存的限制制约文件存储数目。
2:性能更高效。多个NameNode管理不同的数据,且同时对外提供服务,将为用户提供更高的读写吞吐率。
3:良好的隔离性。用户可根据需要将不同业务数据交由不同NameNode管理,这样不同业务之间影响很小。
这里面用到了4个NameNode和6个DataNode
NN-1、NN-2、NN-3、NN-4
DN-1、DN-2、DN-3、DN-4、DN-5、DN-6、
其中NN-1、和NN-3配置了HA,提供了一个命令空间,/share,其实可理解为一个顶级目录
NN-2和NN-4配置了HA,提供了一个命名空间,/user
这样后期我们存储数据的时候,就可以根据数据的业务类型来区分是存储到share目录下还是user目录下,此时HDFS的存储能力就是/share和/user两个命名空间的总和了。
注意:由于Federation+HA需要的机器比较多,大家本地的机器开不了那么多虚拟机,所以暂时在这就不再提供对应的安装步骤了,大家主要能理解它的原理就可以了,在工作中也不需要我们去配置。