《OD学HBase》20160821

一、HBase性能调优

1. JVM内存调优

MemStore内存空间，设置合理大小

memstore.flush.size 刷写大小 134217728 = 128M

memstore.mslab.enabled

preclose.flush.size

JVM堆内存

初生代内存空间：数据停留时间较短  128~512M -Xmn128M

老生代内存空间：数据停留时间比较长，几GB

内存碎片  GC清理 -->进程停顿

当垃圾过多，GC进程限制应用程序进程的进行

GC垃圾回收策略：

Parrallel New Collector垃圾回收策略

Concurrent Mark-Sweep Collector 并行标记垃圾回收器

2. 本地MemStore缓存

数据从MemStore刷写到磁盘上，MemStore空间就会留下随便（内存孔洞）

GC对这些随便进行清理

内存孔洞，重复使用

预先设置固定大小的内存孔洞，下次数据写进内存，根据数据的大小找到合适之前预先设置好的后者留下来的内存孔洞，写进去。

缺点：占用大量的内存空间

hbase.hregion.memstore.mslab.enabled 开关

大小 2M

3. 拆分与合并

split: Region分割 Region大小增大一定大小

hbase.hregion.max.filesize     只要region中的任何一个StoreFile大小默认上限   10GB

Region

-->拆分成平均大小的两个小的Region

-->Region1 -->接收数据 -->又继续拆分

-->Region2

HBase表数据量连续增长非常快，拆分过程频繁进行，明显降低HBase表的读写性能

解决办法： 将hbase.hregion.max.filesize 设置大一点

手动执行split命令进行拆分，选择业务发生量最小的时刻

compact 合并：

memstore刷写数据到磁盘，生成StoreFile(HFile)，

HFile好多小文件，造成HBase读性能不高，HBase内部有合并机制。

合并为了优化读性能

合并：

minor compact： 只是简单将同一个Store中小的StoreFile合并成大的StoreFile

major compact： 将整个HBase表的StoreFile进行大范围的合并，真正进行删除数据，另外也对过期的数据进行移除。

HBase删除数据，并没有立即删除，其实只是打了个删除标记。

手动进行ajon compact

hbase.hregion.majorcompaction 默认七天

hbase.hregion.majorcompation.jitter 浮动

根据业务具体情况来决定如何进行优化拆分与合并

4. 预创建Region

5. 负载均衡

6. 热点现象

rowkey优化

二、Storm

1. 实际场景

（1）交通部门：检测高速公路上的车辆超速情况，对超速车辆实时发罚单

（2）公安部门：追踪疑犯，实时检测到疑犯的出现地点。

（3）金融行业：反欺诈交易实时检测，事后反欺诈。

（4）游戏行业：实时得到游戏上线后的一些反馈博爱高

（5）软件系统上线后：日志分析，实时检测到一些运行不良的系统、组件

Hadop mapreduce能否解决以上需求？

实时

以上场景都有共同的需求：讲数据分析结果能够实时反馈，需要对数据进行实时处理

实时数据分析框架：

Storm 流失数据处理技术框架

Spark Streaming 实时数据分析框架

三、数据分析处理

数据分析一定基于时段

批处理：时段跨度相对来说比较大

一年，一季度，一月，一星期，一天，一小时，一分钟 ，一秒钟

实时处理：时间跨度偏小的批处理

单位时间（秒）数据量非常大GB TB

四、Storm SparkStreaming的区别

Storm真正的实时处理框架，针对数据，来一条记录就处理一次，流式数据处理技术框架。

SparkStreaming微批数据处理框架，秒级

并不是hadoop生态系统的一个框架

1. 环境搭建

1）下载

http://storm.apache.org/

2）安装要求、前提

zookeeper集群

python 2.6.6以上

python --version

3）解压安装

apache-storm-0.9.6

4）修改配置

strom_env.ini

storm.yarn：

nimubs.host: "nibus"

storm.local.dir: "/mnt/storm"

指定supervisor节点启动一些工作进程worker所使用的默认端口

supervisor storm的节点

supervisor.slots.ports:

ui

2. Storm架构

1）nimbus主节点：

接收客户端提交的任务，任务由nimbus进行分配

2）zookeeper集群：

（1）在zookeeper响应的znode节点上写入任务分配信息，由supervisor查看这些znode上的任务分配信息，获取分配到的任务。

（2）监控整个集群的状态

从zookeepe集群的znode上读取supervisor、worker进程的状态信息数据

（3）容错：

当任务在某些supervisor节点上运行的时候，由于supervisor进程失效，重新将这些任务分配给其他supervisor运行。

3）supervisor：

（1）需要定时讲自己的运行状态信息（心跳信息）汇报给zookeeper（在zookeeper相应的znode节点上写入心跳信息）

（2）接收nimbus分配给它的任务，负责启动、停止工作进程worker，其本身并不是执行任务的工作进程，worker的容错由supervisor进程负责

4）worker：

并不是常驻进程，不能通过手动启动，真正执行任务的进程。

worker进程启动后，也会定时将状态信息汇报给zookeeper

executor线程：worker进程来启动，executor负责执行客户提交到storm集群上任务中的task。

task：(spout/bolt)

五、启动

1. 启动nimbus

nohup bin/storm nimbus >~/storm-nimbus-start.log 2>&1 &

jps

config_value 表示正在启动并读取配置文件

nimbus

ps -ef | grep daemon.nimbus

2. 启动supervisor

nohup bin/storm supervisor >~/storm-supervisor-start.log 2>&1 &

ps -ef | grep daemon.supervisor

3. 启动ui

nohup bin/storm ui >~/storm-ui-start.log 2>&1 &

ps -ef | grep ui.core

netstat -tlnup | grep 8081

4. 启动logviewer日志收集进程

一定要在每个supervisor节点上启动

nohup bin/storm logviewer >~/storm-logviewer-start.log 2>&1 &

5.

bin/storm jar examples/storm-starter/storm-starter-topologies-0.9.6.jar storm.starter.WordCountTopology wordcount

六、Storm的任务

1. kill 任务

bin/storm kill wordcount

2. topology 提交到storm集群上的任务

拓扑图 有向无环图 DAG

比较Storm与MapReduce：

1）Topology

提交到Storm集群上运行，除非手动执行kill命令，否则将一直永远运行下去。

MapReduce任务把数据处理完就终止。

2）实时处理 批处理

地铁站： 自动扶梯，普通电梯

Topology：

spout： 数据采集器

bolt：数据处理器，在bolt里面实现数据的处理逻辑。

stream： Tuple格式。keyvalue对的集合

{"name" : "", }

随机语句->SentenceSpout->SplitBolt -> CountBolt -> 存储Bolt

"Hello Storm" ->

　　Tuple : {"sentence" : "Hello Storm"}

　　　　　　　-> SplitBolt

　　　　　　　-> Tuple {"word" : "Hello"}, {"word" : "Storm"}

　　　　　　　-> key : 单词, value : 单词次数

　　　　　　　 ->

七、zookeeper在Storm中的作用

/storm

　　/workerbeats worker工作进程的状态信息

　　/errors topology在运行过程中出现异常的task信息，方便Nimbus讲运行出错任务进行重新分配

　　/supervisors  supervisor

　　/storms Toplogy的基本配置信息

　　/assignments Topology任务的分配信息

http://blog.sina.com.cn/s/blog_62bb28cc0101j4h6.html

八、实现Topology

Storm编程模型

数据源： kafka

词频统计

kafka： topic "logs"

topology： 数据采集器(KafkaSpout)

SentenceSpout extends RickSpout

+ open()

+ close()

+ nextTuple() 实现如何从数据源上获取数据的逻辑，以及向后面的bolt组件发射数据

+ ack() Topology启用了消息可靠性保障机器，当某个tuple在Topology上处理成功后，调用ack方法执行一些消息处理成功后代码。

+ fail() Topology启用了消息可靠性保障机器，当某个tuple在Topology上处理失败后，调用ack方法执行一些消息处理成功后代码。比如重试，重试达到可执行次数

+ declareOutputFields () 声明向后面组件发射的Tuple keyy一次是什么

+ getComponentConfiguration() //设置该组件Spout一些专用的参数

在Topology中使用的一些类，最好都要实现序列化接口。java.io.Serializable

IRichBolt

+prepare() bolt初始化方法

+execute() 类似于spout的nextTuple()方法

+cleanup()

+declareOutputFields()

+getComponentConfiguration()

数据流分组方式

shuffleGrouping 随机分配

fieldsGrouping

globalGrouping