HDFS——数据平衡策略

Hadoop的HDFS集群非常容易出现机器与机器之间磁盘利用率不平衡的情况,比如集群中添加新的数据节点。当HDFS出现不平衡状况的时候,将引发很多问题,比如MR程序无法很好地利用本地计算的优势,机器之间无法达到更好的网络带宽使用率,机器磁盘无法利用等等。可见,保证HDFS中的数据平衡是非常重要的。

在Hadoop中,包含一个Balancer程序,通过运行这个程序,可以使得HDFS集群达到一个平衡的状态,使用这个程序的命令如下:

sh $HADOOP_HOME/bin/start-balancer.sh –t 10%

这个命令中-t参数后面跟的是HDFS达到平衡状态的磁盘使用率偏差值。如果机器与机器之间磁盘使用率偏差小于10%,那么我们就认为HDFS集群已经达到了平衡的状态。

   一 编程原则

Hadoop的开发人员在开发Balancer程序的时候,遵循了以下几点原则:

1.    在执行数据重分布的过程中,必须保证数据不能出现丢失,不能改变数据的备份数,不能改变每一个rack中所具备的block数量。

2.    系统管理员可以通过一条命令启动数据重分布程序或者停止数据重分布程序。

3.    Block在移动的过程中,不能暂用过多的资源,如网络带宽。

4.    数据重分布程序在执行的过程中,不能影响name node的正常工作。

  二 Balance逻辑

基于这些基本点,目前Hadoop数据重分布程序实现的逻辑流程如下图所示:

Rebalance程序作为一个独立的进程与name node进行分开执行。

1 Rebalance Server从Name Node中获取所有的Data Node情况:每一个Data Node磁盘使用情况。

2 Rebalance Server计算哪些机器需要将数据移动,哪些机器可以接受移动的数据。并且从Name Node中获取需要移动的数据分布情况。

3 Rebalance Server计算出来可以将哪一台机器的block移动到另一台机器中去。

4,5,6 需要移动block的机器将数据移动的目的机器上去,同时删除自己机器上的block数据。

7  Rebalance Server获取到本次数据移动的执行结果,并继续执行这个过程,一直没有数据可以移动或者HDFS集群以及达到了平衡的标准为止。

Hadoop现有的这种Balancer程序工作的方式在绝大多数情况中都是非常适合的。

  三 数据平衡case

现在我们设想这样一种情况:

1 数据是3份备份。

2 HDFS由2个rack组成。

3 2个rack中的机器磁盘配置不同,第一个rack中每一台机器的磁盘空间为1TB,第二个rack中每一台机器的磁盘空间为10TB。

4 现在大多数数据的2份备份都存储在第一个rack中。

在这样的一种情况下,HDFS级群中的数据肯定是不平衡的。现在我们运行Balancer程序,但是会发现运行结束以后,整个HDFS集群中的数据依旧不平衡:rack1中的磁盘剩余空间远远小于rack2。这是因为Balance程序的开发原则1导致的。

简单的说,就是在执行Balancer程序的时候,不会将数据中一个rack移动到另一个rack中,所以就导致了Balancer程序永远无法平衡HDFS集群的情况。

针对于这种情况,可以采取2中方案:

1 继续使用现有的Balancer程序,但是修改rack中的机器分布。将磁盘空间小的机器分叉到不同的rack中去。

2 修改Balancer程序,允许改变每一个rack中所具备的block数量,将磁盘空间告急的rack中存放的block数量减少,或者将其移动到其他磁盘空间富余的rack中去。

转自:http://www.cnblogs.com/gpcuster/tag/Hadoop/

时间: 2024-08-05 05:21:37

HDFS——数据平衡策略的相关文章

HDFS副本放置策略

前言 前一篇文章中刚刚分析完HDFS的异构存储以及相关的存储类型选择策略,浏览量还是不少的,说明大家对于HDFS的异构存储方面的功能还是很感兴趣的.但是其实一个文件Block块从最初的产生到最后的落盘,存储类型选择策略只是其中1步,因为存储类型选择策略只是帮你先筛选了一些符合存储类型要求的存储节点目录位置列表,通过这些候选列表,你还需要做进一步的筛选,这就是本文所准备阐述的另外一个主题,HDFS的副本放置策略.在写本文之前,我搜过网上关于此方面的资料与文章,还是有许多文章写的非常不错的,所以我会

hbase数据存取策略

复制策略是hadoop文件系统最核心的部分,对读写性能影响很大,hadoop和其它分布式文件系统的最大区别就是可以调整冗余数据的位置,这个特性需要很多时间去优化和调整. 一.数据存放 目前hadoop采用以机柜为基础的数据存放策略,这样做的目的是提高数据可靠性和充分利用网络带宽.当前具体实现了的策略只是这个方向的尝试,hadoop短期的研究目标之一就是在实际产品环境中观察系统读写的行为,测试性能和研究更深入的规则. 一个大的hadoop集群经常横跨多个机柜,而不同机柜之间的数据通讯同经过交换机或

HDFS的存储策略

我们在安装HDFS的时候,我们在hdfs-site.xml配置过DataNode的数据存储的文件目录,如下: <property> <name>dfs.datanode.data.dir</name> <value>/home/hadoop-twq/bigdata/dfs/data</value> <description>DataNode存放数据的地方</description> </property> 目录

数据保存策略(Retention Policies)

数据保存策略(Retention Policies) InfluxDB没有提供直接删除Points的方法,但是它提供了Retention Policies.主要用于指定数据的保留时间:当数据超过了指定的时间之后,就会被删除. 查看当前数据库的Retention Policies SHOW RETENTION POLICIES ON "testDB" 创建新的Retention Policies CREATE RETENTION POLICY "rp_name" ON

ceph学习笔记之七 数据平衡

数据平衡 当在集群中新增一个OSD设备时,整个集群将会发生数据迁移使数据重新分布达到均衡.在Ceph集群中数据迁移的的基本单位是PG.其实在迁移过程中是将PG中的所有对象作为一个整体来进行迁移. 数据迁移触发流程: 1.当新加入一个OSD时,会改变系统的CRUSH Map,从而引起对象映射过程中的变化: 2.PG到OSD的映射关系发生了变化,从而引发数据的迁移. 当ceph集群中出现组件故障时(通常是指OSD,当然也有可能是网络),ceph会将OSD标记为Down,如果在300秒内MON没有收到

基于Java LinkedList,实现Android大数据缓存策略

import java.util.HashMap; import java.util.LinkedList; /* * 基于Java LinkedList,实现Android大数据缓存策略 * 作者:Zhang Phil * 原文出处:http://blog.csdn.net/zhangphil * * 实现原理:原理的模型认为:在LinkedList的头部元素是最旧的缓存数据,在LinkedList的尾部是最新的缓存数据. * 在一个LinkedList(类型C的链表)维护一个存储堆栈,添加元

InfluxDB学习之InfluxDB数据保留策略(Retention Policies)

InfluxDB每秒可以处理成千上万条数据,要将这些数据全部保存下来会占用大量的存储空间,有时我们可能并不需要将所有历史数据进行存储,因此,InfluxDB推出了数据保留策略(Retention Policies),用来让我们自定义数据的保留时间.更多InfluxDB详细教程请看:InfluxDB系列学习教程目录 InfluxDB技术交流群:580487672(点击加入) 一.InfluxDB 数据保留策略 说明 InfluxDB的数据保留策略(RP) 用来定义数据在InfluxDB中存放的时间

HDFS数据迁移解决方案之DistCp工具的巧妙使用

前言 在当今每日信息量巨大的社会中,源源不断的数据需要被安全的存储.等到数据的规模越来越大的时候,也许瓶颈就来了,没有存储空间了.这时候怎么办,你也许会说,加机器解决,显然这是一个很简单直接但是又显得有些欠缺思考的办法.无谓的加机器只会带来无限上升的成本消耗,更好的办法应该是做到更加精细化的数据存储与管理,比如说非常典型的冷热数据的存储.对于巨大的长期无用的冷数据而言,应该用性能偏弱,但是磁盘空间富余的机器存,热数据则反之.数据的分类存储一定会带来数据的同步问题,假若我有2套集群,1个是线上的正

redis 提供 6种数据淘汰策略

淘汰策略的原因 在 redis 中,允许用户设置最大使用内存大小 server.maxmemory,在内存限定的情况下是很有用的.譬如,在一台 8G 机子上部署了 4 个 redis 服务点,每一个服务点分配 1.5G 的内存大小,减少内存紧张的情况,由此获取更为稳健的服务. 6中淘汰策略 redis 内存数据集大小上升到一定大小的时候,就会施行数据淘汰策略.redis 提供 6种数据淘汰策略: volatile-lru:从设置了过期时间的数据集中,选择最近最久未使用的数据释放: allkeys