大数据培训：Spark和Spark Streaming的区别
作者：张老师 浏览次数： 2021-03-17 17:46
作为业界主流的开源大数据处理框架之一，Spark的地位还是值得肯定的。在面对大规模的离线批处理任务上，Spark性能优异，同时又有Spark Streaming来负责流计算处理。今天的大数据培训分享，我们主要来聊聊Spark和Spark Streaming的区别。
Spark用于进行分布式、大规模的数据处理，是在MapReduce的基础上进行了优化，提供了更高级的编程接口、更高的性能。Spark进行常规的批处理计算，Spark Streaming提供流式计算支持。
从Hadoop MapReduce到Spark
Hadoop是大数据处理领域的开创者。严格来说，Hadoop不只是一个软件，而是一整套生态系统，例如MapReduce负责进行分布式计算，而HDFS负责存储大量文件。
MapReduce模型的诞生是大数据处理从无到有的飞跃。但随着技术的进步，对大数据处理的需求也变得越来越复杂，MapReduce的问题也日渐凸显。通常，我们将MapReduce的输入和输出数据保留在HDFS上，很多时候，复杂的ETL、数据清洗等工作无法用一次MapReduce完成，所以需要将多个MapReduce过程连接起来。
这种方式下，每次中间结果都要写入HDFS落盘保存，代价很大（别忘了，HDFS的每份数据都需要冗余若干份拷贝）。另外，由于本质上是多次MapReduce任务，调度也比较麻烦，实时性无从谈起。
Spark与RDD模型
针对上面的问题，如果能把中间结果保存在内存里，岂不是快的多？之所以不能这么做，最大的障碍是：分布式系统必须能容忍一定的故障，所谓fault-tolerance。如果只是放在内存中，一旦某个计算节点宕机，其他节点无法恢复出丢失的数据，只能重启整个计算任务，这对于动辄成百上千节点的集群来说是不可接受的。
一般来说，想做到fault-tolerance只有两个方案：要么存储到外部（例如HDFS），要么拷贝到多个副本。Spark大胆地提出了第三种——重算一遍。但是之所以能做到这一点，是依赖于一个额外的假设：所有计算过程都是确定性的（deterministic）。Spark借鉴了函数式编程思想，提出了RDD（Resilient Distributed Datasets），译作“弹性分布式数据集”。
RDD是一个只读的、分区的（partitioned）数据集合。RDD要么来源于不可变的外部文件（例如HDFS上的文件），要么由确定的算子由其他RDD计算得到。
回到刚刚的问题，RDD如何做到fault-tolerance？很简单，RDD中的每个分区都能被确定性的计算出来，所以一旦某个分区丢失了，另一个计算节点可以从它的前继节点出发、用同样的计算过程重算一次，即可得到完全一样的RDD分区。这个过程可以递归的进行下去。
流计算框架：Spark Streaming
以往，批处理和流计算被看作大数据系统的两个方面。我们常常能看到这样的架构——以Kafka、Storm为代表的流计算框架用于实时计算，而Spark或MapReduce则负责每天、每小时的数据批处理。在ETL等场合，这样的设计常常导致同样的计算逻辑被实现两次，耗费人力不说，保证一致性也是个问题。
Spark Streaming正是诞生于此类需求。传统的流计算框架大多注重于低延迟，采用了持续的（continuous）算子模型；而Spark Streaming基于Spark，另辟蹊径提出了D-Stream（Discretized Streams）方案：将流数据切成很小的批（micro-batch），用一系列的短暂、无状态、确定性的批处理实现流处理。
Spark Streaming的做法在流计算框架中很有创新性，它虽然牺牲了低延迟（一般流计算能做到100ms级别，Spark Streaming延迟一般为1s左右），但是带来了三个诱人的优势：
更高的吞吐量（大约是Storm的2-5倍）
更快速的失败恢复（通常只要1-2s），因此对于straggler（性能拖后腿的节点）直接杀掉即可
开发者只需要维护一套ETL逻辑即可同时用于批处理和流计算
关于大数据培训，Spark和Spark Streaming的区别，以上就从历史源流为大家做了简单的介绍了。从Hadoop到Spark到Spark Streaming，其实也代表着数据处理的场景在不断变化，而相应地技术框架也在不断迭代更新以适应更新的需求。成都加米谷大数据，专业大数据培训机构，大数据开发、数据分析与挖掘，零基础就业班本月正在招生中，课程大纲及学习视频可联系客服获取！
Spark用于进行分布式、大规模的数据处理，是在MapReduce的基础上进行了优化，提供了更高级的编程接口、更高的性能。Spark进行常规的批处理计算，Spark Streaming提供流式计算支持。
从Hadoop MapReduce到Spark
Hadoop是大数据处理领域的开创者。严格来说，Hadoop不只是一个软件，而是一整套生态系统，例如MapReduce负责进行分布式计算，而HDFS负责存储大量文件。
MapReduce模型的诞生是大数据处理从无到有的飞跃。但随着技术的进步，对大数据处理的需求也变得越来越复杂，MapReduce的问题也日渐凸显。通常，我们将MapReduce的输入和输出数据保留在HDFS上，很多时候，复杂的ETL、数据清洗等工作无法用一次MapReduce完成，所以需要将多个MapReduce过程连接起来。
这种方式下，每次中间结果都要写入HDFS落盘保存，代价很大（别忘了，HDFS的每份数据都需要冗余若干份拷贝）。另外，由于本质上是多次MapReduce任务，调度也比较麻烦，实时性无从谈起。
Spark与RDD模型
针对上面的问题，如果能把中间结果保存在内存里，岂不是快的多？之所以不能这么做，最大的障碍是：分布式系统必须能容忍一定的故障，所谓fault-tolerance。如果只是放在内存中，一旦某个计算节点宕机，其他节点无法恢复出丢失的数据，只能重启整个计算任务，这对于动辄成百上千节点的集群来说是不可接受的。
一般来说，想做到fault-tolerance只有两个方案：要么存储到外部（例如HDFS），要么拷贝到多个副本。Spark大胆地提出了第三种——重算一遍。但是之所以能做到这一点，是依赖于一个额外的假设：所有计算过程都是确定性的（deterministic）。Spark借鉴了函数式编程思想，提出了RDD（Resilient Distributed Datasets），译作“弹性分布式数据集”。
RDD是一个只读的、分区的（partitioned）数据集合。RDD要么来源于不可变的外部文件（例如HDFS上的文件），要么由确定的算子由其他RDD计算得到。
回到刚刚的问题，RDD如何做到fault-tolerance？很简单，RDD中的每个分区都能被确定性的计算出来，所以一旦某个分区丢失了，另一个计算节点可以从它的前继节点出发、用同样的计算过程重算一次，即可得到完全一样的RDD分区。这个过程可以递归的进行下去。
流计算框架：Spark Streaming
以往，批处理和流计算被看作大数据系统的两个方面。我们常常能看到这样的架构——以Kafka、Storm为代表的流计算框架用于实时计算，而Spark或MapReduce则负责每天、每小时的数据批处理。在ETL等场合，这样的设计常常导致同样的计算逻辑被实现两次，耗费人力不说，保证一致性也是个问题。
Spark Streaming正是诞生于此类需求。传统的流计算框架大多注重于低延迟，采用了持续的（continuous）算子模型；而Spark Streaming基于Spark，另辟蹊径提出了D-Stream（Discretized Streams）方案：将流数据切成很小的批（micro-batch），用一系列的短暂、无状态、确定性的批处理实现流处理。
Spark Streaming的做法在流计算框架中很有创新性，它虽然牺牲了低延迟（一般流计算能做到100ms级别，Spark Streaming延迟一般为1s左右），但是带来了三个诱人的优势：
更高的吞吐量（大约是Storm的2-5倍）
更快速的失败恢复（通常只要1-2s），因此对于straggler（性能拖后腿的节点）直接杀掉即可
开发者只需要维护一套ETL逻辑即可同时用于批处理和流计算
关于大数据培训，Spark和Spark Streaming的区别，以上就从历史源流为大家做了简单的介绍了。从Hadoop到Spark到Spark Streaming，其实也代表着数据处理的场景在不断变化，而相应地技术框架也在不断迭代更新以适应更新的需求。成都加米谷大数据，专业大数据培训机构，大数据开发、数据分析与挖掘，零基础就业班本月正在招生中，课程大纲及学习视频可联系客服获取！
