【HDFS】HDFS的整体架构设计,阅读笔记

HDFS是一个高度容错性的系统,适合部署在廉价的机器上。

HDFS可能由成百上千的服务器构成,每个服务器上存储着文件系统的部分数据,构成系统的组件数目是巨大的,任一组件都有可能失效,这意味着总是有一部分HDFS的组件是不工作的,所以HDFS的核心架构目标是错误检测和快速、自动的恢复

HDFS上的一个典型文件大小一般都在G字节至T字节

一个单一的HDFS实例应该能支撑数以千万计的文件

HDFS应用需要一个“一次写入多次读取”的文件访问模型。一个文件经过创建、写入和关闭之后就不需要改变。这一假设简化了数据一致性问题,并且使高吞吐量的数据访问成为可能。

一个应用请求的计算,离它操作的数据越近就越高效,在数据达到海量级别的时候更是如此。

HDFS为应用提供了将它们自己移动到数据附近的接口。

架构

HDFS采用主从架构,一个HDFS集群有一个namenode和一定数目的datanode组成。

namenode是一个中心服务器,负责管理文件系统的名字空间(namespace)以及客户端对文件的访问(namenode去映射文件所在datanode)。

集群中的datanode一般是一个节点作为一个datanode,负责管理自己节点上的存储。

一个文件被分成一个或多个数据块,存储在一组datanode上。

namenode负责执行文件系统操作,确定数据块到具体datanode节点的映射。

datanode负责处理文件系统客户端的读写请求,在namenode的统一调度下进行数据块的创建、删除、复制。

HDFS采用JAVA开发,因此任何支持java的机器都可以部署namenode和datanode

集群中单一Namenode的结构大大简化了系统的架构。Namenode是所有HDFS元数据的仲裁者和管理者,这样,用户数据永远不会流过Namenode。

HDFS被设计成能够在一个大集群中跨机器可靠地存储超大文件。它将每个文件存储成一系列的数据块,除了最后一个,所有的数据块都是同样大小的。为了容错,文件的所有数据块都会有副本。每个文件的数据块大小和副本系数都是可配置的。应用程序可以指定某个文件的副本数目。副本系数可以在文件创建的时候指定,也可以在之后改变。HDFS中的文件都是一次性写入的,并且严格要求在任何时候只能有一个写入者。

Namenode全权管理数据块的复制,它周期性地从集群中的每个Datanode接收心跳信号和块状态报告(Blockreport)。接收到心跳信号意味着该Datanode节点工作正常。块状态报告包含了一个该Datanode上所有数据块的列表。

HDFS采用一种称为机架感知(rack-aware)的策略来改进数据的可靠性、可用性和网络带宽的利用率。

通过一个机架感知的过程,Namenode可以确定每个Datanode所属的机架id。一个简单但没有优化的策略就是将副本存放在不同的机架上。这样可以有效防止当整个机架失效时数据的丢失,并且允许读数据的时候充分利用多个机架的带宽。这种策略设置可以将副本均匀分布在集群中,有利于当组件失效情况下的负载均衡。但是,因为这种策略的一个写操作需要传输数据块到多个机架,这增加了写的代价。

在大多数情况下,副本系数是3,HDFS的存放策略是将一个副本存放在本地机架的节点上,一个副本放在同一机架的另一个节点上,最后一个副本放在不同机架的节点上。这种策略减少了机架间的数据传输,这就提高了写操作的效率。机架的错误远远比节点的错误少,所以这个策略不会影响到数据的可靠性和可用性。于此同时,因为数据块只放在两个(不是三个)不同的机架上,所以此策略减少了读取数据时需要的网络传输总带宽。在这种策略下,副本并不是均匀分布在不同的机架上。三分之一的副本在一个节点上,三分之二的副本在一个机架上,其他副本均匀分布在剩下的机架中,这一策略在不损害数据可靠性和读取性能的情况下改进了写的性能。

HDFS会尽量让读取程序读取离它最近的副本

namenode启动后会进入一个安全模式的特殊状态,这时候不会进行块复制,但是会通过块状态报告确认是否安全(数据块副本达到最小值的比例),安全后则退出,后续会确定哪些块副本未达标的将进行块复制。

EditLog事务日志,FsImage文件块映射、文件属性等

namenode在内存中保存映射表,这个数据结构设计紧凑,4G内存的namenode足够支撑大量的文件和目录;

当namenode启动时,从硬盘读取EditLog和FsImage,将所有的EditLog中的事务作用在内存的FsImage上,并将新的FsImage从内存保存到磁盘上,然后删除旧的EditLog,这就是检查点过程。

如果namenode很久都没有启动,那么EditLog是不是慢慢变的越来越大了(因为只有启动才会合并fsimage和edits),下一次启动很慢!!

所以secondary namenode就应运而生了,负责定期合并fsimage和edits,将edits日志大小控制在一个限度下。和namenode在不同机器上

datanode启动时,扫描本地文件系统,产生一个本地文件对应的所有HDFS数据块的列表,将这块状态报告发送给namenode。

FsImage和Editlog是HDFS的核心数据结构。如果这些文件损坏了,整个HDFS实例都将失效。

因而,Namenode可以配置成支持维护多个FsImage和Editlog的副本。任何对FsImage或者Editlog的修改,都将同步到它们的副本上。这种多副本的同步操作可能会降低Namenode每秒处理的名字空间事务数量。然而这个代价是可以接受的,因为即使HDFS的应用是数据密集的,它们也非元数据密集的。当Namenode重启的时候,它会选取最近的完整的FsImage和Editlog来使用。

网络错误的解决,datanode失效??

每个datanode节点周期性的想namenode发送心跳信号。网络断开可能导致一部分datanode和namenode失去联系,namenode通过心跳信号的缺失将此datanode标记为宕机,不会在将新的IO请求发给它们。这进一步导致一些数据块的副本系数下降,namenode会不断检测需要复制的块并启动复制操作。

DFSAdmin

hadoop is deprecated,use hdfs

如何知道谁是admin呢??

启动NameNode的用户被视为HDFS的超级用户

副本系数减小

namenode感知到会将多余的副本删除,下个心跳会将该信息传递给datanode,datanode即将数据块删除,空闲空间加大。

fsck用来检查文件系统

用法:hadoop fsck [GENERIC_OPTIONS]
<path> [-move | -delete | -openforwrite] [-files [-blocks [-locations | -racks]]]

时间: 2024-10-11 12:29:35

【HDFS】HDFS的整体架构设计,阅读笔记的相关文章

【大数据干货】基于Hadoop的大数据平台实施——整体架构设计

大数据的热度在持续的升温,继云计算之后大数据成为又一大众所追捧的新星.我们暂不去讨论大数据到底是否适用于您的公司或组织,至少在互联网上已经被吹嘘成无所不能的超级战舰.大数据的热度在持续的升温,继云计算之后大数据成为又一大众所追捧的新星.我们暂不去讨论大数据到底是否适用于您的公司或组织,至少在互联网上已经被吹嘘成无所不能的超级战舰.好像一夜之间我们就从互联网时代跳跃进了大数据时代!关于到底什么是大数据,说真的,到目前为止就和云计算一样,让我总觉得像是在看电影<云图>--云里雾里的感觉.或许那些正

【项目总结】扯一扯电商网站前端css的整体架构设计(1)

最近半忙不忙的写了一个外包网站,网站主要功能是艺术品竞拍和艺术衍生品的销售.工程已经完成了80%左右,现在前后端代码量已经50W行左右,我主要负责的是前端设计和前端布局.下面就先放一个网站的设计图吧,因为涉及到甲方的"商业机密",所以打一下马赛克: 这篇文章主要算是我对于这个项目的总结或者说是对于这阶段自己看的一些前端书或者经验的一个总结吧,所以设计图就不贴那么多了.整个项目的设计图由最开始的ui定了个首页稿基调,剩下的界面大部分都是我在首页稿基础上做出来的,以后有机会再唠.PS:不过

数道云大数据平台解决方案,Hadoop + HDFS+Hive+Hbase大数据开发整体架构设计

波若大数据平台(BR-odp)Hadoop + HDFS+Hive+Hbase大数据开发工具剖析: HDFS:分布式.高度容错性文件系统,能提供高吞吐量的数据访问,非常适合大规模数据集上的应用,大规模的波若大数据平台(BR-odp)用户部署上1000台的HDFS集群.数据规模高达50PB以上 HDFS和MR共同组成Hadoop分布式系统体系结构的核心.HDFS在集群上实现了分布式文件系统,MR在集群上实现了分布式计算和任务处理.HDFS在MR任务处理过程中提供了文件操作和存储等支持,MR在HDF

架构漫谈阅读笔记

<架构漫谈>读后感 经过一个寒假对<架构之美>的解读,其实我已经对什么是架构有了一个初步的认识,但是还是有一些不太明白的地方.今天,我仔细地阅读了由资深架构师王概凯Kevin执笔的系列专栏--架构漫谈,让我对什么是架构.怎样做好架构.软件架构如何落地.如何写好程序等问题有了更深刻的认识. 正如文章开篇所说的那样:一直以来,在软件行业,对于什么是架构,都有很多的争论,每个人都有自己的理解.那么究竟什么是软件架构呢?其实,把一个整体(完成人类生存的所有工作)切分成不同的部分(分工),由

jQuery 源码解析一:jQuery 类库整体架构设计解析

如果是做 web 的话,相信都非要对 Dom 进行增删查改,那这相信大家都或多或少接触到过 jQuery 类库,其最大特色就是强大的选择器,让开发者脱离原生 JS 一大堆 getElementById.getElementsByName...官方提供超长方法 api . jQuery 整体源码,本人也还在阅读中,暂时记录一下.(为什么要看源码,原因很简单---- 一 好好了解一下 jQuery 原理  二 为了装逼显摆).   一  使用 jQuery 时候,首先需引入 jQuery 文件,而之

面向对象分析与设计阅读笔记二

今天我阅读了面向对象分析与设计的第二章对象模型,从计算机一开始的第一代语言到面向对象编程的演化,经历了很长的演变,同时面向对象的编程也是历史性的演变.那么什么是面向对象的编程呢?面向对象的编程其实是一种实现的方法,在这种方法中,程序组成许多相互协作的对象,每个对象代表一个实例,而类则属于一个通过继承关系形成的层次结构.以前我的认为是:面向对象的编程不就是写一个类,然后用类去创建一个对象,用对象来实现其中的某些功能.现在看来这样的想法有些片面. 每一种编程风格都是基于它自己的概念框架.对于所有面向

面向对象分析与设计阅读笔记一

今天阅读了<面向对象分析与设计>第一章复杂性,从这里我认识到,世界上的任何东西都是复杂的,从我们学习中就可以看出来:计算机的结构.动植物的结构.物质结构和社会机构的结构等等,这里边都蕴含了事物的复杂性.当然我们的软件也有复杂性,软件面临的问题域很复杂:软件的开发过程中常常会涉及到一些不可避免的复杂性,在其中我们可以发现数不清的竞争需求,甚至是相反的需求:其中也避免不了和用户沟通的困难,用户往往表达不完整.管理软件开发的困难性:软件开发团队的基本任务就是制造简单的假象,开发过程中我们会遇到很复杂

扯一扯前端css的整体架构设计:(2)base基础类的那些事儿

周一下午在实验室写了第一篇博文,有几个人捧场,那咱就得接着下去啊.然后我觉得现在写的内容更多的偏向于谈一下我对于前端css架构的理解和前端经验的一个小总结,所以就把标题里原来的[项目总结]给删掉了.但是这不是说以后文章就不提我手里这个半死不活的类电商网站了,还得接着提,要不然拿什么自黑呢~~ [回顾一下上一篇] 上一篇里我主要针对于我最近写的一个项目的前端结构,开始介绍了一些前端结构的一些知识或者说是经验吧. 为什么前端css也有架构,为什么要考虑css的架构,怎么实现css的简单架构,这些问题

支付系统整体设计:整体架构设计以及注意要点(三)

一般来说,银行会提供两种支付途径:无跳转的快捷支付接口和带跳转的网银接口.前者在绑卡,支付的时候,不需要跳到银行页面上去处理,后者则需要在银行的网银页面上完成.显然前者对用户来说体验要好多了,用户流程不会被打断.快捷支付要求支付系统在本地保存用户的支付信息,如卡号,登记手机.系统要确保这些信息不被泄漏.风险非常好,所以大部分银行要求接入方必须经过ADSS检验才能够接入快捷支付. 这种固定方式的接入有单点故障的问题,一旦某个渠道出问题,绑定的支付方式就无法使用.改进策略是为每个支付方式定义多个渠道