HDFS
(Hadoop Distributed File System
)是基于流数据模式访问和处理超大文件的需求而开发的,它可以运行于廉价的商用服务器上。
HDFS
(Hadoop Distributed File System
)采用了主从Master/Slave
结构模型,一个HDFS
集群是由一个NameNode
和若干个DataNode
组成的。其中NameNode
作为主服务器,管理文件系统的命名空间和客户端对文件的访问操作;集群中的DataNode
管理存储的数据。HDFS
允许用户以文件的形式存储数据。从内部来看,文件被分成若干个数据块,而且这若干个数据块存放在一组DataNode
上。NameNode
执行文件系统的命名空间操作,比如打开、关闭、重命名文件或目录等,它也负责数据块到具体DataNode
的映射。DataNode
负责处理文件系统客户端的文件读写请求,并在NameNode
的统一调度下进行数据块的创建、删除和复制工作。
NameNode
是所有HDFS
元数据的管理者,用户需要保存的数据不会经过NameNode
,而是直接流向存储数据的DataNode
。
重视数据吞吐量
NameNode
建立连接之后,它和名字节点的协议便是客户端协议Client Protocal
。数据节点DataNode
和名字节点之间则用数据节点协议DataNode Protocal
。特点 | 说明 |
---|---|
处理超大文件 | 数百MB,乃至TB、PB级的数据。 |
流式访问数据 | “一次写入、多次读取”,这意味着一个数据集一旦由数据源生成,就会被分发到不同的存储结点,响应各种数据分析要求。 |
运行在廉价的商用机器集群上 | 廉价的机器也意味着出现节点故障的概率非常高。这就要求HDFS在设计的时候需要充分考虑数据的可靠性、安全性和高可用性。 |
局限性 | 说明 |
---|---|
不适合低延迟的网络访问 | HDFS是为了处理大型数据集分析任务,主要是为达到高的数据吞吐量而设计的,这就要求可能以高延迟作为代价。补充方案HBase 。 |
无法高效存储大量小文件 | 在Hadoop中需要用NameNode 管理文件系统的元数据。每个文件、索引目录以及块大约需要占用100字节,一旦有1千万个文件,每个文件占一个块,那么至少需要消耗2G的内存。如果更多,机器很难满足这些这个要求,而且检索元数据的时间也将难以接受。 |
不支持多用户写入及任意修改文件 | 只允许一个写入者,只允许在末尾追加数据。 |
序号 | 说明 |
---|---|
1 | Client 向NameNode 发起文件写入请求。NameNode 会检查目标文件是否存在,父目录是否存在,然后会判断此客户端是否有写权限。如果都满足,NameNode 会给客户端返回一个输出流。此外,NameNode 会为文件分配块存储信息。注意,NameNode 也是分配块的存储信息,但不做物理切块工作。 |
2 | 客户端拿到输出流以及块存储信息之后,就开始向DataNode 写数据。因为一个块数据,有三个副本,所以图里有三个DataNode 。Packet 初学时可以简单理解为就是一块数据。 |
3 | 数据块的发送,先发给第一台DataNode ,然后再有第一台DataNode 发往第二台DataNode ……实际这里,用到了pipeLine 数据流管道的思想。 |
4 | 通过ack 确认机制,向上游节点发送确认,这么做的目的是确保块数据复制的完整性。 |
5 | 通过最上游节点,向客户端发送ack ,如果块数据没有发送完,就继续发送下一块。如果所有块数据都已发完,就可以关流了。 |
6 | 所有块数据都写完后,关流。 |
序号 | 说明 |
---|---|
1 | 客户端发出读数据请求,Open File 指定读取的文件路径,去找NameNode 要元数据信息。 |
2 | NameNode 返回文件存储的DataNode 信息给Client 。(就近原则、然后随机访问) |
3 | Client 根据返回的元数据信息,去对应的DataNode 去读Block 数据。假如一个文件特别大,比如1TB ,会分成好多块,此时,NameNode 并是不一次性把所有的元数据信息返回给客户端。 |
4 | 客户端读完此部分后,再去想NameNode 要下一部分的元数据信息,再接着读。 |
5 | 读完之后,通知NameNode 关闭流。 |
假如有三份数据。
编号 | 放置位置 |
---|---|
1 | 第一份Block 放在NameNode 指定的DataNode 上。 |
2 | 第二份Block 副本放置在与第一个DataNode 节点相同的机架中的另一个DataNode 中(随机选择)。 |
3 | 第三份Block 副本放置于另一个随机远端机架的一个随机DataNode 中。 | |
说明(参见自:HDFS block块的副本存放策略) |
---|
将第一、二个Block 副本放置在同一个机架中,当用户发起数据读取请求时可以较快地读取,从而保证数据具有较好的本地性。 |
第三个及更多的Block 副本放置于其他机架,当整个本地结点都失效时,HDFS将自动通过远端机架上的数据副本将数据副本的娄得恢复到标准数据。 |
Hadoop 的副本放置策略在可靠性(Block 在不同的机架)和带宽(一个管道只需要穿越一个网络节点)中做了一个很好的平衡。 |
摘录自:如何手动开启或关闭HDFS的安全模式(safemode)
在Hadoop
启动NameNode
的时候,会启动安全模式(safemode
),在该模式下,NameNode
会等待DataNode
向它发送块报告(block report
),只有接收到的DataNode
上的块数量(datanodes blocks
)和实际的数量(total blocks
)接近一致, 超过datanodes blocks / total blocks >= 99.9%
这个阀值,就表示 块数量一致,就会推出安全模式。达到99.9%
的阀值之后,文件系统不会立即推出安全模式,而是会等待30秒之后才会退出。
比如在启动Hadoop
的HDFS
的 30 s 30s 30s内执行一个任务,将会出现Name node is in safe mode.(目前处于安全模式) 的错误:
[root@node0 opt]# hadoop jar hdfs-1.0-SNAPSHOT.jar WordCountDriver /data/input /data/output11
18/09/18 02:18:08 INFO client.RMProxy: Connecting to ResourceManager at node1/192.168.80.9:8032
18/09/18 02:18:09 WARN mapreduce.JobResourceUploader: Hadoop command-line option parsing not performed. Implement the Tool interface and execute your application with ToolRunner to remedy this.
18/09/18 02:18:09 INFO mapreduce.JobSubmitter: Cleaning up the staging area /tmp/hadoop-yarn/staging/root/.staging/job_1537251454694_0001
Exception in thread "main" org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.hdfs.server.namenode.SafeModeException): Cannot delete /tmp/hadoop-yarn/staging/root/.staging/job_1537251454694_0001. Name node is in safe mode.(目前处于安全模式)
The reported blocks 9 has reached the threshold 0.9990 of total blocks 9. The number of live datanodes 3 has reached the minimum number 0. In safe mode extension. Safe mode will be turned off automatically in 14 seconds.(需要等待14s后自动退出安全模式)
……
主要内容是部分的内容:
Name node is in safe mode.(目前处于安全模式)
The reported blocks 9 has reached the threshold 0.9990 of total blocks 9.
The number of live datanodes 3 has reached the minimum number 0.
In safe mode extension.
Safe mode will be turned off automatically in 14 seconds.
(需要等待14s后自动退出安全模式)
NameNode
发现集群中的Block
丢失数量达到一个阀值时,NameNode
就进入安全模式状态,不再接受客户端的数据更新请求。NameNode
退出安全模式,bin/hdfs dfsadmin -safemode leave
,或者:调整safemode
门限值:dfs.safemode.threshold.pct=0.999f
。NameNode
的重要性是显而易见的,在实际应用中,常将NameNode
上的持久化存储的元数据文件转储到其他文件系统中,这种转储是同步的、原子的操作。
在Hadoop
系统中,系统同步运行一个Secondary NameNode
。这个结点的主要作用就是周期性地合并编辑日志中的命名空间镜像,以避免编辑日志过大。Secondary NameNode
需要占用大量的CPU、内存去做合并操作,因此常常将Secondary NameNode
防止在单独一台机器上。在这台机器上定时合并NameNode
上的镜像文件和日志,但是由于Secondary NameNode
的同步备份总是滞后于NameNode
,所以损失是必然的。
序号 | 说明 |
---|---|
1 | NameNode 发现部分文件的Block 不符合最小复制数这一要求或者部分DataNode 失效。 |
2 | 通知DataNode 相互复制Block 。 |
3 | DataNode 开始直接相互复制。 |
当客户端要写入文件到DataNode
上时,首先会读取一个Block
,然后将其写到第一个DataNode
上,接着由第一个DataNode
将其传递到备份的DataNode
上,直到所有需要写入这个Block
的DataNode
都成功写入后,客户端才会开始写下一个Block
。
hadoop之——datanode节点超时时间设置
DataNode
进程死亡或者网络故障造成DataNode
无法与NameNode
通信,NameNode
不会立即把该节点判定为死亡,要经过一段时间,这段时间暂称作超时时长。HDFS默认的超时时长为 10 分 钟 + 30 秒 10分钟+30秒 10分钟+30秒。如果定义超时时间为timeout
,则超时时长的计算公式为:
t i m e o u t = 2 ∗ h e a r t b e a t . r e c h e c k . i n t e r v a l + 10 ∗ d f s . h e a r t b e a t . i n t e r v a l timeout = 2 * heartbeat.recheck.interval + 10 * dfs.heartbeat.interval timeout=2∗heartbeat.recheck.interval+10∗dfs.heartbeat.interval
而默认的 h e a r t b e a t . r e c h e c k . i n t e r v a l heartbeat.recheck.interval heartbeat.recheck.interval大小为 5 分 钟 5分钟 5分钟, d f s . h e a r t b e a t . i n t e r v a l dfs.heartbeat.interval dfs.heartbeat.interval默认为 3 秒 3秒 3秒。需要注意的是hdfs-site.xml
配置文件中的 h e a r t b e a t . r e c h e c k . i n t e r v a l heartbeat.recheck.interval heartbeat.recheck.interval的单位为毫秒, d f s . h e a r t b e a t . i n t e r v a l dfs.heartbeat.interval dfs.heartbeat.interval的单位为秒。
举个例子,如果 h e a r t b e a t . r e c h e c k . i n t e r v a l heartbeat.recheck.interval heartbeat.recheck.interval设置为 5000 m s 5000ms 5000ms(毫秒,默认), d f s . h e a r t b e a t . i n t e r v a l dfs.heartbeat.interval dfs.heartbeat.interval设置为 3 s 3s 3s(秒,默认),则总的超时时间为 40 s 40s 40s。
hdfs-site.xml
中的参数设置格式:
<property>
<name>heartbeat.recheck.intervalname>
<value>5000value>
property>
<property>
<name>dfs.heartbeat.intervalname>
<value>3value>
property>
在日常维护Hadoop
集群的过程中发现这样一种情况:某个节点由于网络故障或者DataNode
进程死亡,被NameNode
判定为死亡,HDFS
马上自动开始数据块的容错拷贝;当该节点重新添加到集群中时,由于该节点上的数据其实并没有损坏,所以造成了HDFS
上某些Block
的备份数超过了设定的备份数。通过观察发现,这些多余的数据块经过很长的一段时间才会被完全删除掉,那么这个时间取决于什么呢?
该时间的长短跟数据块报告的间隔时间有关。Datanode
会定期将当前该结点上所有的Block
信息报告给Namenode
,参数 d f s . b l o c k r e p o r t . i n t e r v a l M s e c dfs.blockreport.intervalMsec dfs.blockreport.intervalMsec就是控制这个报告间隔的参数。
hdfs-site.xml
文件中有一个参数:
<property>
<name>dfs.blockreport.intervalMsecname>
<value>3600000value>
<description>Determines block reporting interval in milliseconds.description>
property>
其中 3600000 3600000 3600000为默认设置, 3600000 3600000 3600000毫秒,即 1 个 小 时 1个小时 1个小时,也就是说,块报告的时间间隔为 1 个 小 时 1个小时 1个小时,所以经过了很长时间这些多余的块才被删除掉。通过实际测试发现,当把该参数调整的稍小一点的时候( 60 秒 60秒 60秒),多余的数据块确实很快就被删除了。