大数据系列2:Hdfs的读写操作 |
您所在的位置:网站首页 › hdfs文件读取过程包括哪些步骤 › 大数据系列2:Hdfs的读写操作 |
在前文大数据系列1:一文初识Hdfs中,我们对Hdfs有了简单的认识。 在本文中,我们将会简单的介绍一下Hdfs文件的读写流程,为后续追踪读写流程的源码做准备。 Hdfs 架构首先来个Hdfs的架构图,图中中包含了Hdfs 的组成与一些操作。 对于一个客户端而言,对于Hdfs的操作不外乎也就读写两个操作,接下来就去看看整个流程是怎么走的。 下面我们由浅及深,分为简单流程,详细流程分别介绍读写过程 简单流程 读请求流程客户端需要读取数据的时候,流程大致如下: 客户端需要写入数据的时候,流程大致如下: 客户端需要读取数据的时候,流程大致如下: Client 读取数据流的时候,Block是按照DFSInputStream与DataNode打开新的连接的顺序读取的。 并且在有需要的时候,还会请求NameNode返回下一个批次Blocks的DataNode信息 在DFSInputStream与DataNode交互的时候出现错误,它会尝试选择这个Block另一个最近的DataNode,并且标记之前的DataNode避免后续的Block继续在该DataNode上面出错。 DFSInputStream也会对来自DataNode数据进行校验,一旦发现校验错误,也会从其他DataNode读取该Bclock的副本,并且向NamaNode上报Block错误信息。 整个流程下来,我们可以发现Client直接连接到DataNode检索数据并且通过NameNode知道每个Block的最佳DataNode。 这样设计有一个好处就是: 因为数据流量分布在集群中的所有DataNode上,所以允许Hdfs扩展到大量并发Client. 与此同时,NamaNode只需要响应Block的位置请求(这些请求存储在内存中,非常高效), 而不需要提供数据。 否则随着客户端数量的快速增加,NameNode会成为成为性能的瓶颈。 读请求流程客户端需要写入数据的时候,流程大致如下: 如果在写入的过程中发生了错误,会采取以下的操作: 关闭管道,并将所有在ack queue中的packets加到 data queue的前面,避免故障节点下游的DataNode发生数据丢失。 给该Block正常DataNode一个新的标记,将之告知NameNode,以便后续故障节点在恢复后能删除已写入的部分数据。 将故障节点从管道中移除,剩下的两个正常DataNodes重新组成管道,剩余的数据写入正常的DataNodes。 当NameNode发现备份不够的时候,它会在另一个DataNode上创建一个副本补全,随后该Blcok将被视为正常针对多个DataNode出现故障的情况,我们只要设置 dfs.NameNode.replication.min的副本数(默认为1),Block将跨集群异步复制,直到达到其目标复制因子( dfs.replication,默认为3)为止. 通俗易懂的理解上面的读写过程可以做一个类比, NameNode 可以看做是一个仓库管理员; DataNode 可以看作是仓库; 管理员负责管理商品,记录每个商品所在的仓库; 仓库负责存储商品,同时定期向管理员上报自己仓库中存储的商品; 此处的商品可以粗略的理解为我们的数据。 管理员只能有一个,而仓库可以有多个。 当我们需要出库的时候,得先去找管理员,在管理员处取得商品所在仓库的信息; 我们拿着这个信息到对应仓库提取我们需要的货物。 当我们需要入库的时候,也需要找管理员,核对权限后告诉我们那些仓库可以存储; 我们根据管理员提供的仓库信息,将商品入库到对应的仓库。 存在的问题上面是关于Hdfs读写流程介绍,虽然我分了简单和详细,但是实际的读写比这个过程复杂得多。 比如如何切块? 为何小于块大小的文件按照实际大小存储? 备份是如何实现的? Block的结构等等。 这些内容会在后续的源码部分详细解答。 此外,有人也许发现了,前文大数据系列1:一文初识Hdfs中Hdfs架构的介绍和本文读写的流程的介绍中,存在一个问题。 就是NameNode的单点故障问题。虽然之前有SecondaryNameNode 辅助NameNode合并fsiamge和edits,但是这个还是无法解决NameNode单点故障的问题。 很多人听过HA(High Availability) 即高可用,误以为高可用就是SecondaryNameNode,其实并不是。 在下一篇文章中会介绍Hdfs高可用的实现方式。 想了解更多内容观影关注:【兔八哥杂谈】 |
今日新闻 |
推荐新闻 |
CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |