您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
Spark Streaming应用与实战全攻略(Ⅱ)
 
来源:csdn 发布于:2017-7-19
   次浏览      
 

Spark Streaming应用与实战系列包括以下六部分内容:

1.背景与架构改造

2.通过代码实现具体细节,并运行项目

3.对Streaming监控的介绍以及解决实际问题

4.对项目做压测与相关的优化

5.Streaming持续优化之HBase

6.管理Streaming任务

点此阅读第一部分内容,本篇为第二部分,包括 Streaming 持续优化之 HBase 以及管理 Streaming 任务。

五、Streaming持续优化之HBase

5.1 设置WALog

关闭WALog后写入能到20万,但是发现还是不是特别稳定,有时耗时还是比较长的,发现此阶段正在做Compaction!!!

查看streaming统计,发现耗时不稳定

HBase界面统计信息

HBase是一种 Log-Structured Merge Tree 架构模式,用户数据写入先写WAL,再写缓存,满足一定条件后缓存数据会执行flush操作真正落盘,形成一个数据文件HFile。随着数据写入不断增多,flush次数也会不断增多,进而HFile数据文件就会越来越多。然而,太多数据文件会导致数据查询IO次数增多,因此HBase尝试着不断对这些文件进行合并,这个合并过程称为Compaction。

Compaction会从一个 region 的一个 store 中选择一些 hfile 文件进行合并。合并说来原理很简单,先从这些待合并的数据文件中读出KeyValues,再按照由小到大排列后写入一个新的文件中。之后,这个新生成的文件就会取代之前待合并的所有文件对外提供服务。

HBase根据合并规模将 Compaction 分为了两类: inorCompaction 和 MajorCompaction 。

1. Minor Compaction 是指选取一些小的、相邻的 StoreFile 将他们合并成一个更大的 StoreFile ,在这个过程中不会处理已经 Deleted 或 Expired 的 Cell 。一次 Minor Compaction 的结果是更少并且更大的 StoreFile 。

2. Major Compaction 是指将所有的 StoreFile 合并成一个 StoreFile ,这个过程还会清理三类无意义数据:被删除的数据、TTL过期数据、版本号超过设定版本号的数据。另外,一般情况下, Major Compaction时间会持续比较长,整个过程会消耗大量系统资源,对上层业务有比较大的影响。因此线上业务都会将关闭自动触发Major Compaction功能,改为手动在业务低峰期触发。

5.2 调整压缩

通常生产环境会关闭自动 major_compact (配置文件中 hbase . hregion . majorcompaction 设 为 0 ),选择一个晚上用户少的时间窗口手工 major _ compact 。

手动 : major_compact ‘ testtable ’

如果 hbase 更新不是太频繁,可以一个星期对所有表做一次 major_compact,这个可以在做完一次major_compact后,观看所有的 storefil e数量,如果 storefile 数量增加到 major_compact 后的 storefile 的近二倍时,可以对所有表做一次 major_compact ,时间比较长,操作尽量避免高锋期。

查看统计信息

Compact触发条件:

1.memstore flush之后触发

2.客户端通过shell或者API触发

3.后台线程CompactionChecker定期触发

查看统计信息

查看统计信息

周期为: Hbase . server . thread . wakefrequencyhbase . server . compactchecker . interval . multiplier 触发 compaction ,后面还有一些其他的条件也可以在源码里面看看

条件的验证逻辑就是在这个时间范围:mcTime = 7-70.5天,7+70.5天=3.5-10.5;

是否有文件修改具体逻辑可见 RatioBasedCompactionPolicy # isMajorCompaction 方法。

5.3 Split

通过上面的截图我们可以看到,该表只有一个 region ,写入数据都集中到了一台服务器,这个远远没有发挥出 HBase 集群的能力呀,手动拆分吧!

通过hbase ui界面拆分Region

拆分后:

Region拆分后

六、管理Streaming任务

这是 Spark Streaming 系列博客的最后一部分,主要讲一下我自己对 Spark Streaming 任务的一些划分,还有一个Spark Streaming 任务的邮件监控。

6.1 Streaming 任务的划分

当 Spark Streaming 开发完成,测试完成之后,就发布上线了, Spark Streaming 任务的划分,以及时间窗口调试多少这些都是更具业务划分的。

kafka 一个topic对应HBase里面的一张表

Kafka topic 里面的partition(3-5个不等)

Strea Streaming 消费者到底去对应哪些 topic 呢?还有为什么这么划分,以及这样划分有什么好处呢?

因为 kafka topic 对应了业务中的具体 HBase 表,然后就通过监控 HBase 表插入流量来判断该表插入情况

对于 HBase 表数据的插入量划分了5种,插入量特别大、插入条数多每条数据量不大、每次插入数据量少数据大、比较均匀、插入少不频繁

对于插入量特别大,比如该表都占了插入总量的10%、20%的这种就独立出来一张表对应一个streaming消费者

插入条数多每条数据量不大,就是把插入比较频繁的可以放在一起,这时候可以调小 timeWindow

每次插入数据量少数据大,就是可以看见插入每次都是1000条,2000条,有些时间间隔,就可以调大 timeWindow 时间间隔, maxRatePerPartition 设置大一点

比较均匀就好办了,很好设置参数

插入少不频繁,可以调大timeWindow到几秒,甚至太少,太不频繁可以继续调大

好处大家应该也看出来了吧,资源的合理利用,对 streaming 的优化, timeWindow 、 maxRatePerPartition 对应不同表,增加和控制了并发量

6.2 Streaming任务的监控

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

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

通过 job name 在 yarn 8088 界面/cluster/apps/RUNNING找 ApplicationMasterURL 地址

然后通过该地址到 streaming 界面监控具体 Streaming job的Scheduling Delay 、 Processing Time 值

yarn 8088界面/cluster/apps/RUNNING

具体代码:

Python 监控爬虫 邮件通知

   
次浏览       
相关文章

基于EA的数据库建模
数据流建模(EA指南)
“数据湖”:概念、特征、架构与案例
在线商城数据库系统设计 思路+效果
 
相关文档

Greenplum数据库基础培训
MySQL5.1性能优化方案
某电商数据中台架构实践
MySQL高扩展架构设计
相关课程

数据治理、数据架构及数据标准
MongoDB实战课程
并发、大容量、高性能数据库设计与优化
PostgreSQL数据库实战培训