分布式文件系统设计，hdfs的副本机制，hdfs的block块，hdfs的元数据信息，hdfs的文件上传，hdfs的文件读取，分布式文件系统的JavaAPI操作

最新推荐文章于 2022-05-29 09:34:57 发布

smalllllerr

最新推荐文章于 2022-05-29 09:34:57 发布

阅读量692

点赞数

分类专栏：学习笔记

本文链接：https://blog.csdn.net/Tracy19970428/article/details/106451051

版权

分布式文件系统设计，hdfs的副本机制，hdfs的block块，hdfs的元数据信息，hdfs的文件上传，hdfs的文件读取，分布式文件系统的JavaAPI操作

分布式文件系统的设计

分布式文件系统介绍

在hadoop当中，分布式文件系统（HDFS），对文件系统有一个抽象，HDFS属于当中的一个实现类，也就是说分布式文件系统类似于一个接口，定义了标准，下面有很多的实现类，其中HDFS是一个子实现类。其中，常见的实现类有：LOCAL、HDFS、HFTP等
在这里插入图片描述

HDFS分布式文件系统设计目标

1、硬件错误由于集群很多时候由数量众多的廉价机组成，使得硬件错误成为常态
2、数据流访问所有应用以流的方式访问数据，设置之初便是为了用于批量的处理数据，而不是低延时的实时交互处理
3、大数据集典型的HDFS集群上面的一个文件是以G或者T数量级的，支持一个集群当中的文件数量达到千万数量级
4、简单的相关模型假定文件是一次写入，多次读取的操作
5、移动计算比移动数据便宜一个应用请求的计算，离它操作的数据越近，就越高效
6、多种软硬件的可移植性

HDFS的来源

HDFS起源于Google的GFS论文（GFS，Mapreduce，BigTable为google的旧的三驾马车）
发表于2003年10月
HDFS是GFS的克隆版
Hadoop Distributed File system
易于扩展的分布式文件系统
运行在大量普通廉价机器上，提供容错机制
为大量用户提供性能不错的文件存取服务

HDFS的架构图之基础架构

在这里插入图片描述
1、NameNode是一个中心服务器，单一节点（简化系统的设计和实现），负责管理文件系统的名字空间（namespace）以及客户端对文件的访问
2、文件操作，namenode是负责文件元数据的操作，datanode负责处理文件内容的读写，跟文件内容相关的数据流不经过Namenode，只询问它跟哪个dataNode联系，否则NameNode会成为系统的瓶颈
3、副本存放在哪些Datanode上由NameNode来控制，根据全局情况作出块放置决定，读取文件时NameNode尽量让用户先读取最近的副本，降低读取网络开销和读取延时
NameNode全权管理数据的复制，它周期性的从集群中的每个DataNode接收心跳信息和状态报告，接收到心跳信号意味着DataNode节点工作正常，块状态报告包含了一个该DataNode上所有的数据列表

NameNode与Datanode对比

在这里插入图片描述

hdfs的副本机制

在这里插入图片描述

hdfs的block块

所有的文件都是以block块的方式存放在HDFS文件系统当中，在hadoop1当中，文件的block块默认大小是64M，hadoop2当中，文件的block块大小默认是128M，block块的大小可以通过hdfs-site.xml当中的配置文件进行指定

    <property>
        <name>dfs.block.size</name>
        <value>块大小 以字节为单位</value>//只写数值就可以
    </property>

抽象成数据块的好处

1.一个文件有可能大于集群中任意一个磁盘
10T*3/128 = xxx块 2T，2T，2T 文件方式存—–>多个block块，这些block块属于一个文件
2.使用块抽象而不是文件可以简化存储子系统
3.块非常适合用于数据备份进而提供数据容错能力和可用性

块缓存

通常DataNode从磁盘中读取块，但对于访问频繁的文件，其对应的块可能被显示的缓存在DataNode的内存中，以堆外块缓存的形式存在。默认情况下，一个块仅缓存在一个DataNode的内存中，当然可以针对每个文件配置DataNode的数量。作业调度器通过在缓存块的DataNode上运行任务，可以利用块缓存的优势提高读操作的性能。
例如：
连接（join）操作中使用的一个小的查询表就是块缓存的一个很好的候选。
用户或应用通过在缓存池中增加一个cache directive来告诉namenode需要缓存哪些文件及存多久。缓存池（cache pool）是一个拥有管理缓存权限和资源使用的管理性分组。
例如一个文件 130M，会被切分成2个block块，保存在两个block块里面，实际占用磁盘130M空间，而不是占用256M的磁盘空间

hdfs的元数据信息

在这里插入图片描述

元数据存储位置

在hadoop当中，使用此架构的时候，也就是namenode就一个的时候，所有的元数据信息都保存在了FsImage与Eidts文件当中，这两个文件就记录了所有的数据的元数据信息，元数据信息的保存目录配置在了hdfs-site.xml当中

<property>
                <name>dfs.namenode.name.dir</name>
                <value>file:///export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/namenodeDatas</value>
        </property>
<property>
                <name>dfs.namenode.edits.dir</name>
                <value>file:///export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/dfs/nn/edits</value>
  </property>

FSImage与edits详解

FSImage与edits运作机制

客户端对hdfs进行写文件时会首先被记录在edits文件中。
edits修改时元数据也会更新。
每次hdfs更新时edits先更新后客户端才会看到最新信息。
fsimage:是namenode中关于元数据的镜像，一般称为检查点。
一般开始时对namenode的操作都放在edits中，为什么不放在fsimage中呢？
因为fsimage是namenode的完整的镜像，内容很大，如果每次都加载到内存的话生成树状拓扑结构，这是非常耗内存和CPU。
fsimage内容包含了namenode管理下的所有datanode中文件及文件block及block所在的datanode的元数据信息。随着edits内容增大，就需要在一定时间点和fsimage合并。

FSimage文件当中的文件信息查看

官方查看文档
http://archive.cloudera.com/cdh5/cdh/5/hadoop-2.6.0-cdh5.14.0/hadoop-project-dist/hadoop-hdfs/HdfsImageViewer.html

使用命令 hdfs oiv

cd  /export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/namenodeDatas/current
hdfs oiv -i fsimage_0000000000000000864 -p XML -o hello.xml

edits当中的文件信息查看

官方查看文档
http://archive.cloudera.com/cdh5/cdh/5/hadoop-2.6.0-cdh5.14.0/hadoop-project-dist/hadoop-hdfs/HdfsEditsViewer.html
查看命令 hdfs oev

cd  /export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/dfs/nn/edits
hdfs oev -i  edits_0000000000000000865-0000000000000000866 -o myedit.xml -p XML

secondarynameNode辅助管理FSImage与Edits文件

①：secnonaryNN通知NameNode切换editlog
②：secondaryNN从NameNode中获得FSImage和editlog(通过http方式)
③：secondaryNN将FSImage载入内存，然后开始合并editlog，合并之后成为新的fsimage
④：secondaryNN将新的fsimage发回给NameNode
⑤：NameNode用新的fsimage替换旧的fsimage
完成合并的是secondarynamenode，会请求namenode停止使用edits,暂时将新写操作放入一个新的文件中（edits.new)。secondarynamenode从namenode中通过http get获得edits，因为要和fsimage合并，所以也是通过http get 的方式把fsimage加载到内存，然后逐一执行具体对文件系统的操作，与fsimage合并，生成新的fsimage，然后把fsimag