HBase生产环境配置与使用优化不彻底指南

HBase上线至今，承载了线上全部实时交易量，虽然大部分请求都可以保证服务稳定（99.56%响应时间毫秒级），可是一旦HBase出现问题就是鸡飞狗跳的灾难。 
从老机器到新集群，从老机房到新机房，期间经历过各类问题和生产故障，总结一番以备不时之需。

HBase使用定位：大规模数据+高并发+毫秒级响应的OLTP实时系统（数据库）。

集群部署架构

HBase集群一旦部署使用，再想对其做出调整须要付出惨痛代价，因此如何部署HBase集群是使用的第一个关键步骤。

如下是HBase集群使用以来的部署架构变化以及对应的分析。

第一阶段 硬件混合型+软件混合型集群

• 集群规模：20
• 部署服务：HBase、Spark、Hive、Impala、Kafka、Zookeeper、Flume、HDFS、Yarn等
• 硬件状况：内存、CPU、磁盘等良莠不齐，有高配有低配，混搭结构

硬件混合型指的是该集群机器配置良莠不齐，混搭结构。 
软件混合型指的是该集群部署了一套CDH全家桶套餐。

这个集群无论是规模、仍是服务部署方式相信都是不少都有公司的”标准“配置。

那么这样的集群有什么问题呢？

若是仅仅HBase是一个非“线上”的系统，或者充当一个历史冷数据存储的大数据库，这样的集群其实一点问题也没有，由于对其没有任何苛刻的性能要求。

可是若是但愿HBase做为一个线上可以承载海量并发、实时响应的系统，这个集群随着使用时间的增长很快就会崩溃。

先从硬件混合型来讲，一直以来Hadoop都是以宣称可以用低廉、老旧的机器撑起一片天。是的没错，这确实是Hadoop的一个大优点。然而前提是做为离线系统使用。首先说明一下离线系统的定义，就是跑批的系统，Spark、Hive、MapReduce等等，这些都算，没有很强的时间要求，显著的吞吐量大，延迟高。由于没有实时性要求，几台拖拉机跑着也没有问题，只要最后能出结果而且结果正确就ok。