大数据学习笔记

一、Hadoop简介

Apache基金会全称为Apache软件基金会，是专门为支持开源软件项目而办的一个非盈利性组织。在它所支持的Apache项目与子项目中，所发行的软件产品都遵循Apache许可证。 使用Java语言实现，开源，免费使用。

1.1 Hadoop的核心组件

Hadoop HDFS（分布式文件存储系统）：解决了海量数据存储的问题。

Hadoop MapReduce（分布式计算框架）：解决了海量数据的计算问题。
Hadoop YARN（集群资源管理和任务调度框架）：解决了集群环境下的资源分配问题。
官方网站

1.2 Hadoop基础架构

• Hadoop HDFS 一个高可靠、高吞吐量的分布式文件系统。
• Hadoop MapReduce 一个分布式的离线并行计算框架。
• Hadoop YARN 作业调度与集群资源管理的框架。
• Hadoop Common 支持其他模块的工具模块（Configuration、RPC、序列化机制、日志操作）。

1.2.1 HDFS

HDFS(Hadoop Distributed File System)是一个分布式文件存储系统，采用的是主从架构【即Master-Slave】，一个 HDFS由一个NameNode和若干个DataNode组成，其中NameNode作为主服务器，管理文件系统的命名空间和客户端对文件的访问操作；集群中的DataNode管理存储的数据。

• NameNode 在Hadoop 1.x中只能有一个NameNode，在Hadoop 2.x的版本中，可以配置2个NameNode，而在Hadoop 3.x的版本中，可以配置多个NameNode，以解决NameNode单点故障问题，存储文件的元数据，如文件名，文件目录结构，文件属性（创建时间、副本数、文件权限），以及每个文件的块列表和块所在的DataNode的列表信息等。
• DataNode 主要负责来源于客户端的读写请求，在本地文件系统存储文件块数据，以及块数据的校验和。
• SecondaryNameNode 辅助NameNode工作的，帮助Namenode进行元数据的合并

1.2.2 YARN

Yarn是一个资源调度平台，负责为运算程序提供服务器运算资源。

• ResourceManager 用来处理客户端的任务请求，监控NodeManager，做资源的调度与分配。
• NodeManager 单个节点上的资源管理器。

1.2.3 MapReduce

MapReduce是一个分布式计算系统，将一个计算过程分为两个阶段Map阶段和Reduce阶段Map阶段用来分而治之地处理输入的数据，Reduce阶段用来合并Map阶段的计算。MapReduce任务最终运行在YARN上。

1.3 Hadoop安装模式

本地模式（Standalone Mode）

• 不对配置文件进行修改。
• 使用本地文件系统，而不是分布式文件系统。
• Hadoop不会启动NameNode、DataNode、SecondaryNameNode、ResourceManager、NodeManager等守护进程，Map()和Reduce()任务作为同一个进程的不同部分来执行的。
• 用于对MapReduce程序的逻辑进行调试，确保程序的正确。

伪分布模式（Pseudo-Distributed Mode）

• 在一台主机模拟一个小规模的集群，在这种模式下Hadoop使用的是分布式文件系统，一般用于程序调试与测试。也可以说 伪分布式 是 完全分布式 的一个特例。

• 在这种模式下，Hadoop使用的是分布式文件系统。在单机模式之上增加了代码调试功能，允许检查内存使用情况，HDFS输入输出，以及守护进程交互。Hadoop启动NameNode、DataNode、SecondaryNameNode、ResourceManager、NodeManager，这些守护进程都在同一台机器上运行，是相互独立的Java进程。

• 需要修改配置文件：core-site.xml、hdfs-site.xml、mapred-site.xml、yarn-site.xml。

• 格式化文件系统

完全分布式模式（Cluster Mode）

• 在这种模式下，Hadoop在所有的主机上安装JDK、Hadoop、Zookeeper等软件，组成相互连通的网络。
• 主机间设置SSH免密码登录，把各从节点生成的公钥添加到主节点的信任列表中。
• 需要修改配置文件：core-site.xml、hdfs-site.xml、mapred-site.xml、yarn-site.xml、hadoop-env.sh。
• 格式化文件系统
• 启动Hadoop后的进程：NameNode，DataNode，ResourceManager，NodeManager，SecondaryNameNode

二、配置文件说明

Hadoop集群配置

2.1 hadoop-env.sh

此配置文件时Hadoop一些核心脚本的配置文件，要指定JAVA_HOME。

2.2 core-site.xml

此配置文件是Hadoop核心的配置文件，对应于Common模块在此配置文件中配置文件系统的访问端口和访问权限等。

• fs.defaultFS
  文件系统访问路径，由于我们将集群中任意节点配置为NameNode节点，因此在完全分布式中配置以下值。默认为file:///即本地文件系统，伪分布的时候可配置为hdfs://localhost:9000。
• hadoop.tmp.dir
Hadoop运行时的临时存储目录，默认值为/tmp/hadoop-${user.name}，配置后就会在Hadoop安装目录下。
• io.file.buffer.size
  用作序列化文件处理时读写buffer的大小，默认为4096，单位为byte，可以设置的大一些，较大的缓存都可以提供更高的数据传输，但这也就意味着更大的内存消耗和延迟。一般情况下，可以设置为64KB(65536byte)。

2.3 hdfs-site.xml

此配置文件是HDFS核心的配置文件，对应于HDFS模块，在此配置文件中配置文件系统数据存储路径和SecondaryNameNode地址等。

• dfs.namenode.name.dir
HDFS中NameNode节点元数据存储目录，默认为file://${hadoop.tmp.dir}/dfs/name。可以配置多个，那么多个目录的内容完全一样。
  * dfs.datanode.data.dir
  HDFS中NameNode节点元数据存储目录，默认为file:// ${hadoop.tmp.dir}/dfs/name。可以配置多个，那么多个目录的内容完全一样。
• dfs.replication
DataNode存储的Block的副本数量，不大于DataNode的个数就行，默认为3，实际生产环境中设置为3即可，过多则会更多地占用磁盘空间。
• dfs.namenode.checkpoint.dir
  指定SecondaryNamenode的工作目录，即辅助名称节点在本地文件系统上存储要合并的临时fsimage的位置。
• dfs.namenode.secondary.http-address
  指定SecondaryNameNode的http协议访问地址，配置的话则会启动SecondaryNameNode。
• dfs.webhdfs.enabled
  是否启用WEB访问，默认为true，但是在Hadoop3.x中已被移除，webhdfs应该始终允许被访问，但是增加了dfs.webhdfs.rest-csrf.enabled等相关配置，默认值为false。
• dfs.hosts
  值为循序访问的节点列表文件路径，dfs.hosts所对应的文件中列出了所有可以连接到NameNode的DataNode，如果为空则所有的都可以连入。注意：指定的文件只能是主机名，不能用ip，用于节点的动态上下线。最后要注意使用hdfs dfsadmin-refreshNodes刷新配置，还要修改slaves文件。
• dfs.hosts.exclude
  值为不允许的节点列表文件路径，dfs.hosts.exclude所对应的文件中列出了所有被禁止连接到NameNode的DataNode，如果为空，则都可以连入。注意：指定的文件只能是主机名，不能用ip，用于节点的动态上下线。最后要注意使用hdfs dfsadmin-refreshNodes刷新配置，还要修改slaves文件。
• dfs.blocksize
  文件的默认块大小，以字节为单位。可以使用以下后缀（不区分大小写）：k,m,g,t,p,e指定大小（如128k，64m，1G），也可提供完整大小（如134217708表示128MB），在Hadoop2.x以及之后版本中默认值为128M，Hadoop1.x中默认大小为64M。
• dfs.namenode.handler.count
NameNode有一个工作线程池用来处理客户端的远端过程调用以及集群守护进程的调用。处理程序数量越多意味着要更大的池用来处理来自不同DataNode的并发心跳以及客户端并发的元数据操作。对于大集群或者又大客户端的集群来说，通常需要增大参数。dfs.namenode.handle.count的默认值为10。设置值一般为集群大小的自然对数乘20，即20 x lg(N)，N为集群大小。

2.4 yarn-site.xml

此配置文件是Yarn核心的配置文件，对应于Yarn模块，在此配置文件中配置ResourceManager主机名和NodeManager内存大小等。

• yarn.nodemanager.zux-servicees
MapReduce应用程序的shuffle服务，需要配置为mapreduce_shuffle。
• yarn.log-aggregation-enable
  是否启用日志聚合功能，默认为false，生产环境下设置为true。
• yarn.log-aggregation.retain-seconds
  配置多久聚合后的日志文件被删除，默认值为-1，表示禁用，单位为s。生产环境下可以设置为604800(7天)或者更长时间。
• yarn.log-aggregation.retain-check-interval-seconds
  多久检查一次日志，执行时候满足条件的日志删除，如果是0或者负数，则为上述值的1/10。
• yarn.resourcemanager.hostname
ResourceManager的主机名，此参数配置后其余的yarn.resourcemanager*address均可不配置，除非要修改默认端口。
• yarn.nodemanager.resource.memory-mb
  当前NodeManager的可用物理内存，单位为MB，默认值为-1，需要根据节点情况进行配置。如果不知道内存情况，可以配置。yarn.nodemanager.resource.detect-hardware-capabilities为true，并且内存配置为-1的情况下可以自动检测节点的内存，但是内存只会使用其中的一部分(内存较小的情况下还是要手动设置内存大小)。
• yarn.nodemanager.vmem-pmem-pmem-ratio
  可使用的虚拟内存与物理内存的比值，默认为2.1，对于大内存的不用管，如果内存过小，可以适当调大此参数。
  * yarn.nodemanager.resource.cpu-vcores
  当前节点的可用的虚拟核心数，默认为-1，可以根据节点的情况进行配置。也可以根据。yarn.nodemanager.resource.detect-hardware-capabilities配置为true，以便自动检测CPU数量。(建议配置)。
• yarn.acl.enable
ACL，中文名称是 “访问控制列表” ，它由一系列规则（即描述报文匹配条件的判断语句）组成。那么我打个比喻，ACL相当于一个过滤器，ACL规则就是过滤器的滤芯，安装什么样的滤芯（即根据报文特征匹配的一系列ACL规则），ACL就能过滤出什么样的报文了。是否启用YARN的ACL，默认值false。
• yarn.admin.acl
  默认值*，也就是说所有用户都可以管理ResourceManager
  格式：User1,User2,User3 Group1,Group2,Group3
  注意：用户与用户组之间必须有一个空格
• yarn.resourcemanager.scheduler.class
  理想情况下，我们应用对YARN资源的请求立刻满足，但是现实情况资源往往是有限的，特别是在一个很繁忙的集群，一个应用资源的请求经常需要等待一段时间才能得到相应的资源。在YARN中，负责给应用分配资源的就是Scheduler。其实调度本身就是一个难题，很难找到一个完美的解决策略可以解决所有应用场景。为此，YARN提供了多种调度器和可配置的策略供我们选择。
  CapacityScheduler：容器调度器
  FairScheduler：公平调度器
  FifoScheduler：先入先出调度器
• yarn.scheduler.minimum-allocation-mb
ResourceManager处理请求时分配给AppMaster单个容器可申请的最小内存，单位为MB，默认为1024，如果电脑内存国小，导致MR程序无法运行，则可以配置此参数和以下参数。
• yarn.scheduler.maximum-allocation-mb
ResourceManager处理请求时分配给AppMaster单个容器可申请的最大内存，单位为MB，默认为8192。
• yarn.resourcemanager.nodes.include-path
NodeManager白名单。
• yarn.resourcemanager.nodes.exclude-path
Nodemanager黑名单。如果发现若干个NodeManager存在问题，比如故障率很高，运行失败率很高，则可以将之加入黑名单。注意这两个配置参数可以动态生效。调用一个 yarn rmadmin -refreshNodes 命令即可。
• yarn.nodemanager.local-dirs
  生产环境下，建议配置多个目录，以提高IO性能。

2.5 mapred-site.xml

此配置文件是MapReduce核心的配置文件，对应于MapReduce模块。

• mapreduce.framework.name
MapReduce程序运行的框架，默认值为local，集群模式配置为yarn
• mapreduce.jobhistory.address
  配置历史服务器
• mapreduce.jobhistory.webapp.address
  篇日志界面地址

2.6 workers

该文件中配置所有DataNode节点的主机名，注意一定要删除默认的主机名localhost。

2.7 注意

格式化的时候：在哪里格式化那么就会在哪里产生dfs目录以及name目录，因此格式化必须在NameNode节点执行。
启动HDFS的时候：在哪里执行启动命令都可以，所识别的是fs.defaultFS的配置，因此建议在NameNode
启动Yarn的时候：只能在配置的resourceManager节点上

2.8 Hadoop相关命令

• 启动hdfs：start-dfs.sh
• 启动yarn：start-yarn.sh
• 启动MapReduce历史记录服务：mapred --daemon start historyserver
• 停止 MapReduce 历史服务:mapred --daemon stop historyserver
• 停止yarn：stop-yarn.sh
• 停止hdfs：stop-dfs.sh
• Hadoop 2.x 单独启动hdfs的某一个服务
  hadoop-daemon.sh start|stop namenode|datanode|secondarynamenode
• Hadoop 2.x 单独启动Yarn的某一个服务
  yarn-daemon.sh start|stop resourcemanager|nodemanager
  - Hadoop 3.x 单独启动hdfs的某一个服务
  hdfs --daemon start|stop namenode|datanode|secondarynamenode
• Hadoop 3.x单独启动Yarn的某一个服务
  yarn --daemon start|stop resourcemanager|nodemanager

2.9 Hadoop启动测试

NameNode WEBUI访问地址
访问地址：http://192.168.100.101:9870/

ResourceManager WebUI访问
访问地址：http://192.168.100.102:8088/
MapReduce JobHistory Server WebUI访问
访问地址：http://192.168.100.101:19888/

SecondaryNameNode WebUi访问
访问地址：http://192.168.100.103:9868/

三、HDFS详解

3.1 什么是文件系统

3.1.1 文件系统

文件系统是一种存储和组织数据的方法，实现了数据的存储、分级组织、访问和获取等操作，使用户对文件访问和查找变得容易。文件系统使用树形目录的抽象逻辑概念代替了硬盘等物理设备使用数据块的概念，用户不必关心数据底层存在硬盘哪里，只需要记住这个文件的所属目录和文件名即可。文件系统通常使用硬盘和光盘这样的存储设备，并维护文件在设备中的物理位置。

3.1.2传统的文件系统

所谓传统常见的文件系统更多指的的单机的文件系统，也就是底层不会横跨多台机器实现。比如windows操作系统上的文件系统、Linux上的文件系统、FTP文件系统等等。
这些文件系统的共同特征包括：
带有抽象的目录树结构，树都是从/根目录开始往下蔓延；
树中节点分为三类：目录、文件和链接【Windows中就是快捷方式，Linux中就是软链接和硬链接】；
从根目录开始，节点路径具有唯一性

3.1.3数据与元数据

数据指存储的内容本身，比如文件、视频、图片等，这些数据底层最终是存储在磁盘等存储介质上的，一般用户无需关心，只需要基于目录树进行增删改查即可，实际针对数据的操作由文件系统完成。

**元数据（metadata）**又称之为解释性数据，记录数据的数据；
文件系统元数据一般指文件大小、最后修改时间、底层存储位置、属性、所属用户、权限等信息。

3.2 HDFS简介

HDFS（Hadoop Distributed File System）是一个分布式文件系统。用于存储文件，通过目录树来定位文件。其次，它是分布式的，由很多服务器联合起来实现其功能，集群中的服务器有各自的角色。
HDFS主要是解决大数据如何存储问题的。分布式意味着是HDFS是横跨在多台计算机上的存储系统。
HDFS是一种能够在普通硬件上运行的分布式文件系统，它是高度容错的，适应于具有大数据集的应用程序，它非常适于存储大型数据 (比如 TB 和 PB)。
HDFS使用多台计算机存储文件, 并且提供统一的访问接口, 像是访问一个普通文件系统一样使用分布式文件系统。

3.2.1 HDFS的设计目标

• 硬件故障（Hardware Failure）是常态， HDFS可能有成百上千的服务器组成，每一个组件都有可能出现故障。因此故障检测和自动快速恢复是HDFS的核心架构目标。
• HDFS上的应用主要是以流式读取数据（Streaming Data Access）。HDFS被设计成用于批处理，而不是用户交互式的。相较于数据访问的反应时间，更注重数据访问的高吞吐量。
• 典型的HDFS文件大小是GB到TB的级别。所以，HDFS被调整成支持大文件（Large Data Sets）。它应该提供很高的聚合数据带宽，一个集群中支持数百个节点，一个集群中还应该支持千万级别的文件。
• 大部分HDFS应用对文件要求的是write-one-read-many访问模型。一个文件一旦创建、写入、关闭之后就不需要修改了。这一假设简化了数据一致性问题，使高吞吐量的数据访问成为可能。
• 移动计算的代价比之移动数据的代价低。一个应用请求的计算，离它操作的数据越近就越高效。将计算移动到数据附近，比之将数据移动到应用所在显然更好。
• HDFS被设计为可从一个平台轻松移植到另一个平台。这有助于将HDFS广泛用作大量应用程序的首选平台。

3.2.2 HDFS的特点

• 支持超大文件。超大文件在这里指的是几百M，几百GB，甚至几TB大小的文件。一般来说Hadoop的文件系统会存储TB级别或者PB级别的数据。所以在企业的应用中，数据节点可达到上千个。
• 检测和快速应对硬件故障。在集群的环境中，硬件故障是常见的问题。因为有上千台服务器关联在一起，这样会导致高故障率。因此故障检测和自动恢复（心跳机制）是HDFS文件系统的一个设计目标。其强大的副本机制和NameNode高可用，可快速应对硬件故障问题。
• 流式数据访问。HDFS的数据处理规模比较大，应用一次需要访问大量的数据，同时这些应用一般都是批量处理，而不是用户交互式处理。应用程序能以流的形式访问数据集。主要的是数据的吞吐量，而不是访问速度。
• 简化的一致性模型。大部分HDFS操作文件时，需要一次写入，多次读取。在HDFS中，一个文件一旦经过创建、写入、关闭后，一般就不需要修改了。这样简单的一致性模型，有利于提高吞吐量。
• 高容错性。数据自动保存多个副本，副本丢失后自动恢复。
• 可构建在廉价机器上。构建在廉价机器上，可以轻松的通过扩展机器数量来近乎线性的提高集群存储能力。
  总的来说，HDFS 具有高容错，高扩展，高吞吐，高效，低成本的特性。

3.2.3 HDFS的局限性

• 不能低延迟数据访问。如和用户进行交互的应用，需要数据在毫秒或秒的范围内得到响应。由于Hadoop针对海量数据的吞吐量做了优化，牺牲了获取数据的延迟，所以对于低延迟来说，不适合用Hadoop来做网盘。
• 不适合存储大量的小文件。HDFS支持超大的文件，是通过数据分块然后分布在DataNode，数据的元数据保存在NameNode上。NameNode的内存大小，决定了HDFS文件系统可保存的文件数量。虽然现在的系统内存都比较大，但大量的小文件还是会影响NameNode的性能。
• 不支持多用户写入、修改文件。HDFS的文件只能有一次写入，支持追加写入（2.0 版本开始支持追加），支持修改（3.0版本开始支持修改）。只有这样数据的吞吐量才能大。
• 不支持超强的事务。没有像关系型数据库那样，对事务有强有力的支持。

3.3 HDFS的架构

官方文档

3.3.1 主从架构

HDFS具有主/从架构。HDFS 集群由单个 NameNode组成，这是一个管理文件系统命名空间并调节客户端对文件的访问的主服务器。此外，还有许多数据节点（通常群集中的每个节点一个），用于管理附加到运行它们的节点的存储。HDFS公开文件系统命名空间，并允许用户数据存储在文件中。在内部，文件被拆分为一个或多个块，这些块存储在一组数据节点中。NameNode 执行文件系统命名空间操作，例如打开、关闭和重命名文件和目录。它还确定块到数据节点的映射。数据节点负责为来自文件系统客户端的读取和写入请求提供服务。数据节点还根据 NameNode 的指令执行块创建、删除和复制。

• HDFS集群是标准的master/slave主从架构。
• 一般一个HDFS集群一般由一个NameNode和多个DataNode组成。
• 官方架构图中是一主五从模式，其中五个从角色位于两个机架(Rack)的不同服务器上。
  

3.3.2 分块存储

• 数据块（Block）是HDFS中数据的最基本单元的存储单元。
• 当在HDFS上存储超大文件时，HDFS会以一个标准将文件切分为几块，分别存储到不同的节点上，切出的数据就称为Block。
• Block默认的大小在Hadoop1.x中时64M，在Hadoop2.x和Hadoop3.x中是128M。
• 存储时Block的大小不是由集群本身决定的，而是由客户端决定的。
• 切块的有点
  • 文件块可以保存在不同的节点上，能够存储超大文件。
  • 有利于数据的复制，便于快速备份
• 有利于数据的分布式计算，即MapReduce
• 在HDFS中，如果一个文件小于一个数据块的大小，并不占用整个数据块存储空间，而是实际多大就占用多大，在不考虑数据压缩的情况下。
• 快的大小可以通过配置参数来规定，参数位于hdfs-default.xml中：dfs.blocksize。
  

3.3.3副本机制

• 文件的所有Block都会有副本。副本系数可以在文件创建的时候指定，也可以在之后通过命令改变。
• 副本数由参数dfs.replication控制，默认值是3，也就是会额外再复制2份，连同本身总共3份副本。
• Block副本放置策略
  • 第一个副本：如果是集群内部提交，那么在哪一个DataNode上提交的就将该副本放在哪个节点上。如果是集群之外的客户端上传的数据，那么就随机选择一台同机架的节点进行存储
  • 第二个副本：放置在与第一个副本不同机架的节点上
  • 第三个副本：放置在与第二个副本相同机架的节点上
  • 更多副本：随机节点(哪个节点比较空闲，就放到哪个节点上)
• 创建的最大副本数就是当前集群中DataNode的总数。

3.3.4 机架感知策略

• 所谓的机架感知策略中的机架指的是逻辑机架而不是物理机架。
• 逻辑机架本质上就是一个映射关系，可以通过shell或者Python脚本指定。
• 可以将不同物理机架上的节点配置在同一个逻辑机架上。
• 习惯上，会将同一个同一个物理机架或者是同一个用户组内的节点配置在同一个逻辑机架上。
  机架感知

3.4 HDFS

3.4.1 NameNode

• NameNode用于存储元数据，管理Datanode节点的数据。

• NameNode会将管理的数据块的数据放入数据块池（Block Pool）中。

• NameNode维护HDFS中的元数据信息：

  • 文件的存储路径。
  • 文件和Block之间关系的信息。
  • Block数量信息。
  • Block和DataNode之间的关系信息。

• 元数据格式参照：FileName replicas block-Ids id2host。例如：/test/a.log,3,{b1,b2},[{b1:[h0,h1,h3]},{b2:[h0,h2,h4]}]

• 每一条元数据大概是150B 大小。

• 元数据信息存储在内存以及文件中。其中内存中为实时信息，这样做的目的是为了快速查询；磁盘中的信息不是实时的，存储在磁盘上的目的是为了崩溃恢复。

• 元数据信息会持久化到Namenode节点的硬盘上的edits文件中，最终整理到fsimage文件。

• 存储元数据的目录：dfs/name/current

• 持久化的文件包括：

  • fsimage：元数据镜像文件。存储某NameNode元数据信息，并不是实时同步内存中的数据。一般而言，fsimage中的元数据是落后于内存中的元数据的。
  • edits：操作日志文件，记录了NameNode所执行的操作。

• 当有写请求时，NameNode会首先写该操作先写到磁盘上的edits_inprogress文件中，当edits_inprogress文件写成功后才会修改内存，内存修改成功后向客户端返回成功信号，而此时fsimage中的数据并没有发生改动。所以，fsimage中的数据并不是实时的数据，而是在达到条件时再进行更新。

• 无论是Hadoop1.X还是2.X和3.X，当HDFS启动，Namenode会做一次edits和fsimage合并的操作。这样做的目的是确保fsimage里的元数据更新。

• Namenode通过RPC心跳机制来检测Datanode是否还活着。

• 当HDFS启动的时候，Namenode会将fsimage中的元数据信息加载到内存中，然后等待每个Datanode向Namenode汇报自身的存储的信息，比如存储了哪些文件块，块大小，块id等。

• 如果HDFS处于安全模式，只能对外提供读服务，不能提供写服务。

• 在Hadoop1.X中，NameNode存在单点故障问题。在Hadoop2.X的伪分布式中，NameNode依然存在单点故障，但是在 Hadoop2.X的完全分布式中，可以配置2个NameNode来保证NameNode的高可用，从Hadoop3.X开始，可以配置超过2个NameNode来保证NameNode的高可用。

• 手动触发滚动操作

hdfs dfsadmin -rollEdits

• 启动NameNode后触发，在NameNode进程启动后，会自动滚动出新的edits文件。
• 达到CheckPoint时机。

3.4.2 DataNode

• 在HDFS中，数据是存放在DataNode上面的，并且是以Block的形式存储的
• 存储Block的目录：

dfs/data/current/BP-139455586-192.168.100.101-1568712565049/current/finalized/subdir0/subdir0

• 在HDFS启动的时候，每个DataNode将当前存储的数据块信息告知NameNode节点。

• 之后，DataNode节点会不断向NameNode节点发送心跳报告，默认是每隔3秒发送一次心跳信息，返回的是NameNode向DataNode发送的指令，比如复制某一个Block块等等。

• 心跳信息包含这个节点的状态以及数据块信息。

• 如果NameNode10分钟都没收到DataNode的心跳，则认为其已经lost，那么NameNode会copy这个DataNode上的 Block到其他DataNode上。

• 在HDFS中，DataNode上存储的复本Replication是多复本策略。默认是三个。

• 如果是伪分布式模式，副本只能配置1个，因为如果副本数量 >1，会导致HDFS一直处于安全模式而不能退出。
  

3.4.3 SecondaryNameNode

• SecondaryNameNode并不是NameNode的热备份，而是协助者，帮助NameNode进行元数据的合并。

• 合并过程可能会造成极端情况下的数据丢失，此时可以从SecondaryNameNode中恢复部分数据，但是无法恢复全部

• 合并时机：

  • 根据配置文件设置的时间间隔：

  dfs.namenode.checkpoint.period：默认设置为1小时，指定两个连续检查点之间的最大延迟，单位为s。

  • 根据NameNode上未经CheckPoint的任务的数量。
    dfs.namenode.checkpoint.txns：默认设置为1百万。如果尚未达到检查点周期，将强制紧急Checkpoint。

  • 当HDFS启动时候，也会触发合并，只不过由NameNode执行

• 合并过程：

  • 达到条件后SecondaryNameNode会将NameNode中的fsimage和edits文件通过网络拷贝到本机。
  • 同时NameNode中会创建一个新的edits.inprogress文件，新的读写请求会写入到这个edits.inprogress中。
  • 在SecondaryNameNode中，会将拷贝过来的fsimage和edits加载到内存中，将数据进行合并，然后将合并后的数据写到一个新的文件fsimage.ckpt中。
  • 最后SecondaryNameNode将合并完成的fsimage.ckpt文件拷贝回NameNode中替换之前的fsimage，同时NameNode再将edtis.inprogress重命名为edits。
    

3.4.4 CheckPointNode

与Secondary NameNode节点相同，可以使用hdfs namenode -checkpoint来启动该服务。

3.4.5 BackupNode

• 备份节点提供与检查点节点相同的检查点功能，并维护始终与的NameNode状态保持同步的文件系统的最新副本。除了从NameNode接受文件系统编辑的日志流并将其持久保存到磁盘外，Backup节点还将这些编辑应用到其在内存中的命名空间副本中，从而创建了命名空间的备份。

• 备份节点不需要像Checkpoint节点或Secondary NameNode所要求的那样从活动的NameNode下载fsimage和编辑文件即可创建检查点，因为它在内存中已经具有名称空间的最新状态。备份节点检查点过程效率更高，因为它仅需要将名称空间保存到本地fsimage文件中并重置编辑。

• 由于备份节点在内存中维护名称空间的副本，因此其RAM要求与NameNode相同。

• NameNode一次支持一个备份节点。如果使用了备份节点，则不能注册任何Checkpoint节点。将来将支持同时使用多个备份节点。

• 备份节点的配置方式与检查点节点相同。它以hdfs namenode -backup启动。

• 备份节点及其随附的Web界面的位置是通过dfs.namenode.backup.address和dfs.namenode.backup.http-address配置变量配置的。

• 以下地址提供与关于SecondaryNameNode，CheckPoint Node，Backup Node的讨论信息。
  讨论信息

3.4.6 HDFS写入流程

3.4.7 HDFS读取流程