分布式存储与HDFS

什么是大数据

简述

短时间内 快速的 产生 海量的 多种多样的 有价值的 数据。
提取出 大数据的四个特性(4个V):

1. Volumes 海量的数据
2. Variety 数据类别
3. Velocity 处理速度
4. Veracity 数据真实性

大数据技术

分布式计算

1. 分布式批处理
   攒一段时间的数据，然后再未来某个时间来处理这批数据
2. 分布式流处理
   数据不需要攒，直接处理，没产生一条数据，立马对数据进行处理，将结果生成报表给老板。
   例如天猫双十一大屏幕 qq实时在线分析统计。

机器学习

人工智能只是愿想，机器学习是实现人工智能的技术支持。
深度学习是机器学习的一部分

分布式存储

先举个简单的例子来引入分布式存储的概念
假设我有10PB的电影需要分布式存储，按类型存储在5个同学的电脑上，假如我在某天需要查看某种类型的电影，我该如何去查看我所需要的电影呢？
我们可以一个一个的去找 但是这样的效率实在是太低了，所以有人就想了一个办法，找一个“班长”，“班长”这里记录着 每位同学电脑里分别存放着什么类型的电影，然后“班长”根据我的需求把特定同学的id‘标识’发给我，我直接根据id‘标识’有目的的去查询。
通过上面的方法只经过了一次io，效率明显提高。

这里我要提出一些在分布式存储上的概念

• 存储单元：一个存储单元的数据，不能拆分为两部分来存储 也成为block 在这里指每一部的电影
• 元数据： 描述数据的数据(不理解的可以参照元学习(描述学习方法的学习))
  • 在这里元数据代表的是 包括 权限、上传时间、存储位置标识BlockId‘标识’、大文件的block数
• 备份：保证了数据的安全。
• 班长：管理元数据(索引) 称为NameNode
• 同学：负责存储数据 称为DataNode

HDFS

HDFS上传文件

1. 如果要上传一个大文件，计算大文件的block数量，文件大小/128M=block数量
2. client向namenode汇报
   • 当前大文件的block数量
   • 当前大文件属于谁 也就是权限
   • 上传的时间
   • 拥有者

for(Block block:blocks){

3. client切割出来一个block
4. 请求block块的id以及存放block的地址（默认两个副本）
5. 由于namenode能够掌控全局，管理所有的DN，所以他会将负载不高的DN地址返回给client
6. client拿到地址后，找到DN去上传数据（详细流程在后面会涉及）
7. DN将block存储完毕后，会向NN汇报当前的存储情况

}

NameNode以及DataNode的左右

• NameNode：
  • 掌控全局，管理DN以及元数据
  • 元数据存在内存中
  • 接受客户端的读写服务
  • 收集DataNode汇报的Block列表信息
  • NameNode保存的metadata信息包括
    • 文件ownership和permissions
    • 文件大小 时间
    • Block副本的位置（由DataNode上报）以及BlockId
  • 接受client的读请求，返回地址
• DataNode
  • 存储block块 向NN汇报 发送心跳(运行状态)
  • 接受client的读请求

备份机制

集群外提交

• 第一个block存储在负载不是很高的一台服务器上
• 第一个备份的block存储在与第一个block不同的机架随机一条服务器上
• 第二个备份在与第一个备份相同的机架随机一台服务器上

集群内提交

• 第一个位置是当前节点
• 第二个第三个同上
  

client向DataNode写数据

前面过程见HDFS上传文件

• client从NN得到了block信息包括Id等
• 通过id查询到该把这些block存储到哪些datanode中
• 再把block切割成一个个packet(64k)
• 并在客户端和DN间建立了管道，源源不断的传输packet

为什么要用管道来传输？
为什么要将block切割成一个个packet？
原因：并行存储，增加效率

client向datanode读数据

持久化的详细过程

再来说说NameNode元数据，他是在内存中保存的

• NameNode元数据：
  • 文件ownership
  • permission
  • 文件大小
  • 上传时间
  • Block列表
  • Block以及副本的位置

题外话
角色在集群中都是用进程来表现的，为什么node01服务器为NamdNode节点呢？
因为在node01节点上启动了一个NameNode进程。

内存是不稳定的，为了防止NameNode出现异常所以采用持久化的方法。
那为什么不备份NameNode呢？
因为首先备份和还原是一件低效的事情，因为他有两次IO和通信；而且NN是掌控全局的，它的崩溃必然导致整个集群的崩溃。
当然持久化也是一个十分繁琐的过程，而所以根据这个问题HDFS给出了一下解决方法：

给NameNode一个助手SecondaryNameNode,它专门用来用于数据持久化。
下面来详细谈谈持久化过程：

1. 首先NN会创建两个空文件

   • edits ：NameNode已经启动情况下对HDFS进行的各种更新操作进行记录
   • fsimage ： 用于保存元数据，保存了最新的元数据检查点，包含了整个HDFS文件系统的所有目录和文件的信息。对于文件来说包括了数据块描述信息、修改时间、访问时间等；对于目录来说包括修改时间、访问权限控制信息(目录所属用户，所在组)等。

   简单来想，NameNode维护了文件与数据块的映射表以及数据块与数据节点的映射表，什么意思呢？就是一个文件，它切分成了几个数据块，以及这些数据块分别存储在哪些datanode上，namenode一清二楚。Fsimage就是在某一时刻，整个hdfs 的快照，就是这个时刻hdfs上所有的文件块和目录，分别的状态，位于哪些个datanode，各自的权限，各自的副本个数。然后客户端对hdfs所有的更新操作，比如说移动数据，或者删除数据，都会记录在editlog中。

2. 把hdfs的数据更新操作写入一个新的文件——edits.new(这也就导致了 数据不可能是最新的)

3. 如果需要持久化(需要合并)SecondaryNamenode助理就会把两个文件读取过来（通过http协议）

4. 将读取过来的edits文件进行“彩排”，获取元数据（相当于备份了namenode）和fsimage文件合并形成一个新的文件——fsimage.ckpt。

5. 再把fismage.ckpt通过http协议发送给namenode。

6. 重命名fsimage.ckpt为fsimage，edits.new为edits。

合并触发机制：
- 超过3600s
- 如果edits文件超过64M

注意点：
- 并不是所有的元数据都会持久化，除了block位置信息，其他的元数据都会持久化。
- 但是这样的话，当HDFS集群重启，NN中的元数据就会有所缺失，导致集群无法对外提供服务。所以当集群启动之时，所有的DN都会向NN汇报当前节点的block信息

再来简单说说心跳机制

一旦有datanode挂掉了（宕机或者是网络阻塞），namenode能很快感知到，并且将宕机的节点上的数据块转移至其余空闲节点。这点是因为hdfs中心跳机制（heartbeat）。
心跳机制默认3s中一次，datanode会向namenode发送一次一跳，告知namenode当前节点上存放的数据文件是什么。如果namenode中记录的是该datanode存放了文件A的两个数据块和文件B的一个数据块，但是心跳中只有文件A的一个数据块信息，namenode就会知道该datanode数据块损坏了，会把损坏的数据块在别的datanode上补充。

当集群启动时

DN会向NN发送一些信息（Block信息、DN地址、DN心跳信息）

安全模式

• 加载fsimage，加载到内存中
• 如果edits文件不为空，那么nameNode自己来合并
• 检查DN的健康情况
• 如果有DN挂掉了，指挥做备份

注意：处于安全模式的过程中是不能读取文件的，只能看到目录结构

HDFS集群注意事项

HDFS集群不允许修改、文件一旦上传成功不能修改block块大小，但是可以通过***append***进行追加，禁掉的功能就是为了防止集群泛洪。

鸣谢

张富刚老师的指导

如有不足请指正。