業(yè)務背景：由于需要將ngix日志過濾出來的1億+條用戶行為記錄存入Hbase數(shù)據(jù)庫，以此根據(jù)一定的條件來提供近實時查詢，比如根據(jù)用戶id及一定的時間段等條件來過濾符合要求的若干行為記錄，滿足這一場景的技術包括：Solr，Elasticsearch，hbase等，在此選用了Hbase來實踐。
step 1 :
直接hbase建表，然后讀取記錄文件逐條寫入Hbase。由于hbase實際的寫入速度遠遠小于我的提交速度，在寫入了1700條記錄后，hbase出現(xiàn)了宕機，提交后無響應。查看hbase日志，出現(xiàn) out of memory異常。
step 2：
考慮在建表的時候沒有進行預分區(qū)，因此寫入的時候會存在熱點寫的問題，同時數(shù)據(jù)持續(xù)增長，需要不斷的對region進行split，實際上這一步相當消耗資源。因此對要寫入的Hbase表重新預分區(qū)。好在上一步驟中寫入的數(shù)據(jù)不多，因此直接刪除表和數(shù)據(jù)后重新建表并預分區(qū)：
- create 'user_actions', {NAME => 'info', VERSIONS=> 3},{SPLITS => ['130','140','160','170','180']}
設計預分區(qū)的時候需要有個預判，rowkey的范圍及在各個區(qū)間的可能分布情況，由于我這里的rowkey是組合用戶的注冊電話/時間及其他字段，因此上述的預分區(qū)，可以將記錄較好的散列在各個region上，對熱點寫有一定的減緩作用。
同時，針對out of memory異常，修改hbase配置文件/conf/hbase-site.xml，將hbase的堆內(nèi)存增加到3GB(條件有限，如果硬件條件好的話，可以增加到4-8GB)。
繼續(xù)寫入，但是寫入速度很慢，維持在數(shù)百條/秒的樣子，同時寫入了20幾萬條后響應速度越來越慢。
STEP?。常?/h2>
上述問題的根源在于高頻提交小數(shù)據(jù)，導致Hbase疲于創(chuàng)建線程并進行資源的回收，最終甚至會出現(xiàn)宕機。
之后，將單條put到Hbase改為一次put多條記錄到hbase，即批量提交，同時限制一秒內(nèi)提交的頻次。最后順利寫入。由于hbase集群只有三臺機器(一臺master,2臺slave)，進過上述優(yōu)化后，寫入速度基本維持在1w-2w條/秒的水平，基本滿足需要了。
總結：在hbase涉及一次性寫入大量數(shù)據(jù)時，有幾個地方可以考慮進行優(yōu)化：(1)建表的同時進行預分區(qū) (2)修改Hbase本身的配置(能夠優(yōu)化寫入和讀取的配置項遠不止修改堆內(nèi)存這一項，在此不表了) (3)盡量使用批量寫入的方法，同樣的道理，讀取的時候，使用批量讀的方法 (4)網(wǎng)絡IO/磁盤IO
除了批量Put外，Hbase還支持Hfiles方式導入：
STEP 1:
將要導入的數(shù)據(jù)預生成hfiles文件。
STEP 2:
使用Hbase的BulkLoad方式將Hfile文件批量導入Hbase。
