1、分布式计算引擎的核心设计思路
分布式里的核心思路：就是 分而治之 （比如怎么切分和怎么合并）
既然复杂问题，单台计算搞不定，那么就发挥人多力量大的优势：组建一个多服务器组成的集群来完成分布式计算的问题。
核心过程就是：
1、第一阶段：复杂的大任务拆分成多个简单的小任务来进行执行
2、第二阶段：把第一阶段的并行执行的小任务的执行结果进行汇总
MapReduce：一句话讲就是分而治之+并行计算
HDFS：一句话总结，就是分散存储+冗余存储
但是，把单机计算程序，扩展成分布式计算应用程序，会遇到非常多的问题：
- 数据存储的问题，首先需要搞定海量数据存储的问题。
- 运算逻辑至少要切分为两个阶段，一个是怎么并发计算，还有就是怎么汇聚结果
- 这两个阶段如何启动执行，和如何配合
- 运算程序怎么写，才能保证大数据量的问题，移动计算还是移动数据（其实就是数据找程序，还是程序找数据）？
- 如何分配两个阶段的执行计划
- 如何管理计算过程中的中间状态，容错怎么办，例如网络io的一些问题？
- 如何监控和跟踪任务的执行？
- 出错如何处理，抛异常还是重试
可以设想一下啊，由单机扩展成分布式的时候，会引入大量的复杂工作。为了提高开发效率，我么是不是可以将分布式计算程序中的公共部分封装成框架，让开发人员可以将精力集中于业务逻辑。
2、MapReduce的诞生
MapReduce最早是由Google公司研究提出的一种面向大规模数据处理的并行计算模型和方法。Google公司设计MapReduce的初衷主要是为了解决其搜索引擎中大规模网页数据的并行化处理。Google公司发明了MapReduce之后首先用其重新改写了其搜索引擎中的Web文档索引处理系统。但由于MapReduce可以普遍应用于很多大规模数据的计算问题，因此自发明MapReduce以后，Google公司内部进一步将其广泛应用于很多大规模数据处理问题。Google公司内有上万个各种不同的算法问题和程序都使用MapReduce进行处理。
2003年和2004年，Google公司在国际会议上分别发表了两篇关于Google分布式文件系统和MapReduce的论文，公布了Google的GFS和MapReduce的基本原理和主要设计思想。
Hadoop的思想来源于Google的几篇论文，Google的那篇MapReduce论文里说：Our abstraction is inspired by the map and reduce primitives present in Lisp and many other functional languages。这句话提到了MapReduce思想的渊源，大致意思是，MapReduce的灵感来源于函数式语言（比如Lisp）中的内置函数map和reduce。函数式语言也算是阳春白雪了，离我们普通开发者总是很远。简单来说，在函数式语言里，map表示对一个列表（List）中的每个元素做计算，reduce表示对一个列表中的每个元素做迭代计算。它们具体的计算是通过传入的函数来实现的，map和reduce提供的是计算的框架。不过从这样的解释到现实中的MapReduce还太远，仍然需要一个跳跃。再仔细看，reduce既然能做迭代计算，那就表示列表中的元素是相关的，比如我想对列表中的所有元素做相加求和，那么列表中至少都应该是数值吧。而map是对列表中每个元素做单独处理的，这表示列表中可以是杂乱无章的数据。这样看来，就有点联系了。在MapReduce里，Map处理的是原始数据，自然是杂乱无章的，每条数据之间互相没有关系；到了Reduce阶段，数据是以key后面跟着若干个value来组织的，这些value有相关性，至少它们都在一个key下面，于是就符合函数式语言里map和reduce的基本思想了。
3、MapReduce架构设计概述
MapReduce其实就是责任链设计模式的典型实现！
MapReduce在设计之初，认为不管多复杂的设计模型，不管数据在哪里，存储在哪里，都应该可以使用这个框架执行相关的任务计算，也就是设计之处就要做到通用型。根据这个设计思想，然后开始开发，然后执行了规范，让用户遵循着我们的规范，就可以顺利的编写对应的业务逻辑
MapReduce的架构设计类似于责任链设计模式，每个组件发挥自己的作用。串联起来完成一个完整的分布式应用程序的执行。
接下来让我们看看MapReduce的运行流程：
3.1 MapTask的并行度决定机制
假设现在默认的数据块大小是128M，我现在有一个300M的文件，请问，启动几个MapTask？如果是260M呢，启动几个MapTask？
未完待续。。。