全方位揭秘！大数据从0到1的完美落地之HDFS的体系结构

HDFS的体系结构

体系结构解析

HDFS采用的是master/slaves这种主从的结构模型来管理数据，这种结构模型主要由四个部分组成，分别是Client(客户端)、Namenode(名称节点)、Datanode(数据节点)和SecondaryNameNode。真正的一个HDFS集群包括一个Namenode和若干数目的Datanode。

Namenode是一个中心服务器，负责管理文件系统的命名空间 (Namespace ),它在内存中维护着命名空间的最新状态，同时并持久性文件（fsimage和edit）进行备份，防止宕机后，数据丢失。namenode还负责管理客户端对文件的访问，比如权限验证等。

集群中的Datanode一般是一个节点运行一个Datanode进程，真正负责管理客户端的读写请求，在Namenode的统一调度下进行数据块的创建、删除和复制等操作。数据块实际上都是保存在Datanode本地的Linux文件系统中的。每个Datanode会定期的向Namenode发送数据，报告自己的状态(我们称之为心跳机制)。没有按时发送心跳信息的Datanode会被Namenode标记为“宕机”，不会再给他分配任何I/O请求。

用户在使用Client进行I/O操作时,仍然可以像使用普通文件系统那样，使用文件名去存储和访问文件，只不过，在HDFS内部，一个文件会被切分成若干个数据块，然后被分布存储在若干个Datanode上。

比如，用户在Client上需要访问一个文件时，HDFS的实际工作流程如此：客户端先把文件名发送给Namenode，Namenode根据文件名找到对应的数据块信息及其每个数据块所在的Datanode位置，然后把这些信息发送给客户端。之后，客户端就直接与这些Datanode进行通信，来获取数据（这个过程，Namenode并不参与数据块的传输）。这种设计方式，实现了并发访问，大大提高了数据的访问速度。

HDFS集群中只有唯一的一个Namenode,负责所有元数据的管理工作。这种方式保证了Datanode不会脱离Namenode的控制，同时，用户数据也永远不会经过Namenode，大大减轻了Namenode的工作负担，使之更方便管理工作。通常在部署集群中，我们要选择一台性能较好的机器来作为Namenode。当然，一台机器上也可以运行多个Datanode，甚至Namenode和Datanode也可以在一台机器上，只不过实际部署中，通常不会这么做的

HDFS进程之NameNode

namenode进程只有一个（HA除外）

管理HDFS的命名空间，并以fsimage和edit进行持久化保存。

在内存中维护数据块的映射信息

实施副本冗余策略

处理客户端的访问请求

HDFS进程之DataNode

存储真正的数据(块进行存储)

执行数据块的读写操作

心跳机制（3秒）

HDFS进程之SecondaryNamennode

帮助NameNode合并fsimage和edits文件

不能实时同步，不能作为热备份节点

HDFS的Client接口

HDFS实际上提供了各种语言操作HDFS的接口。

与NameNode进行交互，获取文件的存储位置（读/写两种操作）

与DataNode进行交互，写入数据，或者读取数据

上传时分块进行存储，读取时分片进行读取

映像文件fsimage

命名空间指的就是文件系统树及整棵树内的所有文件和目录的元数据，每个Namenode只能管理唯一的一命名空间。HDFS暂不支持软链接和硬连接。Namenode会在内存里维护文件系统的元数据，同时还使用fsimage和edit日志两个文件来辅助管理元数据，并持久化到本地磁盘上。

fsimage
命名空间镜像文件，它是文件系统元数据的一个完整的永久检查点，内部维护的是最近一次检查点的文件系统树和整棵树内部的所有文件和目录的元数据，如修改时间，访问时间，访问权限，副本数据，块大小，文件的块列表信息等等。
fsimage默认存储两份，是最近的两次检查点

使用XML格式查看fsimage文件：
[root@qianfeng01 current]# hdfs oiv -i 【fsimage_xxxxxxx】 -o 【目标文件路径】 -p XML
案例如下：
[root@qianfeng01 current]# hdfs oiv -i fsimage_00000000052 -o ~/fs52.xml -p XML

日志文件edit

集群正常运行时，客户端的所有更新操作(如打开、关闭、创建、删除、重命名等)除了在内存中维护外，还会被写到edit日志文件中，而不是直接写入fsimage映像文件。

因为对于分布式文件系统而言，fsimage映像文件通常都很庞大，如果客户端所有的更新操作都直接往fsimage文件中添加，那么系统的性能一定越来越差。相对而言，edit日志文件通常都要远远小于fsimage,一个edit日志文件最大64M，更新操作写入到EditLog是非常高效的。

那么edit日志文件里存储的到底是什么信息呢，我们可以将edit日志文件转成xml文件格式，进行查看

查看editlog文件的方式：
[root@qianfeng01 current]# hdfs oev -i 【edits_inprogress_xxx】 -o 【目标文件路径】-p XML

参考xml文件后，我们可以知道日志文件里记录的内容有：

行为代码：比如打开、创建、删除、重命名、关闭

事务id

inodeid

副本个数

修改时间

访问时间

块大小

客户端信息

权限等

块id等

全方位揭秘！大数据从0到1的完美落地之HDFS的体系结构相关推荐

全方位揭秘！大数据从0到1的完美落地之HDFS块详解
HDFS块详解传统型分布式文件系统的缺点现在想象一下这种情况:有四个文件 0.5TB的file1,1.2TB的file2,50GB的file3,100GB的file4:有7个服务器,每个服务器上有 ...
全方位揭秘！大数据从0到1的完美落地之HDFS的工作机制
HDFS的工作机制开机启动Namenode过程非第一次启动集群的启动流程我们应该知道,在启动namenode之前,内存里是没有任何有关于元数据的信息的.那么启动集群的过程是怎样的呢?下面来叙述一 ...
全方位揭秘！大数据从0到1的完美落地之HDFS读写流程
数据流读流程的详解读操作: hdfs dfs -get /file02 ./file02 hdfs dfs -copyToLocal /file02 ./file02 FSDataInputStr ...
全方位揭秘！大数据从0到1的完美落地之大数据简介
大数据简介什么是大数据最近几年,IT行业最火的名词中,少不了"大数据"."人工智能"."云计算"."物联网".& ...
全方位揭秘！大数据从0到1的完美落地之MapReduce实战案例(1)
案例一: MR实战之小文件合并(自定义inputFormat) 项目准备需求无论hdfs还是MapReduce,对于小文件都有损效率,实践中,又难免面临处理大量小文件的场景,此时,就需要有相应解决 ...
全方位揭秘！大数据从0到1的完美落地之Hive自定义函数
自定义函数自定义函数介绍 hive的内置函数满足不了所有的业务需求.hive提供很多的模块可以自定义功能,比如:自定义函数.serde.输入输出格式等.而自定义函数可以分为以下三类: 1)UDF:u ...
全方位揭秘！大数据从0到1的完美落地之Mysql介绍
导读在大数据中,我们需要处理的数据来自不同的渠道,其中有一个很重要的渠道就是关系型数据库中存储的数据.在企业中,会把业务数据存储在关系型数据库中,一般以 MySQL 居多.另外,我们在后续的学习中需 ...
全方位揭秘！大数据从0到1的完美落地之Hive介绍
Hive定义 Hive是一个基于Hadoop的数据仓库工具,可以将结构化的数据文件映射成一张数据表,并可以使用类似SQL的方式来对数据文件进行读写以及管理.这套Hive SQL 简称HQL.Hive的 ...
全方位揭秘！大数据从0到1的完美落地之Hive分桶
分桶的概述为什么要分桶数据分区可能导致有些分区数据过多,有些分区数据极少.分桶是将数据集分解为若干部分(数据文件)的另一种技术. 分区和分桶其实都是对数据更细粒度的管理.当单个分区或者表中的数据越 ...