HDFS 读写流程与进程角色工作机制

1、HDFS 总结

1、HDFS 集群分为两大主要角色：namenode、datanode (secondarynamenode 和 client) 。
2、namenode 负责管理整个文件系统的元数据，并且负责响应客户端的请求。
3、datanode 负责管理用户的文件数据块，并且通过心跳机制汇报给 namenode。
4、文件会按照固定的大小(dfs.blocksize)切成若干块后分布式存储在若干台 datanode 上。
5、每一个文件块可以有多个副本，并存放在不同的 datanode 上 。
6、datanode 会定期向 namenode 汇报自身所保存的文件 block 信息，而 namenode 则会负责保持文件的副本数量。
7、HDFS 的内部工作机制对客户端保持透明，客户端请求访问 HDFS 都是通过向 namenode 申请来进行。

2、HDFS 的读写流程

2.1、写流程

1、客户端要向 HDFS 写数据，首先要跟 namenode 通信以确认可以写文件并获得接收文件 block 的 datanode，然后，客户端按顺序将文件逐个 block 传递给相应 datanode，并由接收到 block 的 datanode 负责向其他 datanode 复制 block 的副本。
（1） client 发写数据请求；
（2） namenode 响应请求，然后做一系列校验，如果能上传该数据，则返回该文件的所有切块应该被存在哪些 datanode 上的 datanodes 列表：
blk-001: hadoop02 hadoop03
blk-002: hadoop01 hadoop02
（3） client 拿到 datanode 列表之后，开始传数据；
（4） 首先传第一块 blk-001，datanode 列表就是 hadoop02,hadoop03，client 就把 blk-001 传到 hadoop02 和 hadoop03 上；
（5） ……… 用传第一个数据块同样的方式传其他的数据块；（6） 当所有的数据块都传完之后，client 会给 namenode 返回一个状态信息，表示数据已全部写入成功，或者是失败的信息；
（7） namenode 接收到 client 返回的状态信息来判断当次写入数据的请求是否成功，如果成功，就需要更新元数据信息。


2、详细步骤文字说明：
（1）使用 HDFS 提供的客户端 Client，向远程的 namenode 发起 RPC 请求。
（2）namenode 会检查要创建的文件是否已经存在，创建者是否有权限进行操作，成功则会为文件创建一个记录，否则会让客户端抛出异常。
（3）当客户端开始写入文件的时候，客户端会将文件切分成多个 packets 包队列，并在内部以数据队列“data queue（数据队列）”的形式管理这些 packets 包队列，并向 namenode 申请 blocks，获取用来存储 replicas 的合适的 datanode 列表，列表的大小根据 namenode 中 replication 的设定而定。
（4）开始以 pipeline（管道）的形式将 packet 写入所有的 replicas 中。客户端把 packet 以流的方式写入第一个 datanode，该 datanode 把该 packet 存储之后，再将其传递给在此 pipeline 中的下一个 datanode，直到最后一个 datanode，这种写数据的方式呈流水线的形式。
（5）最后一个 datanode 成功存储之后会返回一个 ack packet（确认队列），在 pipeline 里传递至客户端，在客户端的开发库内部维护着"ack queue"，成功收到 datanode 返回的 ack packet 后会从"data queue"移除相应的 packet。
（6）如果传输过程中，有某个 datanode 出现了故障，那么当前的 pipeline 会被关闭，出现故障的 datanode 会从当前的 pipeline 中移除，剩余的 block 会继续剩下的 datanode 中继续
以 pipeline 的形式传输，同时 namenode 会分配一个新的 datanode，保持 replicas 设定的数量。
（7）客户端完成数据的写入后，会对数据流调用 close()方法，关闭数据流。
（8）只要写入了 dfs.replication.min（最小写入成功的副本数）的复本数（默认为 1），写操作就会成功，并且这个块可以在集群中异步复制，直到达到其目标复本数（dfs.replication
的默认值为 3），因为 namenode 已经知道文件由哪些块组成，所以它在返回成功前只需要等待数据块进行最小量的复制。

2.2、读流程

1、客户端将要读取的文件路径发送给 namenode，namenode 获取文件的元信息（主要是 block 的存放位置信息）返回给客户端，客户端根据返回的信息找到相应 datanode 逐个获取文件的 block 并在客户端本地进行数据追加合并从而获得整个文件。


2、详细步骤文字说明：
（1）使用 HDFS 提供的客户端 Client，向远程的 namenode 发起 RPC 请求；
（2）namenode 会视情况返回文件的全部 block 列表，对于每个 block，namenode 都会返回有该 block 拷贝的 datanode 地址；
（3）客户端 Client 会选取离客户端最近的 datanode 来读取block；如果客户端本身就是datanode，那么将从本地直接获取数据；
（4）读取完当前 block 的数据后，关闭当前的 datanode 链接，并为读取下一个 block 寻找最佳的 datanode；
（5）当读完列表 block 后，且文件读取还没有结束，客户端会继续向 namenode 获取下一批的 block 列表；
（6）读取完一个 block 都会进行 checksum 验证，如果读取 datanode 时出现错误，客户端会通知 namenode，然后再从下一个拥有该 block 拷贝的 datanode 继续读。

3、NameNode 工作机制

1、学习目标：理解 namenode 的工作机制尤其是元数据管理机制，以增强对 HDFS 工作原理的理解，及培养 hadoop 集群运营中“性能调优”、“namenode”故障问题的分析解决能力。
2、问题场景：
（1）Namenode 服务器的磁盘故障导致 namenode 宕机，如何挽救集群及数据？
（2）Namenode 是否可以有多个？namenode 内存要配置多大？namenode 跟集群数据存储能力有关系吗？
（3）文件的 blocksize 究竟调大好还是调小好？结合 mapreduce。
…
诸如此类问题的回答，都需要基于对 namenode 自身的工作原理的深刻理解。
3、namemode的架构(metadata)
（1） namenode 磁盘故障？
a、修复磁盘；
b、不可修复（1、避免发生 ----> 备份 standby -----> 高可用集群HA；2、secondarynamenode 辅助 ----> 元数据复制到 namenode ------> 不完整修复（部分元数据镜像数据不存在））。
（2）namenode 可以有多个，但是正在活动的完整的 namenode 只能有一个。
a、HDFS 是主从架构（一主多从）；
b、HA —> active namenode + standby namenode；
fera ----> 多个 active namenode ，每一个都不是完整的 namenode，每一个active namenode只负责部分业务，业务分离。
（3）namenode 和集群存储能力有关？（元数据）
a、有；
b、每一条 block 元数据 = 150Byte（内存+磁盘）。
（4）blocksize 调大调小好？
a、存储（大 —> 单位负载 / 上传；小 ----> namenode 压力大）；
b、计算（并行 汇总）。
4、NameNode 职责：
（1）负责客户端请求（读写数据请求）的响应。
（2）维护目录树结构（元数据的管理：查询，修改）。
（3）配置和应用副本存放策略。
（4）管理集群数据块负载均衡问题。
5、NameNode 元数据管理：
（1）WAL（Write ahead Log）: 预写日志系统
在计算机科学中，预写式日志（Write-ahead logging，缩写 WAL）是关系数据库系统中用于提供原子性和持久性（ACID 属性中的两个）的一系列技术。在使用 WAL 的系统中，所
有的修改在提交之前都要先写入 log 文件中。
Log 文件中通常包括 redo 和 undo 信息。这样做的目的可以通过一个例子来说明。假设一个程序在执行某些操作的过程中机器掉电了。在重新启动时，程序可能需要知道当时执行的操作是成功了还是部分成功或者是失败了。如果使用了 WAL，程序就可以检查 log 文件，并对突然掉电时计划执行的操作内容跟实际上执行的操作内容进行比较。在这个比较的基础上，程序就可以决定是撤销已做的操作还是继续完成已做的操作，或者是保持原样。
WAL 允许用 in-place 方式更新数据库。另一种用来实现原子更新的方法是 shadow paging，它并不是 in-place 方式。用 in-place 方式做更新的主要优点是减少索引和块列表的修改。ARIES 是 WAL 系列技术常用的算法。在文件系统中，WAL 通常称为 journaling。PostgreSQL 也是用 WAL 来提供 point-in-time 恢复和数据库复制特性。
（2）NameNode 对数据的管理采用了两种存储形式：内存和磁盘。
（3）内存：包含了完整的 metadata（预写日志 + 元数据镜像文件）；
磁盘：
a、历史操作日志文件：
edits_0000000000000000001-0000000000000000018
b、元数据的镜像文件（所有的历史操作日志文件合并并序列化的文件）：
fsimage_0000000000000000555
c、预写操作的日志文件：
edits_inprogress_0000000000000000556

metadata = 最新 fsimage_0000000000000000555 + edits_inprogress_0000000000000000556
metadata = 所有的 edits 之和（edits_001_002 + …… + edits_444_555 + edits_inprogress_556）

6、VERSION（存放 hdfs 集群的版本信息）文件解析：

#Sun Jan 06 20:12:30 CST 2017 ## 集群启动时间
namespaceID=844434736 ## 文件系统唯一标识符
clusterID=CID-5b7b7321-e43f-456e-bf41-18e77c5e5a40 ## 集群唯一标识符
cTime=0 ## fsimage 创建的时间，初始为 0，随 layoutVersion 更新
storageType=NAME_NODE ##节点类型
blockpoolID=BP-265332847-192.168.123.202-1483581570658 ## 数据块池 ID，可以有多个
layoutVersion=-60 ## hdfs 持久化数据结构的版本号

7、查看 edits 文件信息：

hdfs oev -i edits_0000000000000000482-0000000000000000483 -o edits.xml
cat edits.xml

8、查看 fsimage 镜像文件信息：

hdfs oiv -i fsimage_0000000000000000348 -p XML -o fsimage.xml
cat fsimage.xml

9、NameNode 元数据存储机制：
A、内存中有一份完整的元数据(内存 metadata)。
B、磁盘有一个“准完整”的元数据镜像（fsimage）文件(在 namenode 的工作目录中) C、用于衔接内存 metadata 和持久化元数据镜像 fsimage 之间的操作日志（edits 文件）。

PS：当客户端对 hdfs 中的文件进行新增或者修改操作，操作记录首先被记入 edits 日志文件中，当客户端操作成功后，相应的元数据会更新到内存 metadata 中。

10、元数据的 CheckPoint：
每隔一段时间，会由 secondary namenode 将 namenode 上积累的所有 edits 和一个最新的 fsimage 下载到本地，并加载到内存进行 merge（这个过程称为 checkpoint）。

11、CheckPoint 触发配置：

dfs.namenode.checkpoint.check.period=60 ##检查触发条件是否满足的频率，60 秒
dfs.namenode.checkpoint.dir=file://${hadoop.tmp.dir}/dfs/namesecondary
##以上两个参数做 checkpoint 操作时，secondary namenode 的本地工作目录
dfs.namenode.checkpoint.edits.dir=${dfs.namenode.checkpoint.dir}
dfs.namenode.checkpoint.max-retries=3 ##最大重试次数
dfs.namenode.checkpoint.period=3600 ##两次 checkpoint 之间的时间间隔 3600 秒
dfs.namenode.checkpoint.txns=1000000 ##两次 checkpoint 之间最大的操作记录

12、CheckPoint 附带作用：
Namenode 和 SecondaryNamenode 的工作目录存储结构完全相同，所以，当 Namenode 故障退出需要重新恢复时，可以从 SecondaryNamenode 的工作目录中将 fsimage 拷贝到Namenode 的工作目录，以恢复 namenode 的元数据。

4、DataNode 工作机制

1、问题场景：
（1）集群容量不够，怎么扩容？
添加 datanode 节点，注意 namenode 的压力，合理添加。
（2）如果有一些 datanode 宕机，该怎么办？
a、datanode 内存故障，重启。
b、datanode 磁盘故障（（1）block 没有丢失 ------> 影响不大，处理硬盘；（2）block 块丢失，低于 0.1% ------> 集群没有进入 safemode，此时要防止出现大批量的宕机 -----> 多副本：可靠性，副本都损坏，那没得办法）。（3）block 块丢失，大于 0.1% ------> 进入 safemode模式，一定解决（解决 ----> 自动退出）。
（3）datanode 明明已启动，但是集群中的可用 datanode 列表中就是没有，怎么办？
a、datanode 有可能启动失败（查看 jps，如果启动失败查看日志）；
b、启动成功：jps —> 看到，web —> 看不到 ----> web展示的通信端口50010问题，进程不能正常通信（将死状态，虚拟机的”挂起“问题）。

2、Datanode 工作职责：
（1）存储管理用户的文件块数据。
（2）定期向 namenode 汇报自身所持有的 block 信息（通过心跳信息上报）。
（PS：这点很重要，因为，当集群中发生某些 block 副本失效时，集群如何恢复 block 初始副本数量的问题）
（3）namenode 断定 datanode 故障失效的时间，心跳机制。
3、功能：
上传一个文件，观察文件的 block 具体的物理存放情况：
在每一台 datanode 机器上的这个目录中能找到文件的切块：
/home/hadoop/hadoopdata/data/current/BP-771296455-192.168.123.106-1504830258603/current/finalized/subdir0/subdir0

5、SecondaryNamenode 工作机制

SecondaryNamenode 的作用就是分担 namenode 的合并元数据的压力。所以在配置 SecondaryNamenode 的工作节点时，一定切记，不要和 namenode 处于同一节点。但事实上，只有在普通的伪分布式集群和分布式集群中才有会 SecondaryNamenode 这个角色，在 HA 或者联邦集群中都不再出现该角色。在 HA 和联邦集群中，都是有 standby namenode 承担。
就是 CheckPoint 的工作机制；
请看元数据的 CheckPoint。

6、学习内容

上节学习内容：HDFS 的四大核心设计
下节学习内容：MapReduce 入门案例wordcount