Hadoop最佳实践_hadoop集群备份最佳实践-CSDN博客

本文链接：https://blog.csdn.net/vinowan/article/details/5634152

1. 简介

Hadoop是Apache自由软件基金会资助的顶级项目，致力于提供基于map-reduce计算模型的高效、可靠、高扩展性分布式计算平台。

2. Map-Reduce应用场景

作为一种受限的分布式计算模型，Map-Reduce计算模型有其擅长的领域，也有其不擅长的方面：

条款1：map-reduce计算模型适用于批处理任务，即在可接受的时间内对整个数据集计算某个特定的查询的结果，该计算模型不适合需要实时反映数据变化状态的计算环境。

条款2：map-reduce计算模型是以“行”为处理单位的，无法回溯已处理过的“行”，故每行日志都必须是一个独立的语义单元，行与行之间不能有语义上的关联。

条款3：相对于传统的关系型数据库管理系统，Map-Reduce计算模型更适合于处理半结构化或无结构话的数据。

因为Map-Reduce计算模型是在处理的时候对数据进行解释的，这就意味着输入的Key和Value可以不是数据本身固有的属性，Key、Value的选择完全取决于分析数据的人。

条款4：Map-Reduce是一个线性可扩展模型，服务器越多，处理时间越短。

以下是同一个任务在不同机器数下获得的测试结果：

机器数	30台	40台	50台
200G任务运行时间 (分)	101	77	64

表二

3. 任务调度优化

首先对一些术语进行一下说明。Job是一组客服端想要完成的工作，包括输入数据，map-reduce程序以及配置信息，Hadoop通过将Job划分为一些task来执行，task又分为map task和reduce task。

如何调度Hadoop任务才能充分发挥集群中所有服务器的能力呢？

条款5：每个Job的输入文件不宜过大，也不宜过小。文件过大会造成reduce任务分布不均匀，导致reduce time的不可预知性，而大量的小文件则会严重影响Hadoop的性能。

Hadoop会将Job的输入文件分割成64M固定大小的split，每个split启动一个map task处理，这个split中的每个record都经过用户定义的map函数处理生成中间结果。若输入文件小于64M，则此文件单独作为一个split处理。故当输入文件中有大量的小文件时，那么管理这些小文件的开销以及map task的创建开销会占据绝大多数的Job执行时间。

为了找到Hadoop合适的Job文件大小，我们在一个有50台退役机器组成的集群做了一组性能测试，结果如下表：

文件大小	50G	100G	150G	200G	250G	300G	350G	400G	450G	500G
reduce shuffle time（分钟）	9	18	27	37	45	54	62	69	77	86
reduce time（分钟）	12	16	23	27	39	46	62	89	99	109
计算总时间（分钟）	21	34	50	64	84	100	124	158	176	195

表三

我们把一个任务的计算时间分为两部分：reduce shuffle time和reduce time。

l reduce shuffle time是reduce任务把map输出的<key，value>对copy到本地的时间，即reduce shuffle time=map时间+<key，value>对网络传输时间。

l reduce time就是rudece处理这些<key，value>对的时间。

从上表我们可以得出结论：

l 各个任务的reduce shuffle time是完全线性的（随着任务量增加，时间线性增加）。

l 任务量在300G以内，reduce time基本线性增长，之后随着任务量增加，reduce time呈现随机性加大的趋势。在任务量达到550G后这种随机性更加明显，先后运行同样的任务时间可能会相差一个小时。可以推断，随着任务量增加，reduce任务分布不均匀的机率提高，导致了reduce time的不可预知性。

l 上面两个时间的叠加影响下，在300G以内退役机器处理任务的时间是线性增加的。300G以上的任务需要分成若干个小任务串行运行，保证reduce处理在线性可控的区间内。

条款6：多个大输入的Job建议使用串行执行，多个小输入的Job建议使用并行执行。

Hadoop的任务处理分为map阶段以及reduce阶段，当集群的task slots足够支持多个任务同时执行时，建议使用多任务并行执行，反之，建议使用串行执行，且当一个Job开始执行reduce task时，可以开始执行下一个Job的map task。

以下是我们在50台退役机器上分别并行和串行运行2个100G，200G，300G的任务的测试结果：

文件大小	50G	100G	200G	300G
并行运行二个任务总时间（分）	26	53	140	211
串行运行二个任务总时间（分）	41	68	128	200
并行串行时间差（分）	-15	-15	+12	+11

表四

条款7：reducer的个数应该略小于集群中全部reduce slot的个数。

map task的个数由输入文件大小决定，所以选择合适的reducer的个数对充分利用Hadoop集群的性能有重要的意义。

Hadoop中每个task均对应于tasktracker中的一个slot，系统中mapper slots总数与reducer slots总数的计算公式如下：

mapper slots总数 = 集群节点数 × mapred.tasktracker.map.tasks.maximum

reducer slots总数 = 集群节点数 × mapred.tasktracker.reduce.tasks.maximum

设置reducer的个数比集群中全部的reducer slot略少可以使得全部的reduce task可以同时进行，而且可以容忍一些reduce task失败。

条款8：多个简单串行的Job优于一个复杂的Job。

将复杂的任务分割成多个简单的任务，这是典型的分治的思想。这样不仅可以使得程序变得更简单，职责更单一，而且多个串行的任务还可以在上一个任务的正在执行reduce任务的时候，利用空闲的map资源来执行下一个任务。

4. Key-Value权衡

Map-Reduce算法的核心过程如下：

map (k1,v1) --> list(k2,v2)

reduce (k2,list(v2)) --> list(v2)

即通过用户定义的map函数将输入转换为一组<Key，Value>对，而后通过用户定义的reduce函数将<Key，List<Value>>计算出最后的结果。

如何选择合适的map和reduce函数才能充分利用Hadoop平台的计算能力呢？换句话说，如何选择上式中合适的K2和V2呢？

条款9：map task或reduce task的大小应该适中，以一个task运行2-3分钟为宜，且task不能超出计算节点的运算能力。

虽然Hadoop平台帮助我们将数据分割成为小任务来执行，但我们也应当意识到，每个task都是在一个计算节点运行的，若一个task对机器资源（CPU、内存、磁盘空间等）的需求超出了计算节点的能力的话，任务将会失败。而如果task过小的话，虽然计算节点能够快速的完成task的执行，但过多的task的管理开销，以及中间结果频繁的网络传输将占据任务执行的绝大部分时间，这样同样会严重影响性能。建议的task大小最好是以能够运行2-3分钟为宜。