HDFS学习笔记：HDFS基础

目录

 

HDFS基础

HDFS概述

HDFS设计特点

HDFS设计目标

HDFS不适合的存储场景

机架感知

HDFS高可用性设计

HDFS文件存储

HDFS底层原理

NameNode和DataNode

NameNode

DataNode

HDFS缓存机制

HDFS缓存的优势

使用场景

缓存架构图

缓存指令

缓存相关命令

HDFS快照

HDFS快照命令行

---

HDFS基础

HDFS概述

• HDFS是一个分布式文件系统，用于存储和管理文件，有统一的命名空间。HDFS上的文件在物理上是分块存储的，块大小可以通过配置参数(dfs.blocksize)来规定，在hadoop2.x版本中的默认大小是128M。
• HDFS有两种节点，namenode和datanode，namenode承担目录结构及文件分块位置信息（元数据）的管理，namenode是HDFS集群的主节点，负责维护整个hdfs文件系统的目录树，以及每一个文件所对应的数据块信息，是管理文件命名空间和调度客户端访问文件的主服务器，而这些元数据是存储在内存中的；还有一个Secondary NameNode，和NameNode是在同一台机器上的，当内存不够用的情况下，会将操作的日志存储下来，通过日志的查找也能找到文件在DataNode的分布情况，这里有一篇Secondary NameNode的详细解析https://blog.csdn.net/yangjjuan/article/details/71107012。datanode是HDFS集群的从节点，文件的各个block的存储管理由datanode承担，通常是一个节点一个机器。

HDFS设计特点

• 在HDFS文件系统中，一个文件将被分布在集群中的多台机器上存储
• HDFS与其他分布式文件系统的主要区别是它是一个高度容错性的系统，能提供高吞吐量的数据访问，非常适合大规模数据集上的使用

HDFS设计目标

• 降低硬件故障带来的损失
• 提高数据访问效率
• 适合存储大规模数据集
• 简单一致性模型，即比较适合一次写入后就不再更改
• 移动计算比移动数据更为经济，因为HDFS可以把任务分发到DataNode上执行后再汇总到NameNode，而不需要把数据传到一起计算
• 易构软硬件平台间的可移植性

HDFS不适合的存储场景

• 将HDFS用于要求低延迟数据访问的场景，由于HDFS是为高数据吞吐量应用而设计的，必然以高延迟为代价
• 存储大量小型数据文件，由于HDFS中元数据（文件的基本信息）存储在NameNode的内存中，而NameNode为单点进程，这样当小文件数量达到一定程度时，NameNode内存就吃不消了

机架感知

• 机架是用于容纳多台机器的框架，通常情况下，一个机架可安装2-8台机器，若干机架再组成一个大型系统，一个Hadoop集群可能由若干机架构成
• Hadoop有一个机架感知功能，在默认配置下，文件的副本数是三个，通常的策略是：第一个副本放在和Client相同机架的Node里（如果Client不在集群范围，第一个Node是随机选取不太满或不太忙的Node）；第二个副本放在与第一个Node不同的机架中的Node；第三个副本放在于第二个Node所在机架里不同的Node里。
• 启用机架感知需要在NameNode的hadoop-site.xml里配置topology.script.file.name选项，这个选项的value指定为一个脚本，该脚本接受一个参数，输出一个值，接受的参数通常为DataNode机器的ipizhi，而输出的值通常为该ip地址对应的DataNode所在的rackID，例如/rack1。当NameNode启动时，会判断该配置选项是否为空，如果非空，则表示已经启用机架感知的配置，此时namenode会根据配置寻找该脚本，并在接收到每一个DataNode的heartbeat时，将该datanode的ip地址作为参数传给该脚本运行，并将得到的输出作为该datanode所属的机架，保存到内存的一个map中。
• 至于脚本的编写，就需要将真实的网络拓朴和机架信息了解清楚后，通过该脚本能够将机器的ip地址正确的映射到相应的机架上去。Hadoop官方给出的脚本：http://wiki.apache.org/hadoop/topology_rack_awareness_scripts
• 以下分别是没有配置机架感知信息和配置机架感知信息的hadoop HDFS进行数据上传时的测试结果。
  
  当没有配置机架信息时，所有的机器hadoop都默认在同一个默认的机架下，名为 “/default-rack”，这种情况下，任何一台datanode机器，不管物理上是否属于同一个机架，都会被认为是在同一个机架下，此时，就很容易出现之前提到的增添机架间网络负载的情况。在没有机架信息的情况下，namenode默认将所有的slaves机器全部默认为在/default-rack下，此时写block时，三个datanode机器的选择完全是随机的。
  
  当配置了机架感知信息以后，hadoop在选择三个datanode时，就会进行相应的判断：
  1. 如果上传本机不是一个datanode，而是一个客户端，那么就从所有slave机器中随机选择一台datanode作为第一个块的写入机器(datanode1)。而此时如果上传机器本身就是一个datanode，那么就将该datanode本身作为第一个块写入机器(datanode1)。
  2. 随后在datanode1所属的机架以外的另外的机架上，随机的选择一台，作为第二个block的写入datanode机器(datanode2)。
  3. 在写第三个block前，先判断是否前两个datanode是否是在同一个机架上，如果是在同一个机架，那么就尝试在另外一个机架上选择第三个datanode作为写入机器(datanode3)。而如果datanode1和datanode2没有在同一个机架上，则在datanode2所在的机架上选择一台datanode作为datanode3。
  4. 得到3个datanode的列表以后，从namenode返回该列表到DFSClient之前，会在namenode端首先根据该写入客户端跟datanode列表中每个datanode之间的“距离”由近到远进行一个排序，客户端根据这个顺序有近到远的进行数据块的写入。
  5. 当根据“距离”排好序的datanode节点列表返回给DFSClient以后，DFSClient便会创建Block OutputStream，并向这次block写入pipeline中的第一个节点（最近的节点）开始写入block数据。
  6. 写完第一个block以后，依次按照datanode列表中的次远的node进行写入，直到最后一个block写入成功，DFSClient返回成功，该block写入操作结束。
  
  通过以上策略，namenode在选择数据块的写入datanode列表时，就充分考虑到了将block副本分散在不同机架下，并同时尽量地避免了之前描述的网络开销。

HDFS高可用性设计

高可用性包含了软件设计、架构、硬件策略等大量各种不同的因素。为了达到高可用的目的，通常需要多个数据拷贝同时运行，任何一个服务器的失败，其他服务器都能立刻接管它的服务器，从而使系统的不可用时间降到最低程度

HDFS文件存储

• 在HDFS文件系统上，每个文件都被分割成大小相等的数据块，并存储到不同的从节点上，每个数据块都有一个对应的元数据，记录该数据块的位置和大小等信息，而这些元数据都被存放在主节点上
• 当客户端访问一个文件时，首先从主节点获取该文件的元数据，从而获取该文件所有数据块的存放信息

HDFS底层原理

• HDFS的底层通信原理采用的是动态代理和RPC
• 动态代理
      为其他对象提供一种代理以控制对这个对象的访问，核心的使用JDK的Proxy类
  
• RPC
  Remote Procedure Call，远程过程调用。也就是说，调用过程代码并不是在调用者本地运行，而是要实现调用者与被调用者两者之间的连接与通信。
  RPC的基本通信模型是基于Client/Server进程间相互通信模型的一种同步通信形式；它对Client提供了远程服务的过程抽象，其底层消息传递操作对Client是透明的
  在RPC中，Client即是请求服务的调用者Caller，而Server则是执行Client的请求而被调用的程序
• 在HDFS中，Client访问NameNode需要请求数据时，NameNode会返回一个代理，Client通过代理来实现对DataNode的读写

NameNode和DataNode

NameNode

• NameNode进程运行在主节点上，其职责是响应客户端请求、管理元数据（目录、文件、Block的对应关系，Block和DataNode的映射关系等）
• NameNode主要使用以下两个文件
  fsimage：保存文件系统的映射信息。所有数据块和文件的对应关系都被保存在该文件中，即元数据信息，当Client读取HDFS文件时，从NameNode获取的元数据就位于fsimage文件中
  edits：用来临时性记录数据改变情况的文件。保存了对元数据进行的每次操作，例如创建文件、删除文件、或修改文件的副本系数。如果Client进行了创建文件、删除文件，或修改文件的副本系数等操作，从而导致元数据发生变化时，这些改变不会立即更新到fsimage中，而是临时记录在edits文件中，称为EditLog
• HDFS提供了Checkpoint机制，用于在适合的时机将edits文件内容合并到fsimage，而这个工作由Secondary NameNode和Checkpoint Node承担
  Secondary NameNode进程的Checkpoint工作过程如下
  1.定期启动Checkpoint。当Checkpoint启动时，NameNode创建一个新文件来接受日志文件系统的变化，该文件名为edits.new
  2.文件edits不再接受新的变化，并和fsimage一起拷贝到Checkpoint Node所在的文件系统中
  3.Checkpoint Node将两个文件合并产生fsimage.ckpt文件
  4.Checkpoint Node将fsimage.ckpt拷贝到NameNode上
  5.NameNode使用新的fsimage.ckpt替代原fsimage文件
  6.NameNode用edits.new替代edits
• 当Hadoop系统启动时，将启动NameNode进程，在启动的过程中，将执行以下步骤以完成初始化工作
  1.NameNode进程将fsimage载入内存
  2.NameNode载入edit，并将日志文件中记录的数据改变更新到内存中的元数据
  3.DataNode进程向NameNode发送数据块报告单
• 初始化完成后，NameNode进程随即进入就绪态，在就绪状态下，将执行以下任务
  1.处理基于客户端的请求，在DataNode上进行数据块的增加、删除等
  2.更新日志文件edit，并在NameNode内存中更新元数据和数据块的位置
  3.DataNode进程每三秒向NameNode发送心跳信号，表明DataNode活动状态
  4.DataNode每六小时向NameNode发送其所在节点的文件数据块报告（时间间隔可以修改）

DataNode

HDFS机制将每个文件分割成一个或多个数据块，存储在一组DataNode上，对于HDFS客户端而言，无论读文件还是写文件，首先向NameNode发出元数据操作请求，以获取文件数据块与DataNode映射，然后再根据映射在对应的DataNode上进行数据块读/写操作，因此，用户的实际文件操作是不经过NameNode

• HDFS上传图解

1.客户端向NameNode(NN)发送请求上传文件路径
2.NN响应Client确认是否能够上传文件
3.Client再次请求NN,上传一个Block块
4.NN响应Client给予几个要上传的DataNode的地址(有一定的容灾规则)
5.Client向第一个DataNode请求建立连接进行文件上传,第一个DataNode会向第二个DataNode请求建立连接传输文件，依次到最后一个,通知Client进行文件的传输
6.Client会将文件分成每个64k的小块进行传输(方便副本间同步,前后副本仅仅差距一个包)
7.Client上传结束后,如果还有Black块,继续重复3-6过程.直到传输结束

• HDFS下载图解

1.Client向NN请求下载指定目标
2.NN返回该目标的存储信息(Block块及相应的机器列表)
3.Client依次向Block块的机器发送数据传输请求,将文件下载到本地进行拼接，直到下载完成
注意：Client读取DataNode数据时，使用DFSClient中的read函数，将数据读入到Client的数据缓冲区，然后检查校验和（校验文件），将校验和与DataNode中的校验和进行比较，如果两个校验信息一致，说明数据传输无误

HDFS缓存机制

HDFS的缓存机制允许用户指定HDFS路径，NameNode会和保存着所需块数据的所有NameNode通信，并指导它们将块数据缓存在缓存中

HDFS缓存的优势

• 可以阻止频繁使用的数据被从内存中清除，当工作集的大小超过主内存大小时，指定缓存的数据能获取优先权
• 由于DataNode缓存是由NameNode管理的，所以分配任务时，把任务和缓存块副本放在一个位置上可以提高读操作的性能
• 当块已经被DataNode缓存时，客户端就可以使用一个新的梗搞笑的零拷贝读操作API
• 可以提高整个集群的内存使用率

使用场景

需要频繁、重复访问的文件，使用缓存可以有利于提高性能

缓存架构图

缓存指令

• 一条缓存指令定义了一个要被缓存的路径，这些路径可以是文件夹或文件。文件夹是以非迭代方式缓存，只有在文件夹顶层列出的文件才缓存
• 文件夹也可以指定额外的参数，比如缓存副本因子，有效期等。副本因子指定了要缓存的块副本数
• 有效期是在命令行指定的，缓存指令过期之后，再决定缓存时，它就不再被NameNode考虑了
• 缓存池是一个管理实体，用于管理缓存指令组。可以限制哪个用户和组可以访问、添加、删除该缓存池

缓存相关命令

添加一个缓存池

hdfs cacheadmin -addPool admin

查看缓存池列表

hdfs cacheadmin -listPools

将一个目录加入缓存池

hdfs cacheadmin -addDirective -path /data -pool admin

查看已缓存的数据

hdfs cacheadmin -listDirectives

按path清除缓存

hdfs cacheadmin -removeDirectives -path /data

HDFS快照

快照是HDFS文件系统的基于某时间点的只读拷贝，可以针对某个目录，或者整个文件系统做快照。快照比较常见的应用场景是数据备份，用于防止用户错误以及用于灾难恢复。

HDFS快照的实施非常有效

• 快照创建是即时的，时间成本为O（1），不包括inode查找时间
• 只有当涉及到快照目录的修改被执行时，才会产生额外的内存消耗，而且内存消耗为O（M），其中M是被修改的文件或目录数
• 创建快照时，block并不会被拷贝，快照文件中只记录block列表和文件大小，不会做任何数据拷贝
• 快照不会对正常的HDFS操作有任何影响，创建快照以后发生的修改操作，会按操作时间的倒序记录下来，所以当前的数据能直接获取，而快照点的数据则通过再当前的数据基础上减去执行过的操作来获取，所以时间越久的快照，要获取就需要越长的时间。

HDFS的快照实际上将要备份的数据拷贝一份到一个隐藏目录，这个功能默认是禁用的

HDFS快照命令行

对/demo1目录开启快照功能

hdfs dfsadmin -allowSnapshot /demo1

对demo1目录执行快照

hdfs dfs -createSnapshot /demo1 mydemo1_backup_1

查看快照备份的文件

hdfs dfs -ls /demo1/.snapshot

再往demo1的目录放一个文件，并创建快照

hdfs dfs -put student.txt /demo1
hdfs dfs -createSnapshot /demo1 mydemo1_backup_2

对比快照，这个操作需要用户对两个快照目录同时具有读权限

hdfs snapshotDiff /demo1 mydemo1_backup_1 mydemo1_backup_2

删除快照

hdfs dfs -deleteSnapshot /demo1 mydemo1_backup_1

重命名快照

hdfs dfs -renameSnapshot /demo1 mydemo1_backup_2 backup_3

参考及引用

HDFS机架感知功能原理（rack awareness）：https://www.jianshu.com/p/372d25352d3a，作者GodHehe
HDFS上传和下载文件图解：https://blog.csdn.net/wypersist/article/details/80044958
Hadoop 2.6官方文档：https://hadoop.apache.org/docs/r2.6.0/hadoop-project-dist/hadoop-hdfs/HdfsSnapshots.html