大数据----12.MapReduce计算框架

1. MapReduce基本编程模型和框架

1.1 MapReduce抽象模型

大数据计算的核心思想是：分而治之。如下图所示。把大量的数据划分开来，分配给各个子任务来完成。再将结果合并到一起输出。注：如果数据的耦合性很高，不能分离，那么这种并行计算就不合适了。

1.2 Hadoop的MapReduce的并行编程模型

如下图2所示，Hadoop的MapReduce先将数据划分为多个key/value键值对。然后输入Map框架来得到新的key/value对，这时候只是中间结果，这个时候的value值是个集合。再通过同步屏障(为了等待所有的Map处理完)，这个阶段会把相同key的值收集整理(Aggregation&Shuffle)在一起，再交给Reduce框架做输出组合，如图2中每个Map输出的结果，有K1，K2，K3，通过同步屏障后，K2收集到一起，K2收集到一起，K3收集到一起，再分别交给Reduce，通过Reduce组合结果。

1.3 Hadoop的MapReduce的完整编程模和框架

图3是MapReduce的完整编程模型和框架，比模型上多加入了Combiner和Partitioner。

\1. Combiner
Combiner可以理解为一个小的Reduce，就是把每个Map结果，先做一次整合。例如图3中第三列的Map结果中有2个good，通过Combiner之后，先将本地的2个goods组合到了一起（红色的（good，2））。好处是大大减少需要传输的中间结果数量，达到网络数据传输优化，这也是Combiner的主要作用。

\2. Partitioner
为了保证所有的主键相同的key值对能传输给同一个Reduce节点，如图3中所有的good传给第一个Reduce前，所有的is和has传给第二个Reduce前，所有的weather，the和today传到第三个Reduce前。MapReduce专门提供了一个Partitioner类来完成这个工作，主要目的就是消除数据传入的Reduce节点后带来不必要的相关性。

2.mapreduce入门

1、什么是mapreduce

首先让我们来重温一下 hadoop 的四大组件：
HDFS：分布式存储系统
MapReduce：分布式计算系统
YARN： hadoop 的资源调度系统
Common： 以上三大组件的底层支撑组件，主要提供基础工具包和 RPC 框架等

Mapreduce 是一个分布式运算程序的编程框架，是用户开发“基于 hadoop 的数据分析 应用”的核心框架
Mapreduce 核心功能是将用户编写的业务逻辑代码和自带默认组件整合成一个完整的 分布式运算程序，并发运行在一个 hadoop 集群上

2、为什么需要mapreduce

为什么需要 MapReduce？
(1) 海量数据在单机上处理因为硬件资源限制，无法胜任
(2) 而一旦将单机版程序扩展到集群来分布式运行，将极大增加程序的复杂度和开发难度
(3) 引入 MapReduce 框架后，开发人员可以将绝大部分工作集中在业务逻辑的开发上，而将 分布式计算中的复杂性交由框架来处理

可见在程序由单机版扩成分布式版时，会引入大量的复杂工作。为了提高开发效率，可以将 分布式程序中的公共功能封装成框架，让开发人员可以将精力集中于业务逻辑。
Hadoop 当中的 MapReduce 就是这样的一个分布式程序运算框架，它把大量分布式程序都会
涉及的到的内容都封装进了，让用户只用专注自己的业务逻辑代码的开发。 它对应以上问题
的整体结构如下：

场景：比如有海量的文本文件，如订单，页面点击事件的记录，量特别大，单机版很难搞定。

怎样解决海量数据的计算？
求和： 1 + 5 +7 + 3 +4 +9 +3 + 5 +6

MapReduce产生背景
如果让你统计日志里面的出现的某个URL的总次数，让你自己去写个单机版的程序，写个逻辑：无非就是读这个文件一行,然后把那个地方截取出来，截取出来之后，然后可以把它放到一个HashMap里面，用Map去重，看到一条新的URL ,就把它put进去，然后+1，如果下次看到再有就直接+1,没有就put进去，单机版的话逻辑是很好实现，但是数据量一大，你觉得单机版本还能搞定吗？

首先2T的文件，你放在单机上可能存不下来，如果再他多一点呢？比如几千个文件，几十个T，单机存都存不下，那么存在哪里-------hdfs上。

因为放在HDFS上可以放很多很多，比如说HDFS上有100个节点，每个节点上能耐挂载8T的硬盘，那就有800T，800T，你每个文件存3个副本的话，耗费了大概6个T的空间.

但是你一旦放到HDFS上就有一个问题：你的文件就会被切散了，被切散到很多的机器上，这个时候，你再对它们进行统计，这个时候，按照原来的逻辑，会不会出现问题？

你的任何一个节点上存的是某个文件的某些块，假设你是在那台机器上去做统计的话，你统计到的永远是局部的数据，那你专门写一个客户端，我的程序运行在这个客户端上，我去读数据，读一点统计一点，到把整个文件都读完了，统计结果也就出来了，问题是那样的话，你的程序又变成了一个单机版的，那你的内存也就不够，因为你要第一点进来统计一点，是不是要保存一些中间数据，那你可能内存也不够了，而且你因为是一个单机版的程序，所以你的速度是不是也很慢，而且你还要不断的从网络里面去拿那些数据，也会很慢，所以这个时候呢？你专门写一个客户端去做统计，肯定是不合适。

那你是不是应该把你的程序分发到集群的每一台DN上去做统计，也就是把运算往数据去移动，而不是把数据移动到运算，把我的运算逻辑移动到数据那端去，数据在哪里，我就在哪里运算，但是这也有一个问题，因为运算也变成了一个分布式的了，你的每一份运算结果都只是局部的结果，那么这个时候也存在问题：

1.你的代码怎么实现分发到很多机器上去运行，这件事情谁帮你做，如果是要你自己写程序的话，你是不是得有个U盘拷你的jar包，一个计算一个计算的去拷，拷完之后再启动，每个机器都启动jar,等你启动最后一台的时候，前面那台已经运行完了，最后一台才刚开始启动，这个工作你用手动去做是不是不合适啊？所以当你把一个简单的逻辑，变成这种分布式运行的时候，你发现很多问题就来了：

1）我的代码怎么分发，怎么配置启动环境，怎么启动起来，这个是不是得有一个庞大的系统去做，也就是说你应该额外开发这么一个叫做资源分发和Java启动程序这么一个配置 的系统，这个系统你会吗？写得出来吗？你要是写的话，是不是还得花很多时间，你还要写很多东西，因为你现在的Java不一定是擅长那个领域的 ，那这个耗费的代价就很大了

2）那个数据，比如刚才那个日志数据，是放到HDFS上面去了，但是不代表HDFS上的每一台DN上面都有这一部分数据里面的内容，因为我们这个集群很大，你这个文件存进去的时候可能只占了其中的30台节点，其中某30台节点上有你这些文件，其他节点上个根本就没有你这些文件，那我们的代码，运行逻辑，最好是放到那30台上面去做统计，你放到其他的那些机器上，它可以运行，但是它的数据必须来源于网络，是不是效率会比较低，也就是说你的代码究竟分发到哪些机器上去运行，是不是也要一个策略的问题，那么这个策略是不是也有一定的算法，那么这个时候，你为了实现你那个简单的逻辑，就再去开发这样一个系统出来是不是也是很大的开发量，再考虑一个问题，假如刚才那两个工作你都做完了，你的代码真的成功的在那30台机器上跑起来了，跑起来之后，其中假设有一台机器宕机了，那么你统计的那一部分局部数据是不是也就没有了，那个局部结果也就没有了，那个局部结果没有，假设你有个汇总的结果还正确吗？没有意义了，也就是说你还得解决一个问题，就是你时时刻刻得却监控着你的程序运行情况，那个节点正常，哪个节点不正常，这个问题也是很复杂的，假设这个问题 你也解决了，还有一个问题：

刚才你的逻辑只是统计出中间结果，这个时候是不是还得汇总啊，汇总就是意味着，你要在那30台节点之间结果里面才能汇总，要么把它们全部调到一台机器上就能进行汇总，但是你调到一台机器上汇总的话，你那一台机器的负载是不是会很高，对吧？假设我调到多台机器汇总，逻辑就变得复杂了，比如说，只要是你们那30台机器上统计，每台机器上的那个URL有多少条，你又把那个所有那个URL的数据全部汇总到某个汇总节点，假如有两个URL，哪个URL分发到那个节点上进行汇总，这个策略是不是也会变得很复杂了，那你还得去做个中间数据的调度系统，那也很麻烦。

那这样的话，我们就发现，哪怕是一个很简单的东西，你也要把它变成一个分布式运行的程序，是不是面临很多很多其他的问题，跟我们逻辑无关的问题，往往这些问题要比解决那个逻辑要复杂得多，那么这些问题解决不是我们擅长的，我们大量的普通程序员还没达到那些程度，这么复杂的问题要写出来是不是很麻烦呢？你不能要求每个程序员都能达到那个功力把，我们不过就是写个简单的逻辑统计这个文本里面哪个URL出现的总次数，很简单的东西，所以呢，MapReduce才是我们这些普通程序员的福音。

就是说当我们面临海量数据处理的时候，那个逻辑也许很简单，但是面临海量数据处理，要我们这个 逻辑代码变成分布式运行，就会变得很复杂，而那些很复杂的事情又不是我们关心的，我关心的只是那个逻辑，那这个时候，就有人把你不擅长的而且又必须解决的，而且跟你的逻辑关系又不大的那些东西全部给封装起来，那么这个时候，我们是不是就直接写逻辑了，就会MapReduce的框架和Yarn，这两个是不是做运算的，由这两个框架把我们刚才讲的那些东西全部封装起来，这个就是MapReduce产生的背景，就是这个问题。

总结
把我们很简单的运算逻辑很方便的扩展到海量数据的场景下分布式运算，所以MapReduce程序对我们程序员来说很简单，因为它把那些东西都给封装起来了，你只要写业务逻辑，写业务逻辑还不擅长吗？业务逻辑大部分就是处理文本，处理字符串，我们学的大部分逻辑里面，大部分都是在处理这个问题：处理文本、处理字符串、查询数据库是不是得到一些东西啊。查询一下数据库，处理一下字符串，输出结果，而这个逻辑本身 不用你太多的分布式细节 ，你只要把逻辑写出来就可以了，但是你写MapReduce的时候，必须要符合人家编程的规范，你不能你的写法写，他按他的写法写，每个人的写法都不一样，那MapReduce也没法给你去分发和运行，所以你也要符合他的规范，怎样才算符合规范呢？

就说你的代码，你的任意一个逻辑实现都要分成这么两个步骤：
1)Map
2)Reduce

比如说我们统计日志文件里面，相同URL出现的总次数
如下图：

例子：