什么是HDFS？算了，告诉你也不懂。

玩转容器技术

上一篇已讲解了「大数据入门」的相干基本观点和学问了，这篇我们来学学HDFS。假如文章有毛病的处所，无妨在批评区和睦指出~

一、HDFS引见

上篇文章已讲到了，跟着数据量越来越大，在一台机械上已没法存储一切的数据了，那我们会将这些数据分配到差别的机械来举行存储，然则这就带来一个问题：不方便治理和保护

所以，我们就愿望有一个体系可以将这些散布在差别操纵服务器上的数据举行统一治理，这就有了散布式文件体系

• HDFS是散布式文件体系的个中一种（如今用得最普遍的一种）

在运用HDFS的时刻是异常简朴的：虽然HDFS是将文件存储到差别的机械上，然则我去运用的时刻是把这些文件当作是存储在一台机械的体式格局去运用（背地倒是多台机械在实行）：

• 比方：我调用了一个RPC接口，我给他参数，他返回一个response给我。RPC接口做了什么事实在我都不晓得的（大概这个RPC接口又调了其他的RPC接口）-----屏蔽掉完成细节，对用户友爱

明白一下：HDFS就是一个散布式文件体系，一个文件体系，我们用它来做什么？存数据呀。

下面，我们来相识一下HDFS的一些学问，可以帮我们更好地去「运用」HDFS

二、HDFS进修

从上面我们已提到了，HDFS作为一个散布式文件体系，那末它的数据是保存在多个体系上的。比方，下面的图：一个1GB的文件，会被切分成几个小的文件，每一个服务器都邑寄存一部份。

那肯定会有人会问：那会切分多少个小文件呢？默许以128MB的大小来切分，每一个128MB的文件，在HDFS叫做块(block)

明显，这个128MB大小是可配的。假如设置为太小或许太大都不好。假如切分的文件太小，那一份数据大概散布到多台的机械上（寻址时候就很慢）。假如切分的文件太大，那数据传输时候的时候就很慢。

PS：老版本默许是64MB

一个用户发出了一个1GB的文件要求给HDFS客户端，HDFS客户端会依据设置(如今默许是128MB)，对这个文件举行切分，所以HDFS客户端会切分为8个文件(也叫做block)，然后每一个服务器都邑存储这些切分后的文件(block)。如今我们假定每一个服务器都存储两份。

这些寄存实在数据的服务器，在HDFS范畴叫做DataNode

如今问题来了，HDFS客户端根据设置切分完今后，怎样晓得往哪一个服务器（DataNode）放数据呢？这个时刻，就须要另一个角色了，治理者（NameNode）。

NameNode实际上就是治理文件的种种信息（这类信息专业点我们叫做MetaData「元数据」），个中包含：文文件路径名，每一个Block的ID和寄存的位置等等。

所以，不管是读照样写，HDFS客户端都邑先去找NameNode，经由过程NameNode得知响应的信息，再去找DataNode

• 假如是写操纵，HDFS切分完文件今后，会讯问NameNode应当将这些切分好的block往哪几台DataNode上写。
• 假如是读操纵，HDFS拿到文件名，也会去讯问NameNode应当往哪几台DataNode上读数据。

2.1 HDFS备份

作为一个散布式体系（把大文件切分为多个小文件，存储到差别的机械上），假如没有备份的话，只需有个中的一台机械挂了，那就会致使「数据」是不可用状况的。

写到这里，假如看过我的Kafka和ElasticSearch的文章大概就懂了。实在头脑都是一样的。

Kafka对partition备份，ElasticSearch对分片举行备份，而到HDFS就是对Block举行备份。

尽大概将数据备份到差别的机械上，即使某台机械挂了，那便可以将备份数据拉出来用。

对Kafka和ElasticSearch不相识的同砚，可以关注我的，搜刮关键字即可查询（我以为还算写得比较通俗易懂的）

注：这里的备份并不须要HDFS客户端去写，只需DataNode之间相互通报数据就好了。

2.2 NameNode的一些事

从上面我们可以看到，NameNode是须要处置惩罚hdfs客户端要求的。（因为它是存储元数据的处所，不管读写都须要经由它）。

如今问题就来了，NameNode是怎样寄存元数据的呢？

• 假如NameNode只是把元数据放到内存中，那假如NameNode这台机械重启了，那元数据就没了。
• 假如NameNode将每次写入的数据都存储到硬盘中，那假如只针对磁盘查找和修正又会很慢（因为这个是纯IO的操纵）

说到这里，又想起了Kafka。Kafka也是将partition写到磁盘里边的，但人家是怎样写的？次序IO

NameNode一样也是做了这个事：修正内存中的元数据，然后把修正的信息append（追加）到一个名为editlog的文件上。

因为append是次序IO，所以效力也不会低。如今我们增编削查都是走内存，只不过增编削的时刻往磁盘文件editlog里边追加一条。如许我们即使重启了NameNode，照样可以经由过程editlog文件将元数据恢复。

如今也有个问题：假如NameNode一向历久运转的话，那editlog文件应当会越来越大（因为一切的修正元数据信息都须要在这追加一条）。重启的时刻须要依靠editlog文件来恢复数据，假如文件迥殊大，那启动的时刻不就迥殊慢了吗？

的确是云云的，那HDFS是怎样做的呢？为了防备editlog过大，致使在重启的时刻须要较长的时候恢复数据，所以NameNode会有一个内存快照，叫做fsimage

说到快照，有无想起Redis的RDB!!

如许一来，重启的时刻只须要加载内存快照fsimage+部份的editlog便可以了。

主意很优美，实际还须要处理一些事：我什么时刻生成一个内存快照fsimage？我怎样晓得加载哪一部份的editlog？

问题看起来彷佛庞杂，实在我们就只须要一个定时使命。

假如让我自身做的话，我大概会想：我们加一份设置，设置个时候就OK了

• 假如editlog大到什么水平或许隔了多长时候，我们就把editlog文件的数据跟内存快照fsiamge给兼并起来。然后生成一个新的fsimage，把editlog给清空，掩盖旧的fsimage内存快照
• 如许一来，NameNode每次重启的时刻，拿到的都是最新的fsimage文件，editlog里边的都是没兼并到fsimage的。依据这两个文件便可以恢复最新的元数据信息了。

HDFS也是相似上面如许干的，只不过它不是在NameNode起个定时的使命跑，而是用了一个新的角色：SecondNameNode。至于为何？大概HDFS以为兼并所消耗的资本太大了，差别的事情交由差别的服务器来完成，也相符散布式的理念。

如今问题照样来了，此时的架构NameNode是单机的。SecondNameNode的作用只是给NameNode兼并editlog和fsimage文件，假如NameNode挂了，那client就要求不到了，而一切的要求都须要走NameNode，这致使全部HDFS集群都不可用了。

因而我们须要保证NameNode是高可用的。平常如今我们会经由过程Zookeeper来完成。架构图以下：

主NameNode和从NameNode须要坚持元数据的信息一致（因为假如主NameNode挂了，那从NameNode须要顶上，这时候从NameNode须要有主NameNode的信息）。

所以，引入了Shared Edits来完成主从NameNode之间的同步，Shared Edits也叫做JournalNode。实际上就是主NameNode假如有更新元数据的信息，它的editlog会写到JournalNode，然后从NameNode会在JournalNode读取到变化信息，然后同步。从NameNode也完成了上面所说的SecondNameNode功用（兼并editlog和fsimage）

轻微总结一下：

• NameNode须要处置惩罚client要求，它是存储元数据的处所
• NameNode的元数据操纵都在内存中，会把增编削以editlog延续化到硬盘中（因为是次序io，所以不会太慢）
• 因为editlog大概存在过大的问题，致使重新启动NameNode过慢（因为要依靠editlog来恢复数据），引出了fsimage内存快照。须要跑一个定时使命来兼并fsimage和editlog，引出了SecondNameNode
• 又因为NameNode是单机的，大概存在单机毛病的问题。所以我们可以经由过程Zookeeper来保护主从NameNode，经由过程JournalNode(Share Edits)来完成主从NameNode元数据的一致性。终究完成NameNode的高可用。

2.3 学点DataNode

从上面我们就晓得，我们的数据是寄存在DataNode上的（还会备份）。

假如某个DataNode掉线了，那HDFS是怎样晓得的呢？

DataNode启动的时刻会去NameNode上注册，他俩会保持心跳，假如凌驾时候阈值没有收到DataNode的心跳，那HDFS就以为这个DataNode挂了。

另有一个问题就是：我们将Block存到DataNode上，那照样有大概这个DataNode的磁盘损坏了部份，而我们DataNode没有下线，但我们也不晓得损坏了。

一个Block除了寄存数据的自身，还会寄存一份元数据（包含数据块的长度，块数据的校验和，以及时候戳）。DataNode照样会按期向NameNode上报一切当前一切Block的信息，经由过程元数据便可校验当前的Block是否是一般状况。

末了

实在在进修HDFS的时刻，你会发明许多的头脑跟之前学过的都相似。就比方提到的Kafka、Elasticsearch这些经常使用的散布式组件。

假如对Kafka、Elasticsearch、Zookeeper、Redis等不相识的同砚，可以在我的GitHub或民众号里边找对应的文章哦~我以为还算写得通俗易懂的。

改天整合一下这些框架的耐久化特性，再写一篇（因为可以发明，他们的耐久化机制都非常相似）

下一篇无不测的话，会写写MapReduce，谢谢你看到这里。

参考资料：

• 《从零开始学大数据 -李伶俐》

假如人人想要及时关注我更新的文章以及分享的干货的话，可以关注我的民众号「Java3y」。

• Java优美脑图
• Java进修线路
• 开发经常使用工具

C#开发BIMFACE系列30 服务端API之模型对比1：发起模型对比