Lecture 10 实时计算平台（设计与实战）

接着上一节的总结：

一、Spark Streaming

1、Reciever dstream && direct dstream

在应用时，Kafka version很重要：
kafka 0.8 和 kafka 0.10的一个重要不同在于：有没有Reciever dstream，0.8 有，0.10 没有。
先看一下，Reciever dstream的工作流程：

在Reciever dstream中(inputstream -> reciever -> broker)中：1、input stream的partition和reciever的partition很可能对不上，从而造成一系列问题，比如，如果要repartition reciever中RDD的partition话，可能会引入shuffle操作，从而消耗大量内存，降低系统性能；2、在这种系统中，出kafka中存有一份数据外，reciever中也会保存一份数据，增加空间开销；

与之相反，direct dstream(inputstream -> broker)中，系统结构如下：

1、inputstream的partition直接决定RDD partition，这样就不会存在两种partition不匹配的情况，当想要增加并行度时，只要增加inputstream的partition即可；
2、direct dstream性能稳定，是一个Preference；
需要注意的是：
在reciever dstream中，进行实时存取用到的offset是由zookeeper管理的，但是，在direct dstream中，offset则需要自己管理，为此，direct dstream又引进了很多的机制。
Reciver dstream and Direct dstream 总结：

2、反压机制

通过控制sparkstreaming中接收数据量的大小来防止 系统 因 过饱和 而 崩溃的状态发生：

3、简介3个sparkstreaming的API

• UpdateStateByKey
  
• transform：运行任何RDD到RDD的函数
  
• foreachRDD：对于需要建立连接的数据 或 web数据 的操作，要考虑 如何操作才能使其 性能最优。如：对于connection data，如果操作不合理，可能会建立过多connection，从而导致空间的无端消耗：
  
  

3、windows操作

举例说明windows操作的必要性：比如你要判断一个人是否对系统进行了攻击，dstream中的一个RDD，可能时间间隔过小，无法做出正确的判断，为了避免重新定义RDD时间间隔，我们可以 采用windows操作，将多个RDD框选，然后执行操作，判断在该时间间隔内，一个人的访问次数，从而判断 这个人 是否为恶意攻击。

4、checkpoint

5、性能调优

增量计算（在线学习）案例： [D:/julytest/spark大数据实战/StreamingModel.scala]

二、Structured Streaming

1、sparkstreaming 与 structuredstreaming区别

sparkstreaming	structuredstreaming
SparkContext -> StreamingContext -> RDD	sparkSQL->sparksession
dstream	datastream (unbounded table)(类似dataframe / dataset)

2、将一个dataframe data写入kafka

3、Programming Model for Structured Stream

如上图，随着时间的推移，structuredstream会将data添加到Unbounded table中；

4、windows && WATERMARK

windows与sparkstreaming中提到的相似，如下图：12：00-12：10为一个窗口，12：15-12:25为另一个窗口：

在数据输入过程中，可能出现这一现象，即窗口12:00-12:10的data可能由于 延时 而在12：13分出现，这样，为了计算12:00-12:10窗口的统计特性，则必须保留这些中间数据，直到 所有延时数据都到达以后，统计计算才能释放所有的窗口数据。这势必会造成过多的空间开销。
为了解决这一问题，structuredstream引入WATERMARKER的概念，他定义了一个窗口数据的最晚接收时间，超过这一时间以后，所有延时数据将会被丢掉。通过这一机制，可以解决 由于 中间态数据 过多 而导致 过大空间开销 的问题。
WATERMARK的出现，使得structuredstream能够根据event time处理数据，而在sparkstreaming中，则需要根据process time来处理数据（因为，sparkstream没有WATERMARK机制，如果用eventtime来处理数据，则由于 延时 的影响，可能一年以前的数据 到 一年以后 仍然没有 全部收集完毕，这样，中间态的数据将会越累越多，从而造成巨大的空间开销）。（data time：event time , recieve time, process time）

在这里需要提及一个概念，即：structuredstream中的数据更新方式，有3种：complete，update，append。complete：是会更新出所有数据，一直累积；updata
and append：是只有某一状态下的数据有更新时，才会更新（显示）该数据，否则，不更新该数据。
下面给出WATERMARK概念，作用，及 图示：

5、structured stream的几个API

1）Join

• stream data 与 static data(离线数据) 的 join
  
• stream data 与 stream data 的 join
  
  2）dropDuplicates
  
  如果数据量过大时，需要考虑采用其他存储方式 存储dropDuplicates后的数据；
  3）ContinousExecution
  sparkstreaming中 只支持 minibatch execution，而 structuredstream中可以支持continous execution，即：每来一条数据就处理一条，具体设置方式如下：
  
  note that：该方法尚未成熟，最好在等更新几个version以后在使用；

6、实时的数据统计

Structured stream 案例：
[D:/julytest/spark大数据实战/StructuredStreaming.scala]