绝对完美解决hdfs datanode数据和磁盘数据分布不均调整(hdfs balancer )——经验总结

本文主要是介绍绝对完美解决hdfs datanode数据和磁盘数据分布不均调整(hdfs balancer )——经验总结,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

Hadoop集群Datanode数据倾斜,个别节点hdfs空间使用率达到95%以上,于是新增加了三个Datenode节点,由于任务还在跑,数据在不断增加中,这几个节点现有的200GB空间估计最多能撑20小时左右,所以必须要进行balance操作。

通过观察磁盘使用情况,发现balance的速度明显跟不上新增数据的速度!!!

跟踪了一下balance的日志,发现两个问题:
一是balance时原有的十几个节点都被列入了待balance的节点中,上面的数据分块移动到新增加的3个节点上,由于节点多,最迫切需要balance的几个节点轮到的机会很少;
二是balance的速度太慢了,Hadoop集群为了防止balance影响吞吐、I/O性能,默认balance的速度为1MB,这样一共8TB的数据需要balance,这需要太长时间了。

于是针对上述问题,进行了如下尝试:

  • 提高blance的速度,将默认的balance速度从1MB/s增大到50MB/s
#set balance to 50M/s
[hdfs@sudops.com hadoop]$ hdfs dfsadmin -setBalancerBandwidth 52428800
Balancer bandwidth is set to 52428800 for nn01.sudops.com/10.233.100.161:9000
Balancer bandwidth is set to 52428800 for nn02.sudops.com/10.233.100.162:9000
  • 调整balance的平衡比例:

将原来的%5 提高到20%,调整原则就是尽量先让balance影响到最需要平衡数据的节点。

简单说明一下:原有集群的hdfs占用率为80%,新增加3个节点后,集群hdfs的整体占用量为70%, 如果比例是%5的话,那么原有节点都在这个调整范围内,所以各个节点都要被balance,而接受balance的节点只有三个,所以轮到迫切需要balance的节点的概率就比较小;
如果调整到20%,那么原来使用量小于90%的节点都不会被balance,那几台占用量90%以上的节点才会被最先balance,这样只有3个节点符合这个条件,balance的精确性就高了很多。

综合以上两点,balance的效果好多了,解决了最紧迫的节点的磁盘占满的问题,balance的速度终于快于新增数据,20%时需要balance的数据为6TB左右,待这次balance结束后,再运行一次%5的balance,还有2TB的数据要balance,这样经过两次的balance的操作,集群基本平衡了。


hdfs dfsadmin -setBalancerBandwidth 52428800nohup hdfs balancer -threshold 20 &tail -F nohup.out

一、概述

hdfs 需要存写大量文件,有时磁盘会成为整个集群的性能瓶颈,所以需要优化 hdfs 存取速度,将数据目录配置多磁盘,既可以提高并发存取的速度,还可以解决一块磁盘空间不够的问题

Hadoop 环境部署可以参考我之前的文章:大数据Hadoop之——Hadoop 3.3.4 HA(高可用)原理与实现(QJM)

二、Hadoop DataNode多目录磁盘配置

1)配置hdfs-site.xml

在配置文件中$HADOOP_HOME/etc/hadoop/hdfs-site.xml添加如下配置:

<!-- dfs.namenode.name.dir是保存FsImage镜像的目录,作用是存放hadoop的名称节点namenode里的metadata-->
<property><name>dfs.namenode.name.dir</name><value>file:/opt/bigdata/hadoop/hadoop-3.3.4/data/namenode</value>
</property>
<!-- 存放HDFS文件系统数据文件的目录(存储Block),作用是存放hadoop的数据节点datanode里的多个数据块。 -->
<property><name>dfs.datanode.data.dir</name><value>/data1,/data2,/data3,/data4</value>
</property><!-- 设置数据存储策略,默认为轮询,现在的情况显然应该用“选择空间多的磁盘存”模式 -->
<property><name>dfs.datanode.fsdataset.volume.choosing.policy</name><value>org.apache.hadoop.hdfs.server.datanode.fsdataset.AvailableSpaceVolumeChoosingPolicy</value>
</property><!-- 默认值0.75。它的含义是数据块存储到可用空间多的卷上的概率,由此可见,这个值如果取0.5以下,对该策略而言是毫无意义的,一般就采用默认值。-->
<property><name>dfs.datanode.available-space-volume-choosing-policy.balanced-space-preference-fraction</name><value>0.75f</value>
</property><!-- 配置各个磁盘的均衡阈值的,默认为10G(10737418240),在此节点的所有数据存储的目录中,找一个占用最大的,找一个占用最小的,如果在两者之差在10G的范围内,那么块分配的方式是轮询。 -->
<property><name>dfs.datanode.available-space-volume-choosing-policy.balanced-space-threshold</name>         <value>10737418240</value>
</property>

【温馨提示】此处的dfs.namenode.name.dirdfs.datanode.data.dir位置需要不一样,不能是一个文件夹,之前设置成一个文件夹报错ERROR org.apache.hadoop.hdfs.server.common.Storage: It appears that another node 1003@iZ2zeh8q22e14pvqr3bu01Z has already locked the storage directory:
【原因】是当namenode启动后,锁定了文件夹,导致datanode无法启动。

2)配置详解

1、 dfs.datanode.data.dir

HDFS数据应该存储Block的地方。可以是逗号分隔的目录列表(典型的,每个目录在不同的磁盘)。这些目录被轮流使用,一个块存储在这个目录,下一个块存储在下一个目录,依次循环。每个块在同一个机器上仅存储一份。不存在的目录被忽略。必须创建文件夹,否则被视为不存在。

2、dfs.datanode.fsdataset.volume.cho

这篇关于绝对完美解决hdfs datanode数据和磁盘数据分布不均调整(hdfs balancer )——经验总结的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/681935

相关文章

大模型研发全揭秘:客服工单数据标注的完整攻略

在人工智能(AI)领域,数据标注是模型训练过程中至关重要的一步。无论你是新手还是有经验的从业者,掌握数据标注的技术细节和常见问题的解决方案都能为你的AI项目增添不少价值。在电信运营商的客服系统中,工单数据是客户问题和解决方案的重要记录。通过对这些工单数据进行有效标注,不仅能够帮助提升客服自动化系统的智能化水平,还能优化客户服务流程,提高客户满意度。本文将详细介绍如何在电信运营商客服工单的背景下进行

基于MySQL Binlog的Elasticsearch数据同步实践

一、为什么要做 随着马蜂窝的逐渐发展,我们的业务数据越来越多,单纯使用 MySQL 已经不能满足我们的数据查询需求,例如对于商品、订单等数据的多维度检索。 使用 Elasticsearch 存储业务数据可以很好的解决我们业务中的搜索需求。而数据进行异构存储后,随之而来的就是数据同步的问题。 二、现有方法及问题 对于数据同步,我们目前的解决方案是建立数据中间表。把需要检索的业务数据,统一放到一张M

关于数据埋点,你需要了解这些基本知识

产品汪每天都在和数据打交道,你知道数据来自哪里吗? 移动app端内的用户行为数据大多来自埋点,了解一些埋点知识,能和数据分析师、技术侃大山,参与到前期的数据采集,更重要是让最终的埋点数据能为我所用,否则可怜巴巴等上几个月是常有的事。   埋点类型 根据埋点方式,可以区分为: 手动埋点半自动埋点全自动埋点 秉承“任何事物都有两面性”的道理:自动程度高的,能解决通用统计,便于统一化管理,但个性化定

使用SecondaryNameNode恢复NameNode的数据

1)需求: NameNode进程挂了并且存储的数据也丢失了,如何恢复NameNode 此种方式恢复的数据可能存在小部分数据的丢失。 2)故障模拟 (1)kill -9 NameNode进程 [lytfly@hadoop102 current]$ kill -9 19886 (2)删除NameNode存储的数据(/opt/module/hadoop-3.1.4/data/tmp/dfs/na

异构存储(冷热数据分离)

异构存储主要解决不同的数据,存储在不同类型的硬盘中,达到最佳性能的问题。 异构存储Shell操作 (1)查看当前有哪些存储策略可以用 [lytfly@hadoop102 hadoop-3.1.4]$ hdfs storagepolicies -listPolicies (2)为指定路径(数据存储目录)设置指定的存储策略 hdfs storagepolicies -setStoragePo

HDFS—存储优化(纠删码)

纠删码原理 HDFS 默认情况下,一个文件有3个副本,这样提高了数据的可靠性,但也带来了2倍的冗余开销。 Hadoop3.x 引入了纠删码,采用计算的方式,可以节省约50%左右的存储空间。 此种方式节约了空间,但是会增加 cpu 的计算。 纠删码策略是给具体一个路径设置。所有往此路径下存储的文件,都会执行此策略。 默认只开启对 RS-6-3-1024k

HDFS—集群扩容及缩容

白名单:表示在白名单的主机IP地址可以,用来存储数据。 配置白名单步骤如下: 1)在NameNode节点的/opt/module/hadoop-3.1.4/etc/hadoop目录下分别创建whitelist 和blacklist文件 (1)创建白名单 [lytfly@hadoop102 hadoop]$ vim whitelist 在whitelist中添加如下主机名称,假如集群正常工作的节

Hadoop集群数据均衡之磁盘间数据均衡

生产环境,由于硬盘空间不足,往往需要增加一块硬盘。刚加载的硬盘没有数据时,可以执行磁盘数据均衡命令。(Hadoop3.x新特性) plan后面带的节点的名字必须是已经存在的,并且是需要均衡的节点。 如果节点不存在,会报如下错误: 如果节点只有一个硬盘的话,不会创建均衡计划: (1)生成均衡计划 hdfs diskbalancer -plan hadoop102 (2)执行均衡计划 hd

【Prometheus】PromQL向量匹配实现不同标签的向量数据进行运算

✨✨ 欢迎大家来到景天科技苑✨✨ 🎈🎈 养成好习惯,先赞后看哦~🎈🎈 🏆 作者简介:景天科技苑 🏆《头衔》:大厂架构师,华为云开发者社区专家博主,阿里云开发者社区专家博主,CSDN全栈领域优质创作者,掘金优秀博主,51CTO博客专家等。 🏆《博客》:Python全栈,前后端开发,小程序开发,人工智能,js逆向,App逆向,网络系统安全,数据分析,Django,fastapi

如何解决线上平台抽佣高 线下门店客流少的痛点!

目前,许多传统零售店铺正遭遇客源下降的难题。尽管广告推广能带来一定的客流,但其费用昂贵。鉴于此,众多零售商纷纷选择加入像美团、饿了么和抖音这样的大型在线平台,但这些平台的高佣金率导致了利润的大幅缩水。在这样的市场环境下,商家之间的合作网络逐渐成为一种有效的解决方案,通过资源和客户基础的共享,实现共同的利益增长。 以最近在上海兴起的一个跨行业合作平台为例,该平台融合了环保消费积分系统,在短