【2-2】HDFS的架构,元数据,客户端的上传和读取

HDFS的架构(HDFS architecture)

Namenode:负责管理

DataNode:存储数据

Secondary NameNode:一个Namenode的秘书



当一个客户端client想读取数据时:首先跟namenode打交道,获取一些“元数据”Metadata。

然后namenode要查询它的元数据信息——元数据信息保存在【内存里?掉电就丢失了】内存一份,磁盘一份(磁盘保存了一份镜像)

之后把元数据信息返回给客户端。

比如要读512M的数据,(4块),依次读取。倘若读取前三块之后,第四块存在别的机器上,可以再去别的地方读取块4【数据就近原则:在哪台机器上读取数据快,离我近,就读哪个,走一次交换机就能达到数据,就不走五次】

当一个客户端client想写数据时:写的时候还会复制副本。(见上节)



元数据的存储细节:内存一份,磁盘一份。

namenode里有什么?(文件Filename,副本3,被切分成了几块{blk_1,blk_2},每一块被存放在哪台机器上,机器IP)


/test/a.log副本存了3份,被切分成了两块,第一块的三个副本存在了机器h0,h1,h3,第二块的三个副本存在h0,h2,h4

校验文件块是否损坏的方式:校验核(用原始的校验值和该文件的校验值相比较,以确定是否损坏)


什么是元数据:账本里的一条“账”,并不是真正的数据。


NameNode是干什么的:不仅仅是管理节点,还维护着文件系统的文件目录树。和文件,目录的元信息,和对应的数据块列表。还接受用户的请求【上传下载删除】

里面有:fsimage——元数据的镜像文件。存放在磁盘上【不是内存上】的叫fsimage,备份着内存中的元数据信息,但(伪分布式)并不是实时同步,真正的分布式是实时同

与之相对的,metadata存放在内存当中

edits:记录用户的操作日志。(该用户上传了一个文件,删除了一个文件,等等)

fstime:保存了用户最近一次checkpoint时间。即“最近一次做还原点的时间”


以上这些文件都是存在Linux文件系统里的,而不是HDFS。因为文件很小,在挂起的时候,将内存里的东西序列化到磁盘了,无需存在HDFS上

接下来,在Linux中找找这些东西


里面都是edits和fsimage文件。

NameNode的工作特点:namenode始终在内存中保存metadata【为了速度快】,用于处理用户的“读”请求。放在内存里当然很快了,放在磁盘里读的速度慢。

<think>嗯,用户让我帮忙做一个HDFS的架构图,里面包含元数据读取、NameNode、元数据存储、SecondNameNode、Client、DataNode、Block、数据块副本读取数据这些元素。首先,我需要确认这些组件之间的关系流程,确保架构图准确。 首先,HDFS的架构主要分为NameNode、DataNodeClient这几个核心部分。NameNode负责管理元数据,包括文件系统的命名空间、访问控制信息以及数据块到DataNode的映射。元数据存储应该是在NameNode里面,但可能用户想单独列出来,所以可能需要把元数据存储单独作为一个部分,不过通常元数据是存储在NameNode的内存磁盘上的。不过可能用户希望明确分开,所以在架构图里可能需要分开表示。 然后,SecondNameNode的作用是帮助NameNode合并fsimageedits日志,防止日志过大。它并不是热备份,所以可能需要说明它定期从NameNode获取元数据快照,进行合并,然后返回给NameNode。 Client是用户交互的接口,负责读取写入数据。当Client读取数据时,会先向NameNode获取元数据,确定数据块的位置,然后直接从对应的DataNode读取数据块。这里需要体现Client与NameNode的元数据查询交互,以及后续与DataNode的数据传输。 DataNode存储实际的数据块,每个Block会有多个副本,分布在不同的DataNode上。数据块副本需要明确显示,比如每个Block有三个副本,分布在不同的节点上。用户提到“Block - Block”,可能是指多个Block,所以需要展示多个Block以及它们的副本。 元数据读取的流程应该是Client向NameNode请求元数据,NameNode返回元数据信息,包括数据块的位置。然后Client根据这些位置信息直接联系对应的DataNode读取数据块。同时,DataNode之间可能会有数据复制的过程,比如副本的创建管理。 接下来需要考虑架构图的布局。通常NameNodeSecondNameNode在顶部,Client在左侧或下方,DataNode集群在右侧或下方。箭头需要表示交互流程,比如Client到NameNode的元数据请求,NameNode返回元数据Client到DataNode读取数据,以及DataNode之间的副本同步。 需要注意的是,用户提到的“DataNode”“Data Node”可能是指同一个东西,可能需要统一术语。另外,“Block - Block”可能表示多个Block,每个Block有多个副本,所以需要图示多个Block及其副本分布在不同的DataNode上。 可能还需要考虑使用不同的形状或颜色来区分组件,比如NameNode用矩形,DataNode用圆柱体,箭头表示流程方向。同时,元数据存储可能需要连接到NameNode,表示其存储的位置。 需要确认是否要包含数据写入流程,但用户主要提到读取数据,所以可能只需关注读取的流程。不过数据块副本的创建可能在写入时发生,但用户可能希望在架构图中体现副本的存在,即使不详细说明写入过程。 最后,需要确保架构图符合HDFS的实际工作原理,避免错误。例如,Client读取数据时确实先访问NameNode获取元数据,然后直接与DataNode交互,而SecondNameNode不与Client直接交互,只与NameNode有关联。</think>以下是为您设计的HDFS架构图说明及核心流程解析,采用分层结构呈现: --- ### HDFS架构图核心组件 ``` [客户端 Client] │ ▼ ① 元数据请求 [NameNode] ├── 元数据存储 (文件系统树/块映射) │ └── ② 返回元数据(块位置) │ ▼ [SecondNameNode] ◄──► 定期合并fsimage与edits │ ▼ [DataNode集群] ├── DataNode1: [Block A][Block B副本] ├── DataNode2: [Block A副本][Block C] └── DataNode3: [Block B][Block C副本] ``` --- ### 关键流程说明(带编号箭头对应架构图) 1. **元数据读取阶段** - 客户端向NameNode发起文件路径查询 - NameNode返回文件对应的数据块列表及副本位置(例如: *Block A: DataNode1, DataNode2* *Block B: DataNode1, DataNode3*) 2. **数据读取阶段** - 客户端根据元数据信息直接访问对应DataNode - 采用就近读取原则(优先选择同机架节点) 3. **数据块副本机制** - 默认3副本策略(可通过`dfs.replication`配置) - 副本分布遵循机架感知策略: *1副本在本地机架 → 1副本在同中心不同机架 → 1副本在远程数据中心* 4. **SecondNameNode工作机制** - 定期触发检查点(默认1小时) - 合并fsimage与edits文件后回传NameNode - **注意**:不是热备节点,无法替代NameNode故障 --- ### 可视化设计建议 1. **组件层级** - 顶层:NameNode + SecondNameNode(用虚线连接表示协作关系) - 中层:Client(左右分布表示交互方向) - 底层:DataNode集群(横向排列,用方块图标表示服务器) 2. **数据流向标注** - 红色箭头:元数据请求/响应 - 蓝色箭头:实际数据流 - 灰色虚线:检查点操作 3. **特殊标注** - 在DataNode存储区域使用堆叠方块表示Block - 用不同颜色区分原始块与副本(例如绿色为原始块,黄色为副本) --- ### 技术细节补充 1. **NameNode高可用方案**(可选标注) - 通过JournalNode实现主备切换 - ZooKeeper协调故障转移 2. **数据完整性校验** - DataNode定期发送块报告 - 使用CRC32校验验证数据 需要制作具体图形时,建议使用以下工具: - 绘图工具:Draw.io/Lucidchart(适合交互式流程图) - 架构图模板:AWS架构图标库/Azure图标库 - 文本绘图:PlantUML(适合代码生成图表) 如果需要具体图形文件格式(PNG/SVG),请提供更详细的样式要求,我可进一步协助生成可编辑的图表文件。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值