个人Hadoop学习笔记

大数据 启蒙

分治思想

适用于以下场景：

1. Redis集群
2. ElasticSearch
3. HBase
4. Hadoop生态
5. 等等场景

大数据重点核心思想

1. 分而治之
2. 并行计算
3. 计算向数据移动
4. 数据本地化读取

Hadoop的项目中，包含了如下模块

1. Hadoop Common

2. Hadoop Distributed File System (HDFS)

3. Hadoop YARN（分布式资源管理）

4. Hadoop MapReduce

   1、2、4在1.X的Hadoop的版本中已经存在，到2.X版本时才推出了YARN。

Hadoop相关的其他较为重要的apache项目

1. HBase
2. Hive
3. Spark
4. ZooKeeper

Hadoop—HDFS（Hadoop Distributed File System）

引出疑问：为何已经有那么多的分布式文件系统了，hadoop项目还要再开发出一个HDFS文件系统？

答：为了更好地支持分布式计算

存储模型

• 将文件，线性地，按字节切割成块（block），有id和offset(偏移量)

  • 按字节切割，会把一个字符对应多个字节给切"坏"了，比如，"中"字，按照UTF-8的编码，是3个字节，这样有可能会分在两个不同的块之中。

    这就需要后期计算时去修复这个问题。

• 文件与文件的的block可以不一样

  • A文件可以每个块4M，而B文件可以是每个块8M。

• 一个文件除了最后一个块，其他的块，大小一致

  • 因为最后一个块可能不够一个块的标准那么大。

• 块（block）的大小，应该依据硬件的I/O特性进行调整

• 块（block）被分散存放在集群的节点中，需要具有location

• 块（block）需要具有副本（replication），没有主从概念，副本不能出现在同一个节点。

  • 这里需要区分一下，主从和主备。

• 副本是满足可靠性和性能的关键

• 文件上传可以指定块的大小和副本的数量，上传后只能修改副本的数量

  • 上传后，块的大小是不支持修改的，若修改文件的某个块，该块及其后面的块的偏移量为了保持正确，需要将各自的块内容进行修改，这样集群中的机器则需要大量的资源参与该行为（泛洪效应）！

• 一次写入，多次读取，不支持修改

  • 如上一条

• 文件支持追加数据（追加新的块）

架构设计

• HDFS是一个主从（Master/Slaves）架构
• 由一个NameNode和若干个DataNode组成
• 面向文件，包含文件数据（data）和文件元数据（metadata）
• NameNode负责存储和管理文件元数据，并维护了一个层次型的文件目录树
• DataNode负责存储文件数据（block块），并提供block块的读写
• DataNode和NameNode维持心跳，并汇报自己持有的block块信息
• Client和NameNode交互元数据，和DataNode交互文件block块数据

角色功能

• NameNode
  • 完全基于内存存储文件元数据、目录结构、文件block块的映射
    • 基于内存是要快速对请求进行响应
  • 需要持久化方案保证数据可靠性
    • 由于基于内存，所以需要将数据持久化，以保证数据可靠性
  • 提供副本放置策略
• DataNode
  • 基于本地磁盘存储block块（文件形式）
  • 并保存block块的校验和数据，保证block块的可靠性
    • 类似于常用的MD5值的校验
  • 与NameNode保持心跳，并汇报block块列表状态

元数据持久化

​ 方案一：日志文件（记录实时发生的增删改的操作）；优点：完整性好；缺点：加载恢复数据慢，并且日志文件占空间特别大

​ 方案二：镜像、快照、dump、db，间隔一段时间，内存中全量数据基于某一个时间点，向磁盘的溢写。优点：恢复速度快。缺点：由于是间隔，容易丢失部分数据。

​ HDFS中，两种方案都使用了，日志文件使用的是EditLog，快照则是使用FsImage。HDFS是使用最近时点的FsImage和增量的EditLog。

• 任何对文件系统元数据产生修改的操作，NameNode都会使用一种叫EditLog的事务日志j记录下来
• 使用FsImagec存储内存所有的元数据状态
• 使用本地磁盘保存EditLog和FsImage
• EditLog具有完整性，数据丢失少，但恢复速度慢，并有体积膨胀风险
• FsImage具有恢复速度快，体积与内存数据相当，但不能实时保存，数据丢失多
• NameNode使用了FsImage + EditLog整合的方案
• 滚动将增量的EditLog更新到FsImage，以保证更近时点的FsImage和更小的EditLog体积

安全模式

• HDFS搭建时会格式化，格式化操作会产生一个空的FsImage
• 当NameNode启动时，它从硬盘中读取EditLog和FsImage
• 将所有的EditLog中的事务作用在内存中的FsImage上
• 并将新版本的FsImage从内存中保存到本地磁盘上
• 然后删除旧的EditLog，因为这个EditLog的事务已经作用到FsImage上了

PS：NameNode恢复FsImage中，只恢复了文件的元数据信息，和块的名称，而块的位置，是不会恢复的，因为没有持久化块的位置信息，这时候就是在启动后，由DataNode向NameNode汇报，从而重新获取块的位置信息

Q：什么是安全模式

A：

• NameNode启动后，会进入一个称为安全模式的特殊状态
• 处于安全模式的NameNode不会进行数据块的复制
• NameNode从所有的DataNode接收心跳信号和块状态报告
• 每当NameNode检测确认某个数据块的副本数目达到某个值之后，那么该数据块就会被认为是**副本安全（safely replicated）**的
• •在一定百分比（这个参数可配置）的数据块被NameNode检测确认是安全之后（加上一个额外的30秒等待时间），NameNode将退出安全模式状态。
• 接下来它会确定还有哪些数据块的副本没有达到指定数目，并将这些数据块复制到其他DataNode上。

---

HDFS中的SNN

SecondaryNameNode（SNN）

• 在非Ha模式下，SNN一般是独立的节点，周期完成对NN的EditLog向FsImage合并，减少EditLog大小，减少NN启动时间
• 根据配置文件设置的时间间隔fs.checkpoint.period 默认3600秒
• 根据配置文件设置edits log大小 fs.checkpoint.size 规定edits文件的最大值默认是64MB

---

Block的副本放置策略

PS：服务器分为塔式服务器，机架服务器和刀片服务器。

• 第一个副本：放置在上传文件的DataNode；如果是集群外提交，则随机挑选一台磁盘不太满，CPU不太忙的节点。
• 第二个副本：放置在与第一个副本不同机架的节点上。
• 第三个副本：与第二个副本相同机架的其他节点上。
• 更多的副本：随机节点。

早期1.X版本的第二个副本是放在与第一个副本同机架的其他节点，这样若是副本数设为2，那这两个副本将会放在同一个机架上，若该机架的交换机或电源出现问题，则直接就GG了！

HDFS的读写流程

HDFS的写流程

1. HDFS的客户端Client向NameNode请求，交互文件的元数据
   • 包括检查目标文件是否存在，父目录是否存在，判定元数据是否有效等。
2. NameNode则根据block的副本放置策略返回一个有序的DataNode列表。这中间还有一个，距离的计算。
3. Client客户端，会与返回的第一个DataNode建立管道连接（Pipeline，本质上是RPC调用）
   • 这里并不是Client客户端与每个DataNode建立连接，而只与第一个DataNode建立连接。
4. 客户端与第一个DataNode的管道中，会将block切分成更小的packet。
   • 客户端把block切割成更小的packet是为了让DataNode副本之间的传输，形成流水线，而对于客户端，也是只传输一次block。
   • packet的大小是64KB，并且其中使用chunk（512B）和chunksum（4B）填充。
     • chunksum，是chunk的校验和
     • 即每512B的内容，会生成一个校验和（4B）
5. 第一个DataNode在接收完block的第一个packet后，则会向第二个DataNode传输这第一个packet并且继续接收客户端发送过来的第二个packet。
6. 同理，第二个接收完第一个DataNode传过来的第一个packet后，则会向第三个DataNode传输这第一个packet并且继续接收第一个DataNode发送过来的第二个packet，以此类推，形成一个流水线。
7. 当block传输完成时，DataNode们各自向NameNode汇报，同时Client继续传输下一个block

PS：Client的传输和block的汇报是并行的！

传输过程中，若其中一个节点"挂"了的情况，分

1. 第一个节点挂了，那么客户端，与第二个节点建立pipeline连接，继续从第二个节点接收的packet开始继续传
2. 中间节点挂了，则上一节点直接向下一节点直接续传packet。
3. 结尾节点挂了，则上一节点不向这个结尾节点传packet。

挂掉导致的block块缺失，会在DataNode与NameNode汇报的时候发现，并且由其他的副本DataNode复制出一份给缺失的节点。

HDFS的读流程

1. 客户端与NameNode进行交互，取回文件的block的位置信息
2. 客户端从每个block的各个副本之中，选出离自己最近的DataNode，进行下载block块

•为了降低整体的带宽消耗和读取延时，HDFS会尽量让读取程序读取离它最近的副本。

•如果在读取程序的同一个机架上有一个副本，那么就读取该副本。

•如果一个HDFS集群跨越多个数据中心，那么客户端也将首先读本地数据中心的副本。

•语义：下载一个文件：

​ • Client和NN交互文件元数据获取fileBlockLocation

​ • NN会按距离策略排序返回

​ • Client尝试下载block并校验数据完整性

•语义：下载一个文件其实是获取文件的所有的block元数据，那么子集获取某些block应该成立

​ • Hdfs支持client给出文件的offset自定义连接哪些block的DN，自定义获取数据

​ • 这个是支持计算层的分治、并行计算的核心

HDFS解决方案

单点故障

• 高可用方案：HA（High Available）
• 多个NameNode，主备切换
• Hadoop 2.x的版本只支持HA的一主一备

压力过大（内存受限）

• 联帮机制：Federation（元数据分片）
• 多个NaneNode管理不同的元数据

HDFS-HA解决方案：

CAP原则

C：Consistency，一致性

A：Availability，可用性

P：Partition tolerance，分区容忍性

修改HDFS的配置

1. core-site.xml

		<property>
		  <name>fs.defaultFS</name>
		  <value>hdfs://mycluster</value>
		  <!-- 这里的mycluster是可以自定义的名称 -->
		</property>

		 <property>
		   <!-- 配置zookeeper集群的位置 -->
		   <name>ha.zookeeper.quorum</name>
		   <value>node02:2181,node03:2181,node04:2181</value>
		 </property>

2. hdfs-site.xml

		<property>
		  <name>dfs.nameservices</name>
		  <value>mycluster</value>
		  <!-- mycluster也是可以自定义写的名称，这里写了什么，后面有些属性就要注意写成什么 -->
		</property>
		<property>
		  <!-- 配置映射一对多 -->
		  <name>dfs.ha.namenodes.mycluster</name>
		  <value>nn1,nn2</value>
		</property>
		<property>
		  <!-- 配置映射的多个节点的地址 -->
		  <name>dfs.namenode.rpc-address.mycluster.nn1</name>
		  <value>node01:8020</value>
		</property>
		<property>
		  <!-- 配置映射的多个节点的地址 -->
		  <name>dfs.namenode.rpc-address.mycluster.nn2</name>
		  <