宣扬Hadoop将死的观点一直以来已经很久了,那这种观点究竟是对还是错,hadoop和spark是什么关系,Spark何德何能将一统大数据的江山,Spark在企业中应用的如何,我们有必要花大量的时间去掌握他么?答案是,1)hadoop不会死,spark也干不死hadoop,2)spark有必要去掌握,如果现在还没掌握,尽快掌握。

1.Spark和Hadoop关系

分布式计算平台=分布式文件系统+分布式计算模型,我们通常讲的hadoop一般是指分布式计算平台的统称,
分布式计算平台(hadoop)=分布式文件系统(HDFS)+分布式计算模型(MapReduce)
Spark=分布式计算模型+图计算模型+机器学习库+流等计算...
Spark包含了很多,但是唯独没有包含分布式计算模型,因为HDFS做的已经足够好了
hadoop包好了分布式文件系统,分布式计算模型,但是没有图计算、机器学习、流式计算。
所以要么是你有的,我没有,我有的,你没有。
hadoop和spark的关系就是:你依赖我,我加强你,互相补充,扬长避短。

2.Hdoop和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追求计算的灵活性,所以就复杂, 复杂就不好控制,不好控制就容易挂掉。

3.为什么Hadoop不被看好

很多人在谈到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快上很多。

4.hadoop是不是要被淘汰

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

内容转自微信公众号:大数据梅峰谷
更多文章请扫描二维码

标签: none

相关文章推荐

已有 6 条评论

  1. 不知道老师 去不去上海讲课 最近 寻思想去上海培训一下 大数据

    边琪 回复
    1. 我们上海已经开了大数据学科,正在火热招生中。上海我一定回去的,能不能和你一起学习技术就是另外一回事情了。

      毛祥溢 回复
  2. 毛老师,有道云笔记的链接挂了,可以更新下吗?

    Jimy 回复
    1. 重复分享之后,也不行。估计是19大影响的,过了这阵再说。

      毛祥溢 回复
  3. Spark的DAG是不可分的,这个对于需要不断的迭代计算的机器学习是不太适合的.腾讯2015年开发的angel,不知道老师有没有耳闻, spark on angel.https://github.com/Tencent/angel,挺不错的有时间可以融入到课程中.不过技术点都是相同的,有了分布式的思想就都简单了许多!

    bianqi 回复
    1. 是的,有了分布式思想什么都简单了。 任务生成、任务分配、任务调度、任务执行……

      毛祥溢 回复
  4. Spark包含了很多,但是唯独没有包含分布式计算模型,因为HDFS做的已经足够好了。
    打错了,应该是唯独没有包含分布式文件存储。

    无极剑圣 回复

添加新评论,含*的栏目为必填