note34sparkstreamingWord文档格式.docx
- 文档编号:22025297
- 上传时间:2023-02-02
- 格式:DOCX
- 页数:12
- 大小:287.29KB
note34sparkstreamingWord文档格式.docx
《note34sparkstreamingWord文档格式.docx》由会员分享,可在线阅读,更多相关《note34sparkstreamingWord文档格式.docx(12页珍藏版)》请在冰豆网上搜索。
接收来的数据会越堆积越多,最后可能会导致OOM。
2.SparkStreaming代码
代码注意事项:
启动socketserver服务器:
nc–lk9999
local的模拟线程必须大于等于2,一个被receiver用来接受数据,另一个线程用来执行job。
Durations时间设置就是我们能接收的延迟度。
这个需要根据集群的资源情况以及任务的执行情况来调节。
创建JavaStreamingContext有两种方式(SparkConf,SparkContext)
所有的代码逻辑完成后要有一个operator算子。
JavaStreamingContext.start()Streaming框架启动后不能再次添加业务逻辑。
JavaStreamingContext.stop()无参的stop方法将SparkContext一同关闭,stop(false),不会关闭SparkContext。
JavaStreamingContext.stop()停止之后不能再调用start。
SparkConfconf=newSparkConf().setMaster("
local[2]"
).setAppName("
WordCountOnline"
);
/**
*在创建streaminContext的时候设置batchInterval
*/
JavaStreamingContextjsc=newJavaStreamingContext(conf,Durations.seconds(5));
JavaReceiverInputDStream<
String>
lines=jsc.socketTextStream("
node5"
9999);
JavaDStream<
words=lines.flatMap(newFlatMapFunction<
String,String>
(){
/**
*
privatestaticfinallongserialVersionUID=1L;
@Override
publicIterable<
call(Strings){
returnArrays.asList(s.split("
"
));
}
});
JavaPairDStream<
String,Integer>
ones=words.mapToPair(newPairFunction<
String,String,Integer>
publicTuple2<
returnnewTuple2<
(s,1);
counts=ones.reduceByKey(newFunction2<
Integer,Integer,Integer>
publicIntegercall(Integeri1,Integeri2){
returni1+i2;
//outputoperator类的算子
counts.print();
jsc.start();
//等待spark程序被终止
jsc.awaitTermination();
jsc.stop(false);
4.SparkStreaming算子操作
1.foreachRDD
output算子
2.transform
transformation类算子
可以通过transform算子,对Dstream做RDD到RDD的任意操作。
3.updateStateByKey
transformation算子
updateStateByKey作用:
1)为SparkStreaming中每一个Key维护一份state状态,state类型可以是任意类型的,可以是一个自定义的对象,更新函数也可以是自定义的。
2)通过更新函数对该key的状态不断更新,对于每个新的batch而言,SparkStreaming会在使用updateStateByKey的时候为已经存在的key进行state的状态更新。
使用到updateStateByKey要开启checkpoint机制和功能。
多久会将内存中的数据写入到磁盘一份?
如果batchInterval设置的时间小于10秒,那么10秒写入磁盘一份。
如果batchInterval设置的时间大于10秒,那么就会batchInterval时间间隔写入磁盘一份。
4.窗口操作
窗口操作理解图:
假设每隔5s1个batch,上图中窗口长度为15s,窗口滑动间隔10s。
窗口长度和滑动间隔必须是batchInterval的整数倍。
如果不是整数倍会检测报错。
优化后的window窗口操作示意图:
优化后的window操作要保存状态所以要设置checkpoint路径,没有优化的window操作可以不设置checkpoint路径。
5.DriverHA(Standalone或者Mesos)
因为SparkStreaming是7*24小时运行,Driver只是一个简单的进程,有可能挂掉,所以实现Driver的HA就有必要(如果使用的Client模式就无法实现DriverHA,这里针对的是cluster模式)。
实现Driver的高可用有两个步骤:
第一:
提交任务层面,在提交任务的时候加上选项–supervise,当Driver挂掉的时候会自动重启Driver。
第二:
代码层面,使用JavaStreamingContext.getOrCreate(checkpoint路径,JavaStreamingContextFactory)
Driver中元数据包括:
1.创建应用程序的配置信息。
2.Dstream的操作逻辑。
3.job中没有完成的批次数据,也就是job的执行进度。
6.Kafka
1.kafka是什么?
使用场景?
kafka是一个高吞吐的分布式消息队列系统。
特点是生产者消费者模式,先进先出(FIFO)保证顺序,自己不丢数据,默认每隔7天清理数据。
消息列队常见场景:
系统之间解耦合、峰值压力缓冲、异步通信。
2.kafka生产消息、存储消息、消费消息
Kafka架构是由producer(消息生产者)、consumer(消息消费者)、borker(kafka集群的server,负责处理消息读、写请求,存储消息)、topic(消息队列/分类相当于队列,里面有生产者和消费者模型)、broker(代理,在kafkacluster这一层这里,其实里面是有很多个broker)、zookeeper(元数据信息存在zookeeper中,包括:
存储消费偏移量,topic话题信息,partition信息)这些部分组成。
kafka里面的消息是有topic来组织的,简单的我们可以想象为一个队列,一个队列就是一个topic,然后它把每个topic又分为很多个partition,这个是为了做并行的,在每个partition内部消息强有序,相当于有序的队列,其中每个消息都有个序号offset,比如0到12,从前面读往后面写。
一个partition对应一个broker,一个broker可以管多个partition,比如说,topic有6个partition,有两个broker,那每个broker就管3个partition。
这个partition可以很简单想象为一个文件,当数据发过来的时候它就往这个partition上面append,追加就行,消息不经过内存缓冲,直接写入文件,kafka和很多消息系统不一样,很多消息系统是消费完了我就把它删掉,而kafka是根据时间策略删除,而不是消费完就删除,在kafka里面没有一个消费完这么个概念,只有过期这样一个概念。
producer自己决定往哪个partition里面去写,这里有一些的策略,譬如如果hash,不用多个partition之间去join数据了。
consumer自己维护消费到哪个offset,每个consumer都有对应的group,group内是queue消费模型(各个consumer消费不同的partition,因此一个消息在group内只消费一次),group间是publish-subscribe消费模型,各个group各自独立消费,互不影响,因此一个消息在被每个group消费一次。
3.kafka的特点
系统的特点:
生存者消费者模型,FIFO
Partition内部是FIFO的,partition之间不是FIFO的,当然我们可以把topic设为一个partition,这样就是严格的FIFO。
高性能:
单节点支持上千个客户端,百MB/s吞吐,接近网卡的极限
持久性:
消息直接持久化在普通磁盘上且性能好
直接写到磁盘中去,就是直接append到磁盘里去,这样的好处是直接持久化,数据不会丢失,第二个好处是顺序写,然后消费数据也是顺序的读,所以持久化的同时还能保证顺序,比较好,因为磁盘顺序读比较好。
分布式:
数据副本冗余、流量负载均衡、可扩展
分布式,数据副本,也就是同一份数据可以到不同的broker上面去,也就是当一份数据,磁盘坏掉的时候,数据不会丢失,比如3个副本,就是在3个机器磁盘都坏掉的情况下数据才会丢,在大量使用情况下看这样是非常好的,负载均衡,可扩展,在线扩展,不需要停服务。
很灵活:
消息长时间持久化+Client维护消费状态
消费方式非常灵活,第一原因是消息持久化时间跨度比较长,一天或者一星期等,第二消费状态自己维护消费到哪个地方了可以自定义消费偏移量。
4.kafka集群搭建
1)上传kafka_2.10-0.8.2.2.tgz包到三个不同节点上,解压。
2)配置../kafka_2.10-0.8.2.2/config/server.properties文件
节点编号:
(不同节点按0,1,2,3整数来配置)
真实数据存储位置:
zookeeper的节点:
3)启动zookeeper集群。
4)三个节点上,启动kafka:
bin/kafka-server-start.shconfig/server.properties
最好使用自己写的脚本启动,将日志写入到一个文件:
nohupbin/kafka-server-start.shconfig/server.properties>
kafka.log2>
&
1&
脚本附件:
(放在与bin同一级别下,注意创建后要修改权限:
chmod755startkafka.sh)
5)相关命令:
创建topic:
./kafka-topics.sh--zookeepernode3:
2181,node4:
2181,node5:
2181--create--topictopic2017--partitions3--replication-factor3
用一台节点控制台来当kafka的生产者:
./kafka-console-producer.sh--topictopic2017
--broker-listnode1:
9092,node2:
9092,node3:
9092
用另一台节点控制台来当kafka的消费者:
./kafka-console-consumer.sh--zookeepernode3:
2181--topictopic2017
查看kafka中topic列表:
./kafka-topics.sh--list--zookeepernode3:
2181
查看kafka中topic的描述:
./kafka-topics.sh--describe--zookeepernode3:
注意:
ISR是检查数据的完整性有哪些个节点。
查看zookeeper中topic相关信息:
启动zookeeper客户端:
./zkCli.sh
查看topic相关信息:
ls/brokers/topics/
查看消费者相关信息:
ls/consumers
5.kafka的leader的均衡机制
当一个broker停止或者crashes时,所有本来将它作为leader的分区将会把leader转移到其他broker上去,极端情况下,会导致同一个leader管理多个分区,导致负载不均衡,同时当这个broker重启时,如果这个broker不再是任何分区的leader,kafka的client也不会从这个broker来读取消息,从而导致资源的浪费。
kafka中有一个被称为优先副本(preferredreplicas)的概念。
如果一个分区有3个副本,且这3个副本的优先级别分别为0,1,2,根据优先副本的概念,0会作为leader。
当0节点的broker挂掉时,会启动1节点broker当做leader。
当0节点的broker再次启动后,会自动恢复为此partition的leader。
不会导致负载不均衡和资源浪费,这就是leader的均衡机制。
在配置文件conf/server.properties中配置开启(默认就是开启):
auto.leader.rebalance.enabletrue
7.SparkStreaming+Kafka
1.receiver模式
receiver模式原理图
receiver模式理解:
在SparkStreaming程序运行起来后,Executor中会有receivertasks接收kafka推送过来的数据。
数据会被持久化,默认级别为MEMORY_AND_DISK_SER_2,这个级别也可以修改。
receivertask对接收过来的数据进行存储和备份,这个过程会有节点之间的数据传输。
备份完成后去zookeeper中更新消费偏移量,然后向Driver中的receivertracker汇报数据的位置。
最后Driver根据数据本地化将task分发到不同节点上执行。
receiver模式中存在的问题
当Driver进程挂掉后,Driver下的Executor都会被杀掉,当更新完zookeeper消费偏移量的时候,Driver如果挂掉了,就会存在找不到数据的问题,相当于丢失数据。
如何解决这个问题?
开启WAL(writeaheadlog)预写日志机制,在接受过来数据备份到其他节点的时候,同时备份到HDFS上一份(我们需要将接收来的数据的持久化级别降级到MEMORY_AND_DISK),这样就能保证数据的安全性。
不过,因为写HDFS比较消耗性能,要在备份完数据之后才能进行更新zookeeper以及汇报位置等,这样会增加job的执行时间,这样对于任务的执行提高了延迟度。
receiver模式代码(见代码)
receiver的并行度设置
receiver的并行度是由spark.streaming.blockInterval来决定的,默认为200ms,假设batchInterval为5s,那么每隔blockInterval就会产生一个block,这里就对应每批次产生RDD的partition,这样5秒产生的这个Dstream中的这个RDD的partition为25个,并行度就是25。
如果想提高并行度可以减少blockInterval的数值,但是最好不要低于50ms。
2.Driect模式
Direct模式理解
SparkStreaming+kafka的Driect模式就是将kafka看成存数据的一方,不是被动接收数据,而是主动去取数据。
消费者偏移量也不是用zookeeper来管理,而是SparkStreaming自己用checkpoint来管理,当然也可以实现用zookeeper来管理。
Direct模式并行度设置
Direct模式的并行度是由读取的kafka中topic的partition数决定的。
Direct模式代码(见代码)
3.相关配置
预写日志:
spark.streaming.receiver.writeAheadLog.enable默认false没有开启
blockInterval:
spark.streaming.blockInterval默认200ms
反压机制:
spark.streaming.backpressure.enabled默认false
接收数据速率:
spark.streaming.receiver.maxRate默认没有设置
用nc-lk9999做stream的信息来源
yuminstall-ync,一般安装时都没有装
nc-lk9999,守候9999端口
集群启动访问hdfs要用8020
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- note34sparkstreaming
![提示](https://static.bdocx.com/images/bang_tan.gif)