Mapreduce汇总大全

问题导读：
1、MapReduce和并行数据库，朋友还是敌人？

2、MapReduce失去了哪些特性？

3、如何整合Cassandra与Hadoop MapReduce？




【一】MapReduce基础
MapReduce 程序是设计用来并行计算大规模海量数据的，这需要把工作流分划到大量的机器上去，如果组件(component)之间可以任意的共享数据，那这个模型就没 法扩展到大规模集群上去了（数百或数千个节点），用来保持节点间数据的同步而产生的通信开销会使得系统在大规模集群上变得不可靠和效率低下。


【二】整合Cassandra与Hadoop MapReduce
看到这个标题，大家一定会问了。这个整合如何定义？
我个人认为，所谓的整合是指：我们可以编写MapReduce程序，从HDFS中读取数据然后插入到Cassandra中。也可以是直接从Cassandra中读取数据，然后进行相应的计算。
从HDFS中读取数据然后插入到Cassandra中
对于这种类型，我们可以按照以下几个步骤来操作。
1 将需要插入Cassandra的数据上传到HDFS中。

2 启动MapReduce程序。
这种类型的整合其实和Cassandra本身没有什么联系。我们只是运行普通的MapReduce程序，然后在Map或者Reduce端将计算好的数据插入到Cassandr中。仅此而已。
直接从Cassandra中读取数据，然后进行相应的计算
这个功能是在Cassandra0.6.x版本中添加上去的。其可以从Cassandra直接读取MapReduce需要的数据，实现对于Cassandra的全表扫描的功能。
操作步骤如下：
1 在MapReduce程序中指定使用的KeySpace，ColumnFamily，和SlicePredicate等和Cassandra相关的参数。（关于这些概念，可以参考《大
Cassandra数据模型》和《谈谈Cassandra的客户端》）
2 启动MapReduce程序。
这种类型的整合和从HDFS读取数据的整合相比，还是有许多不同的，主要有下面几点区别：
1 输入数据来源不同：前一种是从HDFS中读取输入数据，后一种是从Cassandra中直接读取数据。
2 Hadoop的版本不同：前一种可以使用任何版本的Hadoop，后一种只能使用Hadoop0.20.x
整合Hadoop0.19.x与Cassandra0.6.x
在Cassandra0.6.x中，默认实现的是与Hadoop0.20.x的整合，我们无法直接在Hadoop0.19.x中使用。
所以，要实现这个目标，我们第一步需要做的事情是，修改Cassandra的源代码，提供一个可以在Hadoop0.19.x中使用的功能。
想要进行这项测试，我们可以按照如下步骤来进行：
1 下载修改后的代码。
2 在MapReduce中指定如下内容（注意，这里的class使用的package都是com.alibaba.dw.cassandra.hadoop下面的）：

ConfigHelper.setColumnFamily(conf, Keyspace, MemberCF,
                "/home/admin/apache-cassandra-0.6.1/conf");
        SlicePredicate predicate = new SlicePredicate().setColumn_names(Arrays.asList("CITY"
                .getBytes(UTF8), "EMPLOYEES_COUNT".getBytes(UTF8)));
        ConfigHelper.setSlicePredicate(conf, predicate);
        ConfigHelper.setRangeBatchSize(conf, 512);
        ConfigHelper.setSuperColumn(conf, "MemberInfo");
复制代码

3 确保每一台运行MapReduce的机器的指定目录与MapReduce程序中设定的storage-conf.xml文件路径一致。
4 运行MapReduce程序。
存在的问题与改进
在实际的使用中，我们会发现Map端会出现这样的错误信息：

java.lang.RuntimeException: TimedOutException()
    at com.alibaba.dw.cassandra.hadoop.ColumnFamilyRecordReader$RowIterator.maybeInit(ColumnFamilyRecordReader.java:125)
    at com.alibaba.dw.cassandra.hadoop.ColumnFamilyRecordReader$RowIterator.computeNext(ColumnFamilyRecordReader.java:164)
    at com.alibaba.dw.cassandra.hadoop.ColumnFamilyRecordReader$RowIterator.computeNext(ColumnFamilyRecordReader.java:1)
    at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:135)
    at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:130)
    at com.alibaba.dw.cassandra.hadoop.ColumnFamilyRecordReader.next(ColumnFamilyRecordReader.java:224)
    at com.alibaba.dw.cassandra.hadoop.ColumnFamilyRecordReader.next(ColumnFamilyRecordReader.java:1)
    at org.apache.hadoop.mapred.MapTask$TrackedRecordReader.moveToNext(MapTask.java:192)
    at org.apache.hadoop.mapred.MapTask$TrackedRecordReader.next(MapTask.java:176)
    at org.apache.hadoop.mapred.MapRunner.run(MapRunner.java:48)
    at org.apache.hadoop.mapred.MapTask.run(MapTask.java:342)
    at org.apache.hadoop.mapred.Child.main(Child.java:158)
Caused by: TimedOutException()
    at org.apache.cassandra.thrift.Cassandra$get_range_slices_result.read(Cassandra.java:11015)
    at org.apache.cassandra.thrift.Cassandra$Client.recv_get_range_slices(Cassandra.java:623)
    at org.apache.cassandra.thrift.Cassandra$Client.get_range_slices(Cassandra.java:597)
    at com.alibaba.dw.cassandra.hadoop.ColumnFamilyRecordReader$RowIterator.maybeInit(ColumnFamilyRecordReader.java:108)
    ... 11 more
复制代码

引起这样的问题的原因就在于使用Thrift API从Cassandra读取数据失败了。
所以我们可以优化这段代码，提供想要的错误处理功能来提供程序的可用性。
另一个做法是修改Cassandra的配置，将RPCTimeout的时间调长。


【三】在云中使用 MapReduce 和负载平衡
云计算旨在通过 Internet 提供随需应变的资源或服务，通常视数据中心的规模和可靠性水平而定。MapReduce 是一个为并行处理大量数据而设计的编程模型，它将工作划分为一个独立任务组成的集合。它是一种并行编程，由某种功能随需应变的云（如 Google 的 BigTable、Hadoop 和Sector）提供支持。


【四】MapReduce和并行数据库，朋友还是敌人？
在 2010年1月的ACM上，有两篇文章非常吸引人注意。一篇文章是Google的Jeffrey Dean、Sanjay Ghemawat发表的标题为《MapReduce:一个灵活的数据库处理工具》，另一篇文章是Michael Stonebraker、Daniel  Abadi、 David J. DeWitt、Sam Madden、Erik Paulson、Andrew Pavlo、Alexander、Rasin等人发表的《MapReduce和并行数据库：是朋友还是敌人？》。这两篇文章让我想起去年初Michael Stonebraker等人就MapReduce发表的一些评论而导致了一次MapReduce和数据库系统的大辩论。那篇文章的标题是《MapReduce：一个巨大的倒退》。这次辩论双方则准备了丰富的实践和实验案例。看上去更加有趣也更加有说服力。
以下“正方”代表坚持并行数据库解决方案的Andrew Pavlo、 Michael Stonebraker等，而反方则是Google的MapReduce（下文简称MR）的拥趸Jeffrey Dean、Sanjay Ghemawat等。


正方抛出观点
2009 年Andrew Pavlo等人发表了一篇标题为《大规模数据分析的方法对比》（http://database.cs.brown.edu /projects/mapreduce-vs-dbms/）的文章，里面对比了数据库和MR两种大规模数据分析方法的对比。通过对比流行的MR软件 Hadoop和一种并行数据库之间的架设、使用和性能等方面的异同，指出MR并不是解决大规模数据分析的好方法，其在性能、易用性等方面有诸多问题：
一、MR没法用索引，总是对数据进行完全扫描；
二、MR 输入和输出，总是文件系统中的简单文件；
三、MR需要使用不高效的文本数据格式。


反方接招
对于正方第一个观点，反方如此应对：“错了！MR的输入本身可以是数据库的输出，所以，我们是可以用索引的。另外一个例子是MR从BigTable里面读取数据，如果数据落在一个行范畴里面，当然是可以用索引的。而且，在很多需要处理的数据里头，比如Web Server的日志，经过轮转之后天然就有索引（文件名包含时间戳）。”
对于第二个观点，反方认为：“现存的很多MR系统，本身就是一个异构环境，用户的数据可能存储在关系数据库里头，而其处理结果可能会记录在文件系统里头。而且，这样的环境可能会进化，用户的数据会迁移到新的系统里。而MR可以非常便利地在这些环境上运行。更进一步，用户可以扩展这些存储，比如分布文件系统、数据库查询结果，存储在BigTable里面的数据，结构化的数据（B-tree文件等）。对于这些场合，单个MR处理就可以很容易地捏合它们。”
对于第三个观点，反方认为：“这点的确很精辟。很到位，不过这个因素是取决于具体的实现的，比如在Google的MR实现里，有个 Protocol Buffer层，可以对输入的数据进行格式定义，因此就可以直接适用二进制类型，而不用有额外的格式转换的开销，在我们的测试里，原来要花1731ns的一个格式分析，用Protocol Buffer预定义之后，只要20几ns。所以，如果实现得足够好，我们认为MR系统不会只能处理文本格式的数据，而是可以处理二进制数据，因此效率还可以极大提升。”除了这些之外，反方还抛出了几块大砖头，等着正方接招：
MR与存储系统无关，而且可以不用把数据装载到数据库就直接处理之，在很多场合下，在数据库系统把数据装载到数据库里头并且完成一次分析所花的时间，用MR的方式都能完成50次分析运算了。
用MR可以表现更复杂的数据变换规则，很多反方的意见都是实现相关的，是针对一些不好的MR的实现做出来的，因此站不住脚。
反方的最有力的证据就是，在Google里头跑得很好的一万多各种MR应用，从网页分析到索引建立，从日志分析到网图计算等等。


正方的回应
作为正方，Michael Stonebraker 教授等人在同一期杂志上发表了另外一篇文章，很有趣的是刚好排在反方的文章之前。这篇文章以批评与自我批评的方式提出了若干有趣的观点，其中有些刚好是对反方的一个回应：
MR系统可以用于（注意：不是胜出）下列场合：
    1.ETL类的应用：从多个不同的源读取日志信息；分析以及清理日志数据；执行复杂的变换，比如“会话转换”；决定存储什么样的属性以及把信息装载到DBMS或者其他存储引擎中；
    2.复杂分析应用：这种挖掘类型的应用需要对数据进行多步骤的计算和处理，通常一个程序的输出会是另外一个程序的输入，因此很难用单个SQL语句来表示，这种应用场合下，MR是很好的候选方案；
    3.半结构化数据：因为MR不需要对数据的存储进行格式定义，因此MR比较适合处理半结构化数据，这些数据通常都是一些键值对。这些场合下，MR非常适合做 ETL的事情，如果并行数据库选用了面向列的存储方案，并且查询大多是分析性的查询，那么数据库方案依然是更好些的选择（正方有试验结果支撑）；
    4.快速实施的系统：并行数据库最大的缺点就是架设和调优难度要比MR大得多，虽然一旦架设、调优完毕，并行数据库系统表现出远胜MR的性能和特性，但对大多数急于上手的入门级用户来说，并行数据库系统的学习门槛显然要高得多。最后就是成本，虽然并行数据库在性能和应用编写简易性方面明显胜于MR系统，但现实世界里确实还缺乏完善和健壮的低成本开源解决方案，这点是MR最大的优点。数据库社区显然在这个方面输了一阵。


正方认为，把适合于数据库的工作交给MR去做结果其实并不好。在正方的试验里，证实了MR更加适用于做数据转换和装载的（ETL）工作，在这些场合，MR可以成为并行数据库的良好补充，而不是替代品。为了证明上述论点，正方做了一些有趣的试验，试验对比的双方是并行数据库集群和Hadoop集群，试验的主要内容有：
    1.Grep任务：两个系统都对分布在100个节点上的1TB数据进行无法使用排序和索引的Grep处理，按说应该是面向更低层数据接口的Hadoop胜出，结果却出乎人们的意料，是并行数据库快了两倍左右。

    2. Web 日志分析：两个系统都对分布在100个节点上的2TB数据进行类似GROUP BY的操作，对每个来源IP的点击和计费记录进行统计运算，这也是一个对所有数据进行扫描的操作，没有办法使用排序和索引。所以，直觉认为直接操作数据文件、更低层的Hadoop应该胜出，结果依然让人大跌眼镜，并行数据库胜出面甚至比Grep任务还要大。

  3.连接（Join）任务的性能：把上面测试的用户访问日志和另外一个包含18M URL的100GB的PageRank表连接起来。这个连接有两个子任务，分别对两个数据集进行复杂的计算。第一个子任务连接在一个特定用户数据范围内找出收入最高的IP地址，找到后再由第二个子任务连接计算这个范围内被访问页面的平均PageRank。数据库对付这种设计复杂连接的分析性查询是非常在行的。最后的结果是并行数据库比Hadoop快了21~36倍。
针对上面的结果，正方做了一些分析，认为这些差距的来源主要来自于具体实现，而非并行数据库模型和MR模型之间的差异。比如，MR可以使用并行数据库为低层的存储，所以所有分析都针对现实中两种模式的具体实现。正方分析了导致差距的几个实现相关的架构原因：
    1. 数据解析。Hadoop需要用户代码来对输入的文本数据进行解析，然后再加以计算，而这个解析是每个Map和每个Reduce过程都要进行的，相比之下，并行数据库系统只在装载数据的时候解析一次数据，中间计算的开销大大降低。

    2.数据压缩。并行数据库系统使用数据压缩后，性能显著提升，而MR系统却不能，甚至倒退，在反方的试验中，也没有使用压缩，这方面让人感到奇怪，分析出来的可能原因是商业数据库系统对压缩的调优做得比较好，很多压缩算法，比如gzip，未经调优的话，在现代的CPU上，甚至都不能提供什么优势。

    3. 管道化。现代数据库系统基本上都是先生成一个查询规划，然后在执行的时候把计算分发到相应节点上。在该计划里一个操作符必须向下一个操作符发送数据，不管下一个操作符是否在同节点上，因此，合格数据是由第一个操作符“推送”给第二个操作符的。这就构成了良好的从生产者到消费者的流水线作业。中间状态的数据不会写到磁盘上，这种运行时的“背压”会在生产者把消费者整崩溃之前把生产者停下来。这种流水线方式和MR的实现不同，MR是把中间状态写到一个本地的数据结构中，然后由消费者“拖取”。这种本地数据结构通常是相当庞大的，虽然这种做法可以在中间步骤上设置更多检查点，从而可以有更好的容错性，但很显然也引入了新的瓶颈。

    1. 调度。在测试的并行数据库一方，查询规划是编译时生成，运行时执行。而MR的调度方案是运行时针对每个存储块，在处理节点上调度一次。这种对每个存储块一次的调度显然开销要大得多。当然，这种调度方式可以让MR适应不同的负载风格和不同性能的节点。

    2.面向列的存储。这个在对比双方的系统里都不存在。但却是并行数据库可以进一步提升的手段。
正方经过试验得出的结论是：MR和并行数据库结合是最好的方案，MR负责数据装载、转换等工作，并行数据库负责查询密集型的任务。正方最后发出的振聋发聩的呼吁是：很多事情并行数据库系统已经做得很好了，我们为什么不站在这个巨人的肩膀上？


作者结语
对于商业社会，这种争论的背后往往带着巨大的经济利益：MR和并行数据库在一定程度上重叠的使用范畴会导致不小的市场冲突，而在这种潜在冲突的情况下，把握好理论制高点是很重要的一个指导措施。
而对于学术界，避免重新发明轮子以及因为片面的适用范畴导致的学术资源不合理配置，相信也是各位大大争论的缘由。这个争论让人想起十几年前 Tanenbaum老头和Linus Torvalds之间在Kernel上的争论。十多年后来看那场辩论，Tanenbaum站住了学术和技术方向的脚跟，而Linus成就了项目的辉煌。没有对错，留给我们的是极为丰富的经验，Linus站在了Tanenbaum肩膀上，而我们站在了Linus的肩膀上。可能看完这篇对比之后，大多数同学的反应都会是：该干吗干吗，在哪好使就使啥。绝对没错，不过，我们也要从历史中学会更多经验啊！可别因为手里攥着锤子，就满世界都是钉子。虽说各有各的好处和适用范围，可事实呢？人们还是经常会因为某些新发现而被头脑发热冲击得失去了判断力：满世界都是钉子！可不是吗？想想这些年流行的种种，人们总是易于认为一个新技术可以搞定天下所有问题。
做为一个数据库用户，我多少倾向数据库大大们的意见。结合自己的实际，在很多场合下，自己会利用系统工具，如Awk、Perl等做数据并行装载的事情，不知不觉用了MR的概念，很自然也很方便。而真正的数据查询，还是喜欢高级而简单的SQL，让我去写一堆Map/Reduce过程而放弃手边的SQL工具，感觉很痛苦。感觉自己还是应该把一个东西用到极致，结合新的工具来站的更高，而不是盲目放弃。所以尽管自己经常被冠以“手拿锤子，满世界都是钉子”的头衔，但实际工作中却发现很多同学却是在实际行动中打的是MR的旗号，行的是革数据库的命之行动，在重新发明轮子的道路上越行越远，却兴致勃勃。不能不令人扼腕。在这个大讨论里，正反双方最后几乎异口同声地说出了“实现相关”的结论，貌似这个争论已经可以画上句号了。几乎可以肯定的是，MR会以各种方式越来越像数据库系统，而数据库系统会以各种方式集成MR的优点，变成前置的ETL系统/或后置的数据再处理系统。不管怎样，争论中留下的一个个闪光的要点，相信会对我们了解事物，做出判断有着巨大的帮助。

作者简介：
何伟平何伟平，Postgre-SQL中文版文档维护者，《Perl 编程》第三版译者，Linux集群管理员及数据库研究员和软件开发人员。有近十年的软件开发经验，在金融、工业和互联网等行业有着较长的经历。现供职于某互联网公司，从事大型集群管理以及技术指导方面的工作。


【五】Hadoop MapReduce扩展性的测试
主要介绍了BigCloud项目中用到Hadoop MR的子系统（包括BC-PDM、HugeTable和SearchEngine）中，在数据量大小固定或者不能确定的情况下，如何配置 Hadoop MR才能达到更高的性能。或者，如何根据数据量来确定需要多少个节点。
附件: Hadoop MapReduce扩展性的测试.pd


【六】基于Hadoop系统的MapReduce数据流优化
在Hadoop系统的实现中，Map端的输出数据首先被溢写入本地磁盘，当本机任务完成后通知JobTracker，然后Reduce端在得到 JobTracker的通知后会发出HTTP请求，利用复制的方式从相应的Map端拉回其输出。这样的方式只能等该Map任务完成后才能开始执行 Reduce任务，并且Map任务和Reduce任务的执行是分离的。
附件: 基于Hadoop系统的MapReduce数据流优化.pdf


【七】Hadoop Studio开发部署MapReduce应用
  Hadoop Studio是基于Hadoop框架的MapReduce应用集成开发和部署环境。Hadoop Studio以NetBeans模块插件的方式使用，可在NetBeans插件中心获取。开发者可以通过Hadoop Studio的可视化界面，部署分布在不同节点的计算任务，并监控MapReduce处理过程中各阶段的输入、输出以及交互过程。
  针对MapReduce任务执行过程的各要素，Hadoop Studio提供了HDFS、JobTracker以及Cluster节点的配置工具。使用Hadoop Studio配置之前，需要预先在目标机器上部署Hadoop作业执行环境，在Ubuntu Linux上的Hadoop配置过程，已有详尽教程（单节点，多节点）可供参考。
  在Hadoop Studio中对作业节点配置，首先需要定义负责数据存储的Filesystems节点，可选节点包含本地磁盘访问、HDFS文件系统和Amazon S3连接三种方式。HDFS节点的配置，需要指定NameNode节点的地址、访问端口和登录用户名，其中登录用户名为可选项。对于目前最新的r0.20 版本，Filesystems节点的端口配置由conf/hadoop-site.xml改为在conf/core-site.xml中设定。
  在Hadoop Cluster配置部分，添加远程计算节点对应的JobTracker，指定节点的地址，并在下拉列表中选择之前添加的Filesystems节点，添加的节点则会出现在Hadoop可用节点的列表中。在主节点计算任务启动之后，包含DataNode、TaskTracker、JobTracker、 NameNode、SecondaryNameNode进程。对于数据处理，集群中结点由一个NameNode和若干DataNode组成，Secondary NameNode为NameNode的备份。计算任务中，节点由一个JobTracker和若干TaskTracker组成，JobTracker负责任务调度，TaskTracker执行并行计算任务。TaskTracker须运行在DataNode上以获取用于计算的数据。
  对于已编写的计算任务，Hadoop Studio提供了简化的作业部署流程。首先在Hadoop Jobs中添加生成好的jar包（如Hadoop自带的Hadoop-*-examples.jar示例），之后选择要执行的主类并添加依赖项，并选择执行任务的目标Cluster节点和目标Filesystems后即可启动计算任务。同时，Hadoop Studio提供了实时显示的MapReduce任务工作流视图，可显示任务执行过程中的作业类型、完成情况、执行状态、起止时间、报错信息以及输出结果等内容。
  Hadoop应用开发方面，Hadoop Studio将Hadoop类库进行打包，可直接在项目中添加所有依赖项。编码过程中，Hadoop Studio为每种作业的提供了模板，并能够在代码编辑的同时自动对模板视图进行更新。
  目前Hadoop Studio支持Hadoop 0.18.x版本的Client API和Hadoop 0.20.x的Client与Server的API，并且支持不同版本Hadoop的混合使用。但Hadoop Studio目前的文档比较简单，感兴趣的朋友可以在freshmeat.net的项目站点跟踪Hadoop Studio的最新信息。


【八】Google在新的内容索引系统中放弃MapReduce
有消息表明，Google在新型网络内容索引系统——Caffeine中，将放弃以MapReduce为基础架构的分布式计算平台。
据Google高级主管Eisar Lipkovitz表示，在Caffeine中，Google的后端索引系统将从MapReduce上移除，并向Google新建的分布式数据库平台——BigTable上进行迁移。他表示，谷歌将于下月在USENIX研讨会上提交一项新的文件讨论系统。
据了解，从去年开始，Google就已经启动了代号为“Colossus”的研发计划，主要内容围绕新的分布式文件系统——Caffeine进行研发。Caffeine将创建一个新的数据库的编程模型，而这也意味着Google必须在BigTable上重建整个索引系统。
MapReduce完成历史使命
必须看到的是，在Google的直接竞争对手——Yahoo、Facebook们对MapReduce饱含热情进行研发投入的同时，Google却宣布放弃MapReduce，不得不佩服Google的勇气。
实际上，早在Caffeine建立之前，Google就建立了基于MapReduce的搜索索引系统。从本质上而言，这个索引是由序列的批处理操作组成的。它通过把对数据集的大规模操作分发给网络上的每个节点进行运算，而每个节点会周期性的把完成的工作和状态的更新报告回主计算。
Lipkovitz首先谈到了Google基于MapReduce文件索引系统处理方式。“我们必须面对一个非常庞大的数据系统，在这之前，我们需要等待8个小时的计算时间我们才能够得到计算的全结果，然后我们就会把它发布到索引系统中去。过去我们一直在不停地重复这个耗时耗力的工作。”
Lipkovitz进一步解释了Google放弃MapReduce的原因，“MapReduce仅仅是一个批处理操作方式，”Lipkovitz解释说，“一般来说你不能启动下一阶段的命令操作，直到你完成第一项操作。”
可以看到，Google之所以放弃MapReduce，是因为它并不能为谷歌提供它所想要的索引速度，特别是随着实时检索时代的到来，谷歌需要的是在几秒内刷新索引内容，而非8小时。
实际上，在过去的几年里，针对MapReduce的技术讨论可谓是褒贬不一。
麻省理工学院的数据库专家Mike Stonebraker认为，MapReduce的计算方法对于实时计算来说是很不合适的，是过时的。
“MapReduce就像是游击队员而非正规军”，Lipkovitz表示，“如果你想基于Mapreduces建立分布式文件处理系统，如果你想实现更多的操作命令，那么必然会有错误发生。况且你并不能缩短处理的时间，这是Google选择放弃Mapreduces的原因。”

Caffeine的处理原理



早前在谷歌的一篇博文中，谷歌提到了Caffeine的处理原理，“与我们的老索引技术相比，Caffeine能够提供的新网络搜索结果提高50%，最大程度收集我们提供的网络内容。无论是新闻、还是博客或论坛，一经发布，用户都能发现相关内容的链接，索引速度较以前有大幅提高。”
据了解，Google从2009年8月就开始测试Caffeine。当时，Google曾表示新索引技术将是自2006年以来的重大变革。速度和综合性是新技术关注的目标。
Google曾表示，新系统需与网络内容的爆炸性增长保持同步，过去两年中，博客、视频和社交媒体技术都蜂拥至网络。借助Caffeine，Google将加快索引次数的更新，对一小部分网络进行消化，而不是对整个网络重新索引并更新索引内容。
Google软件工程师卡莉·格兰姆斯（Carrie Grimes）在博客中称：“我们将把Caffeine列为未来考虑重点，不仅使之索引更多新结果，还要将之打造为适应网络消息增长的速度更快、理解力更高的搜索引擎，为用户提供相关度更高的搜索结果。”
关于“Colossus”计划
“我们需要一个新的计算框架”，Lipkovitz说，这使工程师能够在BigTable上编写代码，而该系统是基于“Colossus”建立的分布式存储平台——也被称为GFS2。
“原有的基于MapReduce的文件系统，不能达到Google所需要的计算规模。”
据了解，“Colossus”是专门设计BigTable的开发计划，基于这个原因，它并不针对传统的分布式存储平台应用。换句话说，它是专为建立新的Caffeine搜索索引系统而用的，虽然它可能会在Google的其它内容所服务，但其并未跨越整个谷歌的基础设施系统。
在Google的实时搜索引擎Instant的发布上，谷歌著名的工程师Ben Gomes表示，Caffeine并未在Instant架构中，但它的确有助于帮助把数据处理实现“分布”式搜索服务。
Lipkovitz同时指出，MapReduce并非意味着消亡，在Caffeine中，仍然有基于MapReduce的批处理应用，以及全球尚有其它的基础设施。
而在Caffeine的诞生之前，索引系统是谷歌最大的MapReduce的应用程序。


【九】如何在Oracle内使用Hadoop与MapReduce
此文中提供两篇Oracle文档链接， 介绍如何在Oracle内使用Hadoop与MapReduce，在与外界交互方面，Oracle做的还是很不错的。
之前Exadata关于列存储的融合，集成Hadoop与MapReduce到Oracle中都表明了这一点。
如何使用Paralleled Pipeline function来在Oracle中集成MapReduce。
由于原文没有给出直接下载文档，仅仅给出一个网址：http://www.oracle.com/technetwor ... ehousing/index.html

介绍如何在Oracle数据库中访问存储在Hadoop集群上的数据，虽然此文中介绍的是HDFS，但此方法也可应用到其他分布式文件系统上。
Integrating Hadoop Data with Oracle Parallel Processing (PDF)同样没有给出直接下载链接，


【十】MapReduce：一个重大的倒退
这篇文章是由databasecolumn的几个数据库大牛写的，简要的介绍了MapReduce以及将其与现代数据库管理系统进行了对比，并指出了一些不足之处。本文纯属学习性翻译，从多方面来了解MapReduce，不代表完全赞同原文的观点。请读者也辩证的看。
一月八号，一个数据库专栏的读者询问我们关于对新的分布式数据库研究成果的意见。我们在这结合MapReduce谈谈我们的看法。现在是讨论这个问题的不错的时机，因为最近媒体上到处充斥着新的革命所谓“云计算”的信息。这种模式需要利用大量的（低端）处理器并行工作来解决计算问题。实际上，这建议利用大量的低端处理器来构建数据中心，而不是利用数目少的多的高端服务器来构建。
举例来说，IBM和Google已经宣布计划用1000台处理器构建的集群提供给部分大学，传授学生们如何使用MapReduce工具在这些集群上编程。加利福尼亚大学伯克利分校甚至打算开设使用MapReduce框架编程的课程。我们对MapReduce支持者大肆炒作它如何如何能够开发更加具有扩展性，以及数据密集型程序感到震惊。MapReduce可能在某些特定类型的通用计算上是个不错的想法，但是对于数据库社区来说：
1.从大规模数据应用程序模型来说是一个巨大的倒退。
2.不是一个最优实现，因为它使用蛮力来代替索引。
3.一点都不新奇，它只是实现了一个特定的25年前就有的众所周知的技术。
4.失去了大部分目前数据库管理系统的特性。
5.不能兼容所有目前数据库管理系统用户已经依赖的工具。
首先我们将简要的讨论下MapReduce到底是什么，然后我们将就上面5点进行更深层次的讨论。

MapReduce是什么？
MapReduce基础出发点是很易懂的。它由称为map和reduce的两部分用户程序组成，然后利用框架在计算机集群上面根据需求运行多个程序实例来处理各个子任务，然后再对结果进行归并。
Map程序从输入流中读取一组“记录”，然后对记录进行需要的过滤或者转换，然后输出一组记录(key,data)。当map程序生成输出记录时，一个分割方法将记录划分为M个不相交的块并赋予一个键值。这个分割方法一般是一个hash函数，只要这个决定性的函数能够满足就行。当一个块被填充后，它将写入磁盘，map程序结束的时候每个块都将输出M个文件。
通常情况下，将有多个map的程序实例运行在计算机集群的不同的节点上。每个map实例都将由MapReduce调度程序分配一个不重复的输入文件来独立执行。如果有N个节点参与map程序执行，那么N个节点中的每个节点都将有M个文件存储在各自的磁盘上，也就是说，总共将有N*M个文件。Fi,j, 1 ≤ i ≤ N, 1 ≤ j ≤ M。
其中有个值得注意的关键点是每个map实例都必须使用一个相同的hash方法。这样，所有的拥有相同hash值的输出记录才会写入相应的输出文件。
MapReduce的第二个阶段就是执行M个reduce的程序实例。Rj, 1 ≤ j ≤ M.每个reduce实例Rj的输入文件由文件 Fi,j组成,1 ≤ i ≤ N。还有一个值得注意的是：所有从map阶段输出的拥有相同hash值的记录，无论是哪个map实例生成的，都将由一个相同的reduce实例处理。在map-reduce框架收集整理之后，所有的输入记录都将根据它们的键值(key)编组然后提供给reduce程序。跟map程序一样，reduce程序也可以做任意的计算。所以，你可以对输入的记录做任何你想要的事情。举例来说，可能会对记录的别的字段进行一些附加的计算。每个reduce实例都可以将记录写入输出文件，只要是MapReduce计算所需要的结果。
用SQL来做类比，map象聚合(aggregate)查询中的group-by子句。Reduce则类似计算group-by起来的行的聚合函数(例如求平均等)。
现在我们基于这个计算模型来讨论上面提到的五点：

1.MapReduce是一个数据库存取的退步
做为一个数据处理模型，MapReduce呈现出了一个巨大的退步。数据库社区从IBM在1968年第一次发布IMS以来的四十年中学到了以下三个经验：
*结构描述是好的。
*将结构描述从程序中分离是好的
*高阶的访问语言是好的
MapReduce没有吸引上面三个经验中的任何一个，而且还退步到了现在数据库管理系统发明前的60年代。
数据库管理系统社区学习到的关于最重要的结构描述就是：记录的字段和它的数据类型都记录在存储系统中。更重要的是，数据库管理系统的运行时可以保证所有的记录都遵守结构描述。这是避免将垃圾数据添加到数据集中的最好的方法。MapReduce没有这样的方法，也没有避免将垃圾数据添加到数据集中的控制。一个毁坏的数据集可以悄无声息的破坏整个使用这个数据集的MapReduce程序。
将数据描述与程序分离也很关键。如果开发者想在一个数据集上开发一个新的程序，他必须先去了解记录结构。在现代数据库管理系统中，结构描述存储在系统目录中，而且可以被用户用SQL查询来了解它的结构。与此相反的是，如果数据描述不存在，或者隐藏在程序之中，开发者要了解这个数据结构必须通过检查原有的代码。这个工作不仅仅是非常沉闷的，而且开发者必须先找到这个程序的源代码。如果没有相应的结构描述存在，后面的这个沉闷的问题将在所有的MapReduce程序中存在。
在1970年数据库管理系统社区，关系型数据库支持者和数据系统语言协会(Codasyl)支持者进行了一场“剧烈的辩论”。其中一个最大的争议是数据库管理系统的访问程序以何种方式访问：
*用统计来获取你想要的数据(关系型的观点)
*提供一个算法来进行数据访问(Codasyl的观点)
争论的结果已经是古代史了，但是整个世界都看到了高阶语言的价值以及关系型系统的胜利。以高阶语言的形式编程更加容易编写，易于修改，而且方便一个新来者的理解。Codasyl被批判为“以汇编语言的形式来对数据库管理系统进行访问”。MapReduce程序员有点类似Codasyl程序员。他们用低阶的语言来处理低阶记录。没有人提倡回归汇编语言，类似的，不应该强制任何人用MapReduce来编程。
MapReduce提倡者可能会反对说他们的数据集没有数据描述的假设。那么我们解除这个断言。在从输入数据记录中提取一个key时，map方法在每个输入记录中至少依赖一个存在的数据字段。相同Reduce方法的持有者从接受到的处理数据中计算一些值。
基于Google的BigTable或者Hadoop的Hbase来编写MapReduce程序并不会真正重大的改变这种状况。在相同的表中使用一种自描述元组格式（行号，列名，值）确实可以拥有不同的架构。但是，BigTable和Hbase并没有提供逻辑上的独立。以视图机制举例来说，视图有一个明显的简化作用，当逻辑数据描述（logic schema）改变后，仍保持程序运行。

2.MapReduce是一个粗燥的实现
所有现在数据库管理系统使用hash或者B-tree来索引加快对数据的访问。如果一个用户在查找一个记录集的子记录集（比如雇员中谁的薪水在10000或者谁在鞋生产部门），那么他可以使用索引来有效的缩减查找范围。另外，还提供了一个查询优化器来决定到底是使用索引还是进行一个残忍野蛮的顺序查询。
MapReduce没有索引，理所当然的只能使用蛮力来作为处理选项。而不管索引在当前情况下是否是一个最好的访问机制。
一个值得争论的是，MapReduce提出的自动的在计算机集群中提供并行计算的价值。其实这个特性在1980年时代就被数据库管理系统研究社区研究过了，多个型被提出来，比如Gamma，Bubba和Grace。商业化的利用这些思想在系统则在80年代末期，比如Teradata。
概括起来说，在前20年已经出现了高性能，商业化的，面向网格计算机群的SQL引擎（带结构描述和索引）。MapReduce跟这些系统相比并没有那么好。
MapReduce同时存在很多底层的实现问题，特别是数据交换和数据斜交的情况。
一个因素是MapReduce支持者好像没有注意到关于数据斜交的问题。就像在“平行数据库系统：未来的高性能数据库系统”中提到的，数据斜交是构建成功高扩展性并行查询系统的巨大障碍。这个问题重现在map阶段，当拥有相同键的数据拥有大幅度差异的时候。这个差异，反过来导致某些reduce实例花费比其它实例更长甚至常很多的时间来运行。结果就是计算的运行时间由速度最慢的那个reduce实例决定。平行数据库社区已经广泛的研究了这个问题并且拥有了成熟的，MapReduce社区可能愿意采纳的解决方案。
还有第二个严重的性能问题被MapReduce支持者掩盖了。回忆N个map实例中的每个实例都将生成M个输出文件。每个都分发给不同的reduce实例。这些文件都被写入本地硬盘以备map实例使用。如果N是1000，M是500，那么在map阶段将生成500000个本地文件。当reduce阶段开始，500个reduce实例必须读取1000个输入文件，必须使用类似FTP的协议将每个输入文件从各个map实例运行的节点中获取（pull）过来。在100秒内所有reduce实例将同时的运行起来，不可避免的会发生两个或者更多个reduce实例企图并行的从同一个map节点中获取输入文件，包括大量的磁盘搜索，当超过因子20时，将极大的降低磁盘的有效传输率。这就是为什么并行数据库系统不实现分割文件，而使用推(push to sockets)来代替拉(pull)。因为MapReduce通过实现分割文件来获得优秀的容错性，不好说如果MapReduce框架修改成使用推(push)模型是否会成功。
鉴于实验评估，我们严重的怀疑MapReduce在大规模应用中会表现的很好。MapReduce的实现者还需要好好的研究过去25年来并行数据库管理系统的研究文献。

3.MapReduce并不新奇
MapReduce社区看起来感觉他们发现了一个全新的处理大数据集的模型。实际上，MapReduce所使用的技术至少是20年前的。将大数据集划分为小数据集的思想是在Kitsuregawa首次提出的“Application of Hash to Data Base Machine and Its Architecture”的基础上发展出来的一个新的连接算法。在“Multiprocessor Hash-Based Join Algorithms”中，Gerber演示了如何将Kitsuregawa的技术扩展到使用联合分区表，分区执行以及基于hash的分割来连接并行的无共享集群。DeWitt演示了如何采用这些技术来执行有group by子句以及没有group by子句的并行聚合。DeWitt和Gray描述了并行数据库系统以及他们如何处理查询。Shatdal和Naughton探索了并行聚合的替代策略。
Teradata已经出售利用这些技术构建的数据库管理系统20多年了，而这些技术正是MapReduce一伙声称的发明的技术。
当然MapReduce提倡者将毫无疑问的声称他们编写的MapReduce函数实现他们的软件与使用并行SQL实现有多么大的不同，我们必须提醒他们，POSTGRES已经在80年代中期就支持了用户自定义函数以及用户自定义聚合。本质上来说，从1995年Illustra引擎开始算，所有现代数据库系统都提供了类似的功能很长一段时间了。

4.MapReduce失去了很多特性
所有下面的特性都被现在的数据库管理系统提供了，而MapReduce没有：
*批量导入    —— 将输入数据转化成想要的格式并加载到数据库中
*索引        —— 如上文所述
*更新        —— 改变数据集中的数据
*事务        —— 支持并行更新以及从失败的更新中恢复
*完善的约束  —— 防止垃圾数据添加到数据集
*完善的引用  —— 类似FK，防止垃圾数据的存在
*视图        —— 底层逻辑数据描述可以改变但不需要重写程序
简单的说来，MapReduce只提供了现在数据库管理系统的函数性功能。

5.MapReduce与现有的数据库管理系统工具不兼容
一个现代的SQL数据库管理系统都拥有如下可用的工具：
*报表              —— (比如水晶报表) 将数据友好的展示给人
*商业智能工具      —— (比如Business Objects or Cognos)允许在数据仓库中进行特定查询
*数据挖掘工具      —— (比如Oracle Data Mining)允许用户在大数据集中发现数据规律
*复制工具          —— 允许用户在不同的数据库中进行复制传输
*数据库设计工具    —— 帮助用户构建数据库
MapReduce不能使用这些工具，同时它也没有自己的工具。直到它能与SQL兼容或者有人编写了这些工具，MapReduce仍然在端到端的任务中显得十分困难。

总结
看到一个庞大的社区参与到设计和实现可扩展的查询处理技术中是值得振奋的。但是，我们认为他们不应该忽视超过40年的数据库技术的经验。——特别是拥有巨大优势的数据描述模型以及物理数据与逻辑数据互相独立；描述性的查询语言（比如SQL）；提供设计，实现，以及维护程序。此外，计算机科学社区不应该孤立起来而应该多读读别的社区的技术文献。我们鼓励好好的研究下近25年来的并行数据库管理系统的技术文献。最后，在MapReduce达到现代数据库管理系统之前，还有很多的没实现的特性以及必须的工具需要添加。
我们完全的理解利用数据库来解决他们的问题是可以的。数据库社区意识到数据库系统解决他们的问题使用起来操作过于“复杂”。数据库社区也从MapReduce提供的优秀的容错机制中学到了不少的有价值的东西。最后我们注意到一些数据库的研究者开始探索以MapReduce框架为基础来构建可扩展的数据库系统，yahoo!研究中心的Pig项目就是其中一个努力的结果。


附件资料大全下载：
1、MapReduce资料大全