本节和大家一起学习一下Hadoop，通过它的实际应用来向大家展示它的功能，从而使读者更容易了解，希望通过本节的介绍大家对Hadoop有初步的了解。
Hadoop最佳实践
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是一个线性可扩展模型，服务器越多，处理时间越短。
以下是同一个任务在不同机器数下获得的测试结果：
3.任务调度优化
首先对一些术语进行一下说明。Job是一组客服端想要完成的工作，包括输入数据，map-reduce程序以及配置信息，Hadoop通过将Job划分为一些task来执行，task又分为maptask和reducetask。
如何调度Hadoop任务才能充分发挥集群中所有服务器的能力呢？
条款5：每个Job的输入文件不宜过大，也不宜过小。文件过大会造成reduce任务分布不均匀，导致reducetime的不可预知性，而大量的小文件则会严重影响Hadoop的性能。
Hadoop会将Job的输入文件分割成64M固定大小的split，每个split启动一个maptask处理，这个split中的每个record都经过用户定义的map函数处理生成中间结果。若输入文件小于64M，则此文件单独作
为一个split处理。故当输入文件中有大量的小文件时，那么管理这些小文件的开销以及maptask的创建开销会占据绝大多数的Job执行时间。
为了找到Hadoop合适的Job文件大小，我们在一个有50台退役机器组成的集群做了一组性能测试，结果如下表：
我们把一个任务的计算时间分为两部分：reduceshuffletime和reducetime。
lreduceshuffletime是reduce任务把map输出的<key，value>对copy到本地的时间，即reduceshuffletime=map时间+<key，value>对网络传输时间。
lreducetime就是rudece处理这些<key，value>对的时间。
从上表我们可以得出结论：
l各个任务的reduceshuffletime是完全线性的（随着任务量增加，时间线性增加）。
l任务量在300G以内，reducetime基本线性增长，之后随着任务量增加，reducetime呈现随机性加大的趋势。在任务量达到 550G后这种随机性更加明显，先后运行同样的任务时间可能会相差一个小时。可以推断，随着任务量增加，reduce任务分布不均匀的机率提高，导致了 reducetime的不可预知性。
l上面两个时间的叠加影响下，在300G以内退役机器处理任务的时间是线性增加的。300G以上的任务需要分成若干个小任务串行运行，保证reduce处理在线性可控的区间内。本节关于Hadoop方面的知识没有介绍完毕，请关注下节介绍。