一、Hbase中的常見屬性
VERSIONS：指版本數
MIN_VERSIONS=> '0'：最小版本數
TTL=> 'FOREVER'：版本存活時間
假設versions=10,mini_version=4
到達TTL時間後，version-mini_version=6，最老的6個版本的值會被清空
create't2', {NAME => 'f1', VERSIONS => 1000,MIN_VERSIONS => '1000',TTL =>'31536000'}
BLOOMFILTER=> 'ROW':布隆過濾器
-》NONE：不使用布隆過濾器
-》ROW：行級布隆過濾器
-》ROWCOL：行列布隆過濾器
進行storefile文件檢索的時候：
ROW：會對當前的storefile進行判斷，判斷是否有我需要的rowkey，
如果有就讀，沒有就跳過
ROWCOL：會對當前的storefile進行判斷，判斷是否有我需要的rowkey+列標籤的組合，
如果有就讀，沒有就跳過
這種消耗的資源較大
BLOCKSIZE=> '65536'：數據塊的大小，如果你的數據塊越小，索引就越大
佔用的內存就越高，速度會更快
create't3', {NAME => 'f1', BLOCKSIZE => '65536'}
BLOCKCACHE=> 'true'：緩存，默認就是true
建議：在企業中，對於不常使用的列簇，關閉緩存
IN_MEMORY=> 'false'：緩存中的級別，設置成TRUE，將優先緩存該列簇
緩存清理的算法：LRU
二、hbase中實現預分區
設計分區時按照rowkey的前綴
-》第一種：創建了5個分區
create'split1', 'f1', SPLITS => ['100', '200', '300', '400']
put'split1','001000000_2016','f1:name','111' 會放到第一個分區中
put'split1','501000000_2016','f1:name','222' 會放到第五個分區中
-》第二種
create'split2', 'f1', SPLITS_FILE => '/opt/datas/splits.txt'
-》第三種（默認創建15個分區，一般不使用）
create'split3', 'f1', {NUMREGIONS => 15, SPLITALGO => 'HexStringSplit'}
-》第四種：Java client
byte[][]splitKeys = {
Bytes.toBytes("100"),
Bytes.toBytes("200"),
Bytes.toBytes("300")
};
三、hbase中的優化
-》hbase中的壓縮
-》時間換取空間
-》Hadoop是否支持需要壓縮類型
snappy安裝：將壓縮包放到並解壓/opt/modules/hadoop-2.5.0/lib/native
bin/hadoopchecknative
-》檢測hbase當前是否支持壓縮
bin/hbaseorg.apache.hadoop.hbase.util.CompressionTest /home/beifeng/snappy.txt snappy
-》修改配置支持壓縮
拷貝hadoop/lib下的native下的所有so文件和hadoop-snappy-0.0.1-SNAPSHOT.jar到hbase/lib下面
cp../hadoop-2.5.0/lib/hadoop-snappy-0.0.1-SNAPSHOT.jar lib/
cp../hadoop-2.5.0/lib/native/* lib/
如果有多臺regionserver，要將文件拷貝到每一臺regionserver上
重啓集羣，測試
如果繼續報錯：
cp../hadoop-2.5.0/lib/native/* ../jdk1.7.0_67/jre/lib/amd64/
重啓測試
2016-12-1919:10:48,830 INFO [main]compress.CodecPool: Got brand-new decompressor [.snappy]
SUCCESS
-》創建表測試
create'snappytest',{NAME=>'F1',COMPRESSION => 'SNAPPY'},{NAME=>'F2'}
-》垃圾回收參數調優
-》JVM：
新生代：空間比較小，主要存儲新生成的對象，生存週期比較短
Eden、survivor
老年代：空間表較大、主要存儲應用程序中生命週期較長的對象
永生代：永久保存的區域，存儲meta和class的信息
元空間（本地內存）
GC：
ParrallelNew Collector 垃圾回收策略
特點：速度比較快，但是不適用與大數據量，GC停頓
並行標記回收器（ConcurrentMark-Sweep Collector）：
特點：速度相對較慢，適用於大數據量的回收，避免GC停頓
exportHBASE_REGIONSERVER_OPTS=”-Xmx8g -Xms8G -Xmn128m -XX:UseParNewGC-XX:UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -verbose:gc-XX:+PrintGCDetails -XX:+PrintGCTimeStamps-Xloggc:$HBASE_HOME/logs/gc-${hostname}-hbase.log”
調優：將上述配置放入conf/hbase-env.sh文件
-》hbase中內存的調優
-》memstore
閾值：128M
<property>
<name>hbase.hregion.memstore.flush.size</name>
<value>134217728</value>
</property>
正常情況：關閉自動溢寫
在業務量較低時，手動觸發flush
-》cache
在注重讀響應時間的應用場景下，可以將 BlockCache設置大些，Memstore設置小些，以加大緩存的命中率。
<name>hbase.regionserver.global.memstore.upperLimit</name>
<value>0.4</value>
<name>hfile.block.cache.size</name>
<value>0.4</value>
按照以下百分比分配給Single、Multi、InMemory使用：0.25、0.50和0.25。
-》本地memstore緩存
內存的孔洞過多，需要進行垃圾回收，造成業務停頓
<name>hbase.hregion.memstore.mslab.enabled</name>
<value>true</value>
缺點：容易造成資源的浪費
-》compact：用於文件的合併和清除被刪除的數據
-》minor compaction：小文件（滿足一定的條件）的合併，輕量級，頻繁執行
它不會刪除被標記爲“刪除”的數據和以過期的數據
-》major compaction
把所有的storefile合併成一個單一的storefile文件，
在文件合併期間系統會刪除標記爲"刪除"標記的數據和過期失效的數據，
同時會block所有客戶端對該操作所屬的region的請求直到合併完畢，
最後刪除已合併的storefile文件。
<name>hbase.hregion.majorcompaction</name>
<value>604800000</value>
改成0就是關閉
企業中手動觸發：major_compact
-》split
最好關閉自動拆分，採用手動拆分方式：split
<name>hbase.hregion.max.filesize</name>
<value>10737418240</value>
建議改成100G
四、hbase表的遷移
-》hadoop數據遷移類似
-》hdfs
-》表的遷移
-》將數據遷移-》hadoop distcp
bin/hdfsfsck /
bin/hbasehbck
-》元數據的恢復
實驗步驟：
-》第一步：將t5表遷移到另一個hdfs集羣
在遷移之前要進行flush操作 （原路徑 目標路徑）
bin/Hadoopdistcp hftp://192.168.134.191:50070/hbase/data/default/t5 hdfs://192.168.134.140:8020/distcp/
-》第二步：刪除t5表
-》第三步：t5表遷移回來
bin/Hadoopdistcp hftp://192.168.134.140:50070/distcp/t5hdfs://192.168.134.191:8020/hbase/data/default/
-》第四步：查詢hbase表
list可以查詢，無法操作
ERROR:Unknown table t5!
-》第五步：元數據恢復
bin/hbasehbck -fixAssignments –fixMeta
五、索引的介紹
rowkey:110_20161211
110_20161212
110_20161213
110_20170213
需求1：查找某個用戶某一時間段內的通話記錄
需求2：查詢某一時間段內所有用戶的通話記錄
索引表方式實現：
源 表：110_20161211
索引表：20161211_110 value:對應源表中的rowkey：110_20161211
需求：通過某一列的值來查詢另一列的值
name,age：查詢所有今年18歲的用戶的姓名
傳統思路：1-查詢所有18歲的用戶的rowkey
2-根據rowkey查詢name
索引實現：rowkey：18
info:rowkey:18歲對應的rowkey
索引表同步的問題：
-》第一種（效率低）：在客戶端執行，對源表操作時，同時對索引表進行操作
-》第二種：編寫協處理器
在server端運行在客戶端同步的邏輯，但是中小型企業不會自己編寫
-》其他框架：第三方工具
-》Phoenix：底層就是協處理器
-》solr
-》elasticsearch
協處理器類型：
observer：觀察者類，類似於RDBMS中的觸發器
endpoint：終端類，類似於存儲過程
六、hbase與其他框架的集成
-》Hive
-》sqoop
-》flume
-》hue
-》sqoop與hbase集成（使用的是cdh版本的）
用於hdfs與RDBMS之間的導入導出
-》配置conf/sqoop-env.sh
原始
新配置
exportHADOOP_COMMON_HOME=/opt/modules/hadoop-2.5.0
#Setpath to where hadoop-*-core.jar is available
exportHADOOP_MAPRED_HOME=/opt/modules/hadoop-2.5.0
#setthe path to where bin/hbase is available
exportHBASE_HOME=/opt/modules/hbase-0.98.6-hadoop2
#Setthe path to where bin/hive is available
#exportHIVE_HOME=/opt/cdh-5.3.6/hive-0.13.1-cdh5.3.6
#Setthe path for where zookeper config dir is
exportZOOCFGDIR=/opt/modules/zookeeper-3.4.5/conf
導入：
bin/sqoopimport \
--connect\
jdbc:MySQL://hadoop-senior01.ibeifeng.com:3306/test\
--usernameroot \
--password123456 \
--tablemy_user \
--hbase-create-table\
--hbase-tabletest \
--hbase-row-keyid \
--column-familyinfo \
-m1
在HBase中查詢：
導出：沒有導出
怎麼實現用sqoop導出hbase的數據？
搭橋：hive
hive與hbase集成
|
將hbase表中的數據存儲到另一張hive表中
|
通過hdfs導出
-》hue集成
-》啓動hbase的thrift
bin/hbase-daemon.shstart thrift
—》修改hue.ini配置文件（/opt/cdh-5.3.6/hue-3.7.0-cdh5.3.6/desktop/conf/）
hbase_clusters=(Cluster|hadoop-senior01.ibeifeng.com:9090)
# HBase configuration directory, wherehbase-site.xml is located.
hbase_conf_dir=/opt/modules/hbase-0.98.6-hadoop2/conf
-》啓動hue
hue：build/env/bin/supervisor
hadoop-senior01.ibeifeng.com:8888
