安康创宇网站制作建设,app专业定制开发,网站长期建设 运营计划,可视化网站开发工具有哪些前言 Apache Spark在2016年的时候启动了Structured Streaming项目#xff0c;一个基于Spark SQL的全新流计算引擎Structured Streaming#xff0c;让用户像编写批处理程序一样简单地编写高性能的流处理程序。 Structured Streaming并不是对Spark Streaming的简单改进#xf…前言 Apache Spark在2016年的时候启动了Structured Streaming项目一个基于Spark SQL的全新流计算引擎Structured Streaming让用户像编写批处理程序一样简单地编写高性能的流处理程序。 Structured Streaming并不是对Spark Streaming的简单改进而是吸取了在开发Spark SQL和Spark Streaming过程中的经验教训以及Spark社区和Databricks众多客户的反馈重新开发的全新流式引擎致力于为批处理和流处理提供统一的高性能API。同时在这个新的引擎中也很容易实现之前在Spark Streaming中很难实现的一些功能比如Event Time事件时间的支持Stream-Stream Join2.3.0 新增的功能毫秒级延迟2.3.0 即将加入的 Continuous Processing。
第一章 Structured Streaming
Spark Streaming是Apache Spark早期基于RDD开发的流式系统用户使用DStream API来编写代码支持高吞吐和良好的容错。其背后的主要模型是Micro Batch微批处理也就是将数据流切成等时间间隔BatchInterval的小批量任务来执行。 Structured Streaming则是在Spark 2.0加入的经过重新设计的全新流式引擎。它的模型十分简洁易于理解。一个流的数据源从逻辑上来说就是一个不断增长的动态表格随着时间的推移新数据被持续不断地添加到表格的末尾用户可以使用Dataset/DataFrame 或者 SQL 来对这个动态数据源进行实时查询。 文档http://spark.apache.org/docs/2.4.5/structured-streaming-programming-guide.html
1.1 Spark Streaming 不足
Spark Streaming 会接收实时数据源的数据并切分成很多小的batches然后被Spark Engine执行产出同样由很多小的batchs组成的结果流。 本质上这是一种micro-batch微批处理的方式处理用批的思想去处理流数据。这种设计让Spark Streaming面对复杂的流式处理场景时捉襟见肘。 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
DStreamSpark Streaming 的数据模型提供的API类似RDD的API非常的low level当编写Spark Streaming程序的时候本质上就是要去构造RDD的DAG执行图然后通过Spark Engine运行。这样导致一个问题是DAG 可能会因为开发者的水平参差不齐而导致执行效率上的天壤之别
第三点reason about end-to-end application
end-to-end指的是直接input到out如Kafka接入Spark Streaming然后再导出到HDFS中DStream 只能保证自己的一致性语义是 exactly-once 的而 input 接入 Spark Streaming 和 Spark Straming 输出到外部存储的语义往往需要用户自己来保证
第四点批流代码不统一
尽管批流本是两套系统但是这两套系统统一起来确实很有必要有时候确实需要将的流处理逻辑运行到批数据上面Streaming尽管是对RDD的封装但是要将DStream代码完全转换成RDD还是有一点工作量的更何况现在Spark的批处理都用DataSet/DataFrameAPI
流式计算一直没有一套标准化、能应对各种场景的模型直到2015年Google发表了The Dataflow Model的论文 https://yq.aliyun.com/articles/73255 。Google开源Apache Beam项目基本上就是对Dataflow模型的实现目前已经成为Apache的顶级项目但是在国内使用不多。
国内使用的更多的是Apache Flink因为阿里大力推广Flink甚至把花7亿元把Flink母公司收购。
使用Yahoo的流基准平台要求系统读取广告点击事件并按照活动ID加入到一个广告活动的静态表中并在10秒的event-time窗口中输出活动计数。比较了Kafka Streams 0.10.2、Apache Flink 1.2.1和Spark 2.3.0在一个拥有5个c3.2*2大型Amazon EC2 工作节点和一个master节点的集群上硬件条件为8个虚拟核心和15GB的内存。 上图(a)展示了每个系统最大稳定吞吐量积压前的吞吐量Flink可以达到3300万而Structured Streaming可以达到6500万近乎两倍于Flink。这个性能完全来自于Spark SQL的内置执行优化包括将数据存储在紧凑的二进制文件格式以及代码生成。
1.2 Structured Streaming 概述
或许是对Dataflow模型的借鉴也许是英雄所见略同Spark在2.0版本中发布了新的流计算的APIStructured Streaming结构化流。Structured Streaming是一个基于Spark SQL引擎的可扩展、容错的流处理引擎。统一了流、批的编程模型可以使用静态数据批处理一样的方式来编写流式计算操作并且支持基于event_time的时间窗口的处理逻辑。随着数据不断地到达Spark 引擎会以一种增量的方式来执行这些操作并且持续更新结算结果。 模块介绍 Structured Streaming 在 Spark 2.0 版本于 2016 年引入设计思想参考很多其他系统的思想比如区分 processing time 和 event time使用 relational 执行引擎提高性能等。同时也考虑了和 Spark 其他组件更好的集成。
Structured Streaming 和其他系统的显著区别主要如下 第一点Incremental query model增量查询模型
Structured Streaming 将会在新增的流式数据上不断执行增量查询同时代码的写法和批处理 API基于Dataframe和Dataset API完全一样而且这些API非常的简单。
第二点Support for end-to-end application支持端到端应用
Structured Streaming 和内置的 connector 使的 end-to-end 程序写起来非常的简单而且 “correct by default”。数据源和sink满足 “exactly-once” 语义这样我们就可以在此基础上更好地和外部系统集成。
第三点复用 Spark SQL 执行引擎
Spark SQL 执行引擎做了非常多的优化工作比如执行计划优化、codegen、内存管理等。这也是Structured Streaming取得高性能和高吞吐的一个原因。
