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。
来源:oschina
链接:https://my.oschina.net/u/3611008/blog/2873577