Hadoop 磁盘均衡器(2)

HDFS中的数据按照一定策略分布在集群中的多个数据节点上，但在某些情况下，数据的分布也会出现不均衡的情况，比如说集群新增加了节点，在新增加的节点上就没有数据存在，虽说之后新增的数据会分配到新节点上，不过，对于已有数据，新节点和原有节点上的分布很不均衡，而且这还会导致在分配MapReduce任务的时候新机器分配不到可执行的任务，白白浪费了新增节点的计算能力。而对于一个真实的生产环境来说，随着数据量的增加而对集群逐步扩容是一个很常见的场景，为了解决这个问题，Hadoop设计了Rebalance功能。

rebalance的目的是为了使数据在集群中各节点的分布尽量均衡，那么，什么样的情况被认为是不均衡，又需要达到什么样的目标才算是完成了rebalance呢？简单来说，如果集群中没有“过载”或者“负载”的节点，则认为集群中的数据分布是均衡的，否则就是不均衡。所谓的“过载节点”是指存储使用率大于“平均存储使用率+允许偏差”的节点，“负载节点”是指存储使用率小于“平均存储使用率-允许偏差”的节点。这里又出现了几个概念，下面一一解释。什么是一个节点的存储使用率？它表示一个数据节点上已用空间占可用空间的百分比，所谓可用空间指的是分配给HDFS可使用的空间，并非是节点所在机器的全部硬盘空间。比如，一个数据节点，共有存储空间2T，分配给HDFS的空间为1T，已经用了600G，那么使用率就是600/1000=60%。将集群中各节点的存储使用率做个简单平均，就得到集群中节点的平均存储使用率。举例来说，假设有三个节点A,B,C，HDFS容量分别为2T,2T,1T,分别使用了50%，50%，10%，那么平均使用率是(50%+50%+10%)/3=36.7%，而不是(2 50%+2 50%+1*10%)/(2+2+1)=42%。允许偏差，是启动Rebalance功能的时候指定的一个阈值，也是一个百分比，如果没有指定则默认为是10%，表示允许单个节点的存储使用率与集群中各节点平均存储使用率之间有10%的偏差。Rebalance功能通过命令 hadoop balancer [-threshold] 来启动，直到集群中不再存在不均衡节点时自动停止。Rebalance过程可以指定多次，每次可以指定不同的允许偏差值，以此来逐次渐进达到一个合理的数据均衡分布，同时又不至于使得Rebalance过程持续时间过长，影响集群的正常使用。

rebalance 是一个非自动的管理功能，换句话说，它是由人工启动的。在任意一台能够连接到HDFS的机器上命令行下输入 hadoop balancer [-threshold] 既会启动。如果集群处于不平衡状态，这个过程就会在不平衡的节点之间迁移数据，如果rebalance过程没有被打断的话，完成此次rebalance目标后过程会自动停止。仍以上面的例子来说，以允许偏差为10%启动rebalance（命令行下输入hadoop balancer），则Rebalance完成时各节点的存储使用率如下，A=B=45.825%，C=26.7%。如果认为这样数据分布还不够均衡，那么可以再启动一次Rebalance。假设再启动一次Rebalance，仍不指定参数，也即仍以以10%的默认值为允许偏差。Rebalance前集群的平均存储使用率为45.825%×2+26.7%/3=39.45%。将各节点与之对比，可以看出C节点是负载节点（39.75-26.7=13.05 >10）。输入hadoop balancer 等其结束，各节点的存储使用率为A=B=45.1375%，C=29.45%。由这个过程可以看出，rebalance 的目的虽然是平衡数据，但它并不追求毕其功于一役，而是事先设定目标，每一次执行只实现预设目标，也即只是缩小了过载/负载节点与集群平均使用率的差值，而通过反复多次的执行来是集群内的数据逐渐趋于均衡。这样实际上是将rebalance 拆解成了许多小过程，每次小过程的执行时间都不会太长，对于一个应用中的集群来说，大多数时间需要运行业务任务，大多数的带宽也应该用于传输业务数据，这样做使得辅助管理功能对于资源的占用降低了，而且由于每次运行的时间片都不长，完全可以机动灵活的选择在集群的空闲期来rebalance，是一个非常优秀的设计。

上图展示了参与rebalance过程的各个角色之间的交互。绿色的线表示rebalance专用的信息交换协议，数字表示各步骤的执行顺序。rebalance server首先会向name node要求一个datanode 报告（步骤1）。得到报告之后选择了source和destination，再向namenode请求每个source的部分块映射（步骤2）。然后选择要移动的block，对于每一个block，会选择一个也有此block的数据节点作为代理源节点，被选作代理源的节点应该离destination更近，或者负载比source轻。然后命令代理源节点将这个block拷贝到destination节点上，同时示意该block应该从source节点上删除（步骤3）。代理源节点请求destination节点将该block拷贝到本地硬盘并重新放置（步骤4）。destination完成block的copy之后会提醒namenode从source节点上删除该block（步骤5）。namenode会选择该block的一个副本删除并保证删除不会使block丢失，不会使block的副本减少或者使其分布的机架数减少。然后destination会通知代理源节点block的放置已经完成（步骤6）。代理源节点再通知rebalance server *** 作完成（步骤7）。

rebalance server上的执行逻辑如下：

1、在输入启动命令的那台机器上会启动一个进程作为rebalance Server，为了避免给namenode带来过大的负担，整个rebalance过程由rebalance server而不是namenode来控制。

2、rebalance server会向NameNode请求一份数据节点报告，在收到报告之后，使用获得的信息，计算出网络拓扑、集群平均存储使用率，然后把各个数据节点分成过载节点、负载节点、存储使用率高于平均水平的节点和低于平均水平的节点四类，再判断是否有节点处于过载和负载状态（也即过载节点列表和负载节点列表中是否有机器），如果是则继续，否则退出。如果判断可继续，则遍历过载节点列表和负载节点列表以生成Rebalance策略。生成rebalance策略的过程包括以下步骤：a、选择数据移动的源节点和目的节点，选择依据如下 对于负载节点，依据以下条件随机选取选取作为其source，条件优先级自上而下递减

b、计算每一个source到每个destination要移动的数据量（注意以byte为单位而不是block）。

如果source节点是过载节点，则看容积允许偏差值是否大于1GB，大于则取1GB，否则取允许偏差值。如果source只是高于平均使用率而没有达到过载的条件，则看该节点实际容积率与集群平均容积率之差是否大于2GB，大于取2GB，否则取前者。destination节点也如此计算。3、Rebalance Server 向Name Node请求每个source节点的部分块分布报告（partial block report），请求的形式类似，默认size是1GB。所谓部分块报告，是指每次要求和返回的的只是加起来能满足size大小的block的信息，而非全部的block信息。4、namenode随机挑选一些block，使得block的大小加起来等于请求中size的大小（见上一步，默认1GB），然后将被选中的block信息返回给rebalance server。5、rebalance server 在返回的这些block信息中挑选出每个source上需要移动的block，直到选出的block的大小达到了前面提到过的阈值（见本节2.b中“如果source节点是过载节点……”一段）或者所有的block都被检查过了一遍。a、选取待移动block的时候不能破坏block的分布原则，也即不能造成block丢失，不能使一个block的副本数变少，也不能使一个block放置的机架数变少。选取时依据的原则如下

如果source和destination在不同的机架上，则destination所在的机架上不应该有待移动block的副本

destination上不应该有待移动block的副本

不能同时移动一个block的一个以上的个副本

b、每个block的移动任务一旦确定就会被放入一个队列，然后把copy数据的请求发送给souce

c、将队列中的任务按照source、destination和block分组，保证不能存在5个以上的同一source或者destination的任务，还要保证任意时刻一个block只能有一个副本在传输中

d、当接收到source的确认信息后，一个任务才会从队列中移除，如果一个任务在队列中过长时间没有接收到反馈也会移除。6、所有的block被扫描了一遍后，重复步骤3

7、2中所有的移动计划已经完成，并且队列中没有任务之后，重复步骤2datanode上执行的 *** 作如下：

参考资料 https://issues.apache.org/jira/browse/HADOOP-1652https://issues.apache.org/jira/secure/attachment/12368261/RebalanceDesign6.pdfhttps://issues.apache.org/jira/secure/attachment/12369857/BalancerAdminGuide1.pdf

转自

https://mp.weixin.qq.com/s/floNhFEBvcIA63ORRXXtBg

越来越多的企业开始使用Hadoop来对大数据进行处理分析，但Hadoop集群的整体性能却取决于CPU、内存、网络以及存储之间的性能平衡。而在这篇文章中，我们将探讨如何为Hadoop集群构建高性能网络，这是对大数据进行处理分析的关键所在。

关于Hadoop

“大数据”是松散的数据集合，海量数据的不断增长迫使企业需要通过一种新的方式去管理。大数据是结构化或非结构化的多种数据类型的大集合。而 Hadoop则是Apache发布的软件架构，用以分析PB级的非结构化数据，并将其转换成其他应用程序可管理处理的形式。Hadoop使得对大数据处理成为可能，并能够帮助企业可从客户数据之中发掘新的商机。如果能够进行实时处理或者接近实时处理，那么其将为许多行业的用户提供强大的优势。

Hadoop是基于谷歌的MapReduce和分布式文件系统原理而专门设计的，其可在通用的网络和服务器硬件上进行部署，并使之成为计算集群。

Hadoop模型

Hadoop的工作原理是将一个非常大的数据集切割成一个较小的单元，以能够被查询处理。同一个节点的计算资源用于并行查询处理。当任务处理结束后，其处理结果将被汇总并向用户报告，或者通过业务分析应用程序处理以进行进一步分析或仪表盘显示。

为了最大限度地减少处理时间，在此并行架构中，Hadoop“moves jobs to data”，而非像传统模式那样“moving data to jobs”。这就意味着，一旦数据存储在分布式系统之中，在实时搜索、查询或数据挖掘等 *** 作时，如访问本地数据，在数据处理过程中，各节点之间将只有一个本地查询结果，这样可降低运营开支。

Hadoop的最大特点在于其内置的并行处理和线性扩展能力，提供对大型数据集查询并生成结果。在结构上，Hadoop主要有两个部分：

Hadoop分布式文件系统(HDFS)将数据文件切割成数据块，并将其存储在多个节点之内，以提供容错性和高性能。除了大量的多个节点的聚合I/O，性能通常取决于数据块的大小——如128MB。而传统的Linux系统下的较为典型的数据块大小可能是4KB。

MapReduce引擎通过JobTracker节点接受来自客户端的分析工作，采用“分而治之”的方式来将一个较大的任务分解成多个较小的任务，然后分配给各个TaskTrack节点，并采用主站/从站的分布方式(具体如下图所示)：

Hadoop系统有三个主要的功能节点：客户机、主机和从机。客户机将数据文件注入到系统之中，从系统中检索结果，以及通过系统的主机节点提交分析工作等。主机节点有两个基本作用：管理分布式文件系统中各节点以及从机节点的数据存储，以及管理Map/Reduce从机节点的任务跟踪分配和任务处理。数据存储和分析处理的实际性能取决于运行数据节点和任务跟踪器的从机节点性能，而这些从机节点则由各自的主机节点负责沟通和控制。从节点通常有多个数据块，并在作业期间被分配处理多个任务。

部署实施Hadoop

各个节点硬件的主要要求是市县计算、内存、网络以及存储等四个资源的平衡。目前常用的并被誉为“最佳”的解决方案是采用相对较低成本的旧有硬件，部署足够多的服务器以应对任何可能的故障，并部署一个完整机架的系统。

Hadoop模式要求服务器与SAN或者NAS进行直接连接存储(DAS)。采用DAS主要有三个原因，在标准化配置的集群中，节点的缩放数以千计，随着存储系统的成本、低延迟性以及存储容量需求不断提高，简单配置和部署个主要的考虑因素。随着极具成本效益的1TB磁盘的普及，可使大型集群的TB级数据存储在DAS之上。这解决了传统方法利用SAN进行部署极其昂贵的困境，如此多的存储将使得Hadoop和数据存储出现一个令人望而却步的起始成本。有相当大一部分用户的Hadoop部署构建都是采用大容量的DAS服务器，其中数据节点大约1-2TB，名称控制节点大约在1-5TB之间，具体如下图所示：

来源：Brad Hedlund, DELL公司

对于大多数的Hadoop部署来说，基础设施的其他影响因素可能还取决于配件，如服务器内置的千兆以太网卡或千兆以太网交换机。上一代的CPU和内存等硬件的选择，可根据符合成本模型的需求，采用匹配数据传输速率要求的千兆以太网接口来构建低成本的解决方案。采用万兆以太网来部署Hadoop也是相当不错的选择。

万兆以太网对Hadoop集群的作用

千兆以太网的性能是制约Hadoop系统整体性能的一个主要因素。使用较大的数据块大小，例如，如果一个节点发生故障(甚至更糟，整个机架宕机)，那么整个集群就需要对TB级的数据进行恢复，这就有可能会超过千兆以太网所能提供的网络带宽，进而使得整个集群性能下降。在拥有成千上万个节点的大型集群中，当运行某些需要数据节点之间需要进行中间结果再分配的工作负载时，在系统正常运行过程中，某个千兆以太网设备可能会遭遇网络拥堵。

每一个Hadoop数据节点的目标都必须实现CPU、内存、存储和网络资源的平衡。如果四者之中的任意一个性能相对较差的话，那么系统的潜在处理能力都有可能遭遇瓶颈。添加更多的CPU和内存组建，将影响存储和网络的平衡，如何使Hadoop集群节点在处理数据时更有效率，减少结果，并在Hadoop集群内添加更多的HDFS存储节点。

幸运的是，影响CPU和内存发展的摩尔定律，同样也正影响着存储技术(TB级容量的磁盘)和以太网技术(从千兆向万兆甚至更高)的发展。预先升级系统组件(如多核处理器、每节点5-20TB容量的磁盘，64-128GB内存)，万兆以太网卡和交换机等网络组件是重新平衡资源最合理的选择。万兆以太网将在Hadoop集群证明其价值，高水平的网络利用率将带来效益更高的带宽。下图展示了Hadoop集群与万兆以太网的连接：

许多企业级数据中心已经迁移到10GbE网络，以实现服务器整合和服务器虚拟化。随着越来越多企业开始部署Hadoop，他们发现他们完全不必要大批量部署1U的机架服务器，而是部署更少，但性能更高的服务器，以方便扩展每个数据节点所能运行的任务数量。很多企业选择部署2U或4U的服务器(如戴尔 PowerEdge C2100)，每个节点大约12-16个核心以及24TB存储容量。在这种环境下的合理选择是充分利用已经部署的10GbE设备和Hadoop集群中的 10GbE网卡。

在日常的IT环境中构建一个简单的Hadoop集群。可以肯定的是，尽管有很多细节需要微调，但其基础是非常简单的。构建一个计算、存储和网络资源平衡的系统，对项目的成功至关重要。对于拥有密集节点的Hadoop集群而言，万兆以太网能够为计算和存储资源扩展提供与之相匹配的能力，且不会导致系统整体性能下降。

下图简单看一下hadoop的发展史

思想: 通过引用数据校验块,使其和原始数据校验块编码产生关联关系,然后听过关联关系恢复,这个技术依赖于线性代数一些姿势.

用处: 用于数据的恢复,可以提高磁盘的利用率

缺点: 时间换空间产物,因为编码解码会浪费时间

纠删码技术原理解释:

假设

x1=1

x2=2

x3=3

x1+2 x2+4 x3=17

x1+2 x2+3 x3=14

根据上面一组方程求x1,x2,x3的值,其实虽然有5个方程,其实最少只需要有三个方程就能求出来另外两个方程

把上面这个原理对应到数据里面就是

x1,x2,x3就相当于是原始数据,

x1+2 x2+4 x3=17

x1+2 x2+3 x3=14

这两个方程结果为校验值,

就是假如只有x1这个数据块,但是有下面连个方程,是不是就可以求出对应的x2,和x3了,

如果一个数据是被是3个原始的数据块:

备份机制中:采用2复本机制,至少需要6个数据块才能够保证数据的可靠性,即每个各备份一个即可,

如果是数据块的这种,最少需要4个,他可以容许你的一个数据块的丢失,比如把1丢了,剩下的2和3剩下,通过一个方程就能求出来1的内容,就可以允许一个数据块丢失

之前数据丢失了,直接从别的服务器位置拷贝一个过来就行,hadoop3用纠删码就需要号计算,还需要拿到另外块的数据和计算公式,因为他是要计算的,比如1,2,3三块数据块,比如采用纠删码存储技术,就可以把1号数据丢失,但是某天需要用到1号,数据,就需要从新计算恢复,所以这个就需要耗费时间.

但是我觉得吧,比如hadoop以后可以在这个基础上优化一下

比如说三台服务器,一个文件被切割成了1,2,3三份,具体存储如下

上面三个为纠删码存储方式

下面三个为正常存储方式

hadoop正在往这个方向优化

即先从其他服务器找这个数据块,找不到再用纠删码计算

所以纠删码用于存储冷数据,冷数据指的是平时很少用到的数据

这个用法创建一个eraszing zone(空间),然后放在这个空间的数据,创建目录,把需要纠删码技术存储的把这个文件放到这个路径即可

比如之前的数据时热门的,但是之前并不是存储在这个eraszing zone里面,但是现在就是冷数据,食之无味,弃之可惜,鸡肋也,所以就可以在这个数据拷贝到这个eraszing zone里面,然后把那旧数据原位置删除就行,hadoop也在做一种简单的办法,通过一个命令,修改这个冷数据的存储方式,hadoop正在做,

所以3.0的冷数据还是建议使用这种备份机制,冷门数据是用纠删码(时间换空间)

namenode的HA升级了,支持两个以上的namemode,

例如，通过配置三个NameNode和五个JournalNode，群集能够容忍两个节点的故障，而不是一个故障。

但是Active的NameNode始终只有1个，余下的都是Standby。 Standby NN会不断与JN同步，保证自己获取最新的editlog，并将edits同步到自己维护的image中去，这样便可以实现热备，在发生failover的时候，立马切换成active状态，对外提供服务。同时，JN只允许一个active状态的NN写入

以前是支持亚马逊的,现在3.0支持了更多的,尤其是阿里云,说明阿里云正在走向壮大

增加DataNode的 内部 负载均衡,之前是DataNode之间的负载均衡,现在是DataNode内部的负载均衡,比如DataNode这台机器有三块磁盘,然后发现只有一块磁盘写满了,另外两块磁盘都没怎么用,这时候输入一个命令,他就可以帮你重新分配一下

现在可以通过hdfs diskbalancer命令，进行节点内部硬盘间的数据平衡。该功能默认是关闭的，需要手动设置参数dfs.disk.balancer.enabled为true来开启。

yarn timeline service做了升级,yarn timeline service是yarn是资源管理和任务调度,这timeline service就是监控这个任务的,什么时候启动的,用到了哪些资源,可以用时间序列这个结构来存储这个结构,hadoop的2.5之前,通过jobhistory server来提供任务监控信息的收集,但是他有缺点,底层扩展性和可靠性不高,因为做这个数据量也挺大的,所以在3.0作了相应的修改.

支持opportunistic(机会主义的) containers(容器)和distributed(分布式) scheduling(调度)

在hadoop上面的跑的任务,对资源都是争抢的状态,但是有时候需要协调人物的优先级,在hadoop3.0跑的时候,比如MapReduce任务,hive任务过来,对底层资源都是争抢状态,所以就需要协调人物的优先级,hadoop3.0的yarn就是比较灵活,比如任务在跑的时候,指定了优先级也好,指定了比如2核,8G的固定资源也好,有时候某个时间点根本用不到这么多资源,那个时间段可能只用了一半,释放了一半,这个opportunistic(机会主义的) containers(容器)就可以让不这么重要的任务临时用一下这个临时的资源

yarn配置资源可以配置的更加细化,比如原先是只支持线级别,现在支持点级别

比如这个hive依赖hadoopclient,但是还依赖某一个jar包的1.0版本,但是呢,这个hadoopclient依赖这个jar包的2.0版本,然后这两个jar包放到一起,肯定报错,因为名字一样,版本不一样,使用就会紊乱

优化,将这个hadoop client的jar包放到另外一个空间,隔离起来,这样就不会乱了

以上内容纯手敲,如有疑问或者错误请留言或者私信

以上内容纯手敲,如有疑问或者错误请留言或者私信

以上内容纯手敲,如有疑问或者错误请留言或者私信

---