HBase生产环境配置与使用优化不完全指南

2019独角兽企业重金招聘Python工程师标准>>>

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。

转载于:https://my.oschina.net/u/3611008/blog/2873577