【原创】Hadoop机架感知对性能调优的理解

　　Hadoop作为大数据处理的典型平台，在海量数据处理过程中，其主要限制因素是节点之间的数据传输速率。因为集群的带宽有限，而有限的带宽资源却承担着大量的刚性带宽需求，例如Shuffle阶段的数据传输不可避免，所以如何优化带宽资源的占用是一个值得思考的问题。仔细思考下，Hadoop数据传输的需求主要表现在几个方面：

  1. Map阶段的数据传输：Map阶段的非本地化任务需要远程拷贝数据块，然而这种带宽消耗在一定程度上不是必要的，如果数据能做到很高程度的本地化可以减少这个阶段的数据传输带来的带宽消耗。
  2. Shuffle阶段的数据传输：Map阶段的中间数据集需要传输到Reduce端需要大量的带宽资源。
  3. Reduce阶段的计算结果保存：Reduce端最终的计算结果需要保存到HDFS上，这种带宽的消耗也是不可避免的。

　　不过还好，Hadoop的设计者们在最初就考虑到了这个问题，所以在Map阶段的任务调度过程中做了一定程度的优化。当一个有空闲资源的TT（TaskTracker）向JT（JobTracker）申请任务的时候，JT会选择一个最靠近TT的任务给它，选择的原则是：

  1. TT本地是否有未处理的任务，有则调度之；
  2. TT本地没有未处理的任务，则调度一个和TT同一个机架上的任务给它；
  3. 否则，调度一个本数据中心的任务给他。

　　然而，我们会思考JT使如何知道这种结构关系的呢？为啥就知道另一个节点就是和这个TT是同一个机架或者数据中心的呢？这就要追溯到Hadoop的机架感知功能了。

  • 什么是机架感知

　　机架感知是一种计算不同计算节点（TT）的距离的技术，用以在任务调度过程中尽量减少网络带宽资源的消耗，这里用尽量，想表达的是当一个TT申请不到本地化任务时，JT会尽量调度一个机架的任务给他，因为不同机架的网络带宽资源比同一个机架的网络带宽资源更可贵。当然，机架感知不仅仅用在MR中，同样还用在HDFS数据块备份过程中（第一个replica选择本节点【如果上传是DataNode】或者随机的一个DN（系统会尽量避免存储太满和太忙的节点），第二个节点选择于第一个节点不同机架的DN，第三个选择放在第二个DN同一个机架的另一个DN上）

  • 机架感知实战

　　首先，看下面这个图的一个集群结构，D1和D2是两个数据中心，下面各有两个机架，然后叶子节点是DN。　

　

　  此时H1和H2是同一个Rack的，H1和H4是同一个数据中心的。而H1和H7是不同数据中心的。

　　然而，上面这种树结构不是Hadoop自己就自动建立的，需要用户的手动设置协助。在小型的集群中和单机测试中，一般是用不着配置的，所以机架感知功能默认是关闭的。

要设置机架感知，用户需要自己编写脚本来定义节点的映射关系和配置conf/core-site.xml文件的属性来启动机架感知。

　　一个脚本实例程序如下面的例子所示，定义了一个rack字典，里面有每个hostname对应的rack信息，后面也给出了每个IP对应的rack信息。将这段脚本程序放在每个节点的hadoop/bin/目录下，包括主节点。

#!/usr/bin/python
#-*-coding:utf-8 -*-
import sys
rack = {
"brix-01":"rack1",
"brix-02":"rack1",
"brix-03":"rack1",
"brix-04":"rack1",
"brix-05":"rack1",
"brix-06":"rack1",
"brix-07":"rack1",
"brix-08":"rack1",
"brix-09":"rack1",
"192.168.1.231":"rack1",
"192.168.1.232":"rack1",
"192.168.1.233":"rack1",
"192.168.1.234":"rack1",
"192.168.1.235":"rack1",
"192.168.1.236":"rack1",
"192.168.1.237":"rack1",
"192.168.1.238":"rack1",
"192.168.1.239":"rack1"
}

if __name__=="__main__":
  print "/"+rack.get(sys.argv[1],"rack0")

写好脚本程序后，然后配置core-site.xml文件，添加如下属性：

<property>
    <name>topology.script.file.name</name>
    <value>/home/hadoop/hadoop/bin/RackAware.py</value>
  </property>
  <property>
        <name>topology.script.number.args</name>
        <value>18</value>
  </property>

在第一次，故意将脚本程序写错，发现启动集群后观察日志发现接收到heartbeat信息后会报错，这说明，JT在得知启动机架感知后，在收到TT的心跳信息后会将其地址作为参数传入脚本，找到其对应的rack，然后将这些信息保存到内存中。

2014-11-17 21:15:24,658 INFO org.apache.hadoop.mapred.JobTracker: Lost tracker ‘tracker_brix-03:localhost/127.0.0.1:39733‘
2014-11-17 21:15:24,658 INFO org.apache.hadoop.ipc.Server: IPC Server handler 4 on 19001, call heartbeat([email protected], true, true, true, -1) from 192.168.1.236:53534:
 error: java.io.IOException: java.lang.NullPointerException
java.io.IOException: java.lang.NullPointerException
        at org.apache.hadoop.mapred.JobTracker.resolveAndAddToTopology(JobTracker.java:2385)
        at org.apache.hadoop.mapred.JobTracker.addNewTracker(JobTracker.java:2377)
        at org.apache.hadoop.mapred.JobTracker.processHeartbeat(JobTracker.java:2756)
        at org.apache.hadoop.mapred.JobTracker.heartbeat(JobTracker.java:2556)
        at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:483)
        at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:508)
        at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:959)
        at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:955)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.security.auth.Subject.doAs(Subject.java:422)
        at org.apache.hadoop.ipc.Server$Handler.run(Server.java:954)
2014-11-17 21:15:24,677 WARN org.apache.hadoop.net.ScriptBasedMapping: org.apache.hadoop.util.Shell$ExitCodeException:   File "/home/hadoop/hadoop/bin/RackAware.py", line 6
    "brix-02":"rack1"
             ^
SyntaxError: invalid syntax

2014-11-17 21:20:05,848 INFO org.apache.hadoop.mapred.JobTracker: Starting RUNNING
2014-11-17 21:20:05,858 INFO org.apache.hadoop.ipc.Server: IPC Server handler 9 on 19001: starting
2014-11-17 21:20:05,985 INFO org.apache.hadoop.net.NetworkTopology: Adding a new node: /rack1/brix-02
2014-11-17 21:20:06,012 INFO org.apache.hadoop.net.NetworkTopology: Adding a new node: /rack1/brix-03
2014-11-17 21:20:06,037 INFO org.apache.hadoop.net.NetworkTopology: Adding a new node: /rack1/brix-01
2014-11-17 21:20:06,078 INFO org.apache.hadoop.net.NetworkTopology: Adding a new node: /rack1/brix-04
2014-11-17 21:20:06,099 INFO org.apache.hadoop.net.NetworkTopology: Adding a new node: /rack1/brix-07
2014-11-17 21:20:06,127 INFO org.apache.hadoop.net.NetworkTopology: Adding a new node: /rack1/brix-08
2014-11-17 21:20:06,151 INFO org.apache.hadoop.net.NetworkTopology: Adding a new node: /rack1/brix-09
2014-11-17 21:20:06,173 INFO org.apache.hadoop.net.NetworkTopology: Adding a new node: /rack1/brix-05
2014-11-17 21:20:06,193 INFO org.apache.hadoop.net.NetworkTopology: Adding a new node: /rack1/brix-06

配置正确后，启动集群观察JT的日志发现建立了机架的拓扑关系了。

时间： 2024-10-14 01:21:50

【原创】Hadoop机架感知对性能调优的理解的相关文章

性能调优：理解Set Statistics Time输出

在性能调优:理解Set Statistics IO输出我们讨论了Set Statistics IO,还有如何帮助我们进行性能调优.这篇文章会讨论下Set Statistics Time,它会告诉我们执行一个查询需要的时间. 我们用一个例子来开始. 1 USE AdventureWorks2008r2 2 GO 3 DBCC dropcleanbuffers 4 DBCC freeproccache 5 6 GO 7 SET STATISTICS TIME ON 8 GO 9 SELECT * 1

性能调优：理解Set Statistics IO输出

原文:性能调优:理解Set Statistics IO输出 性能调优是DBA的重要工作之一.很多人会带着各种性能上的问题来问我们.我们需要通过SQL Server知识来处理这些问题.经常被问到的一个问题是:早上这个存储过程运行时间还是可以的,但到了晚上就很慢很慢.对此,我们可以笑着回答:这个存储过程运行多次后,已经累趴了,所以很慢. 存储过程或语句运行时间取决于服务器的工作量.如果在晚上,服务器负担很重的话,你的存储过程可能需要更多的时间来运行,因为它在等待CPU周期(CPU cycle)和IO

Hadoop之MapReduce性能调优

基于对这些组件的深入理解,用户可以很容易通过调整一些关键参数使作业运行效率达到最优,本文将分别从Hadoop管理员和用户角度介绍如何对Hadoop进行性能调优以满足各自的需求. 1 概述 Hadoop性能调优是一项工程浩大的工作,它不仅涉及Hadoop本身的性能调优,还涉及更加底层的硬件.操作系统和Java虚拟机等系统的调优.对这几个系统适当地进行调优均有可能给Hadoop带来性能提升. Hadoop(JobTracker.TaskTracker) JVM OS Hardware(CPU Mem

Hadoop作业性能指标及參数调优实例 （二）Hadoop作业性能调优7个建议

作者:Shu, Alison Hadoop作业性能调优的两种场景: 一.用户观察到作业性能差,主动寻求帮助. (一)eBayEagle作业性能分析器 1. Hadoop作业性能异常指标 2. Hadoop作业性能调优7个建议 (二)其他參数调优方法 二.Hadoop集群报告异常,发现个别作业导致集群事故. 一.用户观察到作业性能差,主动寻求帮助. (一)eBay Eagle作业性能分析器 对一般作业性能调优.eBay Eagle[i]的作业性能分析器已经能满足用户大部分需求. eBayEagle

Hadoop性能调优总结（一）

目的 随着企业要处理的数据量越来越大,Hadoop运行在越来越多的集群上,同时MapReduce由于具有高可扩展性和容错性,已经逐步广泛使用开来.因此也产生很多问题,尤其是性能方面的问题.这里从管理员角度和用户角度分别介绍Hadoop性能优化的一些体会. 本文是基于Hadoop 0.20.x(包括1x),cdh 3及以上版本做介绍.(Hadoop的版本比较杂乱,具体可以看参考部分链接介绍). 管理员角度 1.    硬件选择: Master机器配置的选择要高于slave机器配置的选择. 2.  

Hadoop性能调优

Hadoop性能调优   Hadoop在处理任务时性能是否足够好,这里的性能主要包括时间和空间两个指标.调优一般要注意以下几个方面: 1.       输入文件尽可能的大 HDFS的默认块文件的大小为64M,假如有1000,个文件,每个文件的大小都是2.3m,那么存储这些文件需要占用1000个块,那么一共会占用64000M大小的空间,如果将这些文件合并大小为2.2G,只有36个块,占用空间会小很多.而1000个文件会产生1000个map任务,么个map任务都会造成一定的性能损失,这对以上数据如果

Hadoop性能调优、YARN的内存和CPU配置

转自: https://blog.csdn.net/tototuzuoquan/article/details/80671128 转: https://blog.csdn.net/dehu_zhou/article/details/52808752 https://blog.csdn.net/dxl342/article/details/52840455 Hadoop为用户作业提供了多种可配置的参数,以允许用户根据作业特点调整这些参数值使作业运行效率达到最优. 一 应用程序编写规范 1.设置Co

HBase 管理，性能调优

设置 Hadoop 来扩展磁盘 I/O 现代服务器通常有多个磁盘硬件来提供大存储能力.这些磁盘通常配置成 RAID 阵列,作为它们的出厂设置.这在很多情况下是有益的,但对 Hadoop 却不是. Hadoop 的 slave 节点存储了 HDFS 数据块和 MapReduce 临时文件在它的本地磁盘.这些本地磁盘操作受益于使用多个独立的磁盘来扩展磁盘 I/O. 在这方面,我们将描述怎样通过使用多个磁盘设置 Hadoop 来扩展磁盘 I/O. 准备工作 我们假设你的每个 DataNode 节点都有

Cloudera Hadoop 5&amp; Hadoop高阶管理及调优课程(CDH5,Hadoop2.0,HA,安全,管理,调优)

1.课程环境 本课程涉及的技术产品及相关版本: 技术 版本 Linux CentOS 6.5 Java 1.7 Hadoop2.0 2.6.0 Hadoop1.0 1.2.1 Zookeeper 3.4.6 CDH Hadoop 5.3.0 Vmware 10 Hive 0.13.1 HBase 0.98.6 Impala 2.1.0 Oozie 4.0.0 Hue 3.7.0 2.内容简介 本教程针对有一定Hadoop基础的学员,深入讲解如下方面的内容: 1.Hadoop2.0高阶运维,包括H