Spark Streaming笔记整理（一）：基本工作原理介绍

概述

大数据实时计算介绍

1、Spark Streaming，其实就是一种Spark提供的，对于大数据，进行实时计算的一种框架。它的底层，其实，也是基于我们之前讲解的Spark Core的。基本的计算模型，还是基于内存的大数据实时计算模型。而且，它的底层的核心组件还是我们在Spark Core中经常用到的RDD。

2、针对实时计算的特点，在RDD之上，进行了一层封装，叫做DStream。其实，学过了Spark SQL之后，你理解这种封装就容易了。之前学习Spark SQL是不是也是发现，它针对数据查询这种应用，提供了一种基于RDD之上的全新概念，DataFrame，但是，其底层还是基于RDD的。所以，RDD是整个Spark技术生态中的核心。

正如市面上存在众多可用的流处理引擎，人们经常询问我们Spark Streaming有何独特的优势？那么首先要说的就是Apache Spark在批处理以及流处理上提供了原生支持。这与别的系统不同之处在于其他系统的处理引擎要么只专注于流处理，要么只负责批处理且仅提供需要外部实现的流处理API接口而已。Spark 凭借其执行引擎以及统一的编程模型可实现批处理与流处理，这就是与传统流处理系统相比Spark Streaming所具备独一无二的优势。尤其特别体现在以下四个重要部分：

1.能在故障报错与straggler的情况下迅速恢复状态；
2.更好的负载均衡与资源使用；
3.静态数据集与流数据的整合和可交互查询；
4.内置丰富高级算法处理库（SQL、机器学习、图处理）

流处理架构——过去与现在1

当前分布式流处理管道执行方式如下所述：

1、接收来自数据源的流数据（比如时日志、系统遥测数据、物联网设备数据等等），处理成为数据摄取系统，比如Apache Kafka、Amazon Kinesis等等。

2、在集群上并行处理数据。这也是设计流处理引擎的关键所在，我们将在下文中做出更细节性的讨论。

3、输出结果存放至下游系统（例如HBase、Cassandra, Kafka等等）。

为了处理这些数据，大部分传统的流处理系统被设计为连续算子 模型，其工作方式如下：

1、有一系列的工作节点，每组节点运行一至多个连续算子；

2、对于流数据，每个连续算子一次处理一条记录，并且将记录传输给管道中别的算子；

3、源算子从摄入系统接收数据，接着输出到下游系统。

流处理架构——过去与现在2

1、连续算子是一种较为简单、自然的模型。然而,随着如今大数据时代下，数据规模的不断扩大以及越来越复杂的实时分析，这个传统的架构也面临着严峻的挑战。因此，我们设计Spark Streaming就是为了解决如下几点需求：

2、故障迅速恢复–数据越庞大，出现节点故障与节点运行变慢（例如straggler）情况的概率也越来越高。因此，系统要是能够实时给出结果,就必须能够自动修复故障。可惜在传统流处理系统中，在这些工作节点静态分配的连续算子要迅速完成这项工作仍然是个挑战；

3、负载均衡–在连续算子系统中工作节点间不平衡分配加载会造成部分节点性能的bottleneck（运行瓶颈）。这些问题更常见于大规模数据与动态变化的工作量面前。为了解决这个问题，那么要求系统必须能够根据工作量动态调整节点间的资源分配；

4、统一的流处理与批处理以及交互工作–在许多用例中，与流数据的交互是很有必要的（毕竟所有流系统都将这置于内存中）或者与静态数据集结合（例如pre-computed model）。这些都很难在连续算子系统中实现，当系统动态地添加新算子时，并没有为其设计临时查询功能，这样大大的削弱了用户与系统的交互能力。因此我们需要一个引擎能够集成批处理、流处理与交互查询；

5、高级分析（例如机器学习、SQL查询等等）–一些更复杂的工作需要不断学习和更新数据模型，或者利用SQL查询流数据中最新的特征信息。因此，这些分析任务中需要有一个共同的集成抽象组件，让开发人员更容易地去完成他们的工作。

6、为了解决这些要求，Spark Streaming使用了一个新的结构，我们称之为discretized streams（离散化的流数据处理），它可以直接使用Spark引擎中丰富的库并且拥有优秀的故障容错机制。

Spark Streaming简单介绍

1、Spark的运行模式多种多样，灵活多变，部署在单机上时，既可以用本地模式运行，也可以用伪分布式模式运行；而当以分布式集群的方式部署时，也有众多的运行模式可供选择，这取决于集群的实际情况，底层的资源调度既可以依赖于外部的资源调度框架，也可以使用Spark内建的Standalone模式。对于外部资源调度框架的支持，目前的实现包括相对稳定的Mesos模式，以及还在持续开发更新中的Hadoop YARN模式。

2、Spark Streaming是Spark Core API的一种扩展，它可以用于进行大规模、高吞吐量、容错的实时数据流的处理。它支持从很多种数据源中读取数据，比如Kafka、Flume、Twitter、ZeroMQ、Kinesis、ZMQ或者是TCP Socket。并且能够使用类似高阶函数的复杂算法来进行数据处理，比如map、reduce、join和window。处理后的数据可以被保存到文件系统、数据库、Dashboard等存储中。

Spark Streaming基本工作原理

接收实时输入数据流，然后将数据拆分成多个batch，比如每收集1秒的数据封装为一个batch，然后将每个batch交给Spark的计算引擎进行处理，最后会生产出一个结果数据流，其中的数据，也是由一个一个的batch所组成的。

Spark Streaming DStream

1、Spark Streaming提供了一种高级的抽象，叫做DStream，英文全称为Discretized Stream，中文翻译为“离散流”，它代表了一个持续不断的数据流。DStream可以通过输入数据源来创建，比如Kafka、Flume、ZMQ和Kinesis；也可以通过对其他DStream应用高阶函数来创建，比如map、reduce、join、window。

2、DStream的内部，其实一系列持续不断产生的RDD。RDD是Spark Core的核心抽象，即，不可变的，分布式的数据集。DStream中的每个RDD都包含了一个时间段内的数据。

1、对DStream应用的算子，比如map，其实在底层会被翻译为对DStream中每个RDD的操作。比如对一个DStream执行一个map操作，会产生一个新的DStream。但是，在底层，其实其原理为，对输入DStream中每个时间段的RDD，都应用一遍map操作，然后生成的新的RDD，即作为新的DStream中的那个时间段的一个RDD。底层的RDD的transformation操作。

2、还是由Spark Core的计算引擎来实现的。Spark Streaming对Spark Core进行了一层封装，隐藏了细节，然后对开发人员提供了方便易用的高层次的API。

与其它流式框架对比分析

Spark Streaming、Flink和Storm对比

对比点	Storm	Spark Streaming	Flink
实时计算模型	纯实时，来一条数据处理一条	1、准实时，对一个时间段的RDD数据收集起来，一起处理	流式计算和批处理分别采用DataStream和DataSet
实时计算延迟度	毫秒级	秒级	秒级
吞吐量	低	高	高
事务机制	支持完善	支持，但不够完善	支持，但不够完善
健壮性/容错性	ZK、Acker,很好	CheckPoint，WAL一般	CheckPoint一般
动态调整并行度	支持	不支持	支持
运行时同时支持流失和离线处理	不支持	支持	支持
成熟度	高	高	低
模型	native	Micro-batching	native
API	组合式	声明式	组合式

• 组合式：操作更加基础的API操作，一步步精细控制，各组件组合定义成拓扑；
• 声明式：提供封装后的高阶函数。封装后可提供初步的优化；可提供窗口管理、状态管理等高级操作；

Spark Streaming、Flink和Storm的优势分析

1、Spark Streaming绝对谈不上比Storm、Flink优秀。这两个框架在实时计算领域中，都很优秀，只是擅长的细分场景并不相同。

2、Spark Streaming在吞吐量上要比Storm优秀。

3、Storm在实时延迟度上，比Spark Streaming就好多了，前者是纯实时，后者是准实时。而且，Storm的事务机制、健壮性/容错性、动态调整并行度等特性，都要比Spark Streaming更加优秀。

4、Spark Streaming，有一点是Storm绝对比不上的，就是：它位于Spark整个生态技术栈中，因此Spark Streaming可以和Spark Core、Spark SQL、Spark　Ｇraphx无缝整合，换句话说，我们可以对实时处理出来的中间数据，立即在程序中无缝进行延迟批处理、交互式查询等操作。这个特点大大增强了Spark Streaming的优势和功能。

Spark Streaming、Flink和Storm的应用场景

Storm

1、建议在需要纯实时，不能忍受1秒以上延迟的场景下使用，比如实时计算系统，要求纯实时进行交易和分析时。

2、在实时计算的功能中，要求可靠的事务机制和可靠性机制，即数据的处理完全精准，一条也不能多，一条也不能少，也可以考虑使用Storm，但是Spark Streaming也可以保证数据的不丢失。

3、如果我们需要考虑针对高峰低峰时间段，动态调整实时计算程序的并行度，以最大限度利用集群资源（通常是在小型公司，集群资源紧张的情况），我们也可以考虑用Storm

Spark Streaming

1、不满足上述3点要求的话，我们可以考虑使用Spark Streaming来进行实时计算。

2、考虑使用Spark Streaming最主要的一个因素，应该是针对整个项目进行宏观的考虑，即，如果一个项目除了实时计算之外，还包括了离线批处理、交互式查询、图计算和MLIB机器学习等业务功能，而且实时计算中，可能还会牵扯到高延迟批处理、交互式查询等功能，那么就应该首选Spark生态，用Spark Core开发离线批处理，用Spark SQL开发交互式查询，用Spark Streaming开发实时计算，三者可以无缝整合，给系统提供非常高的可扩展性。

Flink

1.支持高吞吐、低延迟、高性能的流处理
2.支持带有事件时间的窗口（Window）操作
3.支持有状态计算的Exactly-once语义
4.支持高度灵活的窗口（Window）操作，支持基于time、count、session，以及data-driven的窗口操作
5.支持具有Backpressure功能的持续流模型 6.支持基于轻量级分布式快照（Snapshot）实现的容错 7.一个运行时同时支持Batch on Streaming处理和Streaming处理 8.Flink在JVM内部实现了自己的内存管理 9.支持迭代计算 10.支持程序自动优化：避免特定情况下Shuffle、排序等昂贵操作，中间结果有必要进行缓存


原文链接：http://blog.51cto.com/xpleaf/2114744