Spark、Hadoop、Storm对比

发表于   |  

Spark streaming和storm、Hadoop与Spark的对比

Spark 与 Hadoop 的对比

  • 原生语言：Hadoop-JAVA，Spark-scala

  • 计算模型：Hadoop-MapReduce，Spark-DAG（有向无环图）
    经常有人说Spark就是内存版的MapReduce，实际上不是的。Spark使用的DAG计算模型可以有效的减少Map和Reduce人物之间传递的数据，尤其适合反复迭代的机器学习场景。而Hadoop则更擅长批处理。不过Tez也是使用的DAG计算模型，他也是Hadoop，明眼人都知道DAG计算模型比MR更好。

  • Spark的提出很大程度上是为了解决MapReduce在处理迭代算法上的缺陷。apReduce的缺陷很多，最大的缺陷之一是Map ＋ Reduce的模型。这个模型并不适合描述复杂的数据处理过程。由于MapReduce的数据流是acyclic的，且数据存储在磁盘，这就导致在迭代计算时需要反复进行磁盘读写操作，大大降低了计算效率。而事实上当前机器学习的大多数算法都是迭代算法，因此解决这一问题具有很大的应用价值。
  • Spark解决这一问题的方法是提供了一个更强大的primitive数据抽象模型–RDD(Resilient Distributed Datasets)，并定义了一系列转化（map,filter,sample,…）和分布式操作(reduce,collect,count…)。
  • 存储：Hadoop-HDFS， Spark-RDD，HDFS
    Spark既可以仅用内存存储，也可以在HDFS上存储，即使Spark在HDFS上存储，DAG计算模型在迭代计算上还是比MR的更有效率。
    实际上从应用场景上区分，Hadoop更适合做批处理，而Spark更适合做需要反复迭代的机器学习。
  • Spark的优势不仅体现在性能提升上的，Spark框架为批处理（Spark Core），交互式（Spark SQL），流式（Spark Streaming），机器学习（MLlib），图计算（GraphX）提供一个统一的数据处理平台，这相对于使用Hadoop有很大优势。

那么Spark解决了Hadoop的哪些问题呢？

  • 抽象层次低，需要手工编写代码来完成，使用上难以上手。
    • =>基于RDD的抽象，实数据处理逻辑的代码非常简短。。
  • 只提供两个操作，Map和Reduce，表达力欠缺。
    • =>提供很多转换和动作，很多基本操作如Join，GroupBy已经在RDD转换和动作中实现。
  • 一个Job只有Map和Reduce两个阶段（Phase），复杂的计算需要大量的Job完成，Job之间的依赖关系是由开发者自己管理的。
    • =>一个Job可以包含RDD的多个转换操作，在调度时可以生成多个阶段（Stage），而且如果多个map操作的RDD的分区不变，是可以放在同一个Task中进行。
  • 处理逻辑隐藏在代码细节中，没有整体逻辑
    • =>在Scala中，通过匿名函数和高阶函数，RDD的转换支持流式API，可以提供处理逻辑的整体视图。代码不包含具体操作的实现细节，逻辑更清晰。
  • 中间结果也放在HDFS文件系统中
    • =>中间结果放在内存中，内存放不下了会写入本地磁盘，而不是HDFS。
  • ReduceTask需要等待所有MapTask都完成后才可以开始
    • => 分区相同的转换构成流水线放在一个Task中运行，分区不同的转换需要Shuffle，被划分到不同的Stage中，需要等待前面的Stage完成后才可以开始。
  • 时延高，只适用Batch数据处理，对于交互式数据处理，实时数据处理的支持不够
    • =>通过将流拆成小的batch提供Discretized Stream处理流数据。
  • 对于迭代式数据处理性能比较差
    • =>通过在内存中缓存数据，提高迭代式计算的性能。

Spark streaming&storm流计算的相关对比

Spark streaming和Storm作为当今流行的实时流计算框架，已经在实时计算方案应用的非常广泛了，其中Spark streaming是基于Spark的一个扩展，比storm的出现要晚一些。本节从以下几个角度对两者进行了阐述，可以作为选型方面的一个参考。

数据处理方式

Spark streaming是构建在Spark上的实时流计算框架，利用时间批量窗口生成Spark的计算输入源RDD，后对该RDD生成Job，进行排队调度到Spark计算框架中执行，底层是基于Spark资源调度和任务计算框架的；Spark streaming是基于数据的批处理方式，针对数据形成任务进行计算，是移动计算而不移动数据，而Storm恰恰相反，storm在处理架构上是数据流入到计算节点，移动的是数据而不是计算，对于时间窗口的批量数据处理，需要用户自己来实现，这个在之前的storm系列的相关章节中有介绍。

生态体系

Spark streaming是基于Spark的，可以和Spark其他的组件结合，实现交互式的查询adhoc，机器学习MLib等。Storm相对来讲，只是作为一个流式计算框架，缺乏现有的Hadoop生态体系的融合。

延迟以及吞吐量

Spark streaming基于对批量数据的处理，依赖Spark的调度和计算框架，在延迟方面比storm要高，一般最小的延迟在2s左右，而storm可以达到100ms以内。正因为Spark streaming是批处理的方式处理数据，整体的吞吐量比较高。

容错性

Spark streaming通过lineage以及在内存维护两份数据备份进行容错，通过lineage记录之前对RDD的操作，若某节点在运行时候出现故障，则可以通过备份数据在其他节点重新计算得到。

Storm通过ack组件进行数据流的跟踪，开销比Sparking streaming要大。

事务性

Spark streaming保证数据只被处理一次，并且是在批处理的层次级别。

Storm通过跟踪机制能保证每个记录至少被处理一次，如果需要保证状态只更新一次的话，需要由用户自己来实现。

所以对于statefull的计算，对事务性比较高的话，Spark streaming要更好一些。

参考

与 Hadoop 对比，如何看待 Spark 技术？
Spark streaming&storm流计算的相关对比
Spark Streaming实时计算框架介绍