|
|
|
|
|
HDFS 中的文件，在物理上都是以分块（block）存储的，hadoop2.x 默认块大小为128m
|
|
|
|
|
|
块大小可以通过 `hdfs-site.xml` 文件中的参数 `dfs.block.size` 进行设置：
|
|
|
|
|
|
```XML
|
|
|
|
|
|
<property>
|
|
|
|
|
|
<name>dfs.block.size</name>
|
|
|
|
|
|
<value>134217728</value>
|
|
|
|
|
|
</property>
|
|
|
|
|
|
```
|
|
|
|
|
|
**分块存储的好处有：**
|
|
|
|
|
|
1）一个文件有可能大于集群中的所有磁盘，块机制可以很好地解决这个问题；
|
|
|
|
|
|
2）使用块作为文件存储的逻辑单位，可以简化存储子系统；
|
|
|
|
|
|
3）块非常适合用于数据备份（冗余的数据副本），进而提供数据容错能力。
|
|
|
|
|
|
![[1438655-20210220083347391-59878081.png]]
|
|
|
|
|
|
|
|
|
|
|
|
块大小的设置是否合理，对系统性能影响很大：
|
|
|
|
|
|
1. 设置太小，会增加寻址时间：一个正常大小的文件，被拆分成很多小 block，在读取的时候需要找到所有这些 block。
|
|
|
|
|
|
2. 设置太大，从磁盘传输数据的时间会明显大于定位到这个 block 具体位置所需的时间，进而导致处理此 block 时速度变慢。
|
|
|
|
|
|
|
|
|
|
|
|
# 一、HDFS 的机架感知机制
|
|
|
|
|
|
|
|
|
|
|
|
**HDFS 的机架感知，又叫机架策略，用来决定副本存放位置的策略。**
|
|
|
|
|
|
以默认的副本数=3为例：
|
|
|
|
|
|
- **1st replica**. 如果写请求方所在机器是其中一个datanode,则直接存放在本地,否则随机在集群中选择一个datanode.
|
|
|
|
|
|
- **2nd replica**. 第二个副本存放于不同第一个副本的所在的机架.
|
|
|
|
|
|
- **3rd replica**.第三个副本存放于第二个副本所在的机架,但是属于不同的节点.
|
|
|
|
|
|
HDFS采用一种称为机架感知的策略来改进数据的可靠性、可用性和网络带宽的利用率。通过一个机架感知的过程，NameNode可以确定每一个DataNode所属的机架id。
|
|
|
|
|
|
|
|
|
|
|
|
# 二、HDFS机架感知
|
|
|
|
|
|
|
|
|
|
|
|
## 2.1 网络拓扑结构
|
|
|
|
|
|
在海量数据处理中，主要限制原因之一是节点之间数据的传输速率，即带宽。因此，将两个节点之间的带宽作为两个节点之间的距离的衡量标准。
|
|
|
|
|
|
|
|
|
|
|
|
**hadoop为此采用了一个简单的方法**：把网络看作一棵树，两个节点之间的距离是他们到最近共同祖先的距离总和。该树中的层次是没有预先设定的， 但是相对与数据中心，机架和正在运行的节点，通常可以设定等级。具体想法是针对以下每个常见，可用带宽依次递减：
|
|
|
|
|
|
1>.同一节点上的进程
|
|
|
|
|
|
2>.同一机架上的不同节点
|
|
|
|
|
|
3>.同一数据中心中不同机架上的节点
|
|
|
|
|
|
4>.不同数据中心的节点
|
|
|
|
|
|
|
|
|
|
|
|
举个例子，假设有数据中心d1，机架r1中的节点n1。该节点可以表示为“/d1/r1/n1”。利用这种标记，这里给出四种距离描述：
|
|
|
|
|
|
![[v2-bc178ed60f03fb733003a675e3828ba4_720w.webp]]
|
|
|
|
|
|
**注意：**
|
|
|
|
|
|
1）**当没有配置机架信息时，全部的机器Hadoop都默认在同一个默认的机架下**，以名为”/default-rack”。这样的情况下，不论什么一台datanode机器，无论物理上是否属于同一个机架。都会被觉得是在同一个机架下。
|
|
|
|
|
|
2）一旦配置`topology.script.file.name`。就依照网络拓扑结构来寻找datanode。`topology.script.file.name`这个配置选项的value指定为一个可运行程序。通常为一个脚本。
|
|
|
|
|
|
|
|
|
|
|
|
# 三、HDFS负载均衡
|
|
|
|
|
|
|
|
|
|
|
|
## 3.1 HDFS负载均衡
|
|
|
|
|
|
Hadoop的HDFS集群非常容易出现机器与机器之间磁盘利用率不平衡的情况，例如：当集群内新增、删除节点，或者某个节点机器内硬盘存储达到饱和值。当数据不平衡时，Map任务可能会分配到没有存储数据的机器，这将导致网络带宽的消耗，也无法很好的进行本地计算。
|
|
|
|
|
|
当HDFS负载不均衡时，需要对HDFS进行数据的负载均衡调整，即对各节点机器上数据的存储分布进行调整。从而，让数据均匀的分布在各个DataNode上，均衡IO性能，防止热点的发生。进行数据的负载均衡调整，必须要满足如下原则：
|
|
|
|
|
|
- 数据平衡不能导致数据块减少，数据块备份丢失
|
|
|
|
|
|
- 管理员可以中止数据平衡进程
|
|
|
|
|
|
- 每次移动的数据量以及占用的网络资源，必须是可控的
|
|
|
|
|
|
- 数据均衡过程，不能影响namenode的正常工作
|
|
|
|
|
|
|
|
|
|
|
|
## 3.2 HDFS负载均衡原理
|
|
|
|
|
|
数据均衡过程的核心是一个数据均衡算法，该数据均衡算法将不断迭代数据均衡逻辑，直至集群内数据均衡为止。该数据均衡算法每次迭代的逻辑如下：
|
|
|
|
|
|
![[v2-1a675ef9a5b7e5d913c75e769a12c606_720w.webp]]
|
|
|
|
|
|
步骤分析如下：
|
|
|
|
|
|
1. 数据均衡服务（Rebalancing Server）首先要求 NameNode 生成 DataNode 数据分布分析报告,获取每个DataNode磁盘使用情况
|
|
|
|
|
|
2. Rebalancing Server汇总需要移动的数据分布情况，计算具体数据块迁移路线图。数据块迁移路线图，确保网络内最短路径
|
|
|
|
|
|
3. 开始数据块迁移任务，Proxy Source Data Node复制一块需要移动数据块
|
|
|
|
|
|
4. 将复制的数据块复制到目标DataNode上
|
|
|
|
|
|
5. 删除原始数据块
|
|
|
|
|
|
6. 目标DataNode向Proxy Source Data Node确认该数据块迁移完成
|
|
|
|
|
|
7. Proxy Source Data Node向Rebalancing Server确认本次数据块迁移完成。然后继续执行这个过程，直至集群达到数据均衡标准
|
|
|
|
|
|
|
|
|
|
|
|
### 3.2.1 DataNode分组
|
|
|
|
|
|
在第2步中，HDFS会把当前的DataNode节点，根据阈值的设定情况划分到Over、Above、Below、Under四个组中。在移动数据块的时候，Over组、Above组中的块向Below组、Under组移动。
|
|
|
|
|
|
![[v2-1a675ef9a5b7e5d913c75e769a12c606_720w 1.webp]]
|
|
|
|
|
|
|
|
|
|
|
|
### 3.2.2 HDFS数据自动平衡脚本使用
|
|
|
|
|
|
在Hadoop中，包含一个start-balancer.sh脚本，通过运行这个工具，启动HDFS数据均衡服务。该工具可以做到热插拔，即无须重启计算机和 Hadoop 服务。HadoopHome/bin目录下的start−balancer.sh脚本就是该任务的启动脚本。启动命令为：HadoopHome/bin目录下的start−balancer.sh脚本就是该任务的启动脚本。启动命令为：`Hadoop_home/bin/start-balancer.sh –threshold`
|
|
|
|
|
|
|
|
|
|
|
|
**影响Balancer的几个参数：**
|
|
|
|
|
|
- -threshold
|
|
|
|
|
|
- 默认设置：10，参数取值范围：0-100
|
|
|
|
|
|
- 参数含义：判断集群是否平衡的阈值。理论上，该参数设置的越小，整个集群就越平衡
|
|
|
|
|
|
|
|
|
|
|
|
- dfs.balance.bandwidthPerSec
|
|
|
|
|
|
- 默认设置：1048576（1M/S）, 需要跟进自己的集群带宽情况进行设置，一般为30M或者60M左右
|
|
|
|
|
|
- 参数含义：Balancer运行时允许占用的带宽
|
