乐趣区

关于hadoop:Hadoop-入门笔记九-HDFS-优化方案和动态节点管理

jiezi

HDFS 优化计划

1. 短路本地读取：Short Circuit Local Reads

1. 背景

在 HDFS 中，不论是 Local Reads（DFSClient 和 Datanode 在同一个节点）还是 Remote Reads（DFSClient 和 Datanode 不在同一个节点），底层解决形式都是一样的，都是先由 Datanode 读取数据，而后再通过 RPC（基于 TCP）把数据传给 DFSClient。这样解决是比较简单的，然而性能会受到一些影响，因为须要 Datanode 在两头做一次直达。尤其 Local Reads 的时候，既然 DFSClient 和数据是在一个机器下面，那么很天然的想法，就是让 DFSClient 绕开 Datanode 本人去读取数据

所谓的“短路”读取绕过了 DataNode，从而容许客户端间接读取文件。显然，这仅在客户端与数据位于同一机器的状况下才可行。短路读取为许多利用提供了显着的性能晋升。

2. 短路本地读取

在 HDFS-2246 这个 JIRA 中，工程师们的想法是既然读取数据 DFSClient 和数据在同一台机器上，那么 Datanode 就把数据在文件系统中的门路，从什么中央开始读 (offset) 和须要读取多少 (length) 等信息通知 DFSClient，而后 DFSClient 去关上文件本人读取。想法很好，问题在于配置简单以及平安问题。

首先是配置问题，因为是让 DFSClient 本人关上文件读取数据，那么就须要配置一个白名单，定义哪些用户领有拜访 Datanode 的数据目录权限。如果有新用户退出，那么就得批改白名单。须要留神的是，这里是容许客户端拜访 Datanode 的数据目录， 也就意味着，任何用户领有了这个权限，就能够拜访目录下其余数据，从而导致了安全漏洞 。因而，这个实现曾经 不倡议应用 了。

3. 短路本地读取安全性改良

在 HDFS-347 中，提出了一种新的解决方案，让短路本地读取数据更加平安。

Unix Domain Socket 是一种过程间的通信形式，它使得 同一个机器上的两个过程能以 Socket 的形式通信 。它带来的另一大 益处是，利用它两个过程除了能够传递一般数据外，还能够在过程间传递文件描述符。

假如机器上的两个用户 A 和 B，A 领有拜访某个文件的权限而 B 没有，而 B 又须要拜访这个文件。借助 Unix Domain Socket，可 以让 A 关上文件失去一个文件描述符，而后把文件描述符传递给 B，B 就能读取文件外面的内容了即便它没有相应的权限。在 HDFS 的场景外面，A 就是 Datanode，B 就是 DFSClient，须要读取的文件就是 Datanode 数据目录中的某个文件。

这个计划在平安上就比上一个计划上好一些，至多它只容许 DFSClient 读取它须要的文件

4. 短路本地读取配置

  1. libhadoop.so
    因为 Java 不能间接操作 Unix Domain Socket，所以须要装置 Hadoop 的 native 包 libhadoop.so。在编译 Hadoop 源码的时候能够通过编译 native 模块获取。能够用如下命令来查看 native 包是否装置好。

    hadoop checknative

  2. hdfs-site.xml
<property>
    <name>dfs.client.read.shortcircuit</name>
    <value>true</value>
  </property>
  <property>
    <name>dfs.domain.socket.path</name>
    <value>/var/lib/hadoop-hdfs/dn_socket</value>
  </property>

dfs.client.read.shortcircuit 是关上短路本地读取性能的开关，dfs.domain.socket.path 是 Datanode 和 DFSClient 之间沟通的 Socket 的本地门路。

2. HDFS Block 负载平衡器：Balancer

1. 背景

HDFS 数据可能并不总是在 DataNode 之间均匀分布 。一个常见的起因是向现有群集中增加了新的 DataNode。HDFS 提供了一个 Balancer 程序，剖析 block 搁置信息并且在整个 DataNode 节点之间均衡数据，直到被视为均衡为止。
平衡器无奈在单个 DataNode 上的各个卷之间进行均衡。

2. 命令行配置和运行

命令:

hdfs balancer --help

  1. 设置均衡数据传输带宽
    命令：

    hdfs dfsadmin -setBalancerBandwidth   newbandwidth

  2. 默认运行 balancer
    命令:

    hdfs balancer

    此时将会以默认参数进行数据块的均衡操作。

  3. 批改阈值运行 balancer
    命令:

    hdfs balancer -threshold 5

    Balancer 将以阈值 5%运行（默认值 10%），这意味着程序将确保每个 DataNode 上的磁盘使用量与群集中的总体使用量相差不超过 5%。例如，如果集群中所有 DataNode 的总体使用率是集群磁盘总存储容量的 40%，则程序将确保每个 DataNode 的磁盘使用率在该 DataNode 磁盘存储容量的 35%至 45%之间。

3. 磁盘均衡器：HDFS Disk Balancer

1. 背景

绝对于集体 PC, 服务器个别能够通过挂载对块磁盘来扩充单机的存储能力
在 Hadoop HDFS 中，DataNode 负责最终数据 block 的存储，在所在机器上的磁盘之间调配数据块。当写入新 block 时，DataNodes 将依据抉择策略（循环策略或可用空间策略）来抉择 block 的磁盘（卷）。
循环策略: 它将新 block 均匀分布在可用磁盘上。默认此策略。
可用空间策略： 此策略将数据写入具备更多可用空间（按百分比）的磁盘

然而，在长期运行的群集中采纳循环策略时，DataNode 有时会不平均地填充其存储目录（磁盘 / 卷），从而导致某些磁盘已满而其余磁盘却很少应用的状况。产生这种状况的起因可能是因为大量的写入和删除操作，也可能是因为更换了磁盘。
另外，如果咱们应用基于可用空间的抉择策略，则每个新写入将进入新增加的空磁盘，从而使该期间的其余磁盘处于闲暇状态。这将在新磁盘上创立瓶颈。
因而，须要一种 Intra DataNode Balancing（DataNode 内数据块的均匀分布）来解决 Intra-DataNode 偏斜（磁盘上块的不均匀分布），这种偏斜是因为磁盘更换或随机写入和删除而产生的。
因而，Hadoop 3.0 中引入了一个名为 Disk Balancer 的工具，该工具专一于在 DataNode 内散发数据。

2. HDFS Disk Balancer 简介

HDFS disk balancer 是 Hadoop 3 中引入的命令行工具，用于均衡 DataNode 中的数据在磁盘之间散布不平均问题。 这里要特地留神，HDFS disk balancer 与 HDFS Balancer 是不同的：
HDFS disk balancer 针对给定的 DataNode 进行操作 ，并将块从一个磁盘挪动到另一个磁盘, 是 DataNode 外部数据在不同磁盘间均衡；
HDFS Balancer 均衡了 DataNode 节点之间的散布。

3. HDFS Disk Balancer 性能

HDFS Disk balancer 反对两个次要性能，即 报告和均衡。

  1. 数据流传报告

了定义 一种办法来掂量集群中哪些计算机蒙受数据分布不均的影响 ，HDFS 磁盘平衡器定义了 HDFS Volume Data Density metric（卷 / 磁盘数据密度度量规范）和 Node Data Density metric（节点数据密度度量规范）。
HDFS 卷数据密度度量规范可能比拟数据在给定节点的不同卷上的散布状况。
节点数据密度度量容许在节点之间进行比拟。

  • Volume data density metric 计算过程

假如有一台具备四个卷 / 磁盘的计算机 -Disk1，Disk2，Disk3，Disk4，各个磁盘应用状况：

Disk1 Disk2 Disk3 Disk4
capacity 200 GB 300 GB 350 GB 500 GB
dfsUsed 100 GB 76 GB 300 GB 475 GB
dfsUsedRatio 0.5 0.25 0.85 0.95
volumeDataDensity 0.20 0.45 -0.15 -0.24

Total capacity= 200 + 300 + 350 + 500 = 1350 GB
Total Used= 100 + 76 + 300 + 475 = 951 GB
因而，每个卷 / 磁盘上的现实存储为：
Ideal storage = total Used ÷ total capacity= 951÷1350 = 0.70
也就是每个磁盘应该放弃在 70% 现实存储容量。
VolumeDataDensity = idealStorage – dfs Used Ratio
比方 Disk1 的卷数据密度 = 0.70-0.50 = 0.20。其余 Disk 以此类推。
volumeDataDensity 的正值示意磁盘未充分利用，而负值示意磁盘绝对于以后现实存储指标的利用率过高。

  • Node Data Density 计算过程
    Node Data Density（节点数据密度）= 该节点上所有卷 / 磁盘 volume data density 绝对值的总和。
    上述例子中的节点数据密度 =|0.20|+|0.45|+|-0.15|+|-0.24| =1.04
    较低的 node Data Density 值示意该机器节点具备较好的扩展性，而较高的值示意节点具备更歪斜的数据分布。
    一旦有了 volumeDataDensity 和 nodeDataDensity，就能够找到集群中数据分布歪斜的节点，或者能够获取给定节点的 volumeDataDensity。

    1. 磁盘均衡

    当指定某个 DataNode 节点进行 disk 数据均衡，就能够先计算或读取以后的 volumeDataDensity（磁盘数据密度）。有了这些信息，咱们能够轻松地确定哪些卷已超量配置，哪些卷已有余。为了将数据从一个卷挪动到 DataNode 中的另一个卷，Hadoop 开发实现了基于 RPC 协定的 Disk Balancer。

4. HDFS Disk Balancer 开启

HDFS Disk Balancer 通过创立打算进行操作，该打算是一组语句，形容应在两个磁盘之间挪动多少数据，而后在 DataNode 上执行该组语句。打算蕴含多个挪动步骤。打算中的每个挪动步骤都具备指标磁盘，源磁盘的地址。挪动步骤还具备要挪动的字节数。该打算是针对可操作的 DataNode 执行的。
默认状况下，Hadoop 群集上曾经启用了 Disk Balancer 性能。通过在 hdfs-site.xml 中调整 dfs.disk.balancer.enabled 参数值，抉择在 Hadoop 中是否启用磁盘平衡器。

5. HDFS Disk Balancer 相干命令

  1. Plan 打算
    命令:

    hdfs diskbalancer -plan <datanode>

-out    // 管制打算文件的输入地位
-bandwidth    // 设置用于运行 Disk Balancer 的最大带宽。默认带宽 10 MB/s。–thresholdPercentage  // 定义磁盘开始参加数据重新分配或均衡操作的值。默认的 thresholdPercentage 值为 10%，这意味着仅当磁盘蕴含的数据比现实存储值多 10%或更少时，磁盘才用于均衡操作。-maxerror    // 它容许用户在停止挪动步骤之前为两个磁盘之间的挪动操作指定要疏忽的谬误数。-v    // 具体模式，指定此选项将强制 plan 命令在 stdout 上显示打算的摘要。-fs    // 此选项指定要应用的 NameNode。如果未指定，则 Disk Balancer 将应用配置中的默认 NameNode。

  2. Execute 执行
    命令：

    hdfs diskbalancer -execute <JSON file path>

    execute 命令针对为其生成打算的 DataNode 执行打算。

  3. Query 查问
    命令：

    hdfs diskbalancer -query <datanode>

    query 命令从运行打算的 DataNode 获取 HDFS 磁盘平衡器的以后状态。

  4. Cancel 勾销
    命令：

    hdfs diskbalancer -cancel <JSON file path>
hdfs diskbalancer -cancel planID node <nodename>

    cancel 命令勾销运行打算。

  5. Report 汇报
命令：hdfs diskbalancer -fs https://namenode.uri -report <file://>

4. 纠删码技术: Erasure Coding

1. 背景: 3 正本策略弊病

为了提供容错能力，HDFS 会依据 replication factor（复制因子）在不同的 DataNode 上复制文件块。默认复制因子为 3（留神这里的 3 指的是 1 +2=3，不是额定 3 个），则原始块除外，还将有额定两个正本。每个正本应用 100%的存储开销，因而导致 200%的存储开销。这些正本也耗费其余资源，例如网络带宽。

在 复制因子为 N 时，存在 N - 1 个容错能力，但存储效率仅为 1 /N。
这种复制减少了存储开销，并且仿佛很低廉。因而，HDFS 应用 Erasure Coding（纠删码）代替复制，以提供雷同级别的容错能力，并且存储开销不超过 50%。
Erasure Coding 文件的复制因子始终为 1，用户无奈对其进行更改。

2. Erasure Coding（EC）简介

纠删码技术（Erasure coding）简称 EC，是一种编码容错技术 。最早用于通信行业，数据传输中的数据恢复。它 通过对数据进行分块，而后计算出校验数据，使得各个局部的数据产生关联性。 当一部分数据块失落时，能够通过残余的数据块和校验块计算出失落的数据块。
Hadoop 3.0 之后引入了纠删码技术（Erasure Coding），它 能够进步 50% 以上的存储利用率，并且保证数据的可靠性。

存储系统 RAID 应用纠删码。RAID 通过 striping（条带化）实现纠删码，也就是说，将逻辑上间断的数据（例如文件）划分为较小的单位（bit, byte, or block），并将间断的单位存储在不同的磁盘上。

对于原始数据集的每个条带，都会依据纠删码算法来计算并存储肯定数量的奇偶校验单元，该过程称为 编码。

任何条带化单元中的谬误都能够依据残余数据和奇偶校验单元从计算中复原，此过程称为 解码。

3. Reed-Solomon（RS）码

  1. RS 码介绍
    Reed-Solomon（RS）码是存储系统较为 罕用的一种纠删码 ，它有两个参数 k 和 m，记为 RS(k，m)。如下图所示，k 个数据块组成一个向量被乘上一个生成矩阵（Generator Matrix）GT 从而失去一个码字（codeword）向量，该向量由 k 个数据块和 m 个校验块形成。如果一个数据块失落，能够用(GT)- 1 乘以码字向量来复原出失落的数据块。RS(k，m) 最多可容忍 m 个块（包含数据块和校验块）失落。
  2. RS 码艰深解释
    比方有 7、8、9 三个原始数据，通过矩阵乘法，计算出来两个校验数据 50、122。这时原始数据加上校验数据，一共五个数据：7、8、9、50、122，能够任意丢两个，而后通过算法进行复原。

4. Hadoop EC 架构

为了反对纠删码，HDFS 体系结构进行了一些更改调整。

  1. NameNode 扩大
    条带化的 HDFS 文件在逻辑上由 block group（块组）组成，每个块组蕴含肯定数量的外部块。这容许在块组级别而不是块级别进行文件治理。
  2. 客户端扩大
    客户端的读写门路失去了加强，能够并行处理块组中的多个外部块。
  3. DataNode 扩大
    DataNode 运行一个附加的 ErasureCodingWorker（ECWorker）工作，以对失败的纠删编码块进行后盾复原。NameNode 检测到失败的 EC 块，而后 NameNode 抉择一个 DataNode 进行复原工作。
  4. 纠删码策略
    为了适 应异构的工作负载 ，容许 HDFS 群集中的文件和目录具备不同的复制和纠删码策略。纠删码策略封装了如何对文件进行编码 / 解码。默认状况下启用 RS-6-3-1024k 策略，RS 示意编码器算法 Reed-Solomon，6、3 中示意数据块和奇偶校验块的数量，1024k 示意条带化单元的大小。
    目录上还反对默认的 REPLICATION 计划。它只能在目录上设置，以强制目录采纳 3 倍复制计划，而不继承其先人的纠删码策略。此策略能够使 3x 复制计划目录与纠删码目录交织。REPLICATION 始终处于启用状态。
    此外也反对用户通过 XML 文件定义本人的 EC 策略，Hadoop conf 目录中有一个名为 user_ec_policies.xml.template 的示例 EC 策略 XML 文件，用户能够参考该文件。
  5. Intel ISA-L
    英特尔 ISA- L 代表英特尔智能存储减速库。ISA- L 是针对存储应用程序而优化的低级性能的开源汇合。它包含针对 Intel AVX 和 AVX2 指令集优化的疾速块 Reed-Solomon 类型擦除代码。HDFS 纠删码能够利用 ISA- L 减速编码和解码计算。

5. Erasure Coding 部署形式

  1. 集群和硬件配置
    编码和解码工作会 耗费 HDFS 客户端和 DataNode 上的额定 CPU。
    纠删码文件也散布在整个机架上，以实现机架容错。这意味着在读写条带化文件时，大多数操作都是在机架上进行的。因而，网络带宽也十分重要 。
    对于机架容错，领有足够数量的机架也很重要，每个机 架所包容的块数不超过 EC 奇偶校验块的数 。
    机架数量 =（数据块 + 奇偶校验块）/ 奇偶校验块后取整。比方对于 EC 策略 RS（6,3），这意味着起码 3 个机架（由（6 + 3）/ 3 = 3 计算），现实状况下为 9 个或更多，以解决打算内和计划外的停机。对于机架数少于奇偶校验单元数的群集，HDFS 无奈维持机架容错能力，但仍将尝试在多个节点之间散布条带化文件以保留节点级容错能力。因而，倡议设置具备相似数量的 DataNode 的机架。
  2. 纠删码策略配置
    纠删码策略由参数 dfs.namenode.ec.system.default.policy 指定，默认是 RS-6-3-1024k，其余策略默认是禁用的。能够 通过 hdfs ec [-enablePolicy -policy <policyName>]命令启用策略集。

  3. 启用英特尔 ISA-L
    默认 RS 编解码器的 HDFS 本机实现利用 Intel ISA- L 库来改善编码和解码计算。要启用和应用 Intel ISA-L，须要执行三个步骤。

    • 建设 ISA- L 库；
    • 应用 ISA- L 反对构建 Hadoop；
    • 应用 -Dbundle.isal 将 isal.lib 目录的内容复制到最终的 tar 文件中。应用 tar 文件部署 Hadoop。确保 ISA- L 在 HDFS 客户端和 DataNode 上可用。

6. EC 命令

HDFS 提供了一个 ec 子命令来执行与纠删码无关的治理命令。

  • [-setPolicy -path <path> [-policy <policy>] [-replicate]]

在指定门路的目录上设置擦除编码策略。
path：HDFS 中的目录。这是必填参数。设置策略仅影响新创建的文件，而不影响现有文件。
policy：用于此目录下文件的擦除编码策略。默认 RS-6-3-1024k 策略。
-replicate 在目录上利用默认的 REPLICATION 计划，强制目录采纳 3x 复制计划。
-replicate 和 -policy <policy> 是可选参数。不能同时指定它们。

  • [-getPolicy -path < path >]
    获取指定门路下文件或目录的擦除编码策略的详细信息。
  • [-unsetPolicy -path < path >]
    勾销设置先前对目录上的 setPolicy 的调用所设置的擦除编码策略。如果该目录从先人目录继承了擦除编码策略，则 unsetPolicy 是 no-op。在没有显式策略集的目录上勾销策略将不会返回谬误。
  • [-listPolicies]
    列出在 HDFS 中注册的所有（启用，禁用和删除）擦除编码策略。只有启用的策略才适宜与 setPolicy 命令一起应用。
  • [-addPolicies -policyFile < 文件 >]
    增加用户定义的擦除编码策略列表。
  • [-listCodecs]
    获取零碎中反对的擦除编码编解码器和编码器的列表。
  • [-removePolicy -policy <policyName>]
    删除用户定义的擦除编码策略。
  • [-enablePolicy -policy <policyName>]
    启用擦除编码策略。
  • [-disablePolicy -policy <policyName>]
    禁用擦除编码策略。

二.HDFS 优化计划

1. 背景

已有 HDFS 集群容量曾经不能满足存储数据的需要，须要在原有集群根底上动静增加新的 DataNode 节点。就是俗称的 动静扩容 。
旧的服务器须要进行服役更换，暂停服务，须要在当下的集群中进行某些机器上 HDFS 的服务，俗称 动静缩容。

2. 动静扩容、节点上线

  1. 新机器根底环境筹备

    • 主机名 IP
      确保新机器 IP 和已有 HDFS 集群所属同一网段


    新机器零碎 hostname

    • Hosts 映射

      集群所有节点放弃 hosts 文件对立
    • 防火墙 工夫同步
      敞开防火墙


    集群工夫同步

    • SSH 免密登录

    为了后续脚本一键启动敞开集群不便，设置 NameNode 到新机器的免密登录

    1. 运行命令:ssh-keygen -t rsa
      默认在 ~/.ssh 目录生成两个文件：
      id_rsa：私钥
      id_rsa.pub：公钥

    2. 导入公钥到认证文件, 更改权限

      1. 导入本机
      cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
      1. 导入要免明码登录的服务器
      scp ~/.ssh/id_rsa.pub xxx@host:/home/id_rsa.pub
      1. 而后，将公钥导入到认证文件(这一步的操作在服务器上进行)
      cat /home/id_rsa.pub >> ~/.ssh/authorized_keys

    3. 在服务器上更改权限 (很重要，如果不这么设置，就是不让你免密登录)

      chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

    4. 最初在本地登录服务器

      ssh -v hostname@hostip
    • JDK 环境

    2. Hadoop 配置

    1. NameNode 节点配置

    批改 namenode 节点 workers 配置文件，减少新节点主机名，便于后续一键启停。

    2. 新机器配置

    从 namenode 节点复制 hadoop 安装包到新节点，留神不 包含 hadoop.tmp.dir 指定的数据存储目录 。
    新机器上配置 hadoop 环境变量

    vim /etc/profile
export HADOOP_HOME=/export/server/hadoop-3.1.4
export PATH=$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin
source /etc/profile

    3. 手动启动 DataNode 过程

    Hadoop fs --daemon start datanode

    4. Hadoop web 页面查看

    5. DataNode 负载平衡服务

    新退出的节点，没有数据块的存储，使得集群整体来看负载不平衡。因而最初还须要对 hdfs 负载设置平衡。首先设置数据传输带宽。

    hdfs dfsadmin -setBalancerBandwidth 104857600

    而后启动 Balancer，期待集群自平衡实现即可。

    hdfs balancer -threshold 5

    3. 动静缩容、节点下线

    1. 增加服役节点

    在 namenode 机器的 hdfs-site.xml 配置文件中 须要提前配置 dfs.hosts.exclude 属性 ，该属性指向的文件就是所谓的黑名单列表，会被 namenode 排除在集群之外。如果文件内容为空，则意味着不禁止任何机器。
    提前配置好的目标是让 namenode 启动的时候就能加载到该属性，只不过还没有指定任何机器。否则就须要重启 namenode 能力加载，因而这样的操作咱们称之为具备前瞻性的操作。
    编辑 dfs.hosts.exclude 属性指向的 excludes 文件，增加须要服役的主机名称。
    留神：如果正本数是 3，退役的节点小于等于 3，是不能服役胜利的，须要批改正本数后能力服役。

    2. 刷新集群

    在 namenode 所在的机器刷新节点：hdfs dfsadmin -refreshNodes
    期待服役节点状态为 decommissioned（所有块曾经复制实现）

    3. 手动敞开 DataNode 过程

    hdfs --daemon stop datanode

    4. DataNode 负载平衡服务

    如果须要能够对已有的 HDFS 集群进行负载平衡服务。

    hdfs balancer -threshold 5

    4. 黑白名单机智

    1. 白名单

    所谓的 白名单指的是容许哪些机器退出到以后的 HDFS 集群中 ，是一种准入机制。
    白名单由 dfs.hosts 参数指定，该参数位于 hdfs-site.xml。默认值为空。
    dfs.hosts 指向文件，该文件蕴含容许连贯到 namenode 的主机列表 。必须指定文件的残缺路径名。 如果该值为空，则容许所有主机准入。

    2. 黑名单

    所谓的 黑名单指的是禁止哪些机器退出到以后的 HDFS 集群中 ，是一种禁入机制。
    黑名单由 d fs.hosts.exclude 参数指定，该参数位于 hdfs-site.xml。默认值为空。
    dfs.hosts.exclude 指向文件，该文件蕴含不容许连贯到名称节点的主机列表。必须指定文件的残缺路径名。如果该值为空，则不禁止任何主机退出。

退出移动版