读取hdfs文件系统里的文件路径_大数据系列之再识Hadoop文件系统HDFS

本文详细介绍了HDFS,Hadoop的分布式文件系统,包括HDFS的简介、与Hadoop的关系、设计原因、系统架构及其主要组件(Namenode和DataNode)、优缺点。HDFS适合处理大规模数据,支持流式访问,运行在低成本硬件上,但不适合低延迟访问和大量小文件存储。
摘要由CSDN通过智能技术生成
6af47e6d0a51f91a3ddfcddebbd903d6.png

CDA数据分析 出品

在搭建伪分布集群或者搭建分布式集群过程中经常提到HDFS,HDFS到底是什么东东呢?今天我们就给小伙伴们详细介绍一下。

1、 HDFS简介

HDFS(Hadoop Distributed File System)是hadoop项目的核心子项目,是分布式计算中数据存储管理的基础。是基于流数据模式访问和处理超大文件的需求而开发的, 可以运行于廉价的商用服务器上。

它所具有的高容错、 高可靠性、 高可扩展性、 高获得性、 高吞吐率等特征为海量数据提供了不怕故障的存储, 为超大数据集(Large Data Set) 的应用处理带来了很多便利。

HDFS是开源的,存储着Hadoop应用将要处理的数据,类似于普通的Unix和linux文件系统,不同的是它是实现了google的GFS文件系统的思想,是适用于大规模分布式数据处理相关应用的、可扩展的分布式文件系统。

2、 HDFS与Hadoop之间的关系

Hadoop是一个以一种可靠、高效、可伸缩的方式进行处理的,能够对大量数据进行分布式处理的系统框架。

HDFS是hadoop兼容最好的标准级文件系统。

所以可以理解为hadoop是一个框架, HDFS 是Hadoop中的一个部件。

3、 为什么需要HDFS

小量的数据,单机的磁盘是能够很好地处理面对的数据,但当数据量巨大(PB)时,磁盘开始纠结处理我们需要的海量信息。我们无法提升单个磁盘的传输速度, 因为这个技术已经没有空间了• 只能将大任务分解成小任务 , 一块磁盘分解成多个磁盘。• 对多个磁盘上的文件进行管理, 就是分布式文件管理系统—HDFS

379062b17eba87e32254ba7438e5465f.png

4、 HDFS系统架构 及主要组件

在之前分步启动Hadoop集群时大家应该注意到了,集群中与HDFS相关的进程有两类,分别是namenode与datanode。HDFS是一个主从架构的系统,其中namenode作为主节点管理着多个从工点datanode。其架构图如下所示:

811781a04acf1f491dea1c85f4cb5ce5.png

Namenode:

管理维护着文件系统树以及整个文件树内所有的文件和目录即文件系统的元数据; 控制客户端对文件的访问; 它还执行文件系统操作, 如重命名,关闭和打开文件/目录。DateNode:

管理所存储的数据;按照客户端的请求, 执行在文件系统上的读写操作;还根据NameNode的指令执行操作如block的创建、 删除和备份。

Block

通常用户的数据存储在HDFS上的文件中;该文件将被拆分为一个或多个片段, 并存储在单个的数据节点;这些文件片段称为blocks。 换句话说, HDFS可读写的最小数据量叫做Block。 默认的block大小是64MB/128M(可根据配置增加)。

Rack

安装集群计算机的机架,一个机架可以安装几台计算机,在整个Hadoop集群中又会有几个这样的机架组成。

5、 HDFS的优缺点

优点:

1) 处理超大文件

这里的超大文件通常是指百MB、设置数百TB大小的文件。目前在实际应用中,HDFS已经能用来存储管理PB级的数据了。

2) 流式的访问数据

HDFS的设计建立在更多地响应"一次写入、 多次读写"任务的基础上。这意味着一个数据集一旦由数据源生成, 就会被复制分发到不同的存储节点中, 然后响应各种各样的数据分析任务请求。 在多数情况下,分析任务都会涉及数据集中的大部分数据, 也就是说, 对HDFS来说,请求读取整个数据集要比读取一条记录更加高效。

3) 运行于廉价的商用集群上(硬件故障是常态)

Hadoop设计对硬件需求比较低, 只须运行在低廉的商用硬件集群上,而无需昂贵的高可用性机器上。 廉价的商用机也就意味着大型集群中出现节点故障情况的概率非常高。 这就要求设计HDFS时要充分考虑数据的可靠性, 安全性及高可用性。

缺点:

1) 不适合低延迟数据访问

如果要处理一些用户要求时间比较短的低延迟应用请求,则HDFS不适合。 HDFS是为了处理大型数据集分析任务的,主要是为达到高的数据吞吐量而设计的,这就可能要求以高延迟作为代价。

改进策略:对于那些有低延时要求的应用程序,HBase是一个更好的选择。

2) 无法高效存储大量小文件

因为Namenode把文件系统的元数据放置在内存中, 所以文件系统所能容纳的文件数目是由Namenode的内存大小来决定。 一般来说, 每一个文件、 文件夹和Block需要占据150字节左右的空间, 所以, 如果你有100万个文件, 每一个占据一个Block, 你就至少需要300MB内存。 当前来说, 数百万的文件还是可行的, 当扩展到数十亿时,对于当前的硬件水平来说就没法实现了。

改进策略: 利用SequenceFile、 MapFile、 Har等方式归档小文件, 这个方法的原理就是把小文件归档起来管理, HBase就是基于此的。 对于这种方法, 如果想找回原来的小文件内容, 那就必须得知道与归档文件的映射关系。 横向扩展, 一个Hadoop集群能管理的小文件有限, 那就把几个Hadoop集群拖在一个虚拟服务器后面, 形成一个大的Hadoop集群。 google也是这么干过的。

多Master设计, 这个作用显而易见了。 正在研发中的GFS II也要改为分布式多Master设计, 还支持Master的Failover, 而且Block大小改为1M, 有意要调优处理小文件啊。

3)不支持多用户写入及任意修改文件

在HDFS的一个文件中只有一个写入者, 而且写操作只能在文件末尾完成, 即只能执行追加操作。 目前HDFS还不支持多个用户对同一文件的写操作, 以及在文件任意位置进行修改。

659548a4a77cfcd572446931e9d2ef9c.png

更多优质内容及精彩资讯,点击【了解更多】进入!

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值