Hadoop集群性能优化一

挺喜欢这句话：“坚持，是基于你对某件事的热爱，才能有动力坚持下去。
在学习的过程中，需要战胜自己的惰性和骄傲！”好了，下面说下如何提升
集群的性能：

在硬件方面，第一，商业硬件并不等同于低端硬件。低端机器常常使用
便宜的零部件，其故障率远高于更昂贵的机器。当用户管理几十台、上百台
甚至几千台机器时，便宜的零部件故障率更高，导致维护成本更高；第二，
不推荐使用大型数据库级别的机器，因为性价比太低了。

在相同硬件的情况下，一个配置好的的集群要比配置糟糕的集群在性能上
快数倍乃至数十倍。

首先说下对于map/reduce槽位的配置还有job对java虚拟机的配置，一般
情况下，如果NN为8核的服务器，map的数量应该配置为6，reduce的数量为2，
也就是说，NN的槽位总数相加和等于CPU的数量，同时map槽位数大概是reduce
槽位数的三倍；因为我们需要DN的计算能力强一些，因此，在服务器相同配置
的条件下，可以把map/reduce的槽位总和设置为CPU数量的2倍，同时map数是
reduce数量的3倍。

Hadoop性能优化：Hadoop机架感知实现及配置：分布式的集群通常包含非常多的机器，由于受到机架槽位和交换机网口的限制，通常大型的分布式集群都会跨好几个机架，由多个机架上的机器共同组成一个分布式集群。机架内的机器之间的网络速度通常都会高于跨机架机器之间的网络速度，并且机架之间机器的网络通信通常受到上层交换机间网络带宽的限制。

具体到Hadoop集群，由于Hadoop的HDFS对数据文件的分布式存放是按照分块block存储，每个block会有多个副本(默认为3)，并且为了数据的安全和高效，所以Hadoop默认对3个副本的存放策略为：

1.在本地机器的hdfs目录下存储一个block ；

2.在另外一个rack的某个datanode上存储一个block ；

3.在该机器的同一个rack下的某台机器上存储最后一个block ；

这样的策略可以保证对该block所属文件的访问能够优先在本rack下找到，如果整个rack发生了异常，也可以在另外的rack上找到该block的副本。这样足够的高效，并且同时做到了数据的容错。但是，Hadoop对机架的感知并非是自适应的，亦即，Hadoop集群分辨某台slave机器是属于哪个rack并非是只能的感知的，而是需要Hadoop的管理者人为的告知Hadoop哪台机器属于哪个rack，这样在Hadoop的namenode启动初始化时，会将这些机器与rack的对应信息保存在内存中，用来作为对接下来所有的HDFS的写块操作分配datanode列表时（比如3个block对应三台datanode）的选择datanode策略，做到Hadoop allocate block的策略：尽量将三个副本分布到不同的rack。接下来的问题就是：通过什么方式能够告知Hadoop namenode哪些slaves机器属于哪个rack？以下是配置步骤。

默认情况下，Hadoop的机架感知是没有被启用的。所以，在通常情况下，Hadoop集群的HDFS在选机器的时候，是随机选择的，也就是说，很有可能在写数据时，Hadoop将第一块数据block1写到了rack1上，然后随机的选择下将block2写入到了rack2下，此时两个rack之间产生了数据传输的流量，再接下来，在随机的情况下，又将block3重新又写回了rack1，此时，两个rack之间又产生了一次数据流量。在job处理的数据量非常的大，或者往Hadoop推送的数据量非常大的时候，这种情况会造成rack之间的网络流量成倍的上升，成为性能的瓶颈，进而影响作业的性能以至于整个集群的服务。要将Hadoop机架感知的功能启用，配置非常简单，在namenode所在机器的Hadoop-site.xml配置文件中配置一个选项：topology.script.file.name。这个配置选项的value指定为一个可执行程序，通常为一个脚本，该脚本接受一个参数，输出一个值。接受的参数通常为某台datanode机器的ip地址，而输出的值通常为该ip地址对应的datanode所在的rack，例如”/rack1”。Namenode启动时，会判断该配置选项是否为空，如果非空，则表示已经用机架感知的配置，此时namenode会根据配置寻找该脚本，并在接收到每一个datanode的heartbeat时，将该datanode的ip地址作为参数传给该脚本运行，并将得到的输出作为该datanode所属的机架，保存到内存的一个map中。至于脚本的编写，就需要将真实的网络拓朴和机架信息了解清楚后，通过该脚本能够将机器的ip地址正确的映射到相应的机架上去。一个简单的实现如下：
#!/usr/bin/perl -w
use strict;
my $ip = $ARGV[0];
my $rack_num = 3;
my @ip_items = split /\./, $ip;
my $ip_count = 0;
foreach my $i (@ip_items) {
$ip_count += $i;
}
my $rack = "/rack".($ip_count % $rack_num);
print "$rack";

写入数据

当没有配置机架信息时，所有的机器Hadoop都默认在同一个默认的机架下，名为 “/default-rack”，这种情况下，任何一台datanode机器，不管物理上是否属于同一个机架，都会被认为是在同一个机架下，此时，就很容易出现之前提到的增添机架间网络负载的情况。例如，对没有机架信息的Hadoop HDFS启动instance上传一个文件，其block信息如下：

在没有机架信息的情况下，namenode默认将所有的slaves机器全部默认为在/default-rack下，根据Hadoop代码的分析也能知道哦啊，此时在写block时，三个datanode机器的选择完全是随机的。而当配置了机架感知信息以后，Hadoop在选择三个datanode时，就会进行相应的判断：

1.如果上传本机不是一个datanode，而是一个客户端，那么就从所有slave机器中随机选择一台datanode作为第一个块的写入机器(datanode1)。而此时如果上传机器本身就是一个datanode（例如mapreduce作业中task通过DFSClient向hdfs写入数据的时候），那么就将该datanode本身作为第一个块写入机器(datanode1)。

2.随后在datanode1所属的机架以外的另外的机架上，随机的选择一台，作为第二个block的写入datanode机器(datanode2)。

3.在写第三个block前，先判断是否前两个datanode是否是在同一个机架上，如果是在同一个机架，那么就尝试在另外一个机架上选择第三个datanode作为写入机器(datanode3)。而如果datanode1和datanode2没有在同一个机架上，则在datanode2所在的机架上选择一台datanode作为datanode3。

4.得到3个datanode的列表以后，从namenode返回该列表到DFSClient之前，会在namenode端首先根据该写入客户端跟datanode列表中每个datanode之间的“距离”由近到远进行一个排序。如果此时DFS写入端不是datanode，则选择datanode列表中的第一个排在第一位。客户端根据这个顺序有近到远的进行数据块的写入。在此，判断两个datanode之间“距离”的算法就比较关键，Hadoop目前实现如下，以两个表示datanode的对象DatanodeInfo(node1,node2)为例:

a)首先根据node1和node2对象分别得出两个datanode在整个hdfs集群中所处的层次。这里的层次概念需要解释一下：每个datanode在hdfs集群中所处的层次结构字符串是这样描述的，假设hdfs的拓扑结构如下：每个datanode都会对应自己在集群中的位置和层次，如node1的位置信息为“/rack1/datanode1”,那么它所处的层次就为2，其余类推。

b)得到两个node的层次后，会沿着每个node所处的拓朴树中的位置向上查找，如“/rack1/datanode1”的上一级就是“/rack1”，此时两个节点之间的距离加1，两个node分别同上向上查找，直到找到共同的祖先节点位置，此时所得的距离数就用来代表两个节点之间的距离。所以，如上图所示，node1和node2之间的距离就为4.

5.当根据“距离”排好序的datanode节点列表返回给DFSClient以后，DFSClient便会创建Block OutputStream，并想这次block写入pipeline中的第一个节点（最近的节点）开始写入block数据。

6.写完第一个block以后，依次按照datanode列表中的次远的node进行写入，直到最后一个block写入成功，DFSClient返回成功，该block写入操作结束。

通过以上策略，namenode在选择数据块的写入datanode列表时，就充分考虑到了将block副本分散在不同机架下，并同时尽量的避免了之前描述的网络多于开销。对配置了机架信息的Hadoop HDFS启动instance上传一个文件，其block信息如下：在配置了机架信息的情况下，为了减少机架间的网络流量，namenode会将其中两个副本写在同一个机架上，并且为了尽量做到容错，会将第三个block写道另一个机架上的datanode上

Hadoop集群性能优化一相关推荐

SSD对HADOOP集群性能提升调研及测试计划
摘要本文主要调研SSD对于HADOOP集群性能的影响,并制定相应的测试计划,性能影响主要针对常见的HADOOP,HBASE,HIVE三个组件. 通过调研发现,组件自身也在考虑SSD对其产生的性能影响 ...
[ hadoop ] 集群性能调优全面总结
[ hadoop ] 集群性能调优全面总结_bone_ds的博客-CSDN博客_hadoop集群优化引子文章涵盖了hadoop框架的三个组成架构各自的优化方法,涉及存储,计算,故障排除等多个方面的 ...
FreeBSD下安装配置Hadoop集群(性能调优)
hadoop的性能调优是个比较艰难的事情,由于这个系统的整个环境比较复杂,对于接触时间不长的人来说,配置都很难,更别说找出性能优化的点了. 性能优化涉及的方面很广,操作系统,网络配置,配置文件,调度器 ...
软件架构自学笔记----分享“去哪儿 Hadoop 集群 Federation 数据拷贝优化”
去哪儿 Hadoop 集群 Federation 数据拷贝优化背景去哪儿 Hadoop 集群随着去哪儿网的发展一直在优化改进,基本保证了业务数据存储量和计算量爆发式增长下的存储服务质量.然而,随着 ...
唯品会 1000+ 台 Hadoop 集群优化经验
性能挑战 01 HDFS 是一个分布式系统,只要有足够的资源,可以扩容上千个节点支持100PB以上的集群.我们发现Hadoop集群升级(2.5.0-cdh5.3.2-->2.6.0-cdh5.1 ...
Hadoop集群环境下网络架构的设计与优化
2019独角兽企业重金招聘Python工程师标准>>> 大数据时代,研究大数据的IT 厂商把研究重心放在优化大数据系统软件架构.优化业务逻辑.优化数据分析算法.优化节点性能等方向,而 ...
HADOOP集群优化——CPU、内存、磁盘IO、YARN监控
目录 hadoop集群优化指标---CPU.内存.磁盘IO.YARN监控 Linux性能监测:CPU篇 Linux性能监测:内存篇 Linux性能监测:磁盘IO篇 Linux性能监测:YARN篇写在 ...
快手超大规模集群调度优化实践
导读:随着公司业务的快速发展,离线计算集群规模和提交的作业量持续增长,如何支撑超大规模集群,如何满足不同场景的调度需求成为必须要解决的问题.基于以上问题,快手大数据团队基于YARN做了大量的定制和优化 ...
Hadoop集群系列（目录）
目录安排: 1)Hadoop集群_第1期_CentOS安装配置_V1.0 2)Hadoop集群_第2期_机器信息分布表_V1.1 3)Hadoop集群_第3期_VSFTP安装配置_V1.0 4)Had ...

Hadoop集群性能优化一

Hadoop集群性能优化一相关推荐

最新文章

热门文章