标题：MapReduce:Simplified Data Processing on Large Clusters（简化大集群上的数据处理）
相关文件：mapreduce-osdi04.pdf（中文翻译mapreduce-osdi04.docx）
第一作者：JeffreyDean
单位：Google
日期：2004
问题：提出了MapReduce计算架构及其实现，解决了海量数据的分布式计算处理问题。
特征：MapReduce合并了两种经典函数：映射（Mapping），对集合里的每个目标应用同一个操作。即，如果你想把表单里每个单元格乘以二，那么把这个函数单独地应用在每个单元格上的操作就属于mapping。化简（Reducing），遍历集合中的元素来返回一个综合的结果。即，输出表单里一列数字的和这个任务属于reducing。
大规模数据处理时，MapReduce在三个层面上的基本构思
如何对付大数据处理：分而治之。对相互间不具有计算依赖关系的大数据，实现并行最自然的办法就是采取分而治之的策略。上升到抽象模型：Mapper与Reducer
MPI等并行计算方法缺少高层并行编程模型，为了克服这一缺陷，MapReduce借鉴了Lisp函数式语言中的思想，用Map和Reduce两个函数提供了高层的并行编程抽象模型，上升到构架：统一构架，为程序员隐藏系统层细节
MPI等并行计算方法缺少统一的计算框架支持，程序员需要考虑数据存储、划分、分发、结果收集、错误恢复等诸多细节；为此，MapReduce设计并提供了统一的计算框架，为程序员隐藏了绝大多数系统层面的处理细节
如何具体完成这个并行计算任务所相关的诸多系统层细节被隐藏起来,交给计算框架去处理：从分布代码的执行，到大到数千小到单个节点集群的自动调度使用
缺点：抽象层次低，需要手工编写代码来完成，使用上难以上手。
只提供两个操作，Map和Reduce，表达力欠缺。
一个Job只有Map和Reduce两个阶段，复杂的计算需要大量的Job完成，Job之间的依赖关系是由开发者自己管理的。
处理逻辑隐藏在代码细节中，没有整体逻辑
中间结果也放在HDFS文件系统中
ReduceTask需要等待所有MapTask都完成后才可以开始
时延高，只适用Batch数据处理，对于交互式数据处理，实时数据处理的支持不够
对于迭代式数据处理性能比较差
不可分拆的计算任务或相互间有依赖关系的数据无法进行并行计算
具体实现：hadoop（生态圈：pig、hive、hbase、zookeeper、sqoop），它是google的云计算系统的开源实现，主要包括三个部分：分布式文件系统GFS，分布式并行计算模型map/reduce（这篇论文内容，GFS和Bigtable是另外两篇论文），以及分布式数据库Bigtable。hadoop也实现了这三个，GFS对应HDFS，hadoop的map/reduce对应谷歌的map/reduce模型，Hbase对应Bigtable。map/reduce是谷歌提出的一种云计算模型，hadoop用java开源实现了。
硬件环境参考
效果：论文中举了搜索和排序的例子，搜索试验是在1010个记录（每个记录100字节）中搜索特定字符，耗时80s；
排序试验是对1010个记录（每个记录100字节）进行排序，计算过程耗时891秒。
（测试环境：一个由将近1800台机器组成的集群上执行。每台机器有2个打开了超线程的2G Intel Xeon处理器，4GB内存，2个160GB IDE硬盘，一个gigabit 以太网链路。这些机器安排在一个两级的树形交换网络上，根节点具有接近100-200Gbps的总体带宽。所有机器具有相同的配置，因此在任意两个机器间的往返时间小于1ms。）
标题：Spark: ClusterComputing with Working Sets(工作组上的集群计算)
相关文件：hotcloud_spark.pdf（中文翻译hotcloud_spark.docx）
第一作者: MateiZaharia
单位：Universityof California, Berkeley加州伯克利
日期：2010
问题：Spark是为了解决hadoop等传统并行计算模型无法解决的迭代计算、交互式计算等问题而诞生的，其RDD模型需要将所有计算的数据保存在分布式的内存中。
特征：Spark中使用了RDD(Resilient Distributed Datasets, 弹性分布式数据集)抽象分布式计算，即使用RDD以及对应的transform/action等操作来执行分布式计算；并且基于RDD之间的依赖关系组成lineage以及checkpoint等机制来保证整个分布式计算的容错性。Spark更适合于迭代运算比较多的机器学习（ML）和数据挖掘（DM）运算。
Spark提供的数据集操作类型有很多种，不像Hadoop只提供了Map和Reduce两种操作。
缺点：需要大量内存（属于内存计算框架），在内存中处理一切数据，成本更高
不同的spark app之间缺乏有效的共享内存机制
粗粒度的资源管理，每个Application拥有固定数量的executor和固定数量的内存，不适用异步细粒度更新状态的应用，例如web服务的存储或者是增量的web爬虫和索引
数据的partition不够好，会导致集群中的各台机器上计算任务分配不平均
任务调度不够好
具体实现：Spark（最新是Apache Spark 2.0），核心技术是弹性分布式数据集(Resilientdistributed datasets)，提供了比Hadoop更加丰富的MapReduce模型，可以快速在内存中对数据集进行多次迭代，来支持复杂的数据挖掘算法和图计算算法。Spark使用Scala开发，使用Mesos作为底层的调度框架，可以和hadoop和Ec2紧密集成，直接读取hdfs或S3的文件进行计算并把结果写回hdfs或S3，是Hadoop和Amazon云计算生态圈的一部分。
效果：logistic回归模型中的对比，比hadoop快10倍以上
标题：ApacheHadoop YARN: Yet Another Resource Negotiator（YARN：另一种资源协商）
相关文件：2013 - Apache Hadoop YARN- Yet AnotherResource Negotiator (SoCC).pdf（暂未找到中文翻译，只有概述）
第一作者：Vinod Kumar Vavilapalli
单位：hortonworks
日期：2013
问题：MRv1计算框架的局限性日益突出，主要包括扩展性差、资源利用率低、存在单点故障、计算框架单一等问题。为此，Hadoop 2.0提出一种新的资源管理系统YARN (也称为MRv2)，一个多种计算框架通用的资源调度体系，为不同的并行化计算提供资源分配服务。
特征：YARN解耦了资源管理和业务逻辑，YARN专门负责资源分配，剥离业务逻辑到计算框架（Framework）中。YARN仍采用Master-Slave架构，主要包括3个组件。
Resource Manager，简称RM，是YARN的Master，具有中心化的全局资源视图，负责系统的任务调度、资源管理和状态监控。RM根据应用需求、调度优先级和资源情况等，动态调整资源。
ApplicationMaster，简称AM，管理某种应用，具体负责申请资源、监控任务运行和容错等。
Node Manager，简称NM，是YARN的Slave，负责相应节点的资源管理、任务执行、心跳上报等。
YARN的架构图
其中蓝色部分为YARN自身的组件，粉红色部分、黄色部分分别为运行在YARN上的MapReduce和MPI。
YARN支持的计算框架只要实现YARN定义的接口，便可以运行在YARN之上，从而很好地打造一个以YARN为核心的生态系统。
缺点：YARN目前有两种架构。集中式架构的缺点是扩展性差：首先，集群规模受限；其次，新的调度策略难以融入到现有代码中，比如之前仅支持MapReduce作业，现在要支持流式作业，而将流式作业的调度策略嵌入到中央调度其中是一项很难的工作。双层调度架构的特点是：各个框架调度器并不知道整个集群资源使用情况，只是被动地接受资源；资源调度器仅将可用的资源推送给各个框架，而由框架自己选择是使用还是拒绝这些资源；一旦框架接受到新资源，再进一步将资源分配给其内部的任务，进而实现双层调度。然而这种调度器也是有缺点，主要表现在以下两个方面:1.各个框架无法知道整个集群的实时资源使用情况；采用悲观锁，并发粒度小。
具体实现：YARN（hadoop 2.0）。由于YARN具有灵活且支持多计算框架的架构设计、主结点功能的分离、资源调度机制的改进、资源的隔离和Hadoop原生支持等诸多特性，它目前已经成了新一代资源管理的典型代表，许多互联网公司，如阿里的云梯集群、腾讯的Gaia平台等就是基于YARN建立的大数据平台。
效果：在260结点的服务器集群上，每个服务器为16核2.27GHZ的Xeon CPU，38G内存，6T硬盘，ext3文件系统，网络带宽1Gbps，进行了benchmark（YARNin Hadoop 2.1.0对比Hadoop-1 release 1.2.1）
标题：The DataflowModel: A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale,Unbounded, Out-of-Order Data Processing（数据流模型：大规模、无限、无序数据处理中一种平衡准确性、延迟和费用的实践方法）
相关文件：p1792-Akidau.pdf（暂无找到中文翻译，只有概述）
https://cloud.google.com/dataflow/ 官网
第一作者：Tyler Akidau
单位：Google
日期：2015
问题：目前大数据处理领域主要有MR代表的批处理和Storm代表的流式实时处理。批处理的缺点是实时性比较差，一旦数据量达到了PB级MapReduce就会变得难以处理。在Storm作者提出的大数据Lambda架构中，曾经提出近期数据归为Storm来处理，如果超过一定期限由MR处理，这需要在两个不同代码风格之间转换。
Google引入了Pipeline来统一了批处理和实时处理，由统一的代码实现两种处理，使用Cloud Dataflow 云平台支持。Dataflow是设计为处理非常非常大的数据集和复制的工作流，也就是说，MR只适合大数据集+简单流程的应用场景，Dataflow能够自动优化 pipeline，并且管理底层基础设施，Dataflow是语言无关的。
对于批处理，延迟太长，而且只能针对有界数据。所以现在的主流是Streaming，但是Streaming在保证latency的时候，如何保证准确性或完整性，根据CAP定理，是不可能的。那么当前方案是平衡,大致就是backfill（在FCFS算法的基础上,将队列中较小的作业回填到空闲CPU,以提高CPU利用率），通过设计做的比之前的方案更精细，尤其对于windows的场景，更通用。
特征：论文要解决复杂的有状态模式，比如典型的就是基于windowed的聚合操作把这类操作抽象成4个阶段，
what，计算什么
where，在什么范围内聚合，globe的？在某个时间window中？
when，什么时候输出实时统计结果
how，如何修正前面输出的结果
缺点：不能突破CAP定理（指在分布式系统中，Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容错性），三者不可兼得），仍然是在做取舍折中
具体实现：Google Cloud Dataflow是一种构建、管理和优化复杂数据处理流水线的方法，集成了许多内部技术，如用于数据高效并行化处理的Flume和具有良好容错机制流处理的MillWheel。
效果：
标题：Storm Distributedand fault-tolerant realtime computation（分布式容错实时计算）
相关文件：Storm_ distributed and fault-tolerantrealtime computation（作者文章） Presentation.pdfManning.Big.Data.2015.4.pdf(作者著作)
http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html（历史介绍）
https://storm.apache.org/ （官网）
第一作者：Nathan Marz
单位：Twitter
日期：2011
问题：在Storm之前，进行实时处理需要维护一堆消息队列和消费者，他们构成了非常复杂的图结构。消费者进程从队列里取消息，处理完成后，去更新数据库，或者给其他队列发新消息。
这样进行实时处理是非常痛苦的。我们主要的时间都花在关注往哪里发消息，从哪里接收消息，消息如何序列化，真正的业务逻辑只占了源代码的一小部分。一个应用程序的逻辑运行在很多worker上，但这些worker需要各自单独部署，还需要部署消息队列。最大问题是系统很脆弱，而且不是容错的：需要自己保证消息队列和worker进程工作正常。
特征：Storm是一个免费并开源的分布式实时计算系统。利用Storm可以很容易做到可靠地处理无限的数据流，像Hadoop批量处理大数据一样，Storm可以实时处理数据。Storm简单，可以使用任何编程语言。Storm完整地解决了这些问题。它是为分布式场景而生的，抽象了消息传递，会自动地在集群机器上并发地处理流式计算（属于流式计算框架），让你专注于实时处理的业务逻辑。
编程简单：开发人员只需要关注应用逻辑，而且跟Hadoop类似，Storm提供的编程原语也很简单
高性能，低延迟：可以应用于广告搜索引擎这种要求对广告主的操作进行实时响应的场景。
分布式：可以轻松应对数据量大，单机搞不定的场景
可扩展： 随着业务发展，数据量和计算量越来越大，系统可水平扩展
容错：单个节点挂了不影响应用
消息不丢失：保证消息处理
缺点：如果使用的是自己的消息队列，需要加入消息队列做数据的来源和产出的代码。需要考虑如何做故障处理：如何记录消息处理的进度，应对Storm重启，挂掉的场景。需要考虑如何做消息的回退：如果某些消息处理一直失败怎么办。
具体实现：Storm（Storm 2.0基于Jstorm）
效果：storm的网络直传、内存计算，其时延必然比hadoop的通过hdfs传输低得多；当计算模型比较适合流式时，storm的流式处理，省去了批处理的收集数据的时间；因为storm是服务型的作业，也省去了作业调度的时延。所以从时延上来看，storm要快于hadoop。根据HarvardCS61课件，磁盘访问延迟约为内存访问延迟的75000倍。所以Storm更快。两者面向的领域也不完全相同，一个是批量处理，基于任务调度的;另外一个是实时处理，基于流。