这篇文章将为大家详细讲解有关HDFS工作机制是什么，小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。
我们提供的服务有：成都网站建设、网站建设、微信公众号开发、网站优化、网站认证、喀什ssl等。为成百上千企事业单位解决了网站和推广的问题。提供周到的售前咨询和贴心的售后服务，是有科学管理、有技术的喀什网站制作公司
HDFS（Hadoop Distributed File System）分布式文件系统，它是谷歌的GFS提出后出现的一种用户级文件系统。提供了一个高度容错和高吞吐量的海量数据存储解决方案。
hadoop生态-HDFS的核心位置
1
2
3
常见错误种类
节点故障
通信故障和数据损坏
读写故障
以上是漫画解说部分，主要涵盖了读写流程已经故障处理。下面会有具体的架构讲解。
维护和管理DataNodes
管理文件系统namespace并控制client对应的访问权限
记录所有存储在集群中的文件的元信息。eg: blocks存储的位置、文件的大小、权限、文件结构等，有两个文件和元数据关联着FsImage
保存了最新的元数据检查点，包含了整个HDFS文件系统的所有目录和文件的信息。对于文件来说包括了数据块描述信息、修改时间、访问时间等；对于目录来说包括修改时间、访问权限控制信息(目录所属用户，所在组)等。
一般开始时namenode的操作都放在EditLog中，然后通过异步更新。EditLog
记录最近通过namenode对文件系统的所有修改操作。
记录文件系统的所有操作元数据。 存储在 EditLogs
维护着与DataNodes的心跳检测
DataNodes磁盘存储均衡、DataNodes故障转移
数据存储节点
它的主要职责
备用节点，也称为standby namenode。NameNode是HDFS的大脑核心，一旦NameNode出现不可用，那么整个HDFS集群将不可用，Secondary NameNode作为NameNode的备用节点，进行NameNode容错
负责合并Editlogs和FsImage
定时从 namenode 下载Editlogs并和现有FsImage进行合并，然后将合并后的FsImage更新到namenode
FailoverController
故障切换器，管理着将活动namenode转移为备用namenode的过程，默认通过ZK来确保仅有一个活跃namenode。每一个namenode都有一个运行着的故障转移器。
用于平衡DataNode集群之间各节点的磁盘利用率。
提供Http方式访问和操作HDFS功能
上面几个概念的拓扑图
HDFS里的数据都是以blocks分散在DataNodes。
通常，文件系统我们存放数据都是以一个blocks集进行存储，HDFS也是如此。
在 hadoop 集群中，每个 block 的默认大小为 128M（此处指 hadoop 2.x 版本，hadoop 1.x 版本为 64M），也可以通过配置进行修改
dfs.block.size或 dfs.blocksize =64M
HDFS 不会将每个文件存储在配置的 block 大小的确切倍数中，比如一个 514M 的文件 example.txt，下图所示，假设 block 大小为默认的 128M，那么将会创建 5 个block，前 4 个 block 大小为 128M，但是最后一个 block 的大小则仅为 2M。
block大小的设置，如果太小会产生太多的blocks，这样元数据就会很多，从而使管理blocks和元数据产生巨大开销，增加NameNode和DataNode的负载。
假如我们要一个文件名字“example.txt”，248M。
假设block.size设置的128M，因此client会把该文件切分成两个block，分布是 128M和120M。
每当向HDFS写数据的时候，都遵循下面的几个流程
HDFS client 向NameNode 发送 两个blocks（blockA、blockB）的写入请求
NameNode给client进行写入授权并提供用来进行存储和复制的DataNodes IP
DataNodes基于HDFS可用性、复制因子和机架感知的选择是完全随机的
假设复制因子设置的是3，那么NameNode将为每个blocks提供3个DataNodes IP。 相对每个block提供的3个DataNodes都是唯一的。假设NameNode提供的DataNodes列表如下：
For Block A, list A = {IP of DataNode 1, IP of DataNode 4, IP of DataNode 6}
For Block B, set B = {IP of DataNode 3, IP of DataNode 7, IP of DataNode 9}
每个block将在三个不同的DataNode进行复制，维持整个集群的复制因子一致性
接下来整个数据将会经历下面三个阶段：1建立管道 2数据流与复制 3管道关闭及确认
client在blocks写入之前会确保提供的DataNodes是否已经做好接受数据的准备。在这样的情况下，client会连接该block列表中的各个DataNodes，为每个block建一个管道。以BlockA举例，它的DN(DataNode)列表是 { DN 1 IP， DN 4 IP, DN 6 IP }
如上图，大概有一下几个步骤：
client 拿着 blockA 向 NameNode发起写请求
NameNode返回一组可供存储和复制的DN IP列表
client向 DN1 进行写入准备确认，同时会告诉DN1接下来要进行复制的DN4和DN6的IP
DN1 会向 DN4发起写入准备确认，依次类推DN4给DN6发送确认
DN6 确认完毕回传给 DN4，DN4确认后会将自己以及DN6的确认信息给DN1，最后DN1将三个DN的确认结果答复给client
管道建立完毕，client将开始进行数据复制或者数据处理
当client与DataNodes之间的管道建立之后，client将开始将推送数据到管道。我们这里假设的复制因子是3，所以blockA将被复制三份，但是注意的是client只会将blockA推送到DN1，然后由DataNodes自己按照顺序进行复制。
如上图所示，整个复制过程步骤如下：
client 将blockA写入DN1，接着DN1连接DN4
DN1通过管道向DN4复制数据
DN4数据写完后会继续连接DN6进行最后一份数据的复制
当block复制3份完成后，client和NameNode会有一系列的ack确认来保证数据被成功写入。
如下图所示，DataNodes的确认和写入的顺序恰好相反，DN6写入成功后会给DN4发送确认消息，接着DN4会将DN6和自己的确认消息发送给DN1，最后DN1将所有的确认消息发送给client，client再给NameNode确认block写入成功，然后NameNode更新对应的元数据，最终client关闭管道。
以上的所有流程，我们都是针对blockA进行解说，而blockB是完全一样的，blockB有自己的管道、自己的DataNodes并行的进行写入。
如上图所示，有两个管道分别为blokA和blockB提供，他们各自的流程顺序如下：
For Block A: 1A -> 2A -> 3A -> 4A
For Block B: 1B -> 2B -> 3B -> 4B -> 5B -> 6B
读的原理相对写更容易理解，我们同样以example.txt举例。
如上图所示，有以下几个步骤
client请求NameNode 要读取example.txt的数据，NameNode查询元数据，将该文件对应的所有block及对应的DataNode列表返回
client并行的分别从DataNodes读取blockA和blockB的数据。为了保证低延迟和节约带宽，通常会选择离client近的副本进行读取，如果可能，会选择和阅读节点在同一个机架上的副本（如图中所示，选择了Rack1, blockA和blockB都有对应的副本）
client一旦获取到所有的block，就会开始组装成文件，并返回。
关于“HDFS工作机制是什么”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。