大数据系列

上传人:ni****g 文档编号:501631943 上传时间:2022-08-13 格式:DOCX 页数:4 大小:135.90KB
返回 下载 相关 举报
大数据系列_第1页
第1页 / 共4页
大数据系列_第2页
第2页 / 共4页
大数据系列_第3页
第3页 / 共4页
大数据系列_第4页
第4页 / 共4页
亲,该文档总共4页,全部预览完了,如果喜欢就下载吧!
资源描述

《大数据系列》由会员分享,可在线阅读,更多相关《大数据系列(4页珍藏版)》请在金锄头文库上搜索。

1、大数据系列之再识Hadoop文件系统HDFS在搭建伪分布集群或者搭建分布式集群过程中经常提到HDFS,HDFS到底是什么东东呢? 今天我们就给小伙伴们详细介绍一下。1、HDFS 简介HDFS (Hadoop Distributed File System)是hadoop项目的核心子项目,是分布式计算中数 据存储管理的基础。是基于流数据模式访问和处理超大文件的需求而开发的, 可以运行于 廉价的商用服务器上。它所具有的高容错、 高可靠性、 高可扩展性、 高获得性、 高吞吐率等特征为海量数 据提供了不怕故障的存储, 为超大数据集( Large Data Set) 的应用处理带来了很多便利。HDFS

2、是开源的,存储着 Hadoop 应用将要处理的数据,类似于普通的 Unix 和 linux 文件 系统,不同的是它是实现了 google 的 GFS 文件系统的思想,是适用于大规模分布式数据处 理相关应用的、可扩展的分布式文件系统。2、HDFS 与 Hadoop 之间的关系Hadoop 是一个以一种可靠、高效、可伸缩的方式进行处理的,能够对大量数据进行分布 式处理的系统框架。HDFS 是 hadoop 兼容最好的标准级文件系统。所以可以理解为 hadoop 是一个框架, HDFS 是 Hadoop 中的一个部件。3、为什么需要 HDFS小量的数据,单机的磁盘是能够很好地处理面对的数据,但当数据

3、量巨大(PB)时,磁 盘开始纠结处理我们需要的海量信息。我们无法提升单个磁盘的传输速度, 因为这个技术 已经没 有空间了 只能将大任务分解成小任务 , 一块磁盘分解成多个磁盘。对多个磁盘上的文件进行管理,就是分布式文件管理系统一HDFS4、HDFS 系统架构 及主要组件在之前分步启动 Hadoop 集群时大家应该注意到了,集群中与 HDFS 相关的进程有两类, 分别是name node与data node。HDFS是一个主从架构的系统,其中name node作为主节点 管理着多个从工点data node。其架构图如下所示:Client 辩就日曲怙Name,阳pliua気)/foa/dlata

4、39 j -Namenod eMa nodeR1D13 R1D2. R2D1Rack 1Rack ?Data nodeReplicatioDatanodeDatancxjeData nodeNamenode: 管理维护着文件系统树以及整个文件树内所有的文件和目录即文件系统的元数据 控制客户端对文件的访问;它还执行文件系统操作, 如重命名,关闭和打开文件/目录。DateNode:管理所存储的数据;按照客户端的请求, 执行在文件系统上的读写操作; 还根据 NameNode 的指令执行操作如 block 的创建、 删除和备份。Block 通常用户的数据存储在 HDFS 上的文件中; 该文件将被拆分为

5、一个或多个片段, 并存储在单个的数据节点; 这些文件片段称为blocks。换句话说,HDFS可读写的最小数据量 叫做Block。默认的block大小是64MB/128M(可根据配置增加)。Rack安装集群计算机的机架,一个机架可以安装几台计算机,在整个Hadoop集群中又会有几 个这样的机架组成。5、HDFS 的优缺点优点:1)处理超大文件这里的超大文件通常是指百MB、设置数百TB大小的文件。目前在实际应用中,HDFS已 经能用来存储管理PB级的数据了。2)流式的访问数据HDFS的设计建立在更多地响应“一次写入、多次读写”任务的基础上。这意味着一个数 据集一旦由数据源生成,就会被复制分发到不同

6、的存储节点中,然后响应各种各样的数 据分析任务请求。在多数情况下,分析任务都会涉及数据集中的大部分数据,也就是说, 对HDFS来说,请求读取整个数据集要比读取一条记录更加高效。3)运行于廉价的商用集群上(硬件故障是常态)Hadoop设计对硬件需求比较低,只须运行在低廉的商用硬件集群上,而无需昂贵的高可 用性机器上。廉价的商用机也就意味着大型集群中出现节点故障情况的概率非常高。这 就要求设计HDFS时要充分考虑数据的可靠性,安全性及高可用性。缺点:1)不适合低延迟数据访问如果要处理一些用户要求时间比较短的低延迟应用请求,则HDFS不适合。HDFS是为了 处理大型数据集分析任务的,主要是为达到高的

7、数据吞吐量而设计的,这就可能要求以高延 迟作为代价。改进策略:对于那些有低延时要求的应用程序,HBase是一个更好的选择。2)无法高效存储大量小文件因为Namenode把文件系统的元数据放置在内存中,所以文件系统所能容纳的文件数目是 由Namenode的内存大小来决定。一般来说,每一个文件、文件夹和Block需要占据 150字节左右的空间,所以,如果你有100万个文件,每一个占据一个Block,你 就至少需要300MB内存。当前来说,数百万的文件还是可行的,当扩展到数十亿时, 对于当前的硬件水平来说就没法实现了。改进策略:利用SequenceFile、MapFile、Har等方式归档小文件,这

8、个方法的原理就是把小 文件归档起来管理, HBase 就是基于此的。 对于这种方法, 如果想找回原来的小文件 内容, 那就必须得知道与归档文件的映射关系。横向扩展,一个Hadoop集群能管理的小文件有限,那就把几个Hadoop集群拖在一 个虚拟服务器后面,形成一个大的Hadoop集群。google也是这么干过的。多Mas ter设计,这个作用显而易见了。正在研发中的GFS II也要改为分布式多Mast er设计,还支持Mas ter的Fail over,而且Block大小改为1M,有意要调优处理 小文件啊。3) 不支持多用户写入及任意修改文件 在 HDFS 的一个文件中只有一个写入者, 而且写操作只能在文件末尾完成, 即只能执 行追加操作。目前 HDFS 还不支持多个用户对同一文件的写操作, 以及在文件任意位置进行修改。

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 学术论文 > 其它学术论文

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号