重庆分公司,新征程启航
为企业提供网站建设、域名注册、服务器等服务
Hadoop
专注于为中小企业提供网站制作、成都网站建设服务,电脑端+手机端+微信端的三站合一,更高效的管理,为中小企业卢氏免费做网站提供优质的服务。我们立足成都,凝聚了一批互联网行业人才,有力地推动了1000+企业的稳健成长,帮助中小企业通过网站建设实现规模扩充和转变。
文件系统:文件系统是用来存储和管理文件,并且提供文件的查询、增加、删除等操作。
直观上的体验:在shell窗口输入 ls 命令,就可以看到当前目录下的文件夹、文件。
文件存储在哪里?硬盘
一台只有250G硬盘的电脑,如果需要存储500G的文件可以怎么办?先将电脑硬盘扩容至少250G,再将文件分割成多块,放到多块硬盘上储存。
通过 hdfs dfs -ls 命令可以查看分布式文件系统中的文件,就像本地的ls命令一样。
HDFS在客户端上提供了查询、新增和删除的指令,可以实现将分布在多台机器上的文件系统进行统一的管理。
在分布式文件系统中,一个大文件会被切分成块,分别存储到几台机器上。结合上文中提到的那个存储500G大文件的那个例子,这500G的文件会按照一定的大小被切分成若干块,然后分别存储在若干台机器上,然后提供统一的操作接口。
看到这里,不少人可能会觉得,分布式文件系统不过如此,很简单嘛。事实真的是这样的么?
潜在问题
假如我有一个1000台机器组成的分布式系统,一台机器每天出现故障的概率是0.1%,那么整个系统每天出现故障的概率是多大呢?答案是(1-0.1%)^1000=63%,因此需要提供一个容错机制来保证发生差错时文件依然可以读出,这里暂时先不展开介绍。
如果要存储PB级或者EB级的数据,成千上万台机器组成的集群是很常见的,所以说分布式系统比单机系统要复杂得多呀。
这是一张HDFS的架构简图:
client通过nameNode了解数据在哪些DataNode上,从而发起查询。此外,不仅是查询文件,写入文件的时候也是先去请教NameNode,看看应该往哪个DateNode中去写。
为了某一份数据只写入到一个Datanode中,而这个Datanode因为某些原因出错无法读取的问题,需要通过冗余备份的方式来进行容错处理。因此,HDFS在写入一个数据块的时候,不会仅仅写入一个DataNode,而是会写入到多个DataNode中,这样,如果其中一个DataNode坏了,还可以从其余的DataNode中拿到数据,保证了数据不丢失。
实际上,每个数据块在HDFS上都会保存多份,保存在不同的DataNode上。这种是牺牲一定存储空间换取可靠性的做法。
接下来我们来看一下完整的文件写入的流程:
大文件要写入HDFS,client端根据配置将大文件分成固定大小的块,然后再上传到HDFS。
读取文件的流程:
1、client询问NameNode,我要读取某个路径下的文件,麻烦告诉我这个文件都在哪些DataNode上?
2、NameNode回复client,这个路径下的文件被切成了3块,分别在DataNode1、DataNode3和DataNode4上
3、client去找DataNode1、DataNode3和DataNode4,拿到3个文件块,通过stream读取并且整合起来
文件写入的流程:
1、client先将文件分块,然后询问NameNode,我要写入一个文件到某个路径下,文件有3块,应该怎么写?
2、NameNode回复client,可以分别写到DataNode1、DataNode2、DataNode3、DataNode4上,记住,每个块重复写3份,总共是9份
3、client找到DataNode1、DataNode2、DataNode3、DataNode4,把数据写到他们上面
出于容错的考虑,每个数据块有3个备份,但是3个备份快都直接由client端直接写入势必会带来client端过重的写入压力,这个点是否有更好的解决方案呢?回忆一下mysql主备之间是通过binlog文件进行同步的,HDFS当然也可以借鉴这个思想,数据其实只需要写入到一个datanode上,然后由datanode之间相互进行备份同步,减少了client端的写入压力,那么至于是一个datanode写入成功即成功,还是需要所有的参与备份的datanode返回写入成功才算成功,是可靠性配置的策略,当然这个设置会影响到数据写入的吞吐率,我们可以看到可靠性和效率永远是“鱼和熊掌不可兼得”的。
潜在问题
NameNode确实会回放editlog,但是不是每次都从头回放,它会先加载一个fsimage,这个文件是之前某一个时刻整个NameNode的文件元数据的内存快照,然后再在这个基础上回放editlog,完成后,会清空editlog,再把当前文件元数据的内存状态写入fsimage,方便下一次加载。
这样,全量回放就变成了增量回放,但是如果NameNode长时间未重启过,editlog依然会比较大,恢复的时间依然比较长,这个问题怎么解呢?
SecondNameNode是一个NameNode内的定时任务线程,它会定期地将editlog写入fsimage,然后情况原来的editlog,从而保证editlog的文件大小维持在一定大小。
NameNode挂了, SecondNameNode并不能替代NameNode,所以如果集群中只有一个NameNode,它挂了,整个系统就挂了。hadoop2.x之前,整个集群只能有一个NameNode,是有可能发生单点故障的,所以hadoop1.x有本身的不稳定性。但是hadoop2.x之后,我们可以在集群中配置多个NameNode,就不会有这个问题了,但是配置多个NameNode,需要注意的地方就更多了,系统就更加复杂了。
俗话说“一山不容二虎”,两个NameNode只能有一个是活跃状态active,另一个是备份状态standby,我们看一下两个NameNode的架构图。
两个NameNode通过JournalNode实现同步editlog,保持状态一致可以相互替换。
因为active的NameNode挂了之后,standby的NameNode要马上接替它,所以它们的数据要时刻保持一致,在写入数据的时候,两个NameNode内存中都要记录数据的元信息,并保持一致。这个JournalNode就是用来在两个NameNode中同步数据的,并且standby NameNode实现了SecondNameNode的功能。
进行数据同步操作的过程如下:
active NameNode有操作之后,它的editlog会被记录到JournalNode中,standby NameNode会从JournalNode中读取到变化并进行同步,同时standby NameNode会监听记录的变化。这样做的话就是实时同步了,并且standby NameNode就实现了SecondNameNode的功能。
优点:
缺点:
什么是NoSQL数据库?从名称“非SQL”或“非关系型”衍生而来,这些数据库不使用类似SQL的查询语言,通常称为结构化存储。这些数据库自1960年就已经存在,但是直到现在一些大公司(例如Google和Facebook)开始使用它们时,这些数据库才流行起来。该数据库最明显的优势是摆脱了一组固定的列、连接和类似SQL的查询语言的限制。有时,NoSQL这个名称也可能表示“不仅仅SQL”,来确保它们可能支持SQL。 NoSQL数据库使用诸如键值、宽列、图形或文档之类的数据结构,并且可以如JSON之类的不同格式存储。
nosql是not only sql的意思。是近今年新发展起来的存储系统。当前使用最多的是key-value模型,用于处理超大规模的数据。
以下是摘自百度百科中的一部分
NoSQL 是非关系型数据存储的广义定义。它打破了长久以来关系型数据库与ACID理论大一统的局面。NoSQL 数据存储不需要固定的表结构,通常也不存在连接操作。在大数据存取上具备关系型数据库无法比拟的性能优势。该术语在 2009 年初得到了广泛认同。
当今的应用体系结构需要数据存储在横向伸缩性上能够满足需求。而 NoSQL 存储就是为了实现这个需求。Google 的BigTable与Amazon的Dynamo是非常成功的商业 NoSQL 实现。一些开源的 NoSQL 体系,如Facebook 的Cassandra, Apache 的HBase,也得到了广泛认同。从这些NoSQL项目的名字上看不出什么相同之处:Hadoop、Voldemort、Dynomite,还有其它很多。
NoSQL与关系型数据库设计理念比较
关系型数据库中的表都是存储一些格式化的数据结构,每个元组字段的组成都一样,即使不是每个元组都需要所有的字段,但数据库会为每个元组分配所有的字段,这样的结构可以便于表与表之间进行连接等操作,但从另一个角度来说它也是关系型数据库性能瓶颈的一个因素。而非关系型数据库以键值对存储,它的结构不固定,每一个元组可以有不一样的字段,每个元组可以根据需要增加一些自己的键值对,这样就不会局限于固定的结构,可以减少一些时间和空间的开销。
NoSQL,是not only sql,是非关系数据库,不同于oracle等关系数据库。hadoop,是分布式解决方案,即为Mapreduce(计算的)和HDFS(文件系统),使用Hadoop和NoSQL可以构造海量数据解决方案。