Spark Streaming应用与实战全攻略（Ⅱ）

Spark Streaming应用与实战系列包括以下六部分内容：
• 背景与架构改造
• 通过代码实现具体细节，并运行项目
• 对Streaming监控的介绍以及解决实际问题
• 对项目做压测与相关的优化
• Streaming持续优化之HBase
• 管理Streaming任务

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

五、Streaming持续优化之HBase

5.1 设置WALog

put.setDurability(Durability.SKIP_WAL)/* 跳过写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分为了两类：MinorCompaction和MajorCompaction。

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

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

更多Compaction信息参考：http://hbasefly.com/2016/07/13/hbase-compaction-1/

5.2 调整压缩

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

手动：major_compact ‘testtable’

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