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


相关文章
|
3月前
|
监控 Java API
Spring Boot 3.2 结合 Spring Cloud 微服务架构实操指南 现代分布式应用系统构建实战教程
Spring Boot 3.2 + Spring Cloud 2023.0 微服务架构实践摘要 本文基于Spring Boot 3.2.5和Spring Cloud 2023.0.1最新稳定版本,演示现代微服务架构的构建过程。主要内容包括: 技术栈选择:采用Spring Cloud Netflix Eureka 4.1.0作为服务注册中心,Resilience4j 2.1.0替代Hystrix实现熔断机制,配合OpenFeign和Gateway等组件。 核心实操步骤: 搭建Eureka注册中心服务 构建商品
638 3
|
4月前
|
人工智能 Kubernetes 数据可视化
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
本文回顾了一次关键词监测任务在容器集群中失效的全过程,分析了中转IP复用、调度节奏和异常处理等隐性风险,并提出通过解耦架构、动态IP分发和行为模拟优化采集策略,最终实现稳定高效的数据抓取与分析。
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
|
1月前
|
缓存 Cloud Native 中间件
《聊聊分布式》从单体到分布式:电商系统架构演进之路
本文系统阐述了电商平台从单体到分布式架构的演进历程,剖析了单体架构的局限性与分布式架构的优势,结合淘宝、京东等真实案例,深入探讨了服务拆分、数据库分片、中间件体系等关键技术实践,并总结了渐进式迁移策略与核心经验,为大型应用架构升级提供了全面参考。
|
8月前
|
XML 存储 分布式计算
【赵渝强老师】史上最详细:Hadoop HDFS的体系架构
HDFS(Hadoop分布式文件系统)由三个核心组件构成:NameNode、DataNode和SecondaryNameNode。NameNode负责管理文件系统的命名空间和客户端请求,维护元数据文件fsimage和edits;DataNode存储实际的数据块,默认大小为128MB;SecondaryNameNode定期合并edits日志到fsimage中,但不作为NameNode的热备份。通过这些组件的协同工作,HDFS实现了高效、可靠的大规模数据存储与管理。
863 70
|
1月前
|
存储 NoSQL 前端开发
【赵渝强老师】MongoDB的分布式存储架构
MongoDB分片通过将数据分布到多台服务器,实现海量数据的高效存储与读写。其架构包含路由、配置服务器和分片服务器,支持水平扩展,结合复制集保障高可用性,适用于大规模生产环境。
248 1
|
2月前
|
消息中间件 缓存 监控
中间件架构设计与实践:构建高性能分布式系统的核心基石
摘要 本文系统探讨了中间件技术及其在分布式系统中的核心价值。作者首先定义了中间件作为连接系统组件的"神经网络",强调其在数据传输、系统稳定性和扩展性中的关键作用。随后详细分类了中间件体系,包括通信中间件(如RabbitMQ/Kafka)、数据中间件(如Redis/MyCAT)等类型。文章重点剖析了消息中间件的实现机制,通过Spring Boot代码示例展示了消息生产者的完整实现,涵盖消息ID生成、持久化、批量发送及重试机制等关键技术点。最后,作者指出中间件架构设计对系统性能的决定性影响,
|
7月前
|
人工智能 安全 Java
智慧工地源码,Java语言开发,微服务架构,支持分布式和集群部署,多端覆盖
智慧工地是“互联网+建筑工地”的创新模式,基于物联网、移动互联网、BIM、大数据、人工智能等技术,实现对施工现场人员、设备、材料、安全等环节的智能化管理。其解决方案涵盖数据大屏、移动APP和PC管理端,采用高性能Java微服务架构,支持分布式与集群部署,结合Redis、消息队列等技术确保系统稳定高效。通过大数据驱动决策、物联网实时监测预警及AI智能视频监控,消除数据孤岛,提升项目可控性与安全性。智慧工地提供专家级远程管理服务,助力施工质量和安全管理升级,同时依托可扩展平台、多端应用和丰富设备接口,满足多样化需求,推动建筑行业数字化转型。
267 5
|
5月前
|
监控 算法 关系型数据库
分布式事务难题终结:Seata+DRDS全局事务一致性架构设计
在分布式系统中,CAP定理限制了可用性、一致性与分区容错的三者兼得,尤其在网络分区时需做出取舍。为应对这一挑战,最终一致性方案成为常见选择。以电商订单系统为例,微服务化后,原本的本地事务演变为跨数据库的分布式事务,暴露出全局锁失效、事务边界模糊及协议差异等问题。本文深入探讨了基于 Seata 与 DRDS 的分布式事务解决方案,涵盖 AT 模式实践、分片策略优化、典型问题处理、性能调优及高级特性实现,结合实际业务场景提供可落地的技术路径与架构设计原则。通过压测验证,该方案在事务延迟、TPS 及失败率等方面均取得显著优化效果。
323 61
|
6月前
|
监控 Linux 应用服务中间件
Linux多节点多硬盘部署MinIO:分布式MinIO集群部署指南搭建高可用架构实践
通过以上步骤,已成功基于已有的 MinIO 服务,扩展为一个 MinIO 集群。该集群具有高可用性和容错性,适合生产环境使用。如果有任何问题,请检查日志或参考MinIO 官方文档。作者联系方式vx:2743642415。
2122 57
|
10月前
|
存储 缓存 NoSQL
分布式系统架构8:分布式缓存
本文介绍了分布式缓存的理论知识及Redis集群的应用,探讨了AP与CP的区别,Redis作为AP系统具备高性能和高可用性但不保证强一致性。文章还讲解了透明多级缓存(TMC)的概念及其优缺点,并详细分析了memcached和Redis的分布式实现方案。此外,针对缓存穿透、击穿、雪崩和污染等常见问题提供了应对策略,强调了Cache Aside模式在解决数据一致性方面的作用。最后指出,面试中关于缓存的问题多围绕Redis展开,建议深入学习相关知识点。
690 8

热门文章

最新文章