×

HDFS分布式文件系统简介

2021年大数据Hadoop(七):HDFS分布式文件系统简介

Lanson Lanson 发表于2021-07-26 19:01:46 浏览302 评论0

抢沙发发表评论

HDFS分布式文件系统简介


一、HDFS概述

在现代的企业环境中,单机容量往往无法存储大量数据,需要跨机器存储。统一管理分布在集群上的文件系统称为分布式文件系统 。

1 (2).png

HDFS(Hadoop Distributed File System)是 Apache Hadoop 项目的一个子项目. Hadoop 非常适于存储大型数据 (比如 TB 和 PB), 其就是使用 HDFS 作为存储系统. HDFS 使用多台计算机存储文件, 并且提供统一的访问接口, 像是访问一个普通文件系统一样使用分布式文件系统.

   分布式文件系统解决的问题就是大数据存储。它们是横跨在多台计算机上的存储系统。分布式文件系统在大数据时代有着广泛的应用前景,它们为存储和处理超大规模数据提供所需的扩展能力。


二、HDFS发展历史

  • Doug Cutting 在做 Lucene 的时候, 需要编写一个爬虫服务, 这个爬虫写的并不顺利, 遇到 了一些问题, 诸如: 如何存储大规模的数据, 如何保证集群的可伸缩性, 如何动态容错等。

  • 2013年的时候, Google 发布了三篇论文, 被称作为三驾马车, 其中有一篇叫做 GFS, 是描述了 Google 内部的一个叫做 GFS 的分布式大规模文件系统, 具有强大的可伸缩性和容错。

  • Doug Cutting 后来根据 GFS 的论文, 创造了一个新的文件系统, 叫做 HDFS。

三、HDFS设计目标

1、硬件故障是常态, HDFS将有成百上千的服务器组成,每一个组成部分都有可能出现故障。因此故障的检测和自动快速恢复是HDFS的核心架构目标。

2、HDFS上的应用与一般的应用不同,HDFS被设计成适合批量处理,而不是用户交互式的。相较于数据访问的反应时间,更注重数据访问的高吞吐量。

3、典型的HDFS文件大小是GB到TB的级别。所以,HDFS被调整成支持大文件。它应该提供很高的聚合数据带宽,一个集群中支持数百个节点,一个集群中还应该支持千万级别的文件。

4、大部分HDFS应用对文件要求的是write-one-read-many访问模型。一个文件一旦创建、写入、关闭之后就不需要修改了。这一假设简化了数据一致性问题,使高吞吐量的数据访问成为可能。

5、移动计算的代价比之移动数据的代价低。一个应用请求的计算,离它操作的数据越近就越高效,这在数据达到海量级别的时候更是如此。将计算移动到数据附近,比之将数据移动到应用所在显然更好。

6、在异构的硬件和软件平台上的可移植性。这将推动需要大数据集的应用更广泛地采用HDFS作为平台。



四、HDFS应用场景

适合的应用场景

  • 存储非常大的文件:这里非常大指的是几百M、G、或者TB级别,需要高吞吐量,对延时没有要求

  • 采用流式的数据访问方式: 即一次写入、多次读取,数据集经常从数据源生成或者拷贝一次,然后在其上做很多分析工作 ,且不支持文件的随机修改。

  • 正因为如此,HDFS适合用来做大数据分析的底层存储服务,并不适合用来做.网盘等应用,因为,修改不方便,延迟大,网络开销大,成本太高。

  • 运行于商业硬件上: Hadoop不需要特别贵的机器,可运行于普通廉价机器,可以处节约成本

  • 需要高容错性 

  • 为数据存储提供所需的扩展能力

不适合的应用场景

  • 低延时的数据访问 对延时要求在毫秒级别的应用,不适合采用HDFS。HDFS是为高吞吐数据传输设计的,因此可能牺牲延时

  • 大量小文件 文件的元数据保存在NameNode的内存中, 整个文件系统的文件数量会受限于NameNode的内存大小。 经验而言,一个文件/目录/文件块一般占有150字节的元数据内存空间。如果有100万个文件,每个文件占用1个文件块,则需要大约300M的内存。因此十亿级别的文件数量在现有商用机器上难以支持。

  • 多方读写,需要任意的文件修改 HDFS采用追加(append-only)的方式写入数据。不支持文件任意offset的修改HDFS适合用来做大数据分析的底层存储服务,并不适合用来做.网盘等应用,因为,修改不方便,延迟大,网络开销大,成本太高。


五、HDFS的架构

HDFS采用Master/Slave架构,一个HDFS集群有两个重要的角色,分别是Namenode和Datanode。Namenode是管理节点,负责管理文件系统的命名空间(namespace)以及客户端对文件的访问。Datanode是实际存储数据的节点。HDFS暴露了文件系统的命名空间,用户能够以操作文件的形式在上面操作数据。

HDFS的四个基本组件:HDFS ClientNameNodeDataNodeSecondary NameNode


 1、Client:就是客户端。

  • 文件切分。文件上传 HDFS 的时候,Client 将文件切分成 一个一个的Block,然后进行存储

  • 与 NameNode 交互,获取文件的位置信息。

  • 与 DataNode 交互,读取或者写入数据。

  • Client 提供一些命令来管理 和访问HDFS,比如启动或者关闭HDFS。

2、NameNode:就是 master,它是一个主管、管理者。

  • 管理 HDFS 的名称空间

  • 管理数据块(Block)映射信息

  • 配置副本策略

  • 处理客户端读写请求。

3、DataNode:就是Slave。NameNode 下达命令,DataNode 执行实际的操作。

  • 存储实际的数据块。

  • 执行数据块的读/写操作。

  • 定时向namenode汇报block信息

4、Secondary NameNode:并非 NameNode 的热备。当NameNode 挂掉的时候,它并不能马上替换 NameNode 并提供服务。

  • 辅助 NameNode,分担其工作量。

  • 定期合并 fsimage和fsedits,并推送给NameNode。

  • 在紧急情况下,可辅助恢复 NameNode。


六、HDFS的副本机制

HDFS文件副本机制

HDFS被设计成能够在一个大集群中跨机器可靠地存储超大文件。它将每个文件存储成一系列的数据块,这个数据块被称为block,除了最后一个,所有的数据块都是同样大小的。

为了容错,文件的所有block都会有副本。每个文件的数据块大小和副本系数都是可配置的。

所有的文件都是以 block 块的方式存放在 HDFS 文件系统当中,作用如下

1、一个文件有可能大于集群中任意一个磁盘,引入块机制,可以很好的解决这个问题

2、使用块作为文件存储的逻辑单位可以简化存储子系统

3、块非常适合用于数据备份进而提供数据容错能力

4、副本优点是安全,缺点是占空间。

在 Hadoop1 当中, 文件的 block 块默认大小是 64M, hadoop2 当中, 文件的 block 块大小默认是 128M(134217728字节)。假设文件大小是100GB,从字节位置0开始,每128MB字节划分为一个block,依此类推,可以划分出很多的block。每个block就是128MB大小。

block块的大小可以通过 hdfs-site.xml 当中的配置文件进行指定,Hadoop默认的副本数为3,也就是每个block会存三份。

<property>

   <name>dfs.block.size</name>

   <value>块大小以字节为单位</value>

</property>

注意当一个文件的大小不足128M时,比如文件大小为2M,那么这个文件也占用一个block,但是这个block实际只占2M的空间,所以从某种意义上来讲,block只是一个逻辑单位。



HDFS副本放置策略(机架感知)

HDFS分布式文件系统的内部有一个副本存放策略,默认副本数为3,在这里以副本数=3为例:

第一副本:优先放置到离写入客户端最近的DataNode节点,如果上传节点就是DataNode,则直接上传到该节点,如果是集群外提交,则随机挑选一台磁盘不太满,CPU不太忙的节点。

第二个副本:放置在于第一个副本不同的机架的节点上(随机选择)

第三个副本:与第二个副本相同机架的不同节点中。


  • 📢博客主页:https://lansonli.blog.csdn.net

  • 📢欢迎点赞 👍 收藏 ⭐留言 📝 如有错误敬请指正!

  • 📢本文由 Lansonli 原创,首发于 CSDN博客🙉

  • 📢大数据系列文章会每天更新,停下休息的时候不要忘了别人还在奔跑,希望大家抓紧时间学习,全力奔赴更美好的生活✨


欢迎留言

访客