HDFS架构

1、 HDFS的架构图之基础架构

HDFS是使用Java语言构建的; 任何支持Java的机器都可以运行NameNode或DataNode软件。使用高度可移植的Java语言意味着可以在各种计算机上部署HDFS。
集群中存在单个NameNode，极大地简化了系统的体系结构。NameNode是所有HDFS元数据的仲裁者和存储库。系统设计使用户数据永远不会流经NameNode。

1、 NameNode是一个中心服务器，单一节点（简化系统的设计和实现），负责管理文件系统的名字空间（namespace）以及客户端对文件的访问。NameNode记录对文件系统命名空间或其属性的任何更改。应用程序可以指定应由HDFS维护的文件的副本数。文件的副本数称为该文件的复制因子。该信息由NameNode存储。
2、 文件操作，namenode是负责文件元数据的操作，datanode负责处理文件内容的读写请求，跟文件内容相关的数据流不经过Namenode，只询问它跟哪个dataNode联系，否则NameNode会成为系统的瓶颈。
3、 副本存放在哪些Datanode上由NameNode来控制，根据全局情况作出块放置决定，读取文件时NameNode尽量让用户先读取最近的副本，降低读取网络开销和读取延时。
4、 NameNode全权管理数据库的复制，它周期性的从集群中的每个DataNode接收心跳信合和状态报告，接收到心跳信号意味着DataNode节点工作正常，块状态报告包含了一个该DataNode上所有的数据列表。

2、文件副本机制以及block块存储

所有的文件都是以block块的方式存放在HDFS文件系统当中，在hadoop1当中，文件的block块默认大小是64M，hadoop2当中，文件的block块大小默认是128M，block块的大小可以通过hdfs-site.xml当中的配置文件进行指定。

 <property>
        <name>dfs.block.size</name>
        <value>131072</value>//只写数值就可以，单位为kB
    </property>

抽象成数据块的好处

1. 使用数据块而不是文件可以简化存储子系统
2. 块非常适合用于数据备份，进而提供数据容错能力和可用性
   3.一个文件有可能大于集群中任意一个磁盘
   10T*3/128 = xxx块 2T，2T，2T 文件方式存—–>多个block块，这些block块属于一个文件

块缓存

通常DataNode从磁盘中读取块，但对于访问频繁的文件，其对应的块可能被显示的缓存在DataNode的内存中，以堆外块缓存的形式存在。默认情况下，一个块仅缓存在一个DataNode的内存中，当然可以针对每个文件配置DataNode的数量。作业调度器通过在缓存块的DataNode上运行任务，可以利用块缓存的优势提高读操作的性能。
例如一个文件 130M，会被切分成2个block块，保存在两个block块里面，实际占用磁盘130M空间，而不是占用256M的磁盘空间

hdfs的文件权限验证

hdfs的文件权限机制与linux系统的文件权限机制类似
r:read w:write x:execute 权限x对于文件表示忽略，对于文件夹表示是否有权限访问其内容
如果linux系统用户zhangsan使用hadoop命令创建一个文件，那么这个文件在HDFS当中的owner就是zhangsan

副本选择

为了最小化全局带宽消耗和读取延迟，HDFS尝试满足最接近读取器的副本的读取请求。如果在与读取器节点相同的机架上存在副本，则该副本首选满足读取请求。如果HDFS集群跨越多个数据中心，则驻留在本地数据中心的副本优先于任何远程副本。

3、通信协议

所有HDFS通信协议都分层在TCP / IP协议之上。
客户端与NameNode计算机上的可配置TCP端口建立连接。它将ClientProtocol与NameNode进行了对话。DataNode使用DataNode协议与NameNode通信。远程过程调用（RPC）抽象包装了客户端协议和DataNode协议。
按照设计，NameNode永远不会启动任何RPC。相反，它只响应DataNodes或客户端发出的RPC请求。

4、稳健性

HDFS的主要目标是即使在出现故障时也能可靠地存储数据。三种常见的故障类型是NameNode故障，DataNode故障和网络分区。

网络分区故障，心跳检测和重新复制

每个DataNode定期向NameNode发送Heartbeat消息。网络分区可能导致DataNode的子集失去与NameNode的连接。
NameNode通过缺少Heartbeat消息来检测此情况。NameNode将DataBodes标记为没有最近的Heartbeats，并且不会将任何新的IO请求转发给它们。死掉的DataNode的任何数据对于集群来说都不再可用。
DataNode死亡可能导致某些块的复制因子低于其指定值。NameNode不断跟踪需要复制的block块，并在必要时启动重新复制。
由于以下原因可能会出现重新复制的必要性：DataNode可能变得不可用，副本可能会损坏，DataNode上的硬盘可能会失效。

集群重新平衡

HDFS架构与数据重新平衡方案兼容。如果DataNode上的可用空间低于某个阈值，则平衡方案可能会自动将数据从一个DataNode移动到另一个DataNode。如果对特定文件的需求突然增高，则方案可以动态创建其他副本并重新平衡群集中的其他数据。这些类型的数据重新平衡方案（2.x）尚未实施。

数据的完整性

从DataNode获取的数据块可能已损坏。由于存储设备中的故障，网络故障或有缺陷的软件，可能会发生此损坏。HDFS客户端软件对HDFS文件的内容进行校验和检查。当客户端创建HDFS文件时，它会计算文件每个块的校验和，并将这些校验和存储在同一HDFS命名空间中的单独隐藏文件中。当客户端检索文件内容时，它会验证从每个DataNode接收的数据是否与存储在关联校验和文件中的校验和相匹配。如果不是，则客户端可以选择从具有该块的副本的另一个DataNode中检索该块。

元数据磁盘故障

FsImage和EditLog是HDFS的中心数据结构。这些文件损坏可能导致HDFS实例无法正常运行。因此，可以将NameNode配置为支持维护FsImage和EditLog的多个副本。对FsImage或EditLog的任何更新都会导致每个FsImages和EditLogs同步更新。这种FsImage和EditLog的多个副本的同步更新可能会降低NameNode可以支持的每秒命名空间事务的速率。但是，这种降级是可以接受的，因为即使HDFS应用程序本质上是数据密集型的，它们也不是元数据密集型的。
当NameNode重新启动时，它会选择要使用的最新一致FsImage和EditLog。


NameNode计算机是HDFS集群的单点故障。如果NameNode计算机出现故障，则需要手动干预。目前，不支持将NameNode软件自动重启和故障转移到另一台机器。

参考文档：`http://archive.cloudera.com/cdh5/cdh/5/hadoop-2.6.0-cdh5.14.0/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html`