分布式文件系统(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中,文件块大小不足默认块大小,所占用的实际存储空间就是块大小。


相关文章
|
10天前
|
存储 JSON 数据库
Elasticsearch 分布式架构解析
【9月更文第2天】Elasticsearch 是一个分布式的搜索和分析引擎,以其高可扩展性和实时性著称。它基于 Lucene 开发,但提供了更高级别的抽象,使得开发者能够轻松地构建复杂的搜索应用。本文将深入探讨 Elasticsearch 的分布式存储和检索机制,解释其背后的原理及其优势。
39 5
|
17天前
|
存储 NoSQL 关系型数据库
MPP架构数据仓库使用问题之Visibility bitmap表被删除的文件信息是如何记录的
MPP架构数据仓库使用问题之Visibility bitmap表被删除的文件信息是如何记录的
|
26天前
|
存储 监控 固态存储
【vSAN分布式存储服务器数据恢复】VMware vSphere vSAN 分布式存储虚拟化平台VMDK文件1KB问题数据恢复案例
在一例vSAN分布式存储故障中,因替换故障闪存盘后磁盘组失效,一台采用RAID0策略且未使用置备的虚拟机VMDK文件受损,仅余1KB大小。经分析发现,该VMDK文件与内部虚拟对象关联失效导致。恢复方案包括定位虚拟对象及组件的具体物理位置,解析分配空间,并手动重组RAID0结构以恢复数据。此案例强调了深入理解vSAN分布式存储机制的重要性,以及定制化数据恢复方案的有效性。
51 5
|
29天前
|
存储 NoSQL Java
一天五道Java面试题----第十一天(分布式架构下,Session共享有什么方案--------->分布式事务解决方案)
这篇文章是关于Java面试中的分布式架构问题的笔记,包括分布式架构下的Session共享方案、RPC和RMI的理解、分布式ID生成方案、分布式锁解决方案以及分布式事务解决方案。
一天五道Java面试题----第十一天(分布式架构下,Session共享有什么方案--------->分布式事务解决方案)
|
19天前
|
弹性计算 Cloud Native Windows
核心系统转型问题之核心系统需要转型到云原生分布式架构的原因如何解决
核心系统转型问题之核心系统需要转型到云原生分布式架构的原因如何解决
|
19天前
|
存储 分布式计算 Hadoop
【揭秘Hadoop背后的秘密!】HDFS读写流程大曝光:从理论到实践,带你深入了解Hadoop分布式文件系统!
【8月更文挑战第24天】Hadoop分布式文件系统(HDFS)是Hadoop生态系统的关键组件,专为大规模数据集提供高效率存储及访问。本文深入解析HDFS数据读写流程并附带示例代码。HDFS采用NameNode和DataNode架构,前者负责元数据管理,后者承担数据块存储任务。文章通过Java示例演示了如何利用Hadoop API实现数据的写入与读取,有助于理解HDFS的工作原理及其在大数据处理中的应用价值。
37 1
|
24天前
|
机器学习/深度学习 分布式计算 Cloud Native
云原生架构下的高性能计算解决方案:利用分布式计算资源加速机器学习训练
【8月更文第19天】随着大数据和人工智能技术的发展,机器学习模型的训练数据量和复杂度都在迅速增长。传统的单机训练方式已经无法满足日益增长的计算需求。云原生架构为高性能计算提供了新的可能性,通过利用分布式计算资源,可以在短时间内完成大规模数据集的训练任务。本文将探讨如何在云原生环境下搭建高性能计算平台,并展示如何使用 PyTorch 和 TensorFlow 这样的流行框架进行分布式训练。
43 2
|
24天前
|
监控 Java 开发者
随着软件开发的发展,传统单体应用已难以适应现代业务需求,微服务架构因此兴起,成为构建可伸缩、分布式系统的主流
随着软件开发的发展,传统单体应用已难以适应现代业务需求,微服务架构因此兴起,成为构建可伸缩、分布式系统的主流。本文探讨Java微服务架构的设计原则与实践。核心思想是将应用拆分为独立服务单元,增强模块化与扩展性。Java开发者可利用Spring Boot等框架简化开发流程。设计时需遵循单一职责、自治性和面向接口编程的原则。以电商系统为例,将订单处理、商品管理和用户认证等拆分为独立服务,提高可维护性和容错能力。还需考虑服务间通信、数据一致性及监控等高级话题。掌握这些原则和工具,开发者能构建高效、可维护的微服务应用,更好地应对未来挑战。
63 1
|
30天前
|
存储 缓存 分布式计算
|
11天前
|
Java 数据库连接 微服务
揭秘微服务架构下的数据魔方:Hibernate如何玩转分布式持久化,实现秒级响应的秘密武器?
【8月更文挑战第31天】微服务架构通过将系统拆分成独立服务,提升了可维护性和扩展性,但也带来了数据一致性和事务管理等挑战。Hibernate 作为强大的 ORM 工具,在微服务中发挥关键作用,通过二级缓存和分布式事务支持,简化了对象关系映射,并提供了有效的持久化策略。其二级缓存机制减少数据库访问,提升性能;支持 JTA 保证跨服务事务一致性;乐观锁机制解决并发数据冲突。合理配置 Hibernate 可助力构建高效稳定的分布式系统。
24 0