1 HDFS 概述
1.1 HDFS 产出背景及定义
1）HDFS 产生背景
随着数据量越来越大，在一个操作系统存不下所有的数据，那么就分配到更多的操作系统管理的磁盘中，但是不方便管理和维护，迫切需要一种系统来管理多台机器上的文件，这就是分布式文件管理系统。HDFS 只是分布式文件管理系统中的一种。
2）HDFS 定义
HDFS（Hadoop Distributed File System），它是一个文件系统，用于存储文件，通过目录树来定位文件；其次，它是分布式的，由很多服务器联合起来实现其功能，集群中的服务器有各自的角色。
HDFS 的使用场景：适合一次写入，多次读出的场景。一个文件经过创建、写入和关闭
之后就不需要改变。
我们前面已经知道了HDFS是一个分布式的文件系统，具体这个分布式文件系统是如何实现的呢？
我们来举个例子分析一下。
小明租房：
小明同学呢，今年是大四，需要离校去实习了，出去实习首要解决的是住宿的问题，目前软件行业很少包住宿的，反正我是没听说过，但是小明呢，有一个特点，就是懒，还穷，天天出去住酒店肯定是住不起的，那只能租房了，租房呢他还不想自己去找房子，嫌麻烦，所以就随便在路边找了一个二房东贴的广告，单间出租，拎包入住，无中介费，押一付一，一月300，小明一看，可以，还不错，所以就直接打电话过去看房子办手续了，这样就解决了住宿的问题。
紧接着小明的同学看他这么快就搞定了住宿问题，房租也挺便宜，都问他要二房东的电话，小明就把二房东的电话发到了他们的年级群里，上千人啊，结果二房东的手机就被打爆了，最后只能关机了，人太多了，实在搞不定了。
因为目前有租房需求的学员太多了，全部都去找这一个二房东，他是搞不定的，因为他每天带看的人数是有限的。
那这个时候怎么办呢？
小明同学还是比较热心的，发现二房东解决不了这么大的需求，然后他正发愁呢，结果一抬头看到了一个中介公司，小明露出了满嘴的大白牙。
然后他就顺利搞到了这个中介公司的电话，赶紧把这个电话发到了年级群里面，这个时候，当再有学员有租房需求的时候，直接打中介公司的电话，然后中介公司会让具体的工作人员直接联系这个学员，负责他的租房需求，每一个工作人员最多负责5个人，因为中介公司里面是有很多工作人员的，这样一分流，就很轻松的解决了这个问题。
这个时候针对中介公司而言，它只负责管理房源和工作人员就行了，具体干活的是工作人员。
这样就算同时过来很多人，中介公司也是可以扛得住的，因为具体看房租房的流程是直接和工作人员对接的，不会造成阻塞。
ok 这就是小明租房的一个案例，那这个案例和我们要讲的HDFS有什么关系呢？
不要着急，我们来往下面看。
假设让我们来设计一个分布式的文件系统，我们该如何设计呢？
这里的客户端可以理解为安装HDFS的机器,或者连接操作这台机器API
看这个图片，用户在写入数据和读取数据的时候会通过一个文件系统，这个文件系统后面会有很多台服务器，所以我们的数据就可以存储在多台服务器上面。后期服务器增加或者减少，对我们用户而言，不用关注，这个统一由文件系统进行管理，我们只需要和文件系统进行交互就可以了。
这样是不是就实现了分布式存储了，这种方案在实际应用中可行吗？
在这里就可以把文件系统理解为二房东，服务器理解为房子，这种设计架构会存在一个问题，假设同时过来很多人都需要租房子，那么一个二房东是忙不过来的，就会造成阻塞。那继续往下面看
现在这种设计是，我们去找一个中介公司，这里的主节点就可以理解为一个中介公司
这里的从节点就可以理解为是房源，中介公司会在每块房源都安排一个工作人员，当我们找房子的时候，先联系中介公司，中介公司会告诉我们哪里有房子，并且把对应工作人员的信息告诉我们，我们就可以直接去找对应的工作人员去租房子。这样对于中介公司而言，就没什么压力了。
中介公司只负责管理房源和工作人员信息，具体干活的是工作人员。相当于nn
这样就算同时过来很多人，中介公司也是可以扛得住的，因为具体看房租房的流程是我们直接和工作人员联系的，不会造成阻塞。
所以对应到我们的分布式存储设计上面：
用户请求查看数据时候会请求主节点，主节点上面会维护所有数据的存储信息，
主节点会把对应数据所在的节点信息返回给用户，
然后用户根据数据所在的节点信息去对应的节点去读取数据，这样压力就不会全部在主节点上面。
这个就是HDFS这个分布式文件系统的设计思想。
1.2 HDFS 优缺点
HDFS的全称是Hadoop Distributed File System ，Hadoop的 分布式 文件 系统
它是一种允许文件通过网络在多台主机上分享的文件系统，可以让多台机器上的多个用户分享文件和存储空间
其实分布式文件管理系统有很多，HDFS只是其中一种实现而已
还有 GFS(谷歌的)、TFS(淘宝的)、S3(亚马逊的)
为什么会有多种分布式文件系统呢？这样不是重复造轮子吗？
不是的，因为不同的分布式文件系统的特点是不一样的，HDFS是一种适合大文件存储的分布式文件系统，不适合小文件存储，什么叫小文件，例如，几KB，几M的文件都可以认为是小文件
1.3 新框架的学习方法
2 HDFS体系结构
前面我们掌握了HDFS的基本使用，下面我们来详细分析一下HDFS深层次的内容
HDFS支持主从结构，主节点称为 NameNode ，是因为主节点上运行的有NameNode进程，NameNode支持多个，目前我们的集群中只配置了一个
从节点称为 DataNode ，是因为从节点上面运行的有DataNode进程，DataNode支持多个，目前我们的集群中有两个
HDFS中还包含一个 SecondaryNameNode 进程，这个进程从字面意思上看像是第二个NameNode的意思，其实不是，一会我们会详细分析。
在这大家可以这样理解：
公司BOSS：NameNode
秘书：SecondaryNameNode
员工：DataNode
接着看一下这张图，这就是HDFS的体系结构，这里面的TCP、RPC、HTTP表示是不同的网络通信方式，通过这张图是想加深大家对HDFS体系结构的理解，我们前面配置的集群NameNode和SecondaryNameNode进程在同一台机器上面，在这个图里面是把它们分开到多台机器中了。
那接下来我们就详细分析这里面的每一个进程。
官方描述:HDFS has a master/slave architecture. An HDFS cluster consists of a single NameNode, a master server that manages the file system namespace and regulates access to files by clients. In addition, there are a number of DataNodes, usually one per node in the cluster, which manage storage attached to the nodes that they run on. HDFS exposes a file system namespace and allows user data to be stored in files. Internally, a file is split into one or more blocks and these blocks are stored in a set of DataNodes. The NameNode executes file system namespace operations like opening, closing, and renaming files and directories. It also determines the mapping of blocks to DataNodes. The DataNodes are responsible for serving read and write requests from the file system’s clients. The DataNodes also perform block creation, deletion, and replication upon instruction from the NameNode.
翻译:
HDFS具有主/从体系结构。HDFS集群由一个NameNode组成，它是一个主服务器，管理文件系统名称空间并管理客户端对文件的访问。此外，还有许多数据节点，通常是群集中每个节点一个，用于管理连接到它们运行的节点的存储。HDFS公开了一个文件系统名称空间，并允许用户数据存储在文件中。在内部，文件被分割成一个或多个块，这些块存储在一组数据节点中。NameNode执行文件系统名称空间操作，如打开、关闭和重命名文件和目录。它还确定块到数据节点的映射。DataNodes负责为来自文件系统客户端的读写请求提供服务。DataNodes还根据NameNode的指令执行块创建、删除和复制
2.1 NameNode介绍
首先是NameNode，NameNode是整个文件系统的管理节点,它主要维护着整个文件系统的文件目录树，文件/目录的信息 和 每个文件对应的数据块列表，并且还负责接收用户的操作请求
目录树：表示目录之间的层级关系，就是我们在hdfs上执行ls命令可以看到的那个目录结构信息。
文件/目录的信息：表示文件/目录的的一些基本信息，所有者 属组 修改时间 文件大小等信息
每个文件对应的数据块列表：如果一个文件太大，那么在集群中存储的时候会对文件进行切割，这个时候就类似于会给文件分成一块一块的，存储到不同机器上面。所以HDFS还要记录一下一个文件到底被分了多少块，每一块都在什么地方存储着
我们现在可以到集群的9870界面查看一下，随便找一个文件看一下，点击文件名称，可以看到Block information 但是文件太小，只有一个块 叫Block 0
我们试着上传一个大一点的文件，找一个200M左右的文件。
[root@bigdata01 hadoop-3.2.0]# cd /data/soft/ [root@bigdata01 soft]# hdfs dfs -put hadoop-3.2.0.tar.gz /
这个时候再去看 就能看到分成了多个Block块，一个文件对应有多少个Block块信息 是在namenode里面保存着的
接收用户的操作请求：其实我们在命令行使用hdfs操作的时候，是需要先和namenode通信 才能开始去操作数据的。
为什么呢？
因为文件信息都在namenode上面存储着的
namenode是非常重要的，它的这些信息最终是会存储到文件上的，那接下来我们来看一下NameNode中包含的那些文件NameNode主要包括以下文件：
这些文件所在的路径是由hdfs-default.xml的dfs.namenode.name.dir属性控制的
hdfs-default.xml文件在哪呢？
它在hadoop-3.2.0\share\hadoop\hdfs\hadoop-hdfs-3.2.0.jar中，这个文件中包含了HDFS相关的所有默认参数，咱们在配置集群的时候会修改一个hdfs-site.xml文件，hdfs-site.xml文件属于hdfs-default.xml的一个扩展，它可以覆盖掉hdfs-default.xml中同名的参数。
那我们来看一下这个文件中的dfs.namenode.name.dir属性
<property> <name>dfs.namenode.name.dir</name> <value>file://${hadoop.tmp.dir}/dfs/name</value> <description>Determines where on the local filesystem the DFS name node should store the name table(fsimage). If this is a comma-delimited list of directories then the name table is replicated in all of the directories, for redundancy. </description> </property>
这个属性的值是由hadoop.tmp.dir属性控制的，这个属性的值默认在core-default.xml文件中。大家还有没有印象，我们在修改core-site.xml的时候设置的有hadoop.tmp.dir属性的值，值是/data/hadoop_repo，所以说core-site.xml中的hadoop.tmp.dir属性会覆盖掉core-default.xml中的值
最终dfs.namenode.name.dir属性的值就是：/data/hadoop_repo/dfs/name
那我们到bigdata01节点上看一下
进入到/data/hadoop_repo/dfs/name目录下
发现这个下面会有一个current 目录，表示当前的意思，还有一个in_use.lock 这个只是一个普通文件，但是它其实有特殊的含义，你看他的文件名后缀值lock 表示是锁的意思，文件名是in_use 表示这个文件现在正在使用，不允许你再启动namenode。
当我们启动namonde的时候 会判断这个目录下是否有in_use.lock 这个相当于一把锁，如果没有的话，才可以启动成功，启动成功之后就会加一把锁， 停止的时候会把这个锁去掉
[root@bigdata01 name]# cd /data/hadoop_repo/dfs/name [root@bigdata01 name]# ll total 8 drwxr-xr-x. 2 root root 4096 Apr 8 21:31 current -rw-r--r--. 1 root root 14 Apr 8 20:30 in_use.lock [root@bigdata01 name]# cd current [root@bigdata01 current]# ll total 4152 -rw-r--r--. 1 root root 42 Apr 7 22:17 edits_0000000000000000001-0000000000000000002 -rw-r--r--. 1 root root 1048576 Apr 7 22:17 edits_0000000000000000003-0000000000000000003 -rw-r--r--. 1 root root 42 Apr 7 22:22 edits_0000000000000000004-0000000000000000005 -rw-r--r--. 1 root root 1048576 Apr 7 22:22 edits_0000000000000000006-0000000000000000006 -rw-r--r--. 1 root root 42 Apr 8 14:53 edits_0000000000000000007-0000000000000000008 -rw-r--r--. 1 root root 1644 Apr 8 15:53 edits_0000000000000000009-0000000000000000031 -rw-r--r--. 1 root root 1523 Apr 8 16:53 edits_0000000000000000032-0000000000000000051 -rw-r--r--. 1 root root 42 Apr 8 17:53 edits_0000000000000000052-0000000000000000053 -rw-r--r--. 1 root root 1048576 Apr 8 17:53 edits_0000000000000000054-0000000000000000054 -rw-r--r--. 1 root root 42 Apr 8 20:31 edits_0000000000000000055-0000000000000000056 -rw-r--r--. 1 root root 523 Apr 8 21:31 edits_0000000000000000057-0000000000000000065 -rw-r--r--. 1 root root 1048576 Apr 8 21:31 edits_inprogress_0000000000000000066 -rw-r--r--. 1 root root 652 Apr 8 20:31 fsimage_0000000000000000056 -rw-r--r--. 1 root root 62 Apr 8 20:31 fsimage_0000000000000000056.md5 -rw-r--r--. 1 root root 661 Apr 8 21:31 fsimage_0000000000000000065 -rw-r--r--. 1 root root 62 Apr 8 21:31 fsimage_0000000000000000065.md5 -rw-r--r--. 1 root root 3 Apr 8 21:31 seen_txid -rw-r--r--. 1 root root 219 Apr 8 20:30 VERSION
里面有edits文件 和fsimage文件
fsimage文件有两个文件名相同的，有一个后缀是md5 md5是一种加密算法，这个其实主要是为了做md5校验的，为了保证文件传输的过程中不出问题，相同内容的md5是一样的，所以后期如果我把这个fsimage和对应的fsimage.md5发给你 然后你根据md5对fsimage的内容进行加密，获取一个值 和fsimage.md5中的内容进行比较，如果一样，说明你接收到的文件就是完整的。
我们在网站下载一些软件的时候 也会有一些md5文件，方便验证下载的文件是否完整。
