关于spark:用Spark进行实时流计算

2次阅读

共计 2928 个字符，预计需要花费 8 分钟才能阅读完成。

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 一战的能力。

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 了。

绝对的，来看下 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）。
能够应用与静态数据批处理计算雷同的形式来表白流计算。