Spark Streaming--应用与实战(六)
管理Streaming任务
- 这是目前Spark Streaming
系列博客的最后一篇文章了,该篇文章主要讲一下我自己对Spark Streaming
任务的一些划分,还有一个Spark Streaming
任务的邮件监控。
Streaming 任务的划分
- 当
Spark Streaming
开发完成,测试完成之后,就发布上线了,Spark Streaming
任务的划分,以及时间窗口调试多少这些都是更具业务划分的。
- kafka 一个topic对应HBase里面的一张表
- Kafka topic 里面的partition(3-5个不等)
- Streaming job即Kafka消费者,消费一个或多个Kafka topic
- 那一个Streaming消费者到底去对应哪些topic呢?还有为什么这么划分,以及这样划分有什么好处呢?
- 因为kafka topic对应了业务中的具体HBase表,然后就通过监控HBase表插入流量来判断该表插入情况
- 对于HBase表数据的插入量划分了5种,插入量特别大、插入条数多每条数据量不大、每次插入数据量少数据大、比较均匀、插入少不频繁
- 对于插入量特别大,比如该表都占了插入总量的10%、20%的这种就独立出来一张表对应一个streaming消费者
- 插入条数多每条数据量不大,就是把插入比较频繁的可以放在一起,这时候可以调小
timeWindow
- 每次插入数据量少数据大,就是可以看见插入每次都是1000条,2000条,有些时间间隔,就可以调大
timeWindow
时间间隔,maxRatePerPartition
设置大一点 - 比较均匀就好办了,很好设置参数
- 插入少不频繁,可以调大timeWindow到几秒,甚至太少,太不频繁可以继续调大
- 好处大家应该也看出来了吧,资源的合理利用,对streaming的优化,
timeWindow
、maxRatePerPartition
对应不同表,增加和控制了并发量
Streaming 任务的监控
对于
Spark Streaming job
的监控,自带的Streaming UI
能看到具体的一些流量,时间等信息,但是缺少了一个通知,于是简单的开发了一个。
在监控这一块也想了不少方案,比如监控pid,通过shell去监控,或者直接调用源码里面的方法,都尝试过,有的要么没达到预期的效果,要么有的不是很好维护开发成本高最终选了一个比较简单的,但是又能达到一定效果的,通过py爬虫,到原始的streaming UI界面去获取到具体的信息,来监控,到达阈值就发送邮件,总体步骤如下:
- 通过job name在
yarn 8088界面/cluster/apps/RUNNING
找到ApplicationMaster
URL地址 - 然后通过该地址到streaming界面监控具体Streaming job的
Scheduling Delay
、Processing Time
值