作为面向Hadoop的内存内兼实时数据处理框架，Apache Spark已经在1.0版本正式推出之后逐步迈上发展正轨。在1.2版本中的特性变更证明了Spark并不满足于对现有成绩的持续改进，同时也致力于发展成一款足以应对Hadoop环境下大规模数据处理场景的未来框架。
在Spark 1.2版本的众多变更当中，最主要的趋势在于进一步扩大Spark在各类使用方式当中的实用能力。新的弹性扩展系统允许Spark在长期运行任务当中更为出色地发挥集群节点性能，而这一点对于多用户环境而言显然已经成为最常见也最迫切的需求。Spark的流功能如今迎来了一款Python API、同时具备了用于支持高可用性场景的预写入日志方案，这一切都让Spark在用户心目中的地位不断上升。
新版本当中自然不能少了Spark SQL，其允许Spark任务能够对相关数据执行与Apache Hive类似的查询操作，而且它现在能够通过新的API与外部数据源顺利协作。作为Hadoop领域的另一大重点，机器学习方案也在Spark新版本的支持下得到了强化，这要归功于一系列新型API与算法的鼎力协助，此外还有对于Python更出色的支持效果锦上添花。***，Spark的图形-计算API GraphX目前已经告别alpha测试、开始迈入稳定版本阶段。
Spark项目一直在Hadoop世界当中努力推动并拓展两项发展目标。首先是打破Hadoop长久以来对于MapReudce框架的高度依赖，逐步将处理任务交给YARN、Tez以及Spark等新生代方案承载。数据-应用程序基础设施方案供应商Concurrent公司CEO Gary Nakamura认为，在未来一年中“经过时间考验且切实可靠”的MapReduce将继续在生产环境中拥有压倒Spark（以及Tez）的市场占有率。然而，MapReduce自身的局限性实在难于忽略，而且这一切已经开始影响到通过它所实现的业务任务。
另一大值得注意的发展趋势在于，对于Python的支持能力在Spark当中一直处于拓展当中——包括在Hadoop中也一样。Python在数据处理领域的人气一直居高不下，同时也非常适合在Hadoop及Spark当中加以使用，但大部分Python支持能力仍然局限于MapReduce任务范畴。通过对Python支持能力的持续推进，可以看到Spark项目已经将着眼点放在传统企业Java领域之外、开始向真正的通用Hadoop方向进军。
Spark项目的大部分持续性发展成果一直在由Hadoop厂商Hortonworks公司所贡献。这家企业已经将Spark与YARN进行了深度整合，并通过Apache Argus项目向其中添加更多安全性与治理手段、且不断加以改进与调试。
目前摆在面前的***一个、也是过去被无数次批评的问题在于，正如程序员Alex Rubinsteyn所言，Spark项目在调试难度方面实在太过夸张：“Spark项目本身疏于评估，”他写道，“这使我们很难弄清楚自己程序中的真正瓶颈所在。而且即使大家能够确定速度较慢的特定表达式，往往也没办法弄明白它为什么这么慢或者如何才能使其拥有理想的速度表现。”
英文：http://www.infoworld.com/article/2862225/hadoop/spark-12-challenges-mapreduces-hadoop-dominance.html
对于与 Hadoop 对比，如何看待 Spark 技术？在知乎上Xiaoyu Ma曾这么认为：
我本人是类似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模型的潜力。
有兴趣的童鞋可以看看这个PPT
http://www.slideshare.net/Hadoop_Summit/w-235phall1pandey
这是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的例子看起来是这样的，大家可以比较感受下：
incubator-tez/WordCount.java at master · apache/incubator-tez · GitHub
处理大规模数据而言，他们都需要更多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个看起来有戏的“次世代”平台，那慢慢试用，不断观望，逐步替换，会是大多数公司的策略。
