十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
Hadoop
你所需要的网站建设服务,我们均能行业靠前的水平为你提供.标准是产品质量的保证,主要从事成都网站制作、成都网站设计、外贸营销网站建设、企业网站建设、手机网站制作设计、网页设计、成都品牌网站建设、网页制作、做网站、建网站。创新互联建站拥有实力坚强的技术研发团队及素养的视觉设计专才。
文件系统:文件系统是用来存储和管理文件,并且提供文件的查询、增加、删除等操作。
直观上的体验:在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数据库 ——FoundationDB的键-值存储系统
FoundationDB是一个分布式的键-值存储系统,支持全局ACID事务操作,并且性能出众。在安装系统时,可以指定数据分发的级别。数据分发为容错性提供了支持:当某个服务器或网络的某部分产生故障时,数据库仍然可以正常操作,你的应用也不会受到影响。
键-值与SQL架构
我们开发的这套架构能够在键-值存储系统上支持多个层,每个层都能够在FoundationDB的基础上提供一套不同的数据模型,例如SQL数据库、文档数据库或图形数据库。许多使用者也自行创建了自定义的层。
下图中列出架构中的了关键部分。处于最底层的是FoundationDB集群,无论集群的实际大小如何,对它的操作与一个单独的逻辑数据库并没有分别。SQL层则以一种无状态的中间层方式运行在键-值存储系统之上。这一层通过SQL与应用程序进行通信,并使用FoundationDB的客户端API与键-值存储系统进行通信。由于SQL层是无状态的,因此可以并行地运行任意数据的SQL层。
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数据库的四种类型如下:
1.key-value键值存储数据库:
相关产品: Redis、Riak、SimpleDB、Chordless、Scalaris、Memcached.
主要应用: 内容缓存,处理大量数据的高负载访问,也用于系统日志。
优点:查找速度快,大量操作时性能高。
2.列存储数据库:
相关产品: BigTable、HBase、Cassandra、HadoopDB、GreenPlum、PNUTS.
主要应用: 分布式数据的储存与管理。
优点:查找速度快,可扩展性强,容易进行分布式扩展。
缺点:功能相对局限。
3.文档型数据库
相关产品:MongoDB、CouchDB、ThruDB、CloudKit、Perservere、Jackrabbit.
主要应用: web应用,管理面向文档的数据或者类似的半结构化数据。
优点:数据结构灵活,表结构可变,复杂性低。
缺点:查询效率低,且缺乏统一的查询语言。
4.Graph图形数据库
相关产品: Neo4J、OrientDB、InfoGrid、GraphDB.
主要应用: 复杂,互连接,低结构化的图结构场合, 专注构建关系图谱。
优点: 利用图结构相关算法, 可用于构建复杂的关系图谱。
缺点: 复杂度高。
答案:A
1.文档型数据库
作为最受欢迎的NoSQL产品,文档型数据库MongoDB当仁不让地占据了第一的位置,同时它也是所有NoSQL数据库中排名最靠前的产品(总排行榜第七名)。Apache基金会的CouchDB排在第二,基于.Net的数据库RavenDB排在第三,Couchbase排在第四。
2.键值(Key-value)数据库
键值(Key-value)数据库是NoSQL领域中应用范围最广的,也是涉及产品最多的一种模型。从最简单的BerkeleyDB到功能丰富的分布式数据库Riak再到Amazon托管的DynamoDB不一而足。
在键值数据库流行度排行中,Redis不出意外地排名第一,它是一款由Vmware支持的内存数据库,总体排名第十一。排在第二位的是Memcached,它在缓存系统中应用十分广泛。排在之后的是Riak、BerkeleyDB、SimpleDB、DynamoDB以及甲骨文的Oracle NoSQL数据库。值得注意的是,Oracle NoSQL数据库上榜不久,得分已经翻番,上升势头非常迅猛。
3. 列式存储
列式存储被视为NoSQL数据库中非常重要的一种模式,其中Cassandra流行度最高,它已经由Facebook转交给到Apache进行管理,同时Cassandra在全体数据库排名中排在第十位,紧随MongoDB成为第二受欢迎的NoSQL数据库。基于Hadoop的Hbase排在第二位,Hypertable排在第三。而Google的BigTable并未列入排名,原因是它并未正式公开。
什么是NoSQL数据库?从名称“非SQL”或“非关系型”衍生而来,这些数据库不使用类似SQL的查询语言,通常称为结构化存储。这些数据库自1960年就已经存在,但是直到现在一些大公司(例如Google和Facebook)开始使用它们时,这些数据库才流行起来。该数据库最明显的优势是摆脱了一组固定的列、连接和类似SQL的查询语言的限制。有时,NoSQL这个名称也可能表示“不仅仅SQL”,来确保它们可能支持SQL。 NoSQL数据库使用诸如键值、宽列、图形或文档之类的数据结构,并且可以如JSON之类的不同格式存储。