Spark Streaming基础概念介绍

博客地址: http://blog.csdn.net/yueqian_zhu/

有很多文章讲解storm与spark streaming的区别，都非常详细。

本文就介绍一下spark streaming比较重要的概念

一、术语介绍：

离散流（discretized stream）或DStream：这是Spark Streaming对内部持续的实时数据流的抽象描述，即我们处理的一个实时数据流，在Spark Streaming中对应于一个DStream 实例。
批数据（batch data）：这是化整为零的第一步，将实时流数据以时间片为单位进行分批，将流处理转化为时间片数据的批处理。随着持续时间的推移，这些处理结果就形成了对应的结果数据流了。
时间片或批处理时间间隔（ batch interval）：这是人为地对流数据进行定量的标准，以时间片作为我们拆分流数据的依据。一个时间片的数据对应一个RDD实例。
窗口长度（window length）：一个窗口覆盖的流数据的时间长度。必须是批处理时间间隔的倍数，
滑动时间间隔：前一个窗口到后一个窗口所经过的时间长度。必须是批处理时间间隔的倍数，默认同批处理时间间隔
Input DStream :一个input DStream是一个特殊的DStream，将Spark Streaming连接到一个外部数据源来读取数据。
二、特点

Storm可以实现亚秒级时延的处理，而每次只处理一条event，而Spark Streaming可以在一个短暂的时间窗口里面处理多条(batches)Event。所以说Storm可以实现亚秒级时延的处理，而Spark
Streaming则有一定的时延。
在Storm中，每条记录在系统的移动过程中都需要被标记跟踪，所以Storm只能保证每条记录最少被处理一次（Trident代价很大）。storm可以由一个spout和多个blot组成，每个bolt处理不同的业务逻辑，只有在成功处理spout和所有bolt之后才认为这条tuple处理成功，否则失败。这样就有可能导致一些bolt处理成功，一些bolt处理失败的时候。当处理失败的tuple重新处理时，之前成功处理的bolt又被处理了一次，在一些业务场景中有可能导致错误。而Spark
streaming底层依赖spark core，每个批处理数据都是一个RDD。这个原始的RDD经过一系列的转换，最终由action触发执行。如果某个分区处理失败，这个partition会被标记为失败。对于输入源数据，会自动地持久化在内存中供后续操作使用，并复制到不同的节点以保证容错。
spark streaming会将接收到的数据全部存储于内部的内存区域中，所以需要设置合理的spark.cleaner.ttl来及时清理超时无用数据。这个参数需要小心设置以免后续操作中所需数据被超时而错误清理。更合适的方式是将spark.streaming.unpersist设置为true，使系统自动清理不需要使用的RDD。
三、节点失效
1、工作节点失效：由于输入数据在hdfs或者有备份数据，每次转换结果都是一致的，因此总会得到相同的结果。而对于输出而言，只能确保“至少处理一次”。
2、驱动节点失效：如果driver挂掉了，那streamingContext就消失了。通过ssc.checkpoint<dir>设置记录点，周期性的将DStream元信息写入HDFS。一旦失效，就能恢复出来。通过调用函数streamingContext.getOrCreate来开启这个特性。注意，如果程序重新编译了，那就必须重建streamingContext，否则就可能读取时反序列化失败。在驱动节点失效的情况下，standalone模式下可以自动恢复，而其他模式需要依赖其它机制。

具体实现原理见 spark streaming源码分析