CMU论文—Hadoop’s Adolescence（0-3页）

Hadoop的转变时代:三种科研级别集群工作负载比较分析

  Kai Ren1 ， YongChul Kwon2 ， Magdalena Balazinska2 ， Bill Howe2

      1 卡梅隆大学， 2 华盛顿大学

(kair@cs。cmu。edu， {yongchul，magda，billhowe}@cs。washington。edu)

 

       译者注：本文中有许多术语出现多次，准确理解它们是理解全文的基础。本文译者水平有限，难免有词汇翻译不够准确，或与常见译文不同。故将主要术语及其译文汇总如下，便于读者理解。

主要术语翻译对照表

原文

译者翻译

备注

adolescence

转变时代

代表Hadoop有待优化

user behavior

用户行为

 

Workload

工作负载

 

cluster-centric

集群中心模式

 

resource utilization

资源分配

 

job

作业

 

declarative frameworks

声明性框架

 

speculative execution

推测执行    

 

conventional scheduling

常规调度    

 

Hot file

热文件

 

workload

工作负载

 

one-off jobs

一次性作业

 

parameter sweeps

参数扫描    

 

monte carlo simulations

蒙特卡罗模拟

 

shuffling

混排     

 

the outlier

异常值/离群值

 

Hash partitioning

哈希分区

 

directed acyclic graph

有向无环图

 

chain-like jobs

连锁作业    

 

 

摘要

我们从应用程序级别的视角出发，利用三种不同科研级别集群，分析Hadoop的工作量情况。具体目标如下。

(1)探索应用模式和用户行为的新问题。

(2)了解与IO和负载均衡相关的关键性能难点。

我们的分析表明Hadoop的还处于转变时代。Hadoop的功能性，拓展性，工具性都还有不足，并且还有明显可供优化的余地。Hadoop在包括需要交互的工作量的应用模式上，还存在显著的差异性，留给我们很大空间去在Hadoop的生态系统中开发新的工具，并作为未来研究的领域。

 

致谢。。。

 

关键字:Hadoop  工作量分析 用户行为 存储 负载均衡

 

1 简介

     Hadoop是Google公司MapReduce的开源实现。它目前已经大数据分析特别是在科研领域上十分流行。鉴于Hadoop的广泛性，我们很自然会有一个问题，Hadoop运行的如何?为了回答这个问题，我们必须跨越以往将每一个任务看作黑盒，并且着眼于粗粒度的诸如资源利用的全局度量这样一种常规的以集群为中心的分析模式。反而，我们必须意识到，并非所有的集群是使用的相同的方法，那些与Hadoop相关的生态圈中丰富的工具，拓展，和库，也会影响应用程序的特性，用户的行为和工作流的结构。

      本论文中，我们将分析三个不同科研级别集群，其主要用户都来至于学术机构。本工作的目标有二:更好的了解Hadoop集群上的应用模式和用户行为，并对一组研究导向集群的关键性能做出评估。为了分析高级别\面向用户的问题，我们利用了那些Hadoop商业用户相当敏感的信息，包括工作规范(比如，java类命名，用户标示符，输入/输出目录)和高识别度的应用程序级别的统计数据(即HDFS和MapReduce计数器)。对于性能的研究，我们讲我们的发现和之前的工作加以了对比和比较。本论文研究工作分为以下四个部分，应用程序的工作量，用户行为，IO性能和负载均衡。

      总的来说，我们的分析证明Hadoop仍然处在尚须转变的阶段。我们发现大量适用于简单，非Hadoop情况的作业，这些作业相对独立，单步执行，并且规模很小。证据显示用户持续提交作业之后，需要参与交互，以供处理结果的短暂延迟。尽管一些是构建的手动工作流，但是相对的也很少有使用高级声明性框架。我们也发现对默认的配置参数和默认的Hadoop的自定义选项的过度依赖，会产生重大的性能损失。工作负载是五花八门的，表明简单的，普适性的忽略应用程序的优化不在广泛的有效了。推测执行(编者按:所谓的推测执行，就是当所有task都开始运行之后，JobTracker会统计所有任务的平均进度，如果某个task所在的tasknode机器配置比较低或者CPU load很高，导致任务执行比总体任务的平均执行要慢，此时JobTracker会启动一个新的任务（duplicatetask），原有任务和新任务哪个先执行完就把另外一个kill掉，这也是我们经常在JobTracker页面看到任务执行成功，但是总有些任务被kill，就是这个原因)并没有产生太多的益处，而常规调度只是局部性的改善，并且忽略了对热文件缓存的机会。我们发现资源集中化的趋势是有效的，小型的，本地集群利用就显不足。总之我们发现极度需要对集群交互的抽象程度加以提高:改善交互，自动优化复杂任务，自动申请应用程序唤醒的状态调整。

      更准确的说，我们的研究做出了以下的贡献。

      (1) 首先，我们需要比较分析三种Hadoop集群的工作负载。这三个对应的集群都是学术研究级别的。鉴于大数据是科研领域的重要方面，研究在此设置之下大数据集群的使用，是对这些系统的需求和性能的理解的重要组成部分。

      (2)我们将在三种集群中考虑用户执行程序的特性，并且会比以往的Hadoop集群对细节的深入级别更高。我们研究的关键问题着眼于应用程序采取的是复杂的工作流形式还是一次性的作业。这些程序移动了多少数据-它们是在海底捞针的寻找数据，还是有在更高层次搜索的趋势?这些应用程序的实现使用的高层次的接口诸如PigLatin 或者 HiveSQL，或者它们是直接由Java写成的。令人吃惊的是，我们发现很多，小型的，单步执行的应用程序，是直接由Java实现的，但并非是所有的。然而它们的数据处理特点确实各不相同。

      (3) 据我们所知，我们是第一个研究大数据集群中用户行为的。我们研究用户与集群交互:自动还是手动提交的申请?用户串行的提交作业并交互式的等待一个的结果在提交另外一个，还是一次性提交所有作业。(如参数扫描和蒙特卡罗模拟)，用户的资源利用分布是如何的?有多少工作是为了解决重量级问题，而这些问题可以从特定资源或者专门的解决方案中获益的。我们发现约有10%的作业是作为批处理的一部分与其他作业一起提交的。另外30%是串行自动提交的。剩下的60%是用户等待作业完成，在2分钟内手动触发下一个-用户是交互工作的。我们还发现，如果选项可变，只可见很少一部分用户通过改变重要参数来设置它们的作业，诸如启动组合，修改HDFS块大小。绝大部分的用户在Hadoop引擎中执行它们的作业都是默认设置的。

(4)我们从IO需求的角度研究了三个集群的工作负载情况，并和之前的研究做了比较。IO总所周知是高性能数据处理的瓶颈[18，38]。我们关注包括磁盘数据读取，写入磁盘，和网络混排数据的开销。我们也会关注集群上用户使用了哪些IO工作负载，如何做可以减少这种负载。我们发现正如之前研究，读入输入数据以供任务分析占据了主要的IO负载。令人惊讶的是，我们也发现，Hadoop会为了确保输入数据本地读取，也会在调度map任务时候失败。绝大部分的map任务都是通过网络来读取数据的。更为有趣的是，作业在输入数据规模有很大的不同，但同时，在每节点使用中等规模的缓存就可以使很大一部分作业完全从内存中被送出。就各种分析任务的管理结果来看，50%的作业一分钟之内输出数据就会被覆盖，90%的作业，一小时内输出数据会被覆盖。这就要求在大集群上管理大量短暂，大小不一文件的有效方法。

      (5) 最后，我们也要研究在这些集群上负载不平衡的挑战:讨论它们的流行，影响，原因，以及为减少这种不平衡而非常著名的推测执行方法的性能。我们的分析显示倾斜现象仍然是一个重要的问题。超过40%的在三个集群上长时间运行作业有异常值，定义为任务级别运行的有50%时间长于中间运行时间。这一结果证实，离群值的幅度于在工业级别的集群上的问题是相一致的[5，25]。哈希分区是均匀分区负载的一种方法，也是Hadoop采用的默认方法。尽管哈希分区为所有集群中92%的作业在均匀减少的任务中重新分配了减少的键值，由此产生的任务运行时间不平衡的比例占到了作业的22%-38%左右。我们发现推测执行不能很好的定位问题，用户不会通过改变任务分配的工作来手动调整均衡。

      总之，我们的研究显示，Hadoop在科研研究环境下，仍处在不成熟时期:在性能和用户支持方面仍然急需改善。

2数据集概述

     我们分析了三种用于科研集群的执行日志，OpenCloud，M45，WebMing。这三种集群有不同的硬件和软件配置，并且规模有9个节点(WebMing)，64个节点(OpenCloud)，400个节点(M45)。

      OpenCloud。OpenCloud是位于卡梅隆大学并由卡梅隆大学并行数据实验室管理的研究集群。它对校园内各部门的研究人员(包括教师，博士后，研究生)开放。就我们收集的资料来看，集群被分成几组使用，包括计算天体物理学，生物学，神经语言学，信息检索，信息分类，网络内容机器学习，自然语言处理，图像视频分析，安全与恶意软件分析，社交网络分析，云计算系统开发，集群故障诊断以及与信息检索，数据挖掘和分布式系统有关的几个项目。

      集群包括64个节点，每个节点拥有2。8GHz双四核CPU，16GRAM，10Gbps以太网卡和四个希捷7200转SATA磁盘驱动器。集群运行Hadoop0.20.1收集数据。

Cluster

Duration

Start Date

End Date

Successful/Failed/Killed Jobs

Users

OpenCloud

20 months

2010 May

2011 Dec

51975/4614/1762

78

M45

9 months

2009 Jan

2009 Oct

42825/462/138

30

Web Mining

5 months

2011 Nov

2012 Apr

822/196/211

5

Table1: Summary of Analyzed Workloads

       M45:M45是雅虎提供的供科研之用的生产集群。使用这些集群的小组，覆盖了我们所收集到的领域:大规模图挖掘，文本与web挖掘，大规模图形学，自然语言处理，机器翻译，数据密集型文件系统的应用[24]。每个节点包括1。86GHz的Xeon处理器，6GB内存，四个7200转SATA磁盘驱动器。磁盘运行在Hadoop0.18，利用Pig收集数据。

前四个月的跟踪已结束，先前由Kavulya等负责分析。

      Web Ming: Web Ming是由一拨匿名人士管理的小规模集群。这支队伍包括教师，博士后和学生，大多数用户都是运行网络文本挖掘的作业。该集群包含9个节点，每个节点拥有四核XeonE5630处理器，32GB RAM，4个1。88TBHDD硬盘。集群利用Pig运行Hadoop0.20.23版

      LOG:上表1包含了日志收集的时长以及它所包含的Hadoop作业的数量。对每个集群来说，我们的日志都包含了三种信息。所有信息都是有Hadoop标准工具自动收集的，并不需要额外的追踪工具。

      (1) 作业配置文件。Hadoop会为每个提交的作业建立配置文件，它是一个xml文件类型，包含了Hadoop作业所必须的规范内容。(比如Map和Reduce的类名，键值对的类型，Mapper的数量，Reducer的数量)

      (2) 作业历史文件。Hadoop会为每个提交的作业建立作业历史文件，包括，任务初始化时间，开始时间，完成时间，以及每个阶段的转变时间，此外，该文件还包含一系列计数器，包括，每个任务的记录或者字节数，读写数。

      (3)HDFS操作。在版本0.20.x中，Hadoop文件系统(HDFS)，会追踪记录所有文件系统的操作，包括访问路径名称，用户ID，操作类型(如打开，重命名等)。这些信息只在OpenCloud集群中有。