hadoop与spark的区别与联系Spark能否成为Hadoop的替代者呢？为什么？它们有哪些相似点与区别？
两者的侧重点不同，使用场景不同，个人认为没有替代之说。Spark更适合于迭代运算比较多的ML和DM运算。因为在Spark里面，有RDD的概念。RDD可以cache到内存中，那么每次对RDD数据集的操作之后的结果，都可以存放到内存中，下一个操作可以直接从内存中输入，省去了MapReduce大量的磁盘IO操作。但是，我们也要看到spark的限制：内存。我认为Hadoop虽然费时，但是在OLAP等大规模数据的应用场景，还是受欢迎的。目前Hadoop涵盖了从数据收集、到分布式存储，再到分布式计算的各个领域，在各领域都有自己独特优势。
Spark目前还只能比较好对Hadoop的Mapreduce框架进行比较好的替代，Hadoop其他组件特别是HDFS、HBASE、Yarn还是作为基础组件对云计算的存储和资源管理提供了底层的框架，一些组件如SparkSQl和Hive类似，Spark需重点发展计算能力，能够提供比较多可视化数据处理和挖掘工具，不存在互相替代的，大家各自发挥优点，使大数据整个生态链更完善。Spark的特点
Spark极大的优化和简化了Mapreduce框架，使分布式云计算细粒度深入到数据的各个环节，通过RDD模型对并行数据处理这个高难度技术堆栈进行了全方位的创新，就象多年前Delphi 对可视化和面向对象的开发进行的推动一样，spark的RDD计算模型是革命性的将会引领潮流，如果再能能够发展到象kettle那样提供可视的界面组件并行云计算功能就更完美，RDD 计算模型只需要用参数或简单标识符，就可以高效利
用云计算资源，支持多种并行和迭代计算模式，非常适合各种大数据挖掘算法，能充分利用内存，使数据处理效率提升的1-2个数量级，同时能和Hadoop体系的HDFS、Yarn等基础框架兼容，Spark框架采用的是Scala语言，Scala语言集面向对象和函数式优点，Scala非常简洁，函数式编程能够非常高效的在已有的处理处理模型上增加或调整各种业务逻辑，对于大数据时代这种处理需求全动态，数据类型变化多样的业务模式提供了强有力的技术支撑，Scala入门还是需要有些概念转换，如：隐式转换、语法糖果等，但理解了这些新概念，上手就比较容易。
作为一种内存的迭代计算框架，Spark适用哪些场景？
适用于迭代次数比较多的场景。迭代次数多的机器学习算法等。如pageRank、K-Means等。主要用在并行数据处理和迭代，以及一些机器学习方面如：K-Means等，特别更高效提升在处理过程中，需要在多次频繁用到查询和搜索功能的场景，如果这些场景不利用内存，效率会低几个数量级，用简单加节点并行计算是根本无法解决的。
Hadoop的适用场景
hadoop 主要用于大数据的并行计算
并行计算按计算特征分为
数据密集型并行计算：数据量极大，但是计算相对简单的并行处理
如：大规模Web信息搜索
计算密集型并行计算：数据量相对不是很大，但是计算较为复杂的并行计算
如：3-D建模与渲染，气象预报，科学计算
数据密集与计算密集混合型的并行计算
如：3－D电影的渲染
hadoop比较擅长的是数据密集的并行计算。
它主要是对不同的数据做相同的事情，最后再整合。
由于批量处理功能，Hadoop应该部署在这些场合：索引编制、模式识别、推荐引擎建立和情绪分析；在所有这些场合下，数据大量生成，存储在Hadoop中，然后最终使用MapReduce 函数来进行查询。
Hadoop的处理特点
1. Hadoop是数据并行，处理串行. 在一个工作中job, 并行只在一个map段和一个reduce 段中发生. 但是这两个段不能并行运行, reduce段直到map段完全完成后才能开始。
2.所有被map过程访问的数据都必须被冻结(也不能有修改发生)，直至整个工作job完成. 这就意味做Hadoop处理数据是在一个面向批处理batch-oriented风格的链条中实现的，这就注定它不适合在基于流stream-based处理的方式，在流处理中，数据流是持续的必须立即得到及时处理。
3.数据之间联系是通过一个分布式文件系统(HDFS)完成. 延迟会因为网络I/O开销发生了，这种延迟不会成为面向批处理模式的主要问题，在面向批处理模式中，吞吐量才是首要考虑的，但是这意味做Hadoop不适合实现对延迟要求很严格，甚至不允许有延迟发生的在线实时系统。
根据Hadoop以上特点，给出下来Hadoop不适合的场合：
1.需要数据低延迟性的在线数据处理，（比如股票系统，更新需要让所有人及时知道，不能有丝毫延迟。)
2.在一个大数据集中执一个小数据集的随机ad/hoc处理。
3.执行实时/基于流的处理模式，数据持续到达需要立即被处理(如视频等)。
Hadoop的适用场景
1：超大文件
可以是几百M，几百T这个级别的文件。
2：流式数据访问
Hadoop适用于一次写入，多次读取的场景，也就是数据复制进去之后，长时间在这些数据上进行分析。
3：商业硬件
也就是说大街上到处都能买到的那种硬件，这样的硬件故障率较高，所以要有很好的容错机制。
Hadoop的不适用的场景
1：低延迟数据访问
Hadoop设计的目的是大吞吐量，所以并没有针对低延迟数据访问做一些优化，如果要求低延迟，可以看看Hbase。
2：大量的小文件
由于NameNode把文件的MetaData存储在内存中，所以大量的小文件会产生大量的MetaData。这样的话百万级别的文件数目还是可行的，再多的话就有问题了。
3：多用户写入，任意修改
Hadoop现在还不支持多人写入，任意修改的功能。也就是说每次写入都会添加在文件末尾。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。