問題描述：
在某一個時刻，電池資料表的以某些規則開頭的資料，比如M12******，這些電池一直在上報資料，由于HBase的存儲是按照字典順序排序的，所有某一時刻，相似規則的資料落在了同一個region上，造成了資料熱點。
解決方法：
在建表的時候，按照字典順序，随機生成一批startkey和endkey的集合，這些集合按照字典順序排列，寫入資料的時候，将要寫入的【key_時間戳】前面加上哈希字首，形成【三位哈希值_key_時間戳】方式，将寫入資料的壓力分散開。
問題描述：
曆史資料的消費過程，就是把資料寫入HBase的過程，但是寫入HBase過慢，容易造成消費不過來，産生資料堆積，由于資料堆積，會影響Kafka拉取資料消費發送心跳的逾時。
解決方法：
1， HBase寫操作盡量采用批量寫入操作；
2， 禁用預寫日志：put.setDurability(Durability.SKIP_WAL);//禁用hbase的預寫日志功能（但是禁用預寫日志的方式不夠安全）
3， 禁止autoflush:table.setAutoFlushTo(false); 并配置write buff:
<property>
<name>hbase.client.write.buffer</name>
<value>5000000</value>
</property>
4,消費過程采用線程池寫入：最開始用的可回收線程池，但是觀察GC發現，FGC太多，而且資料量大了，CUP占用過高，最後還是采用固定的數目的線程池，多開幾個用戶端進行消費；
問題描述：
采用了固定線程池持續運作一段時間之後，觀察GC發現：
導出對記憶體情況觀察：
發現有寫對象在持續增長，後來觀察寫入HBase的監控，發現Hbase每秒寫入資料操作在0.001次這樣子，通過對象分析，發現線程池在執行任務時候，會有個LinkedBlockingQueue的隊列，由于HBase寫入阻塞，導緻隊列持續遞增，FGC持續進行，判斷問題處在了HBase上面。
觀察HBase目前配置：memstore：256M，hbase.hregion.max.filesize：10G （一個region最多管理10G的HFile），當寫入的資料總量超過一定數量（1T）時，寫入速度變慢。寫入方式rowkey前加hash。
能源站對表預建了20個Region,随着資料量膨脹分裂到了160個
由于寫入方式是完全随機寫入到各個region中，因為region數量過多，大量時間浪費在等待region釋放資源,擷取region連接配接，釋放連接配接。。
車聯網的某些表雖然也有100多個region。但是由于寫入的資料不是完全随機的，是以每次都是client隻連接配接一個region去寫，是以壓測時沒出現此問題。
解決方案：
禁用表的自動分期政策，如果日後有需要，手動分區。
alter'batteryData',{METADATA=>{'SPLIT_POLICY'=>'org.apache.hadoop.hbase.regionserver.DisabledRegionSplitPolicy'}},{NAME=> 't'}