Hadoop文件存储的基础是HDFS(Hadoop Distributed File System),HDFS的实现依赖于NameNode和DataNode,DataNode用来存储具体数据,NameNode用来管理多个DataNode中分别存储的是什么。
理解起来也不难,因为HDFS是分布式的文件系统,也就是有很多机器用来存储数据,一个大文件可能分布在多个机器上,也可能是一台机器上,具体分布在哪些或哪个机器上,每块数据块的副本在哪,得需要一个总管来管理,这个总管就是NameNode,具体存储机器的就是DataNode。
简单的说完了,接下来就复杂的说。
- HDFS架构
HDFS是主/从架构,一个HDFS只有一个NameNode(这里的一个是指起作用的只有一个,在NameNode的HA状态下,也是只有一个NameNode起作用,其他的NameNode节点只是备份,家有千口,主事一人嘛)。这个NameNode管理整个文件系统的命名空间(The File System Namespace),并且调节客户端对文件的访问。DataNode用来存储数据,还有一些DataNode用来管理连接到运行节点的存储。HDFS公开文件系统的命名空间,允许用户在文件系统中存储数据。
在HDFS内部,一个文件被分割为一个或多个数据块,这些数据块存储在一组DataNode上。NameNode负责文件系统的命名空间操作,比如对文件或文件夹执行打开、关闭,以及重命名操作,同时,也负责将数据块映射到DataNode上。DataNode负责向客户端提供对文件系统的读取和写入请求的处理。DataNode还能根据NameNode的指示,执行数据块的创建、删除和复制操作。
NameNode和DataNode通常运行在普通商用服务器上(这里是针对小型机这种又贵很又特别贵的机器说的),这些机器一般装的是Linux。HDFS使用Java实现的,而且Java号称是一处编译到处运行,也就是只要有Java环境,就能运行NameNode和DataNode。典型的部署方式是,一台机器运行NameNode,其他机器运行DataNode,每台机器一个进程。(当然也可能一台机器上有多个DataNode,但是生产环境应该不会有这种情况,毕竟没有任何好处)
HDFS的这种主从架构保证了,所有的数据都会从NameNode经过,这样也简化了系统的体系结构,NameNode就是老大,所有数据都经过他。当然老大也可能出现意外,就得需要其他HA的部署方式(找几个小弟时刻准备接替老大),这个后面再说。
- 文件系统
HDFS文件系统设计与传统分层文件系统类似,有文件夹,文件夹里可以有文件夹或文件。客户端可以对这些文件夹或文件进行操作,比如创建、删除、移动、重命名等。不过目前还不支持软连接和硬连接,后面可能会支持。
如前面所说,这个命名空间由NameNode维护。所有的文件/文件夹的名字、属性、复制因子都由NameNode记录。
- 数据复制
HDFS设计用于在大型集群中存储非常大的文件,它将每个文件存储为一组数据块块中,除了最后一块外,所有文件块大小相同(默认是64MB),HDFS通过复制数据块块进行容错,每个文件的数据块大小、复制因子都是可配的。客户端可以指定文件的副本数,可以在创建时指定,也可以在之后修改。HDFS中的文件是一次写入的,并且在任何时候都有一个明确的作者。
NameNode来管理所有数据块复制操作,它定期与集群中每个DataNode进行心跳和文件块报告。收到心跳意味着DataNode正常运行,文件块报告是DataNode上所有文件块的列表。
3.1 副本存储
副本存储的位置对于HDFS的可靠性和性能是至关重要的,优化副本存储是HDFS与大多数其他分布式文件系统区分开来的优点之一,这是一个经过大量调整和体验的功能。机架感知副本存储策略的目的是提高数据可靠性、可用性和网络带宽的高利用率。目前的副本存储策略是朝这个方向努力的第一步。实施这一政策的短期目标是对生产系统进行验证,更多的了解其行为,并为更加复杂的策略进行测试和研究奠定基础。
大型的HDFS实例通常运行在多个机架上,不同机架中的两个节点之间通信必须通过交换机。通产,同一机架上的机器之间的网络速率会优于不同机架间的速率。
NameNode通过Hadoop 机架感知中介绍的方式确定每个DataNode所属的机架ID。一个简单但不是最优策略是将副本存储在不同的机架上,这样可以防止整个机架故障导致数据丢失,并允许读取数据时使用多个机架的带宽。该策略保证可以在集群中均匀分配副本,可以轻松平衡组件故障时的负载。但是,这种策略会因为需要将副本数据写到多个机架,而增加写入成本。
常见情况中,复制因子是3,HDFS的副本存储策略是将一个副本放置在当前机架上的一个节点上,另一个位于另一个机架上的某个节点上,最后一个放置第二个机架上的另一个节点上。这种策略减少了机架间的通信,从而提高写入性能。机架故障的概率远小于节点故障的概率,这种策略不会影响数据可靠性和可用性。但是,它会降低读取数据的网络带宽,因为数据块放置在两个机架上,而不是三个。使用这种策略,副本不会均匀的分布在机架中。还有一种比较好的策略,就是三分之一的副本在一个节点上,三分之一的副本在另一个机架上,其余的均匀分布在其他机器上,这种方式可以改善写入策略,不会影响数据可靠性或读取性能。不过这种方式还在开发中。
3.2 副本选择
为了最大限度的减少全局带宽消耗和读取延迟,HDFS尝试让读取器读取最接近的副本。如果在同一机架上存在副本,就优先读取该副本。如果HDFS跨越多个数据中心,则优先读取当前数据中心的副本。
3.3 安全模式(SafeMode)
在启动的时候,NameNode进入一个成为安全模式的特殊状态。NameNode处于安全模式时,不会复制数据块。NameNode从DataNode节点接收心跳和数据块报告,数据块报告包含DataNode存储的数据块列表信息。每个数据块有指定的最小数量副本。当使用NameNode检入该数据块的最小副本数量时,数据块被认为是安全复制的。在NameNode检查数据块的安全复制结束后(可配的时间段,再加上30秒),NameNode退出安全模式。然后它开始检查是否有少于指定数量的数据块列表,将这些数据块复制到其他DataNode。
- 文件系统元数据
HDFS由NameNode存储命名空间信息,NameNode使用名为EditLog的事务日志持续记录文件系统元数据发生的每个更改。比如,在HDFS中创建一个新的文件会导致NameNode在EditLog中插入一条记录,用于记录该操作。同样的,修改文件的复制因子也会新增一条记录。NameNode使用本机文件系统存储EditLog文件。整个文件系统命名空间(包括块映射文件和文件系统属性等信息)存储在一个名为FsImage的文件中,该文件也是存储在NameNode所在的本机文件系统中。
NameNode在内存中存储整个文件系统的命名空间和文件数据块映射关系,这个元数据存储模块设计为紧凑存储,可以在4GB内存的NameNode中可以支持大量的文件和文件夹。在NameNode启动时,它从磁盘读取FsImage和EditLog,将所有从EditLog的事务应用到FsImage的内存表示中,并将这个新版本的FsImage文件中。该操作会截断旧的EditLog,因为其中的事务操作已经应用到FsImage文件中。这个过程成为检查点(checkpoint)。在当前版本中,检查点操作只会发生在NameNode启动时,正在增加定期检查点检查操作。
DataNode将HDFS数据存储在其本地文件系统的文件中,DataNode不知道HDFS的文件数据,它只是将HDFS文件数据的数据块存储在本地文件系统中的单独文件中。DataNode不会存储同一文件夹下的所有文件,相反,它会确定每个文件夹的最佳文件数量,并适当的创建子文件夹。在同一文件夹中创建所有本地文件是不合适的,因为本地文件系统可能无法在单个文件夹中有效支持存储大量文件。当DataNode启动时,它会扫描其本地文件系统,生产与每个文件对应的所有HDFS数据块数控报告,并发送给NameNode。
-
通信协议
所有HDFS的通信协议是基于TCP/IP协议的。客户端通过客户端协议与NameNode建立连接,并通信。DataNode通过DataNode协议与NameNode通信。NameNode从不发起通信请求,它只响应客户端和DataNode发出的请求。 -
稳健性
HDFS的主要目标是可靠性存储,即使发生故障,也能够很好的支撑存储。比较常见的故障类型有:NameNode故障、DataNode故障、网络分区异常。
6.1 数据磁盘故障,心跳和重新复制
每个DataNode会定期向NameNode发送心跳请求。网络分区可能导致一部分DataNode与NameNode失去连接,NameNode通过心跳检测这种情况,如果发现长时间没有心跳的DataNode,则标记为丢弃,而且不再转发任何新的IO请求,这些DataNode的数据也不在作用于HDFS。DataNode的死亡可能导致某些数据块的复制因子低于设定值,NameNode会不断扫描哪些数据块需要复制,并在必要的时候进行复制。重复复制可能是因为DataNode不可用、副本文件损坏、DataNode硬盘损坏,或者文件复制因子增加。
6.2 集群重新平衡
HDFS架构与数据重新平衡方案兼容,如果DataNode上的可用空间低于阀值,数据会从一个DataNode移动到另一个DataNode。在对特定文件的需求突然增加的情况下,可能会动态创建其他副本来重新平衡集群中的数据。(这种类型的数据重新平衡还未实现)。
6.3 数据的完整性
DataNode存储的数据块可能会被破坏,这可能是因为存储设备故障、网络故障或软件错误导致的。HDFS客户端会对HDFS文件内容进行校验和检查。当客户端创建一个HDFS文件时,它会计算文件的每个块的检验码,然后将该校验码存储在同一HDFS命名空间中的隐藏文件中。当客户端操作文件时,会将从DataNode接收到的数据与存储的校验文件进行校验和匹配。如果没有成功,客户端会从该数据块的其他副本读取数据。
6.4 元数据磁盘故障
FsImage和EditLog是HDFS的核心数据结构,如果这些文件被损坏,可能导致HDFS实例不可用。因此,NameNode可以配置维护FsImage和EditLog的多个副本。对FsImage或EditLog的任何更新,这些副本也跟着更新。当时这样可能会导致NameNode的TPS。但是,这种性能的降低是可以接受的,因为即使HDFS应用程序本质上是数据密集型,但却不是元数据密集型的。当NameNode重启时,它会选择最新的FsImage和EditLog使用。
比较常见的多备份存储是一份存在本地文件系统中,一份存储在远程网络文件系统中。
因为NameNode单点的,所以可能会出现HDFS集群的单点故障,需要手动干预。这个时候就需要NameNode的HA方案,这个后面再说。
6.5 Secondary NameNode
前面说过,NameNode是单点的,如果NameNode宕机,系统中的文件会丢失,所以Hadoop提供还提供了一种机制:Secondary NameNode。
Secondary NameNode比较有意思,它并不能直接作为NameNode使用,它只是定期将FsImage和EditLog合并,防止EditLog文件过大。通常Secondary NameNode也是运行在单独的机器上,因为日志合并操作需要占用大量的内存和CPU。Secondary NameNode会保存合并后的元数据,一旦NameNode宕机,而且元数据不可用,就可以使用Secondary NameNode备份的数据。
但是,Secondary NameNode总是落后与NameNode,所以在NameNode宕机后,数据丢失是不可避免的。一般这种情况就会使用元数据的远程备份与Secondary NameNode中的合并数据共同作为NameNode的元数据文件。
6.6 快照
快照功能支持在特定时刻存储数据副本,可以在出现数据损坏的情况下,将HDFS回滚到之前的时间点。(目前还不支持,之后会增加)
7 数据
7.1 数据块
HDFS是为了存储大文件的。与HDFS兼容的程序是处理大型数据集的,这些应用通常是一次写入,多次读取,并且要求在读取速率上满足要求。HDFS恰好满足“一次写入、多次读取”的要求。在HDFS中,数据块大小默认是64MB。所以,大文件在HDFS内存切成64MB的数据块,每个数据块会存储在不同的DataNode上。
7.2 阶段
客户端创建文件的请求不会立即到达NameNode。一开始,客户端将文件缓存到临时文件中,写入操作透明的重定向到该临时文件中。当临时文件超过一个HDFS数据块的大小时,客户端将连接NameNode,NameNode会把文件名插入到文件系统中,为其分配一个数据块。NameNode使用DataNode和目标数据块响应客户端请求。然后客户端将数据块信息从本地临时文件刷新到指定的DataNode中。关闭文件时,临时文件中剩余的未刷新数据将传输到DataNode,然后,客户端通知NameNode文件关闭,此时,NameNode将文件创建操作提交到持久存储。如果NameNode在文件关闭前宕机, 则文件丢失。
HDFS采用上述方式是经过仔细考虑的,这些应用需要流式写入文件,如果客户端写入远程文件时没有使用客户端缓冲,网速和网络情况将会大大影响吞吐率。这种做法也是有先例的,早起的分布式文件系统也是采用这种方式,比如ASF。POSIX要求已经放宽,以便实现高性能的数据上传。
7.3 复制流水线
如上所述,当客户端数据写入HDFS时,首先将数据写入本地缓存文件。如果HDFS文件的复制因子是3,当本地缓存文件大小累积到数据块大小时,客户端从NameNode查询写入副本的DataNode列表。然后,客户端将数据块刷新到第一个DataNode中,这个DataNode以小数据(4KB)接收数据,将数据写入本地存储库,并将该部分数据传输到第二个DataNode,第二个DataNode存储后,将数据发送给第三个DataNode。因此,DataNode可以在流水线中接收来自前一个的数据,同时将数据发送给流水线的下一个,以此类推。
8 易使用
可以以多种方式访问HDFS,HDFS提供了一个Java API,C语言包装器也可用。也可以使用浏览器浏览HDFS实例文件。(目前正在通过使用WebDAV协议公开HDFS)。
8.1 FS Shell
HDFS允许以文件和文件夹的形式组织数据,提供了一个名为“FS shell”的命令行界面,可让用户与HDFS中的数据进行交互。该命令集语法类似与用户熟悉的其他shell(比如bash,csh)。以下是一些实例:
操作 命令
创建/foodir文件夹 bin/hadoop dfs -mkdir /foodir
删除/foodir文件夹 bin/hadoop fs -rm -R /foodir
查看文件/foodir/myfile.txt的内容 bin/hadoop dfs -cat /foodir/myfile.txt
FS shell针对需要脚本语言与存储数据进行交互的应用场景。
8.2 DFSAdmin
DFSAdmin命令集用于管理HDFS集群,这些应该是由HDFS管理员使用的命令,以下是一些实例:
操作 命令
集群置为安全模式 bin/hadoop dfsadmin -safemode enter
生成DataNode列表 bin/hadoop dfsadmin -report
启动或停止DataNode bin/hadoop dfsadmin -refreshNodes
8.3 浏览器接口
典型的HDFS安装会配置web服务器,以配置TCP端口公开HDFS命名空间,这允许用户浏览HDFS命名空间,并使用web浏览器查看文件内容。
9 空间复用
9.1 文件删除
如果回收站功能可用,通过FS Shell删除的文件不会立马删除,而是移动到回收站中(每个用户的回收文件夹不同,是在各自的用户目录的.Trash中,即/user//.Trash)。只要文件还保留在回收站中,就可以很快恢复。
大多数的删除文件会移动到回收站的current目录(即/user//.Trash/Current)中,在配置的时间内,HDFS创建会创建检查点(/user//.Trash/),并在旧的检查点过期后删除。具体可以查看删除操作。
文件在回收站的时间过期后,NameNode会从HDFS命名空间中删除文件,同时,释放相关联的数据块空间。
文件删除后,客户端可以取消删除。可以通过浏览/trash文件夹,查找文件。/trash文件夹中包含被删除文件的最新副本。目前HDFS会从/trash删除超过6小时的文件。(/trash类似于文件系统中的回收站、垃圾桶等功能)。
下面是使用FS Shell删除文件的操作:
在当前目录中创建两个文件:test1、test2
$ hadoop fs -mkdir -p delete/test1
$ hadoop fs -mkdir -p delete/test2
$ hadoop fs -ls delete/
Found 2 items
drwxr-xr-x - hadoop hadoop 0 2015-05-08 12:39 delete/test1
drwxr-xr-x - hadoop hadoop 0 2015-05-08 12:40 delete/test2
删除test1:
$ hadoop fs -rm -r delete/test1
Moved: hdfs://localhost:8020/user/hadoop/delete/test1 to trash at: hdfs://localhost:8020/user/hadoop/.Trash/Current
使用skipTrash选项删除test2:
$ hadoop fs -rm -r -skipTrash delete/test2
Deleted delete/test2
查看回收站中的文件只有test1:
$ hadoop fs -ls .Trash/Current/user/hadoop/delete/
Found 1 items
drwxr-xr-x - hadoop hadoop 0 2015-05-08 12:39.Trash/Current/user/hadoop/delete/test1
也就是test1进入回收站,test2之间删除了。
9.2 减少复制因子
当文件的复制因子减少后,NameNode选择可以删除的多余副本,在下一个心跳时将信息传输给DataNode,DataNode删除相应的数据块,并释放空间。调用setReplication API和集群使用可用空间可能会有延迟。