转载于:https://blog.csdn.net/dpengwang/article/details/79297435
侵删。
一、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存储数据
架构图
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的流程图如下:
流程如下:
- 使用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已经知道文件由哪些块组成, 所以它在返回成功前只需要等待数据块进行最小量的复制。
从上面的图中,我们可以清楚的看出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中的数据流程图如下:
- 使用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可能是正在死亡的节点(合法节点)的),这样假几点就会被当做真节点,真节点死亡