第五章 数据中台架构PaaS层离线存储之HDFS的架构演进（图解）

1、分布式文件系统

超级大型电脑=分布式文件系统

2、HDFS1架构说明

• 定义：是一个主从式架构，主节点只有一个NameNode，从节点有多个DataNode
  • NameNode：管理元数据信息，主要包括文件与Block块，Block块与DataNode主机的关系
  • DataNode：以文件块形式存储数据（Hadoop1默认64M），每个文件块默认3个副本

• 注意事项：NameNode为了快速响应用户的操作请求，所以把元数据加载到内存中

• HDFS1架构缺陷

  • 单点故障：NameNode发生故障，那整个集群就会无法运行；
  • 内存受限：

3、HDFS1单点故障解决方案 - HDFS2架构方案

• 解决方案：加一台NameNode，但是怎么加且看如下？

3.1、问题1：如何保持两个NameNode元数据一致？

• 解决方式：JournalNNode集群

• 架构原理：采用JournalNNode集群进行元数据管理，JournalNNode集群本身没有单点故障问题
  • NameNode(active)：往集群中写入元数据信息
  • Name(standby)：读取集群数据

JournalNNode节点：
hadoop<200 3
hadoop>200 5

3.2、问题2：NameNode(active)挂了，如何自动切换到Name(standby)

• 解决方案：Zookeeper集群

• 架构原理：ZKFC负责检测NameNode的心跳，一旦挂掉就会将锁给到备用机

4、HDFS1内存受限解决方案 - HDFS3

• 解决方案：NameNode采用联邦制，支持多个NameNode。

• 架构原理：元数据文件在多组高可用NameNode存储，每组NameNode存储的元数据文件不同

• 应用场景

  • 服务器<1000台，采取主备策略
  • 服务器>1000台，采用联邦策略

5、HDFS支持亿级流量原理

（1）亿级流量概述

​ NameNode管理了元数据，用户所有操作请求都要操作NameNode，大一点的平台一天运行需要几十万上百万的的任务，一个任务就有很多请求，所有NameNode的请求都打到NameNode这儿（更新目录树），对于NameNode就是亿级数据。

• 请求类型：创建文件，上传文件，读取文件等

5.1、原理&问题概述

①格式化HDFS，在磁盘上生成fsimage文件

②启动NameNode，将fsimage文件加载到内存中

③用户写数据将文件上传到集群，文件元数据信息增加到NameNode内存中，同时将操作会写入磁盘中的edit.log，之后将内存fsimage数据同步到磁盘的fsimage文件上

• 问题：内存的读写速度比磁盘要快，磁盘读写性能成为瓶颈

5.2、Editlog写机制之分段加锁&双缓冲机制

• 业务场景：在HA下，客户端的每一条事务都会首先写入缓冲区，然后近可能马上写入磁盘Editlog和journalNode(保证可靠性)，即HDFS应该尽可能保证客户端写的写操作返回成功时，磁盘和JournalNode中Editlog中有该记录。
  
  （1） 因为将记录互斥写入内存，等待时间较短，并且在写磁盘和网络时，不需要持有锁，不影响其他线程的互斥写内存。
  ​ （2）在某线程写磁盘和网络时，其他线程只要判断出其对应的事务已经在被写出了，则可以直接返回。
  ​ （3）两次获取到的锁是同一把锁，都是加在对象(FSEditLog)上的锁。第一次竞争锁为了互斥写缓冲，第二次竞争锁为了交换缓冲。
  ​ （4）通过上述的双缓冲和对线程2阶段加锁，大大提高了性能，并且可以保证返回成功时，该事务已在被写入磁盘和网络；类似于使用一个缓冲区来ack整个缓冲区中的事务，而不是对事务一个接一个ack。

5.3、Checkpoint机制概述

• 业务场景：NameNode宕机挂掉/重启之后，内存中的fsimage文件消失
  • 重启后：重新加载磁盘中的fsimage文件，合并editlog文件到内存中

• SecondNameNode机制：合并NameNode的编辑日志，加快NameNode启动速度
  • 作用：定时拉取NameNode的edit日志，与fsimage进行合并，并将合并编辑的文件传到NameNode上进行文件替换