只会spark不会hadoop
- 作者: 那晚越女说我?
- 来源: 51数据库
- 2020-10-04
谈到大数据，相信大家对Hadoop和Apache Spark这两个名字并不陌生。然而，最近业界有一些人正在大张旗鼓的宣扬Hadoop将死，Spark将立。他们究竟是危言耸听、哗众取宠，还是眼光独到堪破未来呢?与Hadoop相比，Spark技术如何?现工业界大数据技术都在使用何种技术?如果现在想要开始学习大数据的话，应该从哪一种开始呢?
首先我们就从二者的区别讲起好了：
首先，Hadoop与Spark解决问题的层面不同。
Hadoop和Apache Spark两者都是大数据框架，但是各自存在的目的不尽相同。Hadoop实质上更多是一个分布式数据基础设施: 它将巨大的数据集分派到一个由普通计算机组成的集群中的多个节点进行存储，意味着您不需要购买和维护昂贵的服务器硬件。
同时，Hadoop还会索引和跟踪这些数据，让大数据处理和分析效率达到前所未有的高度。Spark，则是那么一个专门用来对那些分布式存储的大数据进行处理的工具，它并不会进行分布式数据的存储。
其次，还有一点也值得注意——这两者的灾难恢复方式迥异。因为Hadoop将每次处理后的数据都写入到磁盘上，所以其天生就能很有弹性的对系统错误进行处理。
Spark的数据对象存储在分布于数据集群中的叫做弹性分布式数据集(RDD: Resilient Distributed Dataset)中。这些数据对象既可以放在内存，也可以放在磁盘，所以RDD同样也可以提供完成的灾难恢复功能。
由于两者的侧重点不同，使用场景不同，笔者认为其实并没有替代之说。Spark更适合于迭代运算比较多的ML和DM运算。因为在Spark里面，有RDD的概念。RDD可以cache到内存中，那么每次对RDD数据集的操作之后的结果，都可以存放到内存中，下一个操作可以直接从内存中输入，省去了MapReduce大量的磁盘IO操作。但是，我们也要看到spark的限制：内存。我认为Hadoop虽然费时，但是在OLAP等大规模数据的应用场景，还是受欢迎的。目前Hadoop涵盖了从数据收集、到分布式存储，再到分布式计算的各个领域，在各领域都有自己独特优势。
那么为什么还有这么多人唱衰Hadoop，力捧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快上很多。
那么可以由此判定Hadoop“死刑”吗?
目前备受追捧的Spark还有很多缺陷，比如：
· 稳定性方面，由于代码质量问题，Spark长时间运行会经常出错，在架构方面，由于大量数据被缓存在RAM中，Java回收垃圾缓慢的情况严重，导致Spark性能不稳定，在复杂场景中SQL的性能甚至不如现有的Map/Reduce。
· 不能处理大数据，单独机器处理数据过大，或者由于数据出现问题导致中间结果超过RAM的大小时，常常出现RAM空间不足或无法得出结果。然而，Map/Reduce运算框架可以处理大数据，在这方面，Spark不如Map/Reduce运算框架有效。
· 不能支持复杂的SQL统计;目前Spark支持的SQL语法完整程度还不能应用在复杂数据分析中。在可管理性方面，SparkYARN的结合不完善，这就为使用过程中埋下隐忧，容易出现各种难题。
但本文的目的并不在于踩Spark为Hadoop证明，而是想指出——大家在比较Hadoop和Spark方面要记住的最重要一点就是，它们并不是非此即彼的关系，因为它们不是相互排斥，也不是说一方是另一方的简易替代者。两者彼此兼容，这使得这对组合成为一种功能极其强大的解决方案，适合诸多大数据应用场合。
也就是说，大数据行业的老鸟们如果只会Hadoop就要当心了，挤出时间来学习Spark和其他新技术是绝对必要的;而对于目前正准备进入大数据行业的朋友们，从Hadoop开始仍然是最好的选择。长远来看新技术总会不断出现，不管是Spark还是Tez似乎都有着更美妙的前景，然而没有人会劝你完全抛开Hadoop。
ssh hadoop2.5 ubuntu14 vmware10 jdk1.7 方法/步骤 一、ssh配置： 1、首先在三台服务器上安装ssh，服务器ip地址为： 192.168.217.128; 192.168.217.129; 192.168.217.130 sudo apt-get install openssh-server openssh-client 2、然后分别在三台服务器上执行以下命令，配置ssh免秘钥： $ ssh-keygen -t dsa -p '' -f ~/.ssh/id_dsa $ cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys 输入命令：ssh localhost 第一次需要输入密码，然后再次输入:ssh localhost 能无密码登陆，说明配置成功 3、手动复制ubuntu2,ubuntu3 ~/.ssh/id_dsa.pub 文件内容添加到ubuntu1的~/.ssh/authorized_keys 文件中； 或者分别执行以下代码（注：zhou是用户名）： 在ubuntu2中执行 $ scp ~/.ssh/id_dsa.pub zhou@ubuntu1:~/.ssh/authorized_keys 在ubuntu3中执行 $ scp ~/.ssh/id_dsa.pub zhou@ubuntu1:~/.ssh/authorized_keys
首先我们就从二者的区别讲起好了：
首先，Hadoop与Spark解决问题的层面不同。
Hadoop和Apache Spark两者都是大数据框架，但是各自存在的目的不尽相同。Hadoop实质上更多是一个分布式数据基础设施: 它将巨大的数据集分派到一个由普通计算机组成的集群中的多个节点进行存储，意味着您不需要购买和维护昂贵的服务器硬件。
同时，Hadoop还会索引和跟踪这些数据，让大数据处理和分析效率达到前所未有的高度。Spark，则是那么一个专门用来对那些分布式存储的大数据进行处理的工具，它并不会进行分布式数据的存储。
其次，还有一点也值得注意——这两者的灾难恢复方式迥异。因为Hadoop将每次处理后的数据都写入到磁盘上，所以其天生就能很有弹性的对系统错误进行处理。
Spark的数据对象存储在分布于数据集群中的叫做弹性分布式数据集(RDD: Resilient Distributed Dataset)中。这些数据对象既可以放在内存，也可以放在磁盘，所以RDD同样也可以提供完成的灾难恢复功能。
由于两者的侧重点不同，使用场景不同，笔者认为其实并没有替代之说。Spark更适合于迭代运算比较多的ML和DM运算。因为在Spark里面，有RDD的概念。RDD可以cache到内存中，那么每次对RDD数据集的操作之后的结果，都可以存放到内存中，下一个操作可以直接从内存中输入，省去了MapReduce大量的磁盘IO操作。但是，我们也要看到spark的限制：内存。我认为Hadoop虽然费时，但是在OLAP等大规模数据的应用场景，还是受欢迎的。目前Hadoop涵盖了从数据收集、到分布式存储，再到分布式计算的各个领域，在各领域都有自己独特优势。
那么为什么还有这么多人唱衰Hadoop，力捧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快上很多。
那么可以由此判定Hadoop“死刑”吗?
目前备受追捧的Spark还有很多缺陷，比如：
· 稳定性方面，由于代码质量问题，Spark长时间运行会经常出错，在架构方面，由于大量数据被缓存在RAM中，Java回收垃圾缓慢的情况严重，导致Spark性能不稳定，在复杂场景中SQL的性能甚至不如现有的Map/Reduce。
· 不能处理大数据，单独机器处理数据过大，或者由于数据出现问题导致中间结果超过RAM的大小时，常常出现RAM空间不足或无法得出结果。然而，Map/Reduce运算框架可以处理大数据，在这方面，Spark不如Map/Reduce运算框架有效。
· 不能支持复杂的SQL统计;目前Spark支持的SQL语法完整程度还不能应用在复杂数据分析中。在可管理性方面，SparkYARN的结合不完善，这就为使用过程中埋下隐忧，容易出现各种难题。
但本文的目的并不在于踩Spark为Hadoop证明，而是想指出——大家在比较Hadoop和Spark方面要记住的最重要一点就是，它们并不是非此即彼的关系，因为它们不是相互排斥，也不是说一方是另一方的简易替代者。两者彼此兼容，这使得这对组合成为一种功能极其强大的解决方案，适合诸多大数据应用场合。
也就是说，大数据行业的老鸟们如果只会Hadoop就要当心了，挤出时间来学习Spark和其他新技术是绝对必要的;而对于目前正准备进入大数据行业的朋友们，从Hadoop开始仍然是最好的选择。长远来看新技术总会不断出现，不管是Spark还是Tez似乎都有着更美妙的前景，然而没有人会劝你完全抛开Hadoop。
ssh hadoop2.5 ubuntu14 vmware10 jdk1.7 方法/步骤 一、ssh配置： 1、首先在三台服务器上安装ssh，服务器ip地址为： 192.168.217.128; 192.168.217.129; 192.168.217.130 sudo apt-get install openssh-server openssh-client 2、然后分别在三台服务器上执行以下命令，配置ssh免秘钥： $ ssh-keygen -t dsa -p '' -f ~/.ssh/id_dsa $ cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys 输入命令：ssh localhost 第一次需要输入密码，然后再次输入:ssh localhost 能无密码登陆，说明配置成功 3、手动复制ubuntu2,ubuntu3 ~/.ssh/id_dsa.pub 文件内容添加到ubuntu1的~/.ssh/authorized_keys 文件中； 或者分别执行以下代码（注：zhou是用户名）： 在ubuntu2中执行 $ scp ~/.ssh/id_dsa.pub zhou@ubuntu1:~/.ssh/authorized_keys 在ubuntu3中执行 $ scp ~/.ssh/id_dsa.pub zhou@ubuntu1:~/.ssh/authorized_keys
推荐阅读
