HDFS 详解

HDFS 概述

基于2.7.3

HDFS 优点：

1、高容错性

　　数据自动保存多个副本，默认是三个副本

　　副本丢失后，会自动恢复

2、适合批处理

　　移动计算而非移动数据，批处理的时候，数据量很大，移动数据是不合适的，好的方式是分布式的移动计算

　　数据位置暴露给计算框架，数据被切分为 block list，block list 存放在哪些node list 上，在 namenode 上，是有这两个维度的记录的

3、适合大数据处理

　　GB、TB、甚至 PB 级数据，当然小数据也是可以的，有相应方法

　　百万规模以上的文件数量

　　10K + 节点规模

4、流式文件访问

　　一次性写入，多次读取

　　保证数据一致性

5、可构建在廉价机器上

　　通过多副本提高可靠性

　　提供了容错和恢复机制

二、HDFS 缺点

1、不适合低延迟的数据访问

　　比如毫秒级，这个 HDFS 是做不到的

　　HDFS 不适合低延迟的处理场景，适合需要高吞吐率的场景

2、不适合小文件存取

　　每个文件存入 HDFS 都会被切分为一些 blocks ，namenode 中保存了二个维度的映射，1亿个1k 的小文件，文件大小一共 1G，可能占用10G 的内存，这是不合适的（数据仅为假设）

　　寻道时间超过读取时间，我们知道，在计算机里面寻找文件，是先要寻道（找到文件存在的扇区），再去读取文件，这两步，时间花费主要在寻道，而不是文件读取

3、不适合并发写入、文件随机修改

　　HDFS 中，一个文件只能有一个写者

　　仅支持 append，不支持或者不建议文件修改，这里解释下，HDFS 对于文件的修改方式，先读取数据，修改数据，最后再重新写入一个文件

HDFS 基本架构与原理

HDFS 设计思想

　　文件写入 HDFS 的时候，file 会被 client 按128M（可自定义，hadoop1 的时候默认是64M）的大小，被分为很多 blocks ，每个block 会被分配存储到一些 node 上，同时每个 block 会有三个副本按照一定规则被存储在一些 nodes 上

　　一个129M 的文件，会被存储为一个 128Ｍ的文件和一个１Ｍ的文件

　　Q&A：一个1TB的文件，被切分为n 个 blocks ，公司是刚开始使用hadoop 集群，集群中只有三台服务器，这些blocks 放在遍布这三台服务器，会不会出现什么问题？三台服务器会不会太少了？

HDFS 架构

DN 会向 NN 每隔几秒钟发一次心跳，来告诉 NN 自己的状态，当一个 DN 挂掉，NN 没有收到该 DN 的心跳，该 DN 上的数据会被再次备份到其他 node 上，但这会有一个问题，不同的机器，负载情况，记录的数据量不均衡，此时，可以通过 balance 组件，来进行负载均衡，当集群扩容的时候，同样可以调用 banance 组件来处理

先介绍下左侧的 NN，它在内存中记录了两个维度（文件结构就是一棵树）的信息

　　file —> block list，这一维度会保存在内存，并被序列化到磁盘，这个树（元信息或者这一维度的记录或者文件镜像）被称之为 fsimage（file system image）

　　block —> node list，这一维度不会被存到磁盘仅保存在内存，其关系的维持，主要靠 DN 周期性的向 NN 汇报自身的 block list ，当调用 balance 的时候，dn 上面的 node list 会发生变化，dn 同样会告知 nn 自身现在的情况

NN 可以配置副本策略，每个 block 及其副本存放在哪些 node 上，可以处理客户端的读写请求，但是具体执行处理请求是 dn 来做

再说右边 Standby NN，这是 hadoop2 之后提出的一个概念 HA，为了解决 NN 的单点故障，之前一直都是 Second NN

Standby NN 会去监控NN 的健康状态，当发现 NN 挂掉以后，Standby NN 会自动切换为 NN

fsimage 因为是被序列化到磁盘，所以当 NN 挂掉或者重启，这部分数据不会丢失，但机器上的 block 信息，如果正好碰到有写入发生，该 node 挂掉，那么数据是不是会丢失呢？答案是不会，原理是：

　　client 每次有写入或者增加一个文件等请求，这时候是会把这些这些操作都会记录到一个 log，也就是fsedit，而不是立马更新到 NN 的 fsimage，重启时，会先加载 fsimage，再去读取 editlog ，这样，NN 中的文件数就是最新的，详细介绍：

　　这个树（fsimage）是写到磁盘了，但是现在有一个对这个树的修改，比如说创建了一个文件，这个时候怎么办，这时候可以引入log，如果重启的时候，我先载入 fsimage ，然后我的log记录了我对文件树的整个修改，我对 fsimage 依次的执行 log，就可以把文件树恢复到最新，但是我如果每次都把修改或者改动记录到log，也不行，因为当log越来越大，重启的时候，会越来越慢，这时候就出现了Second NN，他定期的合并fsimage和editlog，然后将最新的 fsimage 发送给 NN，告诉 NN 可以把旧的 fsimage 删掉，用我这个新的替换

Second NN，一个较老的名字，Second 没有热备的功能，后来发展发展成为 HA 的 Standby，Standby 承载了一部分 Second 的功能（合并 fsimage 和 editlog），并成为热备

HA 与 Federation （这个大公司一般才可能遇到，再说吧）

HDFS内部机制—写流程

HDFS client 创建一个file，会向 NN 申请空间资源，比如写入哪些机器，这些 128M 的块会再次切分成 512字节的package（包含了CRC32的校验，在三个 node 之间验证，来确保数据完整性），因为客户端一次性缓存128M 是比较可怕的事情，会占用大量内存，按照这样的方式依次、流式、串行的写数据

这里为什么不选择同时向三个 DN 写入呢，因为这样会占用更多的带宽，不如串行、流式的写好

写的时候，NN 会生成由三个 DN 构成的一个list，并告诉第一个 DN 要写入的数据以及后面两个 DN 的信息，三个 DN 依次写的时候，有一个 DN 挂掉，则会跳过他，将它从 list 中移除，然后继续入写其余两个 DN

当三个 DN 都遍历写完，DN 才会告知 NN，而不是写完一个 DN 该 DN 就告知 NN

如果一次写入，有两个 DN 都正好挂掉，那么 HDFS 会认为这次写入是失败的，因为这个时候也可能出现唯一写入成功的 DN 挂掉，这违背了 HDFS 高可用高容错性，NN 会重新分配，重新写，这是默认是实现

HDFS内部机制—读流程

HDFS client 读取文件的时候，会向 NN 去获取一个 block locations ，然后打开输入流，按照就近原则，在相应 DN 上读取数据

就近原则是，本地 > 同机架 >同交换机 > 同机房

同一个机架任意两个节点之间共享 1Gbps 带宽，机架之间带宽为 2-10 Gbps，每个机架通常有16-64 个节点

HDFS内部机制—副本放置策略

HDFS 访问方式

主要分为 Shell 命令和 API 这两种方式