Spark Streaming--应用与实战(六)

管理Streaming任务

  - 这是目前Spark Streaming系列博客的最后一篇文章了,该篇文章主要讲一下我自己对Spark Streaming任务的一些划分,还有一个Spark Streaming任务的邮件监控。

Streaming 任务的划分

  • Spark Streaming开发完成,测试完成之后,就发布上线了,Spark Streaming任务的划分,以及时间窗口调试多少这些都是更具业务划分的。
  1. kafka 一个topic对应HBase里面的一张表
  2. Kafka topic 里面的partition(3-5个不等)
  3. Streaming job即Kafka消费者,消费一个或多个Kafka topic
  • 那一个Streaming消费者到底去对应哪些topic呢?还有为什么这么划分,以及这样划分有什么好处呢?
  1. 因为kafka topic对应了业务中的具体HBase表,然后就通过监控HBase表插入流量来判断该表插入情况
  2. 对于HBase表数据的插入量划分了5种,插入量特别大、插入条数多每条数据量不大、每次插入数据量少数据大、比较均匀、插入少不频繁
  3. 对于插入量特别大,比如该表都占了插入总量的10%、20%的这种就独立出来一张表对应一个streaming消费者
  4. 插入条数多每条数据量不大,就是把插入比较频繁的可以放在一起,这时候可以调小timeWindow
  5. 每次插入数据量少数据大,就是可以看见插入每次都是1000条,2000条,有些时间间隔,就可以调大timeWindow时间间隔,maxRatePerPartition设置大一点
  6. 比较均匀就好办了,很好设置参数
  7. 插入少不频繁,可以调大timeWindow到几秒,甚至太少,太不频繁可以继续调大
  8. 好处大家应该也看出来了吧,资源的合理利用,对streaming的优化,timeWindowmaxRatePerPartition对应不同表,增加和控制了并发量

Streaming 任务的监控

  • 对于Spark Streaming job的监控,自带的Streaming UI能看到具体的一些流量,时间等信息,但是缺少了一个通知,于是简单的开发了一个。
    在监控这一块也想了不少方案,比如监控pid,通过shell去监控,或者直接调用源码里面的方法,都尝试过,有的要么没达到预期的效果,要么有的不是很好维护开发成本高

  • 最终选了一个比较简单的,但是又能达到一定效果的,通过py爬虫,到原始的streaming UI界面去获取到具体的信息,来监控,到达阈值就发送邮件,总体步骤如下:

  1. 通过job name在yarn 8088界面/cluster/apps/RUNNING找到ApplicationMasterURL地址
  2. 然后通过该地址到streaming界面监控具体Streaming job的Scheduling DelayProcessing Time
    yarn 8088界面/cluster/apps/RUNNING

当前网速较慢或者你使用的浏览器不支持博客特定功能,请尝试刷新或换用Chrome、Firefox等现代浏览器