大数据学习_Hadoop_HDFS分布式文件系统

1 HDFS简介

HDFS(全称:Hadoop Distribute File System,Hadoop 分布式文件系统)是 Hadoop 核心组成,是分布式存储服务。
分布式文件系统横跨多台计算机,在大数据时代有着广泛的应用前景,它们为存储和处理超大规模数据提供所需的扩展能力。
HDFS是分布式文件系统中的一种。

2 HDFS的重要概念

HDFS通过统一的命名空间目录树来定位文件; 另外,它是分布式的,由很多服务器联合起来实现其功能,集群中的服务器有各自的角色(分式本质是拆分,各司其职)。

  • 典型的Master/Slave架构
    HDFS 的架构是典型的Master/Slave结构。
    HDFS集群往往是一个NameNode(HA架构会有两个NameNode,联邦机制)+多个DataNode组成;
    NameNode是集群的主节点,DataNode是集群的从节点。
  • 分块存储(block机制)
    HDFS 中的文件在物理上是分块存储(block)的,块的大小可以通过配置参数来规定;
    Hadoop2.x版本中默认的block大小是128M;
  • 命名空间(NameSpace)
    HDFS 支持传统的层次型文件组织结构。用户或者应用程序可以创建目录,然后将文件保存在这些目录里。文件系统名字空间的层次结构和大多数现有的文件系统类似:用户可以创建、删除、移动或重命名文件。
    Namenode 负责维护文件系统的名字空间,任何对文件系统名字空间或属性的修改都将被Namenode 记录下来。
    HDFS提供给客户单一个抽象目录树,访问形式:hdfs://namenode的hostname:port/test/input
  • NameNode元数据管理
    元数据是目录结构及文件分块位置信息。
    NameNode的元数据记录每一个文件所对应的block信息(block的id,以及所在的DataNode节点
    的信息)
  • DataNode数据存储
    文件的各个 block 的具体存储管理由 DataNode 节点承担。一个block会有多个DataNode来存储,DataNode会定时向NameNode来汇报自己持有的block信息。
  • 副本机制
    为了容错,文件的所有 block 都会有副本。每个文件的 block 大小和副本系数都是可配置的。应用程序可以指定某个文件的副本数目。副本系数可以在文件创建的时候指定,也可以在之后改变。
    副本数量默认是3个。
  • 一次写入,多次读出
    HDFS 是设计成适应一次写入,多次读出的场景,且不支持文件的随机修改(支持追加写入,不只支持随机更新)。
    正因为如此,HDFS 适合用来做大数据分析的底层存储服务,并不适合用来做网盘等应用(修改不方便,延迟大,网络开销大,成本太高)

3 HDFS 架构

  • NameNode(nn):Hdfs集群的管理者,Master
    维护管理Hdfs的名称空间(NameSpace)
    维护副本策略
    记录文件块(Block)的映射信息
    负责处理客户端读写请求
  • DataNode:NameNode下达命令,DataNode执行实际操作,Slave节点。
    保存实际的数据块
    负责数据块的读写
  • Client:客户端
    上传文件到HDFS的时候,Client负责将文件切分成Block,然后进行上传
    请求NameNode交互,获取文件的位置信息
    读取或写入文件,与DataNode交互
    Client可以使用一些命令来管理HDFS或者访问HDFS
    在这里插入图片描述

4 HDFS 客户端操作

4.1 Shell 命令行操作HDFS

  1. 基本语法
    bin/hadoop fs 具体命令 OR bin/hdfs dfs 具体命令
  2. 命令大全
    https://blog.csdn.net/qq_41612830/article/details/113106275

4.2 Win环境下JAVA客户端

  1. Hadoop解包,并在bin目录下添加winutils.exe(否则后续运行会出错)
    链接:https://pan.baidu.com/s/144uWXxqwzL96fgH02zb03Q 提取码:puxw
  2. 配置Hadoop环境变量
  3. 创建工程并导入Hadoop Maven坐标依赖 + 日志配置
    https://mvnrepository.com/artifact/org.apache.hadoop/hadoop-common
  4. 获取文件系统FileSystem
  5. 创建相关操作类
  • HDFS的API
    FileSystem类的方法来实现上传、下载、查看…
  • IO流操作HDFS
    IOUtils类的方法来实现(流对拷)
  1. 关闭资源
  2. Win环境下HDFS系统权限问题
    由于默认最高权限用户是root,那么其他用户的访问会受到限制。HDFS文件权限的目的,防止好人做错事,而不是阻止坏人做坏事。HDFS相信你告诉我你是谁,你就是谁。
    解决方法:
    1.指定用户信息获取FileSystem对象
    2.关闭HDFS集群权限校验
vim hdfs-site.xml
#添加如下属性
	<property>
		<name>dfs.permissions</name>
		<value>true</value>
	</property>

修改完成之后要分发到其它节点,同时要重启HDFS集群
3.基于HDFS权限本身比较鸡肋的特点,我们可以彻底放弃HDFS的权限校验,如果生产环境中我们可以考虑借助kerberos以及sentry等安全框架来管理大数据集群安全。所以我们直接修改HDFS的根目录权限为777。

hadoop fs -chmod -R 777 /

5 HDFS读写解析

5.1 HDFS读数据流程

在这里插入图片描述

  1. 客户端通过Distributed FileSystem向NameNode请求下载文件,NameNode通过查询元数据,找到文件块所在的DataNode地址。
  2. 这些DataNode会按照Hadoop定义的集群拓扑结构得出客户端的距离,然后再进行排序。如果客户端本身就是一个DataNode,那么他将从本地读取文件。
  3. DataNode开始传输数据给客户端(从磁盘里面读取数据输入流,以Packet为单位来做校验)。
  4. 客户端以Packet为单位接收,先在本地缓存,然后写入目标文件。

5.2 HDFS写数据流程

在这里插入图片描述

  1. 客户端通过Distributed FileSystem模块向NameNode请求上传文件,NameNode检查目标文件是否已存在,父目录是否存在。
  2. NameNode返回是否可以上传。
  3. 客户端请求第一个 Block上传到哪几个DataNode服务器上。
  4. NameNode返回3个DataNode节点,分别为dn1、dn2、dn3。
  5. 客户端通过FSDataOutputStream模块请求dn1上传数据,dn1收到请求会继续调用dn2,然后dn2调用dn3,将这个通信管道建立完成。
  6. dn1、dn2、dn3逐级应答客户端。
  7. 客户端开始往dn1上传第一个Block(先从磁盘读取数据放到一个本地内存缓存),以Packet为单位,dn1收到一个Packet就会传给dn2,dn2传给dn3;dn1每传一个packet会放入一个确认队列等待确认。
  8. 当一个Block传输完成之后,客户端再次请求NameNode上传第二个Block的服务器。(重复执行3-7步)。

6 NN与2NN

6.1 HDFS元数据管理机制

在这里插入图片描述

  • 第一阶段:NameNode启动
    1.第一次启动NameNode格式化后,创建Fsimage和Edits文件。如果不是第一次启动,直接加载编辑日志和镜像文件到内存。
    2.客户端对元数据进行增删改的请求。
    3.NameNode记录操作日志,更新滚动日志。
    4.NameNode在内存中对数据进行增删改。
  • 第二阶段:Secondary NameNode工作
    1.Secondary NameNode询问NameNode是否需要CheckPoint。直接带回NameNode是否执行检查点操作结果。
    2.Secondary NameNode请求执行CheckPoint。
    3.NameNode滚动正在写的Edits日志。
    4.将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode。
    5.Secondary NameNode加载编辑日志和镜像文件到内存,并合并。
    6.生成新的镜像文件fsimage.chkpoint。
    7.拷贝fsimage.chkpoint到NameNode。
    8.NameNode将fsimage.chkpoint重新命名成fsimage。

6.2 Fsimage与Edits文件解析

NameNode在执行格式化之后,会在/opt/lagou/servers/hadoop-2.9.2/data/tmp/dfs/name/current目录下产生如下文件:
在这里插入图片描述
Fsimage文件:是namenode中关于元数据的镜像,一般称为检查点,这里包含了HDFS文件系统
所有目录以及文件相关信息(Block数量,副本数量,权限等信息)
Edits文件 :存储了客户端对HDFS文件系统所有的更新操作记录,Client对HDFS文件系统所有的
更新操作都会被记录到Edits文件中(不包括查询操作)
seen_txid:该文件是保存了一个数字,数字对应着最后一个Edits文件名的数字
VERSION:该文件记录namenode的一些版本号信息,比如:CusterId,namespaceID等

6.2.1 Fsimage文件内容

  1. 查看命令
    oiv:oiv Offline Image Viewer 离线image查看器,用于将fsimage文件的内容转储到指定文件中以便于阅读,,如文本文件、XML文件,该命令需要以下参数:
  • -i (必填参数) –inputFile 输入FSImage文件
  • -o (必填参数) –outputFile 输出转换后的文件,如果存在,则会覆盖
  • -p (可选参数) –processor 将FSImage文件转换成哪种格式: (Ls|XML|FileDistribution).默认为Ls
  • 示例:hdfs oiv -p XML -i /data1/hadoop/dfs/name/current/fsimage_0000000000019372521 -o /home/hadoop/fsimage.txt
    注:在内存元数据中是有记录块所对应的dn信息,但是fsimage中就剔除了这个信息;HDFS集群在启动的时候会加载image以及edits文件,block对应的dn信息都没有记录,集群启动时会有一个安全模式(safemode),安全模式就是为了让dn汇报自己当前所持有的block信息给nn来补全元数据。后续每隔一段时间dn都要汇报自己持有的block信息。

6.2.2 Edits文件内容

oev:Offline edits viewer 离线edits查看器

  • 示例: hdfs oev -p XML -i edits_0000000000000042778-0000000000000042779 -o edits.xml
  • 支持的输出格式有binary(hadoop使用的二进制格式)、xml(在不使用参数p时的默认输出格式)和stats(输出edits文件的统计信息)
    XML在线格式化工具:http://c.runoob.com/front-end/710
    注:Edits中只记录了更新相关的操作,查询或者下载文件并不会记录在内。
    那么NameNode启动时如何确定加载哪些Edits文件呢?
    nn启动时需要加载fsimage文件以及那些没有被2nn进行合并的edits文件,nn如何判断哪些edits已经被合并了呢?
    可以通过fsimage文件自身的编号来确定哪些已经被合并。
    在这里插入图片描述

6.3 checkpoint周期

<!-- 定时一小时 -->
	<property>
		<name>dfs.namenode.checkpoint.period</name>
		<value>3600</value>
	</property>
<!-- 一分钟检查一次操作次数,当操作次数达到1百万时,SecondaryNameNode执行一次 -->
	<property>
		<name>dfs.namenode.checkpoint.txns</name>
		<value>1000000</value>
		<description>操作动作次数</description>
	</property>
	<property>
		<name>dfs.namenode.checkpoint.check.period</name>
		<value>60</value>
		<description> 1分钟检查一次操作次数</description>
	</property >

7 NN故障处理

NameNode故障后,HDFS集群就无法正常工作,因为HDFS文件系统的元数据需要由NameNode来管理维护并与Client交互,如果元数据出现损坏和丢失同样会导致NameNode无法正常工作进而HDFS文件系统无法正常对外提供服务。
如果元数据出现丢失损坏如何恢复呢?

  1. 将2NN的元数据fsimage文件拷贝到NN的节点下(此种方式会存在元数据的丢失)。
    2NN与真正元数据,少了上次checkpoint到当前checkpoint间未合并的Edits文件,所以会丢失一部分数据。
  2. 搭建HDFS的HA(高可用)集群,解决NN的单点故障问题(借助Zookeeper实现HA,一个Active的NameNode,一个是Standby的NameNode)
    Active NN:正常与客户端收发请求
    Standby NN:在Active NN正常的情况下,Standby NN不做任何工作。反之如果Active NN突然宕机,Standby NN开始启用。

8 Hadoop的限额与归档以及集群安全模式

8.1 HDFS文件限额配置

HDFS文件的限额配置允许我们以文件大小或者文件个数来限制我们在某个目录下上传的文件数量或者文件内容总量,以便达到我们类似百度网盘网盘等限制每个用户允许上传的最大的文件的量。

  1. 数量限额
hdfs dfsadmin -setQuota 2 /user/root/lagou # 给该文件夹下面设置最多上传两个文件,上传文件,发现只能上传一个文件
hdfs dfsadmin -clrQuota /user/root/lagou # 清除文件数量限制
  1. 空间大小限额
hdfs dfsadmin -setSpaceQuota 4k /user/root/lagou # 限制上传空间大小4KB
hdfs dfsadmin -clrSpaceQuota /user/root/lagou # 清除空间限额

8.2 HDFS的安全模式

安全模式是HDFS所处的一种特殊状态,在这种状态下,文件系统只接受读数据请求,而不接受删除、修改等变更请求。在NameNode主节点启动时,HDFS首先进入安全模式,DataNode在启动的时候会向NameNode汇报可用的block等状态,当整个系统达到安全标准时,HDFS自动离开安全模式。如果HDFS出于安全模式下,则文件block不能进行任何的副本复制操作,因此达到最小的副本数量要求是基于DataNode启动时的状态来判定的,启动时不会再做任何复制(从而达到最小副本数量要求),HDFS集群刚启动的时候,默认30S钟的时间是出于安全期的,只有过了30S之后,集群脱离了安全期,然后才可以对集群进行操作。

hdfs dfsadmin -safemode

8.3 Hadoop归档技术

作用:主要解决HDFS集群存在大量小文件的问题。
由于大量小文件会占用NameNode的内存,因此对于HDFS来说存储大量小文件造成NameNode内存资源的浪费!
Hadoop存档文件HAR文件,是一个更高效的文件存档工具,HAR文件是由一组文件通过archive工具创建而来,在减少了NameNode的内存使用的同时,可以对文件进行透明的访问,通俗来说就是HAR文件对NameNode来说是一个文件减少了内存的浪费,对于实际操作处理文件依然是一个一个独立的文件。

  • 案例步骤
## 1. 启动YARN集群
start-yarn.sh
## 2. 归档文件
##把/user/lagou/input目录里面的所有文件归档成一个叫input.har的归档文件,并把归档后文件存储到/user/lagou/output路径下。
bin/hadoop archive -archiveName input.har –p /user/root/input /user/root/output
## 3. 查看归档
hadoop fs -ls -R /user/root/output/input.har
hadoop fs -ls -R har:///user/root/output/input.har
## 4. 解归档文件
hadoop fs -cp har:/// user/root/output/input.har/*/user/root

9 日志采集综合案例

需求分析

  • 定时采集已滚动完毕日志文件(后缀带有数字的文件,即已添加完成不会再有修改的日志文件)
  • 将待采集文件上传到临时目录
  • 备份日志文件
  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值