Spark Streaming应用与实战全攻略（Ⅱ））-大数据-火龙果软件

捐助

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 监控爬虫邮件通知

次浏览