分布式计算平台=分布式文件系统+分布式计算模型，我们通常讲的hadoop一般是指分布式计算平台的统称，

分布式计算平台（hadoop）=分布式文件系统（HDFS）+分布式计算模型（MapReduce）

Spark=分布式计算模型+图计算模型+机器学习库+流等计算…

Spark包含了很多，但是唯独没有包含分布式计算模型，因为HDFS做的已经足够好了

hadoop包好了分布式文件系统，分布式计算模型，但是没有图计算、机器学习、流式计算。

所以要么是你有的，我没有，我有的，你没有。

hadoop和spark的关系就是：你依赖我，我加强你，互相补充，扬长避短。

2个都是开源框架，但是解决的问题侧重点不一样,同时各有优缺点。

第一，hadoop是分布式文件系统实现的经典方式，轻轻松松做到平台近乎傻瓜式的横向扩容，并且为分布式计算提供了基础，创造了可能（文件切分，分布式存储），而且依赖的硬件也是普通的PC服务器。这些特点如果没有经历IOE架构是没法深刻理解的，传统的企业以前几乎都是IOE的架构（IBM的服务器，做逻辑运算等功能，Oracle的数据库，做数据库服务，EMC的存储，存储都是SAN、阵列之类的专门服务器来做），硬件价格贵的要命，小型机一台都上百万，而且运维还要专门的团队，小型机一个团队，oracle一个团队，存储一个团队，这兼职就是噩梦。Spark，则是那么一个专门用来对那些分布式存储的大数据进行处理的工具，它并不会进行分布式数据的存储。

第二，还有一点也值得注意——这两者的灾难恢复方式迥异。因为Hadoop将每次处理后的数据都写入到磁盘上，所以其天生就能很有弹性的对系统错误进行处理。

Spark的数据对象存储在分布于数据集群中的叫做弹性分布式数据集(RDD: Resilient Distributed Dataset)中。这些数据对象既可以放在内存，也可以放在磁盘，所以RDD同样也可以提供完成的灾难恢复功能。

第三，使用场景不一样，hadoop适合离线，spark适合计算复杂，能迭代的计算场景，大部分hadoop的计算场景，spark都能做，个别场景只能haodop做，spark做不了。

第四，在我的使用经验里面，稳定性来说，hadoop更好一点，因为人家是磁盘里面做交互么，spark相对来说更差一点，这个和spark代码测试不足有关，因为Spark追求计算的灵活性，所以就复杂， 复杂就不好控制，不好控制就容易挂掉。

很多人在谈到Spark代替Hadoop的时候，其实很大程度上指的是代替MapReduce。

MapReduce的缺陷很多，最大的缺陷之一是Map + Reduce的模型。这个模型并不适合描述复杂的数据处理过程。很多公司把各种奇怪的Machine Learning计算用MR模型描述，不断挖掘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里执行流。他们相对现在的MapReduce模型来说，极大的提升了对各种复杂处理的直接支持，不需要再绞尽脑汁“挖掘”MR模型的潜力。综上，Spark数据处理速度秒杀MapReduce因为其处理数据的方式不一样，会比MapReduce快上很多。

目前备受追捧的Spark还有很多缺陷，比如：

1、稳定性方面，由于代码质量问题，Spark长时间运行会经常出错，在架构方面，由于大量数据被缓存在RAM中，Java回收垃圾缓慢的情况严重，导致Spark性能不稳定，在复杂场景中SQL的性能甚至不如现有的Map/Reduce。

2、不能处理大数据，单独机器处理数据过大，或者由于数据出现问题导致中间结果超过RAM的大小时，常常出现RAM空间不足或无法得出结果。然而，Map/Reduce运算框架可以处理大数据，在这方面，Spark不如Map/Reduce运算框架有效。

3、不能支持复杂的SQL统计;目前Spark支持的SQL语法完整程度还不能应用在复杂数据分析中。在可管理性方面，SparkYARN的结合不完善，这就为使用过程中埋下隐忧，容易出现各种难题。在比较Hadoop和Spark方面要记住的最重要一点就是，它们并不是非此即彼的关系，因为它们不是相互排斥，也不是说一方是另一方的简易替代者。两者彼此兼容，这使得这对组合成为一种功能极其强大的解决方案，适合诸多大数据应用场合。

5.梅峰谷补充以下几点：

1）Spark能被业界接受，除了内存计算这点外还有很多原因，如DAG、生态丰富等等，从架构设计、生态设计、后续演进这几点考虑，Spark是有独到之处的。HDFS可以说是分布式的基础设施，在HDFS发展阶段，各种开源计算模型百花齐放，但是Spark终于做到一统江山了，成为一个事实上的标准，对开发人员、运维人员来说，这是福音。

2）对于大数据的学习，知识点多，有点开发基础的人，或者计算机先关专业毕业的人，找准点并不难切入； 知识点多不可怕，但没有计划的学习，比较可怕。碰到问题不怕，但是闭门造车可怕。

3）有些人常常问，要不要报培训班，报哪个。对于学习时间短要速成的人来时，是可以报个班督促下自己，但是现在的资料已经很丰富了，能消化一个完整的视频教程，基本上入门上手是没问题的，前面已经发了很多连贯完整的视频教程。

4）见到一些学生，2年前在问我大数据怎么学习，2年后还在问我同样的问题，大数据能自学好的人，我觉得已经具备了一些很好的学习素质了，无论后面技术怎么变化，学习的方法论都是同样的。记得之前读研的时候，导师（北大）并不教你什么技巧、资料，只告诉你一个方向，当时并不是很理解，工作多年后，才发现，就是让我们训练和培养出属于自己的学习方法论，这个是终生受益的，无论是新工作、新岗位、新技术、新课题，都不会害怕，技术变换无穷，问题无穷无穷，但是探索方法和流程大体是一致的。

内容转自微信公众号：大数据梅峰谷