spark stream

SparkStreaming

一、SparkStreaming和Storm对比

SparkStreaming：时间驱动
Storm：数据驱动
缺点：storm吞吐量太低了

二、SparkStreaming简介

底层抽象：DStream：封装了一个时间批次的RDD

三、kafka如何保证数据不丢失？

这不是一个问题，这是三个问题
1、producer端如何保证数据不丢失？
2、Broker端如何保证数据不丢失？
3、Consumer端如何保证数据不丢失？

四、kafka为什么那么快？

1、采用pageCache页缓存技术
2、顺序读写

五、kafka保存数据

保存在segment文件段当中
Segment文件段由.log文件和.index文件组成
.log文件保存的是数据
.index文件保存的是.log文件中数据的索引，而且是稀疏索引
当segment文件段数据量达到1G的时候进行分裂
Kafka默认保存数据时长是168小时，也就是7天
Segment文件段命名规则：
以上一个segment文件段当中最后一条数据的偏移量命名
第一个segment段命名：
-rw-r–r-- 1 root root 0 Oct 21 20:35 00000000000000000000.index
-rw-r–r-- 1 root root 0 Apr 8 2020 00000000000000000000.log
第二个segment段命名：
-rw-r–r-- 1 root root 0 Oct 21 20:35 00000000000000014325.index
-rw-r–r-- 1 root root 0 Apr 8 2020 00000000000000014325.log
第三个segment段命名：
-rw-r–r-- 1 root root 0 Oct 21 20:35 00000000000002964265.index
-rw-r–r-- 1 root root 0 Apr 8 2020 00000000000002964265.log

六、DStream转换操作

分为无状态和有状态转换操作
无状态：当前批次计算的结果不依赖于之前的批次结果
有状态：当前批次计算的结果依赖于之前的批次结果

七 简述SparkStreaming窗口函数的原理（重点）

窗口函数就是在原来定义的SparkStreaming计算批次大小的基础上再次进行封装，每次计算多个批次的数据，同时还需要传递一个滑动步长的参数，用来设置当次计算任务完成之后下一次从什么地方开始计算。
图中time1就是SparkStreaming计算批次大小，虚线框以及实线大框就是窗口的大小，必须为批次的整数倍。虚线框到大实线框的距离（相隔多少批次），就是滑动步长。

八 SparkStreaming有哪几种方式消费Kafka中的数据，它们之间的区别是什么？

一、基于Receiver的方式
这种方式使用Receiver来获取数据。Receiver是使用Kafka的高层次Consumer API来实现的。receiver从Kafka中获取的数据都是存储在Spark Executor的内存中的（如果突然数据暴增，大量batch堆积，很容易出现内存溢出的问题），然后Spark Streaming启动的job会去处理那些数据。
然而，在默认的配置下，这种方式可能会因为底层的失败而丢失数据。如果要启用高可靠机制，让数据零丢失，就必须启用Spark Streaming的预写日志机制（Write Ahead Log，WAL）。该机制会同步地将接收到的Kafka数据写入分布式文件系统（比如HDFS）上的预写日志中。所以，即使底层节点出现了失败，也可以使用预写日志中的数据进行恢复。
二、基于Direct的方式
这种新的不基于Receiver的直接方式，是在Spark 1.3中引入的，从而能够确保更加健壮的机制。替代掉使用Receiver来接收数据后，这种方式会周期性地查询Kafka，来获得每个topic+partition的最新的offset，从而定义每个batch的offset的范围。当处理数据的job启动时，就会使用Kafka的简单consumer api来获取Kafka指定offset范围的数据。
优点如下：
简化并行读取：如果要读取多个partition，不需要创建多个输入DStream然后对它们进行union操作。Spark会创建跟Kafka partition一样多的RDD partition，并且会并行从Kafka中读取数据。所以在Kafka partition和RDD partition之间，有一个一对一的映射关系。
高性能：如果要保证零数据丢失，在基于receiver的方式中，需要开启WAL机制。这种方式其实效率低下，因为数据实际上被复制了两份，Kafka自己本身就有高可靠的机制，会对数据复制一份，而这里又会复制一份到WAL中。而基于direct的方式，不依赖Receiver，不需要开启WAL机制，只要Kafka中作了数据的复制，那么就可以通过Kafka的副本进行恢复。
一次且仅一次的事务机制。
三、对比：
基于receiver的方式，是使用Kafka的高阶API来在ZooKeeper中保存消费过的offset的。这是消费Kafka数据的传统方式。这种方式配合着WAL机制可以保证数据零丢失的高可靠性，但是却无法保证数据被处理一次且仅一次，可能会处理两次。因为Spark和ZooKeeper之间可能是不同步的。
基于direct的方式，使用kafka的简单api，Spark Streaming自己就负责追踪消费的offset，并保存在checkpoint中。Spark自己一定是同步的，因此可以保证数据是消费一次且仅消费一次。
在实际生产环境中大都用Direct方式

代码

1 Window Operations
Window Operations有点类似于Storm中的State，可以设置窗口的大小和滑动窗口的间隔来动态的获取当前Steaming的允许状态。
基于窗口的操作会在一个比StreamingContext的批次间隔更长的时间范围内，通过整合多个批次的结果，计算出整个窗口的结果
countByWindow() 和 countByValueAndWindow() 作为对数据进行计数操作的简写。countByWindow() 返回一个表示每个窗口中元素个数的 DStream，而 countByValueAndWindow() 返回的 DStream 则包含窗口中每个值的个数，。

package day05

import org.apache.spark.streaming.dstream.{
   DStream, ReceiverInputDStream}
import org.apache.spark.streaming.{
   Seconds, StreamingContext}
import org.apache.spark.{
   SparkConf, SparkContext}

/**
 * Author:SZX
 * Date:2020/10/22 20:55
 * Version:1.0
 * Description: 
 */
object CountByWindow {
   
  def main(args: Array[String]): Unit = {
   
    //创建程序入口
    val conf: SparkConf = new SparkConf().setAppName("demo").setMaster("local[*]")
    val sc = new SparkContext(conf)
    val scc = new StreamingContext(sc, Seconds(5))
    //设置日志过滤
    sc.setLogLevel("WARN")
    //过滤点
    scc.checkpoint("./888")
    val file: ReceiverInputDStream[String</