Spark概念Spark是UC Berkeley AMP lab所开源的类hadoop MapReduce的通用并行框架，Spark，拥有Hadoop MapReduce所具有的优点；但不同于MapReduce的是Job中间输出结果可以保存在内存中，从而不再需要读写HDFS，因此Spark能更好地适用于数据挖掘与机器学习等需要迭代的MapReduce的算法。

Spark 是一种与 Hadoop 相似的开源集群计算环境，但是两者之间还存在一些不同之处，这些有用的不同之处使 Spark 在某些工作负载方面表现得更加优越，换句话说，Spark 启用了内存分布数据集，除了能够提供交互式查询外，它还可以优化迭代工作负载。

Spark 是在 Scala 语言中实现的，它将 Scala 用作其应用程序框架。与Hadoop不同，Spark 和 Scala 能够紧密集成，其中的 Scala 可以像操作本地集合对象一样轻松地操作分布式数据集。

尽管创建 Spark 是为了支持分布式数据集上的迭代作业，但是实际上它是对 Hadoop 的补充，可以在 Hadoop 文件系统中并行运行。通过名为 Mesos 的第三方集群框架可以支持此行为。Spark 由加州大学伯克利分校 AMP 实验室 （Algorithms， Machines， and People Lab） 开发，可用来构建大型的、低延迟的数据分析应用程序。

Spark生态系统Shark： Shark基本上就是在Spark的框架基础上提供和Hive一样的HiveQL命令接口，为了大程度的保持和Hive的兼容性，Shark使用了Hive的API来实现query Parsing和 Logic Plan generation，最后的PhysicalPlan execution阶段用Spark代替HadoopMapReduce.通过配置Shark参数，Shark可以自动在内存中缓存特定的RDD，实现数据重用，进而加快特定数据集的检索。同时，Shark通过UDF用户自定义函数实现特定的数据分析学习算法，使得SQL数据查询和运算分析能结合在一起，大化RDD的重复使用。

基本原理Spark Streaming： 构建在Spark上处理Stream数据的框架，基本的原理是将Stream数据分成小的时间片断（几秒），以类似batch批量处理的方式来处理这小部分数据。Spark Streaming构建在Spark上，一方面是因为Spark的低延迟执行引擎（100ms+），虽然比不上专门的流式数据处理软件，也可以用于实时计算，另一方面相比基于Record的其它处理框架（如Storm），一部分窄依赖的RDD数据集可以从源数据重新计算达到容错处理目的。此外小批量处理的方式使得它可以同时兼容批量和实时数据处理的逻辑和算法。方便了一些需要历史数据和实时数据联合分析的特定应用场合。

计算方法Bagel： Pregel on Spark，可以用Spark进行图计算，这是个非常有用的小项目。Bagel自带了一个例子，实现了Google的PageRank算法。

当下Spark已不止步于实时计算，目标直指通用大数据处理平台，而终止Shark，开启SparkSQL或许已经初见端倪。

Spark与Hadoop技术对比下面是小编在网上搜集的部分资料，如有不足，还请减料问题：与 Hadoop 对比，如何看待 Spark 技术？

回答一：我本人是类似Hive平台的系统工程师，我对MapReduce的熟悉程度是一般，它是我的底层框架。我隔壁组在实验Spark，想将一部分计算迁移到Spark上。

年初的时候，看Spark的评价，几乎一致表示，Spark是小数据集上处理复杂迭代的交互系统，并不擅长大数据集，也没有稳定性。但是最近的风评已经变化，尤其是14年10月他们完成了Peta sort的实验，这标志着Spark越来越接近替代Hadoop MapReduce了。

Spark the fastest open source engine for sorting a petabyte Sort和Shuffle是MapReduce上最核心的操作之一，比如上千个Mapper之后，按照Key将数据集分发到对应的Reducer上，要走一个复杂的过程，要平衡各种因素。Spark能处理Peta sort的话，本质上已经没有什么能阻止它处理Peta级别的数据了。这差不多远超大多数公司单次Job所需要处理的数据上限了。

回到本题，来说说Hadoop和Spark.Hadoop包括Yarn和HDFS以及MapReduce，说Spark代替Hadoop应该说是代替MapReduce. MapReduce的缺陷很多，大的缺陷之一是Map ＋ Reduce的模型。这个模型并不适合描述复杂的数据处理过程。很多公司（包括我们）把各种奇怪的Machine Learning计算用MR模型描述，不断挖（lan）掘（yong）MR潜力，对系统工程师和Ops也是极大挑战了。很多计算，本质上并不是一个Map，Shuffle再Reduce的结构，比如我编译一个SubQuery的SQL，每个Query都做一次Group By，我可能需要Map，Reduce＋Reduce，中间不希望有无用的Map；又或者我需要Join，这对MapReduce来说简直是噩梦，什么给左右表加标签，小表用Distributed Cache分发，各种不同Join的Hack，都是因为MapReduce本身是不直接支持Join的，其实我需要的是，两组不同的计算节点扫描了数据之后按照Key分发数据到下一个阶段再计算，就这么简单的规则而已；再或者我要表示一组复杂的数据Pipeline，数据在一个无数节点组成的图上流动，而因为MapReduce的呆板模型，我必须一次一次在一个Map/Reduce步骤完成之后不必要地把数据写到磁盘上再读出，才能继续下一个节点，因为Map Reduce2个阶段完成之后，就算是一个独立计算步骤完成，必定会写到磁盘上等待下一个Map Reduce计算。

上面这些问题，算是每个号称下一代平台都尝试解决的。

现在号称次世代平台现在做的相对有前景的是Hortonworks的Tez和Databricks的Spark.他们都尝试解决了上面说的那些问题。Tez和Spark都可以很自由地描述一个Job里执行流（所谓DAG，有向无环图）。他们相对现在的MapReduce模型来说，极大的提升了对各种复杂处理的直接支持，不需要再绞尽脑汁“挖掘”MR模型的潜力。

这是Hadoop峰会上Tez的材料，第九页开始有描述Hive on Tez和传统MR Hive的区别，这些区别应该也适用于MR Hive和Spark SQL，也很清楚的体现了为何MR模型很笨重。

相比Tez，Spark加入了更多内存Cache操作，但据了解它也是可以不Cache直接处理的，只是效率就会下降。

再说Programming Interface，Tez的Interface更像MapReduce，但是允许你定义各种Edge来连接不同逻辑节点。Spark则利用了Functional Programming的理念，API十分简洁，相比MR和Tez简单到令人发指。我不清楚Spark如果要表现复杂的DAG会不会也变得很麻烦，但是至少wordcount的例子看起来是这样的处理大规模数据而言，他们都需要更多proven cases.至少Hadoop MapReduce是被证明可行的。

作为Data Pipeline引擎来说，MapReduce每个步骤都会存盘，而Spark和Tez可以直接网络发送到下一个步骤，速度上是相差很多的，但是存盘的好处是允许继续在失败的数据上继续跑，所以直观上说MapReduce作为pipeline引擎更稳健。但理论上来说，如果选择在每个完成的小步骤上加CheckPoint，那Tez和Spark完全能和现在的MapReduce达到一样的稳健。

总结来说，即便现在不成熟，但是并没有什么阻碍他们代替现有的MapReduce Batch Process.对Tez而言，似乎商业上宣传不如Spark成功。Databricks头顶Berkley的光环，商业宣传又十分老道，阵营增长极快。光就系统设计理念，没有太大的优劣，但是商业上可能会拉开差距。Cloudera也加入了Spark阵营，以及很多其他大小公司，可以预见的是，Spark会成熟的很快，相比Tez.但Tez对于Hortonworks来说是赢取白富美的关键，相信为了幸福他们也必须努力打磨推广tez.所以就算现在各家试用会有种种问题，但是毕竟现在也就出现了2个看起来有戏的“次世代”平台，那慢慢试用，不断观望，逐步替换，会是大多数公司的策略。

回答二：1. spark 是hadoop mapreduce 的不断改进，同时又兼容并包了很多数据库里面的一些基本思想来实现和发展。没有什么怪力乱神，什么内存计算，什么下一代之类的花哨说法的。spark 是站在hadoop and database 这两个巨人肩膀上的。

举个spark 处理迭代计算的Example 2. Spark 版本的PageRank 比Hadoop 快的不是一点点。根本原因就是在每一步迭代的时候，需要做两个big table euqi-join.hadoop mr 的算法是要做data shuffle，同时需要把需要计算的数据从hdfs 多次读出写入。回溯到5年前，最先发现Hadoop 在处理迭代计算，存在i/o 读写浪费的瓶颈的是 vldb10 的 LoopHadoop 的论文，其中的一作是一个中国哥们，现在citation 已经超过400多了。解决的方法就是把多个迭代中不变的数据，cache 下来，下一步计算就不需要从disk 里面读写了，Spark 也是根据类似的idea 可以把需要反复计算的数据， cache 下来。

3. 接着上面的问题，数据cache 下来之后，why spark 在迭代的时候不需要shuffle 了阿？ 因为spark 定义了rdd 之间的dependence 关系，这个关系决定了是否需要shuffle. 比如一个spark 有多个partition， 如果一个rdd 到另外一个rdd 是 全依赖关系，就是说一个partition 的数据，始终在local 计算，或者只是需要去取指定的一个partition 的数据的话，那么shuffle 就是不需要了。我们可以看到，所有计算的依赖关系都是在计算之前就定义好了。有了 rdd 之间的依赖关系，就是可以得到计算的 logical plan and physical plan， 然后去执行计算。 这就是典型的数据库的思想。当然rdd 也就是数据库view 的思想的实现，因为rdd 和view 都是需要的时候再计算的模式，这样就可以有了计算的pipeline，也完全是数据库pipeline 的实现的吗。大家如果看到spark rdd code 里面到处的iterator，就更明白了 . 4. 回到page rank 的列子，两个大表（A，B）之间的join， 因为数据已经按照hash patitioner 把数据分块划好了。就是A B 数据的key 在一个范围的已经分入到具体的partition 里面了，那join的时候，就只是需要对应的partition 作对应的join 就可以的。这样就避免了数据的shuffle 了的。

5. 其实spark 是一点点一点点的工程和学术的结合基础上做出来的， 本质就是Hadoop mapreduce 的增强版本。大家可以看到，在理论上都没有太多新的东西。 所以人家马铁大神当年论文也是被拒了好多遍的。但是系统就是这一点点的改进的基础上做出的。马铁的老板之一是Franklin，F的老板是 UCI 的大牛Carey， Carey 的老板大家自己google 吧。UCB的人的确是牛！

6. 最后我觉得比较hadoop vs spark 不是一个很好的比较方式，因为他们都是一个流派的。比较合适的，是比较 MapReduce Vs MPI，因为在MPI 的计算模式和MapReduce 有大的区别。如果在计算传输数据量不大的时候，比如单纯的numerical 计算的时侯，MPI 都要甩 MapReduce 几条街。最简单就是你想想人家超算做了几十年了，在大的计算集群上的计算上则几万核啊，经典的 one to all， all to all， all to one， data grid 都是很妙的方法好吧。但是如果在处理文本啊之类的数据的时候，一个单词可能出现了很多次，需要大量的数据传输，这时候MapReduce shuffle 机制就显示出优势来了。当然MPI 没有考虑 fault tolerance，也是在cloud 环境下，MapReduce 更有效的原因之一。

回答三：我们公司现在Spark和Hadoop都在用，从我的感受来看，虽然Spark目前还不够成熟，但是今后一定会代替Hadoop. 1. 相同的算法，Spark比Hadoop快数倍，如果是一些迭代或者要对数据反复读取的算法，Spark比Hadoop快数十倍至上百倍2. Spark对于数据的操作种类更多，对于一些比较特殊的计算需求，比如求两个集合的交集并集，Spark都有函数直接计算，而Hadoop实现这样的计算无比繁琐3. Spark的开发效率比Hadoop高很多当然也不是说Spark就是完美的，目前来看Spark还有很多bug，而且可以看的资料也不多。而且据说另一个分布式计算平台Graphlab运行效率比Spark还要高，我最近正准备学一下。

Spark成为大数据分析领域新核心的理由依赖于Hadoop的企业需要借助一系列分析型基础设施与流程以找到与各类关键性问题相关的结论与解答。企业客户需要数据准备、描述性分析、搜索、预测性分析以及机器学习与图形处理等更为先进的功能。与此同时，企业还需要一套能够满足其实际需求的工具集，允许他们充分运用目前已经具备的各类技能及其它资源。就目前而言，并没有哪种标准化单一处理框架足以提供这样的效果。从这个角度出发，Spark的优势恰好得到了完美体现。

尽管Spark还仅仅是个相对年轻的数据项目，但其能够满足前面提到的全部需求，甚至可以做得更多。在今天的文章中，我们将列举五大理由，证明为什么由Spark领衔的时代已经来临。

Spark让高级分析由理想变为现实尽管多数大型创新型企业正在努力拓展其高级分析能力，但在最近于纽约召开的一次大数据分析会议上，只有20%的与会者表示目前正在企业内部部署高级分析解决方案。另外80%与会者反映其仍然只具备简单的数据准备与基本分析能力。在这些企业中，只有极少数数据科学家开始将大量时间用于实现并管理描述性分析机制。

Spark项目提供的框架能够让高级分析的开箱即用目标成为现实。这套框架当中包含众多工具，例如查询加速、机器学习库、图形处理引擎以及流分析引擎等等。对于企业而言，即使拥有极为杰出的数据科学家人才（当然这一前提同样很难实现），他们也几乎不可能通过MapReduce实现上述分析目标。除此之外，Spark还提供易于使用且速度惊人的预置库。在此基础之上，数据科学家们将被解放出来，从而将主要精力集中在数据准备及质量控制之外的、更为关键的事务身上。有了Spark的协助，他们甚至能够确保对分析结果做出正确的解释。