深入理解HDFS
一、HDFS介绍
HDFS（Hadoop Distributed File System）是Hadoop项目的核心子项目，是分布式计算中数据存储管理的基础，是基于流数据模式访问和处理超大文件的需求而开发的，可以运行于廉价的商用服务器上。它所具有的高容错、高可靠性、高可扩展性、高获得性、高吞吐率等特征为海量数据提供了不怕故障的存储，为超大数据集（Large Data Set）的应用处理带来了很多便利。
HDFS优点
1.高容错性
- 数据自动保存多个副本。它通过增加副本的形式，提高容错性
- 某一个副本丢失以后，它可以自动恢复
2.适合批处理
- 它是通过移动计算而不是移动数据
- 它会把数据位置暴露给计算框架。
3.适合处理大数据
- 处理数据达到 GB、TB、甚至PB级别的数据。
- 能够处理百万规模以上的文件数量，数量相当之大。
- 能够处理10K节点的规模
4.流式文件访问
- 一次写入，多次读取。文件一旦写入不能修改，只能追加（这是算缺点吗）。
- 它能保证数据的一致性（通过校验机制）
5.可构建在廉价机器上
- 它通过多副本机制，提高可靠性。
- 它提供了容错和恢复机制。比如某一个副本丢失，可以通过其它副本来恢复。
HDFS 缺点
1.低延时数据访问
-
比如毫秒级的来存储数据，这是不行的，它做不到。
-
它适合高吞吐率的场景，就是在某一时间内写入大量的数据。但是它在低延时的情况下是不行的，比如毫秒级以内读取数据，这样它是很难做到的。
HDFS是单Master的，所有的对文件的请求都要经过它，当请求多时，肯定会有 延时。
2.小文件存储
- 存储大量小文件的话，它会占用 NameNode大量的内存来存储文件、目录和块信息（元信息）。这样是不可取的，因为NameNode的内存总是有限的。
- 小文件存储的寻道时间会超过读取时间，它违反了HDFS的设计目标。
3、并发写入、文件随机修改
- 一个文件只能有一个写，不允许多个线程同时写。
- 仅支持数据 append（追加），不支持文件的随机修改。
针对HDFS缺点可能的改进措施
高延迟问题：
使用缓存或多master设计可以降低client的数据请求压力，以减少延时。
存储小文件问题：
1、利用SequenceFile、MapFile、Har等方式归档小文件，这个方法的原理就是把小文件归档起来管理，HBase就是基于此的。对于这种方法，如果想找回原来的小文件内容，那就必须得知道与归档文件的映射关系。
2、横向扩展，一个Hadoop集群能管理的小文件有限，那就把几个Hadoop集群拖在一个虚拟服务器后面，形成一个大的Hadoop集群。google也是这么干过的。
3、多Master设计，正在研发中的GFS II也要改为分布式多Master设计，还支持Master的Failover，而且Block大小改为1M，有意要调优处理小文件。（Alibaba DFS的设计，也是多Master设计，它把Metadata的映射存储和管理分开了，由多个Metadata存储节点和一个查询Master节点组成。）
二、HDFS存储数据
架构图
1.png
HDFS 采用Master/Slave的架构来存储数据，这种架构主要由四个部分组成，分别为HDFS Client、NameNode、DataNode和Secondary NameNode。
Client：就是客户端。
1、切分文件：文件上传 HDFS 的时候，Client 将文件切分成 一个一个的Block，然后进行存储。
2、与 NameNode 交互，获取文件的位置信息。
3、与 DataNode 交互，读取或者写入数据。
4、Client 提供一些命令来管理 HDFS，比如启动或者关闭HDFS。
5、Client 可以通过一些命令来访问 HDFS。
NameNode：就是 master，它是一个主管、管理者。
1、管理 HDFS 的名称空间（namespace）。
2、管理数据块（Block）映射信息
3、配置副本策略
4、处理客户端读写请求。
DataNode：就是Slave，NameNode 下达命令，DataNode 执行实际的操作。
1、存储实际的数据块。
2、执行数据块的读/写操作。
Secondary NameNode：并非 NameNode 的热备份（两个节点同时运行，一个挂掉了切换另一个）。当NameNode 挂掉的时候，它并不能马上替换 NameNode 并提供服务。
1、辅助 NameNode，分担其工作量。
2、定期合并 fsimage和fsedits，并推送给NameNode。
3、在紧急情况下，可辅助恢复 NameNode。
三、HDFS读写数据流程
HDFS写数据流程
客户端将数据写入HDFS的流程图如下：
2.png
流程如下：
- 使用HDFS提供的客户端Client， 向远程的Namenode发起RPC请求
- Namenode会检查要创建的文件是否已经存在，创建者是否有权限进行操作，成功则会为文件创建一个记录， 否则会让客户端抛出异常；
- 当客户端开始写入文件的时候， 客户端会将文件切分成多个packets， 并在内部以数据队列“data queue（ 数据队列） ”的形式管理这些packets， 并向Namenode申请blocks， 获取用来存储replications的合适的datanode列表， 列表的大小根据Namenode中replication的设定而定；
- 开始以pipeline（ 管道） 的形式将packet写入所有的replications中。 客户端把packet以流的方式写入第一个datanode， 该datanode把该packet存储之后， 再将其传递给在此pipeline中的下一个datanode， 直到最后一个datanode， 这种写数据的方式呈流水线的形式。
- 最后一个datanode成功存储之后会返回一个ack packet（ 确认队列） ， 在pipeline里传递至客户端， 在客户端的开发库内部维护着”ack queue”， 成功收到datanode返回的ack packet后会从”ack queue”移除相应的packet。
- 如果传输过程中， 有某个datanode出现了故障， 那么当前的pipeline会被关闭， 出现故障的datanode会从当前的pipeline中移除， 剩余的block会继续剩下的datanode中继续以pipeline的形式传输， 同时Namenode会分配一个新的datanode， 保持replications设定的数量。
- 客户端完成数据的写入后， 会对数据流调用close()方法， 关闭数据流；
-
只要写入了dfs.replication.min的复本数（ 默认为1），写操作就会成功， 并且这个块可以在集群中异步复制， 直到达到其目标复本数（replication的默认值为3），因为namenode已经知道文件由哪些块组成， 所以它在返回成功前只需要等待数据块进行最小量的复制。
3.png
从上面的图中，我们可以清楚的看出NameNode对应于用户的三个动作分别
以create、 addBlock、 complete来进行相关的处理。现在，我就来详细的分析NameNode的这三个动作是如何实现的。
- NameNode的create动作主要是为客户端传过来的文件名在HDFS的Namesystem中申请一个名字空间，并为之建立一个响应的iNode，当然，这个iNode的状态是underConstruction，然后为这个客户创建一个该文件的租约，就是文件的独占锁，以防止其它的客户端对这个文件同时写。
- NameNode的addBlock动作主要是为文件创建一个新的Block，并为这个Block的副本分配存储DataNode节点，最后给客户端返回一个LocatedBlock对象，该对象包含Block的副本应该存放的位置。在这里我想说得是，NameNode节点此时并不保存该Block的副本位置，而是等到成功接收该Block的数据节点自动报告时它才正式记录该Block的一个副本的位置，这样做是由于HDFS不能保证Block一开始分配的数据节点都能成功结束Block。
- NameNode的complete动作就是更改与当前文件节点相关的状态，同时释放文件的租约。另外，NameNode还要判断文件的所有Blocks的副本是否已满足，对于还不满足的Blocks， NameNode将其放入neededReplications队列中，让其它的后台线程来负责这些Block的副本情况。
block是datanode存放数据的基本单位
HDFS读数据流程
客户端读取HDFS中的数据流程图如下：
4.png
- 使用HDFS提供的客户端Client， 向远程的Namenode发起RPC请求；
- Namenode会视情况返回文件的部分或者全部block列表， 对于每个block， Namenode都会返回有该block拷贝的DataNode地址；
- 客户端Client会选取离客户端最近的DataNode来读取block； 如果客户端本身就是DataNode， 那么将从本地直接获取数据；
- 读取完当前block的数据后， 关闭当前的DataNode链接， 并为读取下一个block寻找最佳的DataNode；
- 当读完列表block后， 且文件读取还没有结束， 客户端会继续向Namenode获取下一批的block列表；
- 读取完一个block都会进行checksum验证， 如果读取datanode时出现错误， 客户端会通知Namenode， 然后再从下一个拥有该block拷贝的datanode继续读。
四、HDFS的安全威胁
大量小文件上传问题 （拒绝服务）
namenode中的块映射表，命名空间数据 文件元数据和
消耗cpu
寻找文件耗时 拒绝服务
随着文件数增加 上传文件时间数增加
数据回收的延迟问题（信息泄露）
在数据回收的过程中，即使文件系统中的trash文件夹下的文件夹被删除后（1小时后），数据块没有被真正删除，而是需要等待副本管理器扫描到该块后才能被彻底删除（6小时后），即HDFS上删除文件一定时间内，datanode上文件依然存在
导致结果，在延迟时间段内窃取数据
数据块权限问题（信息泄露）
所有数据块都以明文的方式，按文件格式存储在HDFS的数据节点的操作系统之上，块文件存储时在节点上的默认权限为允许其他用户读，导致操作系统上任何用户都能窃取该数据块的内容
负载均衡脆弱性问题（信息泄露+拒绝服务）
节点动态增加时，hadoop不自动提供负载均衡操作（管理员手动操作）
在负载均衡成功后，源数据节点没有能够及时删除已经拷贝走的冗余数据块，而是继续占用节点空间，造成资源浪费（注意跟垃圾回收的不同）
在上述缺陷下，当系统资源不足的情况下，当用户继续上传新文件但系统没有可用空间，就会拒绝用户的上传操作
伪节点问题（信息泄露）
datanode和namenode之间的交互信息会被窃取，以后数据也可能流入这个假的节点中
通过发送假ip（这个ip可能是正在死亡的节点（合法节点）的），这样假几点就会被当做真节点，真节点死亡
