星的朋友
星的朋友
3月前 · 6 人阅读

一、HDFS介绍

HDFS(Hadoop Distributed File System)是Hadoop项目的核心子项目,是分布式计算中数据存储管理的基础,是基于流数据模式访问和处理超大文件的需求而开发的,可以运行于廉价的商用服务器上。它所具有的高容错、高可靠性、高可扩展性、高获得性、高吞吐率等特征为海量数据提供了不怕故障的存储,为超大数据集(Large Data Set)的应用处理带来了很多便利。

HDFS优点

1.高容错性

  • 数据自动保存多个副本。它通过增加副本的形式,提高容错性
  • 某一个副本丢失以后,它可以自动恢复

2.适合批处理

  • 它是通过移动计算而不是移动数据
  • 它会把数据位置暴露给计算框架。

3.适合处理大数据

  • 处理数据达到 GB、TB、甚至PB级别的数据。
  • 能够处理百万规模以上的文件数量,数量相当之大。
  • 能够处理10K节点的规模

4.流式文件访问

  • 一次写入,多次读取。文件一旦写入不能修改,只能追加(这是算缺点吗)。
  • 它能保证数据的一致性(通过校验机制)

5.可构建在廉价机器上

  • 它通过多副本机制,提高可靠性。
  • 它提供了容错和恢复机制。比如某一个副本丢失,可以通过其它副本来恢复。
HDFS 缺点

1.低延时数据访问

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的流程图如下:

流程如下:

从上面的图中,我们可以清楚的看出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可能是正在死亡的节点(合法节点)的),这样假几点就会被当做真节点,真节点死亡

收藏 0
hdfs namenode 文件 节点 数据 客户端
评论 ( 0 )