Spark Streaming总结

  对Spark Streaming的原理讲解以及每个批对应blockRDD怎么进行分区的,细看总结第一第二

  1. 实时流的WordCount程序 :包括6个部分,实例编程入口,创建数据接收器,数据处理,结果输出,启动流处理程序,等待终止程序
  2. Spark Streaming本地模式 用于调试,需要注意的是实例content采用local,并且要两个core,一个用于实时计算,一个用于数据接收
  3. nc -lk 9998启动socket服务端,nc master 9998启动socket客户端,两者可以进行socket通信
  4. 实例化Spark Streaming两种方法:一种是传入sparkcontext实例(引用),一种是传入sparkconf,第二种方式本质上还是会创建SparkContext,另外在调用stop方式时,如果传入false,代表只停实时流程序,不停SparkContext,如果为true那sc也会停掉;实时流的处理代码必须在start之前才有效;JVM中只能有一个StreamingContext实例 详情
  5. Spark Streaming提供的是微批处理的服务,怎么分批?会有一个batch interval,这个在实例化StreamingContext时会给,也就是接收的数据会按照这个值(时间间隔),划分批次,存入Spark内存中,而DStream就是Spark streaming的编程模型,你可以理解DStream就是分为多个时间批次的RDD,最后都是转换成RDD来达到计算
  6. 接收器为socket,用作实验String类型的数据,另外队列接收器也做为实验类型,可以测更多种类型的数据  内存队列和Spark Shell交互
  7. 在RDD中的API,DStream里基本都有,并且最终都是调用RDD的Api来进行计算的,它还提供了两个转换成RDD进行计算的API,transform和transformWith,transform就是把单个DStream转换成RDD,然后你就可以进行RDD的操作了,比如你可以用这个 对DStream和HDFS的静态数据进行join操作,transformWith则是把两个DStream抓换成RDD,其中DStream的join操作本质就是调用这个API 详细
  8. Window API:窗口函数的逻辑计算由三个时间决定了,第一个batch interval,决定数据按多久的量来划分块,第二个,window length,这也是按时间计,要求是batch interval的倍数,这个决定了窗口跨度多少个数据块,第三个就是sliding interval,滑动时间间隔,也必须是batch interval的倍数,由于Spark Streaming是实时流处理,所以这个决定了窗口按照啥规律进行移动计算
  9. reduceByKeyAndWindow API:reduceByKey带这个字眼的功能就不用多说了,对于Spark Streaming中这个API有两种用法,第一种使用方法,就是简单的传入累加函数,这种方式发生两次shuffle,第一次是在每个batch interval间隔的分区数据里进行shuffle。第二次则是对窗口里所有的batch interval数据union后,进行shuffle分区,所以这种方式某些场景下,效率比较低, 第二种使用方法就是不仅传入累加函数,还传入的一个反作用的函数,这种方式会发生一次shuffle,原理就是Cogroup + reduceF,跨两个窗口操作,其中对旧RDD进行反作用函数,新RDD就正操作,所以这种方式会之前的RDD有依赖,所以这种方式必须checkpoint,定时斩断依赖,不过它也有自己适合的场景,就是滑动时间比较短,窗口长度很长的场景,说白了就是当前窗口会有好多之前窗口的RDD  详细

  方式一

 

 

方式二

    10. countByWindow 统计窗口的数据量, reduceByWindow 不分key的按计算函数统计,countByValueAndWindow 统计各个key在窗口中出现的次数 详情

  11. updateStateByKey对实时流启动以来所有的数据进行统计,这个也要进行checkpoint,这个API也有两种使用方法,都传入函数,不过函数参数不同,简单版是value和state参数,而复杂点,要求高点的(比如对某些key进行过滤),参数类型为迭代器 详情

  12. mapWithState这个接口相对updateStateByKey性能更高(尤其对其第二种用法),它支持初始化某些key的值,还支持设置key的超时时间(目标是所有的key,只要某个key超过这个时间没更新就会失效),并且在print上也两种方式,默认的是只会输出更新的key,如果要把所有的打印出来,就要用stateSnapshots().print()  详情

  13. DStream有API让处理数据存储到HDFS上,其中saveAsHadoopFiles可以指定文件格式存储,比如TextFile或者SequenceFile, 还有针对各种格式的简单API,比如saveAsTextFiles和saveAsObjectFiles 详情

  14. 实时流数据和MySQL交互,首先DStream提供了foreachRDD,它可以让你获取每个时间点的RDD,其次连接数据这种耗时的操作,应该实例一个连接池,并且使用foreachPartition来达到一个分区的数据使用一个数据库连接,再者就是发送数据使用addBatch,一批一批的发,并且如果分区的数据很大,还应该控制每批的条数,比如控制成500条, 最后考虑事物,操作数据库的原子性 详情

  15. Spark Streaming也支持和Spark Sql交互,本质上就是用foreachRDD得到对应的RDD,然后toDF转成DataFrame来进行操作 详情

  16. Spark Streaming实时流应用可以从数据接收,数据处理,结果输出三个环节进行优化,首先数据接收,你可以开启多个receiver增加吞吐量;另外需要结合core的资源,合理提高blockRDD的并行度,可以调节block interval,比如task太少,可以调小block interval;还可以调节receiver的接收速率(有自动调节的方式);其中就是数据处理过程中,要考虑并行度,blockRDD除了上面调节block interval,还可以通过reparation调节,另外就是shuffleRDD默认情况是有core数量决定的,当然也可以自动进行调节;考虑高效合理的序列化,在数据输入的时候,以及缓存RDD时,都需要序列化,以及传输给Executor的时候选择Kryo高效序列化机制;内存优化方面:如果内存够了,RDD可以只缓存到内存,不选择disk,以及注意tranform如果是window操作,分配合理内存;另外就是driver和Executor启动JVM时选择CMS垃圾收集器(追求最短回收停顿时间);输出数据环节具体考虑存储的地方,比如和mysql 可以参考14点 详细

  17. Backpressure压力反馈机制:Spark Streaming怎么界定哪个时候进行调节呢?它提出了稳定和不稳定状态,当每批处理的时间batch process time 大于 batch interval界定了不稳定状态,这种情况下,程序会返回压力给数据接收receiver,进行调节接收数据,以达到稳定状态;资源动态分配机制,相对spark是指定一个一定时间的值来决定是否删除还是启动Executor,spark streaming则通过process time/batch interval的比值来控制的,当这个比值非常小,比如只有0.5时,则杀掉没有receiver的Executor,进行做到高效稳定,如果这个比值超过1,则会启动Executor,处理数据量增大,又会进行反馈给数据接收方,进而调高数据接收,  这两种机制都需要通过配置的方式把开关打开才能用

  18. Spark Streaming程序考虑高可用性,需要从这几个方面想:1.driver端保存的配置信息,以及receiver跟踪信息   2.Executor接收的信息:包括已经分块的,也就是已经被receiver跟踪到的数据信息,还有就在未分块暂时攒着放在blockGenerator,  对于driver端,通过checkpoint机制做到,把数据存到hdfs上,而对于Executor已经分块的数据,只要实例接收器时,存储级别选择备份2,那么Executor挂掉时,就会找已经备份了的启动receiver,不过这个是针对已经分块,那些没分块没处理的数据,则需要WAL机制,本质就是checkpoint,这种机制不仅备份没分块的数据,还包括分块的数据,所以选择了这种机制,就没必须receiver那再选择备份2了

  19. Spark Streaming实时流程序主要分为数据接收,数据处理,结果保存三个部分,并且流计算语义也分为at most once,at least once,exactly once三种语义,最好的实时流处理程序应该整体符合exactly once语义,也就是说在数据接收,数据处理,结果保存都符合exactly once语义,其中对数据接收receiver,在接收到数据,并存储备份好后发送回执给数据源,这样的receiver被称为Reliable Receiver,如果不发回执,则称为Unreliable,如果Receiver采用checkpint + WAL + Reliable receivers只能保证数据不会丢失,但可能重复消费,而Kafka的Direct方式能保证接收数据时,一条数据只消费一次,kafka的partition作为RDD的分区;数据转换过程,RDD通过依赖链高效容错,保证一条数据只处理一次;至于结果保存,可以通过幂等和支持事务保证数据同样数据只存储一次,幂等就是同样的数据,同样的结果,这样重复结果覆盖写就不会重复,事务可以通过主键唯一控制 详情

posted @ 2021-01-17 18:33  财经知识狂魔  阅读(134)  评论(0编辑  收藏  举报