用Spark进行实时流计算

Spark Streaming VS Structured Streaming

Spark Streaming是Spark最初的流处理框架，使用了微批的形式来进行流处理。

提供了基于RDDs的Dstream API，每一个时间间隔内的数据为一个RDD，源源不断对RDD进行处理来实现流计算

Apache Spark 在 2016 年的时候启动了 Structured Streaming 项目，一个基于 Spark SQL 的全新流计算引擎 Structured Streaming，让用户像编写批处理程序同样简单地编写高性能的流处理程序。

Structured Streaming是Spark2.0版本提出的新的实时流框架（2.0和2.1是实验版本，从Spark2.2开始为稳定版本)

从Spark-2.X版本后，Spark Streaming就进入维护模式，看见Spark已经将大部分精力投入到了全新的Structured Streaming中，而一些新特性也只有Structured Streaming才有，这样Spark才有了与Flink一战的能力。

一、Spark Streaming 不足

• Processing Time 而不是 Event Time

  首先解释一下，Processing Time 是数据到达 Spark 被处理的时间，而 Event Time 是数据自带的属性，通常表示数据产生于数据源的时间。好比 IoT 中，传感器在 12:00:00 产生一条数据，而后在 12:00:05 数据传送到 Spark，那么 Event Time 就是 12:00:00，而 Processing Time 就是 12:00:05。咱们知道 Spark Streaming 是基于 DStream 模型的 micro-batch 模式，简单来讲就是将一个微小时间段，好比说 1s，的流数据当前批数据来处理。若是咱们要统计某个时间段的一些数据统计，毫无疑问应该使用 Event Time，可是由于 Spark Streaming 的数据切割是基于 Processing Time，这样就致使使用 Event Time 特别的困难。

• Complex, low-level api

  这点比较好理解，DStream （Spark Streaming 的数据模型）提供的 API 相似 RDD 的 API 的，很是的 low level。当咱们编写 Spark Streaming 程序的时候，本质上就是要去构造 RDD 的 DAG 执行图，而后经过 Spark Engine 运行。这样致使一个问题是，DAG 可能会由于开发者的水平良莠不齐而致使执行效率上的天壤之别。这样致使开发者的体验很是很差，也是任何一个基础框架不想看到的（基础框架的口号通常都是：大家专一于本身的业务逻辑就好，其余的交给我）。这也是不少基础系统强调 Declarative 的一个缘由。

• reason about end-to-end application

  这里的 end-to-end 指的是直接 input 到 out，好比 Kafka 接入 Spark Streaming 而后再导出到 HDFS 中。DStream 只能保证本身的一致性语义是 exactly-once 的，而 input 接入 Spark Streaming 和 Spark Straming 输出到外部存储的语义每每须要用户本身来保证。而这个语义保证写起来也是很是有挑战性，好比为了保证 output 的语义是 exactly-once 语义须要 output 的存储系统具备幂等的特性，或者支持事务性写入，这个对于开发者来讲都不是一件容易的事情。

• 批流代码不统一

  尽管批流本是两套系统，可是这两套系通通一块儿来确实颇有必要，咱们有时候确实须要将咱们的流处理逻辑运行到批数据上面。关于这一点，最先在 2014 年 Google 提出 Dataflow 计算服务的时候就批判了 streaming/batch 这种叫法，而是提出了 unbounded/bounded data 的说法。DStream 尽管是对 RDD 的封装，可是咱们要将 DStream 代码彻底转换成 RDD 仍是有一点工做量的，更况且如今 Spark 的批处理都用 DataSet/DataFrame API 了。

2.、Structured Streaming 优点

相对的，来看下Structured Streaming优点：

• 简洁的模型。Structured Streaming 的模型很简洁，易于理解。用户能够直接把一个流想象成是无限增加的表格。

• 一致的 API。因为和 Spark SQL 共用大部分 API，对 Spaprk SQL 熟悉的用户很容易上手，代码也十分简洁。同时批处理和流处理程序还能够共用代码，不须要开发两套不一样的代码，显著提升了开发效率。

• 卓越的性能。Structured Streaming 在与 Spark SQL 共用 API 的同时，也直接使用了 Spark SQL 的 Catalyst 优化器和 Tungsten，数据处理性能十分出色。此外，Structured Streaming 还能够直接从将来 Spark SQL 的各类性能优化中受益。

• 多语言支持。Structured Streaming 直接支持目前 Spark SQL 支持的语言，包括 Scala，Java，Python，R 和 SQL。用户能够选择本身喜欢的语言进行开发。

• 一样能支持多种数据源的输入和输出，Kafka、flume、Socket、Json。

• 基于Event-Time，相比于Spark Streaming的Processing-Time更精确，更符合业务场景。

• Event time 事件时间: 就是数据真正发生的时间，好比用户浏览了一个页面可能会产生一条用户的该时间点的浏览日志。

• Process time 处理时间: 则是这条日志数据真正到达计算框架中被处理的时间点，简单的说，就是你的Spark程序是何时读到这条日志的。

• 事件时间是嵌入在数据自己中的时间。对于许多应用程序，用户可能但愿在此事件时间操做。例如，若是要获取IoT设备每分钟生成的事件数，则可能须要使用生成数据的时间（即数据中的事件时间），而不是Spark接收他们的时间。事件时间在此模型中很是天然地表示 - 来自设备的每一个事件都是表中的一行，事件时间是该行中的一个列值。

• 支持spark2的dataframe处理。

• 解决了Spark Streaming存在的代码升级，DAG图变化引发的任务失败，没法断点续传的问题。

• 基于SparkSQL构建的可扩展和容错的流式数据处理引擎，使得实时流式数据计算能够和离线计算采用相同的处理方式（DataFrame&SQL）。

• 可使用与静态数据批处理计算相同的方式来表达流计算。

底层原理彻底不一样

Spark Streaming采用微批的处理方法。每个批处理间隔的为一个批，也就是一个RDD，咱们对RDD进行操做就能够源源不断的接收、处理数据。

Structured Streaming将实时数据当作被连续追加的表。流上的每一条数据都相似于将一行新数据添加到表中。

Spark 3.0.0发布之后 全新的Structured Streaming UI诞生，可见将来的Structured Streaming将不断迎来进步。

更多Flink，Kafka，Spark等相关技术博文，科技资讯，欢迎关注实时流式计算 公众号后台回复 “电子书” 下载300页Flink实战电子书