《Spark Streaming实时流式大数据处理实战》 ——1.2 流式处理与Spark Streaming

1.2  流式处理与Spark Streaming

　　在很多实时数据处理的场景中，都需要用到流式处理框架，Spark也包含了一个完整的流式处理框架Spark Streaming。本节我们先阐述流式处理框架，之后介绍Spark Streaming。

1.2.1  流式处理框架

　　在传统的数据处理过程中，我们往往先将数据存入数据库中，当需要的时候再去数据库中进行检索查询，将处理的结果返回给请求的用户；另外，MapReduce这类大数据处理框架，更多应用在离线计算场景中。而对于一些实时性要求较高的场景，我们期望延迟在秒甚至毫秒级别，就需要引出一种新的数据计算结构——流式计算，对无边界的数据进行连续不断的处理、聚合和分析。

　　流式处理任务是大数据处理中很重要的一个分支，关于流式计算的框架也有很多，如比较出名的Storm流式处理框架，是由Nathan Marz等人于2010年最先开发，之后将Storm开源，成为Apache的顶级项目，Trident对Storm进行了一个更高层次的抽象；另外由LinkedIn贡献给社区的Samza也是一种流处理解决方案，不过其构建严重依赖于另一个开源项目Kafka。

　　Spark Streaming构建在Spark的基础之上，随着Spark的发展，Spark Streaming也受到了越来越多的关注。

　　不同的流式处理框架有不同的特点，也适应不同的场景。

　　1．处理模式

　　对于流式处理框架而言，有两种完全不同的处理模式。一种是原生流处理（Native）的方式，即所有输入记录会一条接一条地被处理，上面我们提到的Storm和Samza都是采用这种方式。

　　另外一种是微批处理（Batch）的方式，将输入的数据以某一时间间隔T，切分成多个微批量数据，然后对每个批量数据进行处理，Spark Streaming和Trident采用的是这种方式。两种处理模式的区别，如图1.5所示。

图1.5  流式处理框架的不同处理模式

　　2．消息传输保障

　　一般有3种消息传输保障，分别是At most once、At least once和Exactly once。At most once表示每条消息传输的次数为0次或者1次，即消息可能会丢失；At least once表示每条消息传输的次数大于等于1次，即消息传输可能重复传输但保证不会丢失；Exactly once表示每条消息只会精确地传递1次，即消息传输过程中既不会丢失，也不会重复。Storm和Samza保证了At least once，而Spark Streaming和Trident保证了Exactly once。

　　3．容错机制

　　在企业的日常生产环境中，流式处理发生中断出错的现象是常有的情况，可能是发生在网络部分、某个节点宕机或程序异常等。

　　因此流式处理框架应该具备容错能力，当发生错误导致任务中断后，应该能够恢复到之前成功的状态重新消费。Storm和Trident是利用记录确认机制（Record ACKs）来提供容错功能，Samza采用了基于日志的容错方式，而Spark Streaming则采用了基于RDD Checkpoint的方式进行容错。

　　4．性能

　　流式处理框架自然要关注一些性能指标，从而了解不同框架的特点，包括延迟时间（Latency）和吞吐量（Throughput）等指标。Storm和Samza采用了逐条处理记录的方式，其延迟时间很低，其中Storm在实时性方面表现更加优异；而Spark Streaming和Trident采用了微批处理的方式，所以其延迟时间较高。另一方面，在吞吐量上，Spark Streaming和Samza的表现要优于Storm和Trident。

　　通过流式处理框架的介绍，以及和不同流式处理框架的比较，我们了解了Spark Streaming作为新兴的流式处理框架的特点，下面对Spark Streaming做一些更加详细的介绍。