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。