深度理解篇之HDFS-个人拙见

Hdfs架构

首先Hdfs是一个分布式文件系统，它是分布式计算架构的支持。

怎么实现的呢？

采用一种“分而治之”的思想，将一个很大的数据块，打散到不同的节点上去存储。

具体怎么实现的呢？

首先将一个数据文件按照一定的偏移量offset进行切割，将不同偏移量的所切割数据放置在不同的储存节点之上，并且采用了副本机制。

什么是副本机制呢？

为了解决数据的容错、丢失，在其他节点上进行数据备份，默认的副本数是3，具体实现，当新的一份数据上传到一个节点上时，会随机找一台磁盘不太满，cpu不太忙的机架的节点上，然后开始复制一份数据，出机架，到与第一份不同的机架的节点上进行储存，第三份数据的存放位置就是与第二份数据相同机架的不同节点服务器上。

这里我们可以知道每份数据存放的location,便于数据的读取，这样就可以体现出大数据的又一个思想，“计算向数据移动”，知道了数据的location信息，则就可以去指定的地点去计算了，则这里的location信息才支持了计算向数据移动的可能。

“分治”思想支持着并行的一堆map,数据块上面的location支持着map向数据的移动，移动过去之后，开始进行真正的并行计算，每个map开始通过自己的offset偏移量，读取到属于自己偏移量的数据，每个map对应着不同的偏移量，则对应着不同的数据，每个map读取出来的都是没有重叠的。

无论是hdfs  impala spark  分布式计算框架，都是用到了“分治”这种思想，和基于这些数据的计算

实现？

无论是hadoop1.x还是2.x永远不变的两个核心角色就是namenode和datanode，无论哪个版本这两个角色都是有的。Datanode也就是从节点，储存的就是这些数据块， namenode是一个主，元数据的管理节点，存的就是上传到集群中的所有的块的属性信息，比如说数据块的size大小、offset偏移量、location位置信息，以及其他属性信息。

Namenode内部维护着数据块文件虚拟目录树结构，虚拟目录树中维护者元数据信息的。

刚提到namenode和datanode是主从架构的，主从架构都知道有一个通用的“毛病”就是单点故障，还有就是主namenode的压力过大，则由于这些通用的“毛病”，在企业中期望的是HA高可用模式，HA高可用模式就是有两个或多个，2.x中有两个一个是active的namenode，联邦机制，多个namenode工作的。一主多备。

既然是HA模式那么namenode之间的切换就是一个问题的，主备namenode之间的必须有一个要求，什么要求呢？

就是元数据必须同步，当主挂掉时，备立马开始工作，则必须和挂掉的namenode的元数据信息一致时才能正常工作。

这里呢先了解一下namenode的和元数据信息来源有那些？

来源主要有两部分，一部分是来源于datanode,由于集群启动的时候datanode会和每个namenode保持着心跳，将自己节点上的数据信息，发送给每个namenode，另一部分就是客户端的增删改造成的edits.log数据文件，这里主要就是使得两个namenode的edits.log达到同步，达到同步目的，在中间加一个数据同步的组件，一个是NFS倾向于单点，一个是journalnode,一般是奇数台，为什么是奇数台呢？

应为这里呢要遵循过半机制，journalnode接收元数据的时候，达到一半时才证明数据接收成功，一般是3台，3台过半能承受挂掉一台机器的风险，而四台也是承受挂掉一台机器的风险，四台的风险比较大。所以企业一般使用的就是技术台。Journalnode之间只是传递的edits.log,journalnode我们可以理解为像kafka一样的消息队列，用于传递edits.log元数据（比如mkdir,rm...一系列元数据的操作）。这样呢由于journalnode，各个namenode之间达到了数据的最终一致性。

这里我们知道了HA这里是实现了，通过这个组件，但是实现两个namenode之间的切换是怎么切换的呢？

企业中更希望namenode之间是通过自动切换的。而不是手动的，人是不靠谱的，总会造成一定的影响的。

那么自动namenode之间的切换的是怎么实现的呢？

实现自动化，这种分布式的自动化的协调服务，一般在企业中我们遇到的分布式的，需要自动化协调的，我们这里都会引入zookeeper（这里我们可以介绍一些zookeeper了？...）,而namenode和zookeeper之间的衔接是通过ZKFC这个服务来进行实现了.

它的作用是什么呢？

主要就是来监控namenode的健康状态的，主要是来进行选主的和状态的切换，ZKFC都是和namenode在同一个节点启动的，这个服务器上有一个namenode那么就一定会有一个ZKFC服务，如果将ZKFC在另一台计算机上启动，那么由于网络的延迟等因素，比如某一时刻由于网络延迟，ZKFC监控不到了namenode的健康状态，那么本来好好工作的namenode，会被切换的，这样会造成影响。

由ZKFC监控namenode向zookeeper中创建一个锁节点，两这争抢锁，那个ZKFC争抢到了，那么那个namenode就是active状态的，另一个是就是standby状态的。这里呢我们知道zookeeper分布式协调服务中是如何进行进行协调的，就是通过这种争抢锁的机制，跟多线程的抢锁机制，也是相似的。