分布式文件系统(HDFS产生背景及定义 HDFS优缺点 HDFS体系架构 HDFS文件块大小)

简介: 分布式文件系统(HDFS产生背景及定义 HDFS优缺点 HDFS体系架构 HDFS文件块大小)

HDFS概述

HDFS产生背景及定义

分布式文件系统(Distributed File System,DFS)是指文件系统管理的物理存储资源不一定直接连 接在本地节点上,而是通过计算机网络与节点(可简单的理解为一台计算机)相连;或是若干不同的逻 辑磁盘分区或卷标组合在一起而形成的完整的有层次的文件系统。DFS为分布在网络上任意位置的资源 提供一个逻辑上的树形文件系统结构,从而使用户访问分布在网络上的共享文件更加简便。单独的 DFS 共享文件夹的作用是相对于通过网络上的其他共享文件夹的访问点。


计算机通过文件系统管理、存储数据,而信息爆炸时代中人们可以获取的数据成指数倍的增长,单纯通 过增加硬盘个数来扩展计算机文件系统的存储容量的方式,在容量大小、容量增长速度、数据备份、数 据安全等方面的表现都差强人意。分布式文件系统可以有效解决数据的存储和管理难题:将固定于某个地点的某个文件系统,扩展到任意多个地点/多个文件系统,众多的节点组成一个文件系统网络。每个节点可以分布在不同的地点,通过网络进行节点间的通信和数据传输。人们在使用分布式文件系统时, 无需关心数据是存储在哪个节点上、或者是从哪个节点从获取的,只需要像使用本地文件系统一样管理和存储文件系统中的数据。分布式文件系统是建立在客户机/服务器技术基础之上的,一个或多个文件服务器与客户机文件系统协同操作,这样客户机就能够访问由服务器管理的文件。


分布式文件系统把大量数据分散到不同的节点上存储,大大减小了数据丢失的风险。分布式文件系统具有冗余性,部分节点的故障并不影响整体的正常运行,而且即使出现故障的计算机存储的数据已经损坏,也可以由其它节点将损坏的数据恢复出来。因此,安全性是分布式文件系统最主要的特征。分布式文件系统通过网络将大量零散的计算机连接在一起,形成一个巨大的计算机集群,使各主机均可以充分发挥其价值。此外,集群之外的计算机只需要经过简单的配置就可以加入到分布式文件系统中,具有极 强的可扩展能力。


Hadoop分布式文件系统(HDFS)是指被设计成适合运行在通用硬件(commodity hardware)上的 分布式文件系统(Distributed File System)。它和现有的分布式文件系统有很多共同点。但同时, 它和其他的分布式文件系统的区别也是很明显的。HDFS是一个高度容错性的系统,适合部署在廉价的机器上。HDFS能提供高吞吐量的数据访问,非常适合大规模数据集上的应用。HDFS放宽了一部分 POSIX约束,来实现流式读取文件系统数据的目的。HDFS在最开始是作为Apache Nutch搜索引擎项目 的基础架构而开发的。HDFS是Apache Hadoop Core项目的一部分。


HDFS的使用场景:适合一经写入,多次读出的场景,且不支持文件的修改。适合用来做数据分析,并 不适合用来做网盘应用。


HDFS优缺点

HDFS优点:

1、高容错性

数据自动保存多个副本。它通过增加副本的形式,提高容错性。 某一个副本丢失以后,它可以自动恢复,这是由 HDFS 内部机制实现的。


2、适合批处理

它是通过移动计算而不是移动数据。


移动数据:从各个只能存的节点上把数据取出来,传输到可以计算的节点上,这是非常消耗机器性能、带宽、时间等等


移动计算:给每个节点装上CPU,内存。然后把计算的逻辑(就是我们写的程序)下发到各个节点上, 让每个节点自己进行计算,这就是移动计算。它会把数据位置暴露给计算框架。


3、适合大数据处理

处理数据达到 GB、TB、甚至PB级别的数据。 能够处理百万规模以上的文件数量,数量相当之大。 能够处理10K节点的规模。


4、流式文件访问

一次写入,多次读取。文件一旦写入不能修改,只能追加。 它能保证数据的一致性。


5、可构建在廉价机器上

它通过多副本机制,提高可靠性。 它提供了容错和恢复机制。比如某一个副本丢失,可以通过其它副本来恢复。


HDFS劣势:

1、低延时数据访问

比如毫秒级的来存储数据,它做不到。 它适合高吞吐率的场景,就是在某一时间内写入大量的数据。


2、小文件存储

存储大量小文件(这里的小文件是指小于HDFS系统的Block大小的文件(默认64M))的话,它会占用 NameNode大量的内存来存储文件、目录和块信息。这样是不可取的,因为NameNode的内存总是有 限的。 小文件存储的寻道时间会超过读取时间,它违反了HDFS的设计目标。


3、并发写入、文件随机修改

一个文件只能有一个写,不允许多个线程同时写。 仅支持数据 append(追加),不支持文件的随机修改。


体系架构

894d8ed7686b4581ba6c3460e609ca5a.png


HDFS具有主/从架构。所谓主从架构,通俗的讲就是主节点管理从节点,指挥从节点完成工作,从节点 向主节点报告工作状态。HDFS集群由单个NameNode,和多个datanode构成。

1. namenode:主/从架构中的主。

   主要职责:


       (1) 管理HDFS的名称空间;


       (2) 配置副本策略;


       (3) 管理数据块映射信息;


       (4) 处理客户端读写请求。


2. datanode:是主/从架构中的从。

   它的职责是:


       (1) 存储实际的数据块;


       (2) 执行数据块的读/写操作。


3. clinet:客户端。

       (1) 文件切分。文件上传HDFS的时候,由客户端切分成一个一个的块,然后上传;


       (2) 与namenode交互,获取文件的位置信息;


       (3) 与datanode交互,读取或者写入数据;


       (4) 客户端提供一些命令来管理HDFS,比如namenode格式化;


       (5) 客户端可以通过一些命令来访问HDFS,比如文件的上传,查看,复制,移动等操作。


4. secondary namenode:次级namenode

       (1) 辅助namenode,分担其工作量,比如定期合并FSimage和Edits,推送给namenode;


       (2) 在紧急情况下,可辅助恢复namenode。但是它不是namenode的备份。


合并过程


1. edits文件记录了客户端对HDFS所做的各种更新操作,客户端所有的写操作都被记录在了此 文件中。 而fsimage文件记录了元数据的文件,这个文件不是实时的,通俗来说,更像是对HDFS的一 个快照,它记录了某个时刻下的HDFS的状态信息。


2. 触发这两个文件合并的条件


       HDFS的重新启动


       edits文件达到指定的大小(默认64M,可更改)


       设置了指定时间促使两文件合并(默认3600s,可更改)



318f85e150f04556b2b6d4e5d29fb918.png

SecondaryNameNode不是NameNode的热备,但也能起到一定的备份作用,这就说 明在一定情况下可能会产生数据丢失情况,所以在Hadoop2.0完全分布式中,抛弃了 SecondaryNameNode,采用了双NameNode机制来进行热备


edits文件和fsimage文件的合并发生在SecondaryNameNode上是因为这两个文件 比较合并耗时,如果在NameNode上合并可能会导致系统卡顿,所以在 SecondaryNameNode上进行

HDFS文件块大小

磁盘上存储数据的最小单位是扇区,扇区的大小为512字节(新的硬盘也有4KB)。


单一磁盘上的文件系统,以块为其读写数据的基本单位,提高读写效率。如果一个块的大小为4K,则该 文件系统中1个块是由连续的8个扇区组成。


在HDFS中,文件被划分成大小相等的数据块(Block),这些数据块被分布存储在文件系统的不同节点 上。块的大小可以通过配置参数(dfs.blocksize)来规定,默认大小在Hadoop2.x版本中是128M,老 版本中是64M。


为什么设计成块存储?


1、因为一个文件可以特别大,可以大于有个磁盘的容量,所以以块的形式存储,可以用来存储无论大小怎样的文件。


2、简化存储系统的设计。因为块是固定的大小,计算磁盘的存储能力就容易多了


3、以块的形式存储不需要全部存在一个磁盘上,可以分布在各个文件系统的磁盘上,有利于复制和容 错,数据本地化计算


· HDFS块不能设置的太小


HDFS的块设置太小,会增加文件的寻址时间。从文件系统的设计角度看,文件的传输速度往往是 不能控制的,能把控的是如何优化设计来提高文件的寻址时间。增大文件块,从而减少文件块文件 的总块数,从而减少块的寻址次数,提高寻址效率。让寻址时间要远远小于数据的传输时间。


· HDFS块不能设置的太大


块设置的太大会影响数据读写的效率;


块设置的太大会影响数据处理的效率。


注意:在HDFS中,文件块大小不足默认块大小,所占用的实际存储空间就是块大小。


目录
打赏
0
1
0
0
17
分享
相关文章
【赵渝强老师】史上最详细:Hadoop HDFS的体系架构
HDFS(Hadoop分布式文件系统)由三个核心组件构成:NameNode、DataNode和SecondaryNameNode。NameNode负责管理文件系统的命名空间和客户端请求,维护元数据文件fsimage和edits;DataNode存储实际的数据块,默认大小为128MB;SecondaryNameNode定期合并edits日志到fsimage中,但不作为NameNode的热备份。通过这些组件的协同工作,HDFS实现了高效、可靠的大规模数据存储与管理。
350 70
大数据-82 Spark 集群模式启动、集群架构、集群管理器 Spark的HelloWorld + Hadoop + HDFS
大数据-82 Spark 集群模式启动、集群架构、集群管理器 Spark的HelloWorld + Hadoop + HDFS
379 6
Hadoop-08-HDFS集群 基础知识 命令行上机实操 hadoop fs 分布式文件系统 读写原理 读流程与写流程 基本语法上传下载拷贝移动文件
Hadoop-08-HDFS集群 基础知识 命令行上机实操 hadoop fs 分布式文件系统 读写原理 读流程与写流程 基本语法上传下载拷贝移动文件
119 1
Hadoop-07-HDFS集群 基础知识 分布式文件系统 读写原理 读流程与写流程 基本语法上传下载拷贝移动文件
Hadoop-07-HDFS集群 基础知识 分布式文件系统 读写原理 读流程与写流程 基本语法上传下载拷贝移动文件
184 1
【赵渝强老师】基于RBF的HDFS联邦架构
最新版Hadoop实现了基于Router的联盟架构,增强了集群管理能力。Router将挂载表从客户端中分离,解决了ViewFS的问题。RBF架构包括Router和State Store两个模块,其中Router作为代理服务,负责解析ViewFS并转发请求至正确子集群,State Store则维护子集群的状态和挂载表信息。
167 0
【赵渝强老师】基于ViewFS的HDFS联邦架构
本文介绍了HDFS联盟(Federation)的概念及其在大数据存储中的应用。HDFS联盟通过允许多个NameNode管理不同的命名空间,实现了负载均衡和NameNode的水平扩展。文章还详细解释了基于ViewFS的联盟架构,以及该方案的局限性。附带的视频进一步讲解了相关概念。
141 0
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
182 3
云原生时代的应用架构演进:从微服务到 Serverless 的阿里云实践
云原生技术正重塑企业数字化转型路径。阿里云作为亚太领先云服务商,提供完整云原生产品矩阵:容器服务ACK优化启动速度与镜像分发效率;MSE微服务引擎保障高可用性;ASM服务网格降低资源消耗;函数计算FC突破冷启动瓶颈;SAE重新定义PaaS边界;PolarDB数据库实现存储计算分离;DataWorks简化数据湖构建;Flink实时计算助力风控系统。这些技术已在多行业落地,推动效率提升与商业模式创新,助力企业在数字化浪潮中占据先机。
222 12
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####

热门文章

最新文章

AI助理
登录插画

登录以查看您的控制台资源

管理云资源
状态一览
快捷访问

你好,我是AI助理

可以解答问题、推荐解决方案等