转自http://t.cn/aWGEH8

MapReduce作为分布式并行计算的思想，目前存大3个无法解决的问题。
1、MR思想的低效性；
2、代码的重用性----无法全局优化；
3、数据处理的线性模式；

下面对这3个问题进行详细的解释：
1、MR思想的低效性
MR的思想，会导致将一个计算分成多步来执行，每步之间还插入了数据存储等操作。MR处理数据的过程可以归纳为序列：map-reduce-map-reduce-……，其中，map框架必须存在（执行可以为空）。
A）第一种情况：“1个map+1个reduce”，这种简单的数据处理基本上所有的分布式计算框架都能有效完成，MR框架也做的不错；
B）第二种情况：“1个map+1个Combiner+1个reduce”，其中map和combiner在一个物理节点上执行，而且是在map运行结束，把数据结果存储到硬盘（内存）后才启动combiner进行计算——这是把一个计算（map+combiner）分成两步执行；
C）第三种情况：“map-reduce-map-reduce-……”的序列，其中map的执行可以为空，reduce可以省略。Map过程是一个映射过程，它的功能是把一个<key,value>映射成一个<key,value>的集合，那么我们可以把map操作（第一个除外）放到前一个reduce过程中去实现——MR思想再次把一个计算（reduce+map）分成两步执行。

写了这么多，可能很多人还没有明白我要说什么。以上内容总结出来就是MR的思想导致了冗余的数据存储过程。
我们看一个具体的实例证明，用hadoop的MR框架自带的wordcout代码：
WordCount 1（W1）：在wordcount代码的基础上，增加一个job2，job2只有一个map过程，但map的执行内容为空；
WordCount2（W2）：wordcount代码，但是reduce结果不要写DFS；
两者运行的时间差就是MR浪费掉的时间。这其中包括4个部分：
其中：
A）T_Job 1 Finished：job1 reduce结束到job2启动之间的时间减去处理中间数据的时间；(基本上大于1秒)
B）T_Job2Start：job2配置作业的时间；（3-5秒）
C）T_RM：job2 map读数据的时间+调度map任务的时间；（3（64M）+3=6秒，跟块的大小有关）
D）T_WR：job1 Reduce写DFS的时间，它跟数据量的大小有关。（修改Contextwrite的次数可以进行统计与估算）
一个空map且只运行一轮的时间是15秒，基本跟以上测试时间匹配。

2、MR代码重用性----无法全局优化
如果需要对数据抽取一部分内容，那么可以写一个MR程序，code1；
如果需要对数据中的某个内容作修改，那么可以写一个MR程序，code2；
如果需要对数据抽取一部分内容，然后再对该内容的某个部分进行修改，那么该怎么办？
方法一，对数据先执行code1，执行完成后，再执行code2。如果数据量足够大，例如code1的执行时间需要2个小时，那么，我们可以再找3个人，摆一桌麻将了。
方法二，再写一个MR程序——code12，把这两个计算放在一起做。OK，效率上来了，可是我们需要写一个新的MR程序。如果这种可并行情况较多（设为N），那么你要写全2种组合，就需要写C（N，2）=N（N-1）/2个程序；如果你要写全3种组合，……（是不是有种想找块豆腐撞死的感觉了？）

3、数据处理线性模式；
假如数据的处理流程是一个有向无环图，那么你用MapReduce就会很累了，你需要考虑如何分割任务，这些任务如何并行等。这些内容不是应该由框架完成吗？

总结一句话：MR思想除了能做分布式计算框架都能做的简单事情外，其他事情它做起来都是在浪费时间。



一个高效的分布式并行计算应该使数据流起来，它有3个特性：
1、编程框架要简单，要符合人的思考问题、解决问题的习惯；
  2、数据处理模型是基于对象的；
  3、数据处理过程是基于有向无环图的，计算框架能有效的全局并行执行过程。
   
  这里仅举一个例子：对一年内某商品的销售数据进行统计，它比去年的销售量增长了多少？（假设数据量很大，一个节点处理不了，需要集群计算）
我们思考问题的思路：
（1）计算今年的销售量和去年的销售量（该问题可分为以下2步）。
A）查询今年和去年的每条记录，看商品分别卖了多少；
  B）对A）的数据，根据商品和年进行求和。
（2）计算今年的销售量比去年的销售量增长了多少。

针对以上步骤，我们就可以写一个程序，交给机器去执行了：
（1） 从记录中抽取目标商品销售时间（今年或者去年），以及销售数据
Object_Record（商品，年，数据） :- Object_Record（data）
（2）按照商品的销售时间对销售数量进行求和
  Object_Record（商品，年，sum（数量））:- Object_Record（商品，年，数量）
  3）按照销售量的增长
  Object_Record（商品，今年，数量）/ Object_Record（商品，去年，数量）

编程过程就是这么简单：只要把解决问题的思路想清楚了，程序就写出来了。
那么它有什么用处呢？
1、分步式并行计算框架，解决数据分析类的应用。（市场很成熟）
2、个人云平台（未来蓝图）
每个用户（终端）都可看作是一个对象，他具有属性和动作等特征；
云平台存储的数据是用户的数据；
云平台可以为用户提供服务；
云平台提供用户数据分析等服务，可以为用户量身打造服务；
云平台可以开放分析应用接口（应用商店），可以让用户自己制作服务、销售服务。

如有问题，可以邮箱联系：qz2003@gmail.com

转自http://t.cn/aWGEH8

MapReduce作为分布式并行计算的思想，目前存大3个无法解决的问题。
1、MR思想的低效性；
2、代码的重用性----无法全局优化；
3、数据处理的线性模式；

下面对这3个问题进行详细的解释：
1、MR思想的低效性
MR的思想，会导致将一个计算分成多步来执行，每步之间还插入了数据存储等操作。MR处理数据的过程可以归纳为序列：map-reduce-map-reduce-……，其中，map框架必须存在（执行可以为空）。
A）第一种情况：“1个map+1个reduce”，这种简单的数据处理基本上所有的分布式计算框架都能有效完成，MR框架也做的不错；
B）第二种情况：“1个map+1个Combiner+1个reduce”，其中map和combiner在一个物理节点上执行，而且是在map运行结束，把数据结果存储到硬盘（内存）后才启动combiner进行计算——这是把一个计算（map+combiner）分成两步执行；
C）第三种情况：“map-reduce-map-reduce-……”的序列，其中map的执行可以为空，reduce可以省略。Map过程是一个映射过程，它的功能是把一个<key,value>映射成一个<key,value>的集合，那么我们可以把map操作（第一个除外）放到前一个reduce过程中去实现——MR思想再次把一个计算（reduce+map）分成两步执行。

写了这么多，可能很多人还没有明白我要说什么。以上内容总结出来就是MR的思想导致了冗余的数据存储过程。
我们看一个具体的实例证明，用hadoop的MR框架自带的wordcout代码：
WordCount 1（W1）：在wordcount代码的基础上，增加一个job2，job2只有一个map过程，但map的执行内容为空；
WordCount2（W2）：wordcount代码，但是reduce结果不要写DFS；
两者运行的时间差就是MR浪费掉的时间。这其中包括4个部分：
其中：
A）T_Job 1 Finished：job1 reduce结束到job2启动之间的时间减去处理中间数据的时间；(基本上大于1秒)
B）T_Job2Start：job2配置作业的时间；（3-5秒）
C）T_RM：job2 map读数据的时间+调度map任务的时间；（3（64M）+3=6秒，跟块的大小有关）
D）T_WR：job1 Reduce写DFS的时间，它跟数据量的大小有关。（修改Contextwrite的次数可以进行统计与估算）
一个空map且只运行一轮的时间是15秒，基本跟以上测试时间匹配。

2、MR代码重用性----无法全局优化
如果需要对数据抽取一部分内容，那么可以写一个MR程序，code1；
如果需要对数据中的某个内容作修改，那么可以写一个MR程序，code2；
如果需要对数据抽取一部分内容，然后再对该内容的某个部分进行修改，那么该怎么办？
方法一，对数据先执行code1，执行完成后，再执行code2。如果数据量足够大，例如code1的执行时间需要2个小时，那么，我们可以再找3个人，摆一桌麻将了。
方法二，再写一个MR程序——code12，把这两个计算放在一起做。OK，效率上来了，可是我们需要写一个新的MR程序。如果这种可并行情况较多（设为N），那么你要写全2种组合，就需要写C（N，2）=N（N-1）/2个程序；如果你要写全3种组合，……（是不是有种想找块豆腐撞死的感觉了？）

3、数据处理线性模式；
假如数据的处理流程是一个有向无环图，那么你用MapReduce就会很累了，你需要考虑如何分割任务，这些任务如何并行等。这些内容不是应该由框架完成吗？

总结一句话：MR思想除了能做分布式计算框架都能做的简单事情外，其他事情它做起来都是在浪费时间。



一个高效的分布式并行计算应该使数据流起来，它有3个特性：
1、编程框架要简单，要符合人的思考问题、解决问题的习惯；
  2、数据处理模型是基于对象的；
  3、数据处理过程是基于有向无环图的，计算框架能有效的全局并行执行过程。
   
  这里仅举一个例子：对一年内某商品的销售数据进行统计，它比去年的销售量增长了多少？（假设数据量很大，一个节点处理不了，需要集群计算）
我们思考问题的思路：
（1）计算今年的销售量和去年的销售量（该问题可分为以下2步）。
A）查询今年和去年的每条记录，看商品分别卖了多少；
  B）对A）的数据，根据商品和年进行求和。
（2）计算今年的销售量比去年的销售量增长了多少。

针对以上步骤，我们就可以写一个程序，交给机器去执行了：
（1） 从记录中抽取目标商品销售时间（今年或者去年），以及销售数据
Object_Record（商品，年，数据） :- Object_Record（data）
（2）按照商品的销售时间对销售数量进行求和
  Object_Record（商品，年，sum（数量））:- Object_Record（商品，年，数量）
  3）按照销售量的增长
  Object_Record（商品，今年，数量）/ Object_Record（商品，去年，数量）

编程过程就是这么简单：只要把解决问题的思路想清楚了，程序就写出来了。
那么它有什么用处呢？
1、分步式并行计算框架，解决数据分析类的应用。（市场很成熟）
2、个人云平台（未来蓝图）
每个用户（终端）都可看作是一个对象，他具有属性和动作等特征；
云平台存储的数据是用户的数据；
云平台可以为用户提供服务；
云平台提供用户数据分析等服务，可以为用户量身打造服务；
云平台可以开放分析应用接口（应用商店），可以让用户自己制作服务、销售服务。