hbase建表create高級屬性 //hbase 表預分區也就是手動分區 這個很重要

2019/2/19 星期二

hbase建表create高級屬性 //hbase 表預分區也就是手動分區 這個很重要

下面幾個shell 命令在后續的hbase 操作中可以起到很到的作用，且主要體現在建表的過程中，看下面幾個create 屬性
1、BLOOMFILTER 默認是NONE 是否使用布隆過慮使用何種方式
布隆過濾可以每列族單獨啟用。使用HColumnDescriptor.setBloomFilterType(NONE |ROW | ROWCOL) 對列族單獨啟用布隆。Default = NONE 沒有布隆過濾。對ROW，行鍵的哈希在每次插入行時將被添加到布隆。對ROWCOL，行鍵+ 列族+ 列族修飾的哈希將在每次插入行時添加到布隆
使用方法: create 'table',{BLOOMFILTER =>'ROW'}
啟用布隆過濾可以節省必須讀磁盤過程，可以有助于改進讀取延遲

2、VERSIONS 默認是3 這個參數的意思是數據保留三個版本，如果我們認為我們的數據沒有這么大的必要保留這么多，隨時都在更新，而老版本的數據對我們毫無價值，那將此參數設為1 能節約2/3 的空間
使用方法: create 'table',{VERSIONS=>'2'}

3、COMPRESSION 默認值是NONE 即 不使用壓縮
這個參數意思是該列族是否采用壓縮，采用什么壓縮算法
使用方法: create 'table',{NAME=>'info',COMPRESSION=>'SNAPPY'}
我建議采用SNAPPY 壓縮算法，個壓縮算法的比較網上比較多，我從網上摘抄一個表格作為參考，具體的snappy 的安裝后續會以單獨章節進行描述。
這個表是Google 幾年前發布的一組測試數據，實際測試Snappy 和下表所列相差無幾。HBase 中，在Snappy 發布之前（Google 2011 年對外發布Snappy），采用的LZO 算法，
目標是達到盡可能快的壓縮和解壓速度，同時減少對CPU 的消耗；在Snappy 發布之后，建議采用Snappy 算法（參考《HBase: The Definitive Guide》），具體可以根據實際情況對LZO 和Snappy 做過更詳細的對比測試后再做選擇。
Algorithm（算法） % remaining（剩余） Encoding（編碼） Decoding（解碼）
GZIP 13.4% 21 MB/s 118 MB/s
LZO 20.5% 135 MB/s 410 MB/s
Zippy/Snappy 22.2% 172 MB/s 409 MB/s
如果建表之初沒有壓縮，后來想要加入壓縮算法，怎么辦hbase 有另外的一個命令alter

4、alter
使用方法：
如修改壓縮算法
disable 'table'
alter 'table',{NAME=>'info',COMPRESSION=>'snappy'}
enable 'table'
刪除列族
disable 'table'
alter 'table',{NAME=>'info',METHOD=>'delete'}
enable 'table'
但是這樣修改之后發現表數據還是那么大，并沒有發生多大變化。怎么辦
major_compact 'table' 命令之后才會做實際的操作。

5、TTL 默認是2147483647 即:Integer.MAX_VALUE 值大概是68 年
這個參數是說明該列族數據的存活時間也就是數據的生命周期單位是s 默寫文章寫的單位是ms 是錯誤的。
這個參數可以根據具體的需求對數據設定存活時間，超過存過時間的數據將在表中不在顯示，待下次major compact 的時候再徹底刪除數據
為什么在下次major compact 的時候刪除數據，后面會具體介紹到。
注意的是TTL 設定之后MIN_VERSIONS=>'0' 這樣設置之后，TTL 時間戳過期后，將全部徹底刪除該family 下所有的數據，如果MIN_VERSIONS 不等于0 那將保留最新的MIN_VERSIONS 個版本的數據，其它的全部刪除，比如MIN_VERSIONS=>'1' 屆時將保留一個最新版本的數據，其它版本的數據將不再保存。

6、describe 'table' 這個命令查看了create table 的各項參數或者是默認值。

7、disable_all 'toplist.*' disable_all 支持正則表達式，并列出當前匹配的表的如下：
toplist_a_total_1001
toplist_a_total_1002
toplist_a_total_1008
toplist_a_total_1009
toplist_a_total_1019
toplist_a_total_1035
...
Disable the above 25 tables (y/n)? 并給出確認提示

8、drop_all 這個命令和disable_all 的使用方式是一樣的

9、hbase 表預分區也就是手動分區
默認情況下，在創建HBase 表的時候會自動創建一個region 分區，當導入數據的時候，所有的HBase 客戶端都向這一個region 寫數據，直到這個region 足夠大了才進行切分。一種可以加快批量寫入速度的方法是通過預先創建一些空的regions，這樣當數據寫入HBase時，會按照region 分區情況，在集群內做數據的負載均衡。
使用方法:create 't1', 'f1', {NUMREGIONS => 15, SPLITALGO => 'HexStringSplit'}
也可以使用api 的方式
hbase org.apache.hadoop.hbase.util.RegionSplitter test_table HexStringSplit -c 10 -f info
參數很容易看懂test_table 是表名HexStringSplit 是split 方式 -c 是分10 個region -f 是family（列族）

這樣就可以將表預先分為10個區，減少數據達到storefile 大小的時候自動分區的時間消耗，并且還有以一個優勢，就是合理設計rowkey 能讓各個region 的并發請求平均分配(趨于均勻) 使IO 效率達到最高，但是預分區需要將filesize 設置一個較大的值，設置哪個參數呢hbase.hregion.max.filesize 這個值默認是10G 也就是說單個region 默認大小是10G
這個值發生從0.90 到0.92 到0.94.3 從256M--1G--10G 這個根據自己的需求將這個值修改。

但是如果MapReduce Input 類型為TableInputFormat 使用hbase 作為輸入的時候，就要注意了，每個region 一個map，如果數據小于10G 那只會啟用一個map 造成很大的資源浪費，這時候可以考慮適當調小該參數的值，或者采用預分配region 的方式，并將
hbase.hregion.max.filesize 設為一個相對比較大的值，不容易達到的值比如1000G，檢測如果達到這個值，再手動分配region。

前面說到了compact 為什么設置了TTL 超過存活時間的數據就消失了，是如何消失的呢？是刪除了嗎？通過哪些參數刪除的。
后面將要說到hbase compact

例如建表語句為： //生產上，可以用于這樣去創建hbase表
hbase(main):009:0> create 'NewsClickFeedback',{NAME=>'Toutiao',VERSIONS=>1,BLOCKCACHE=>true,BLOOMFILTER=>'ROW',COMPRESSION=>'SNAPPY',TTL => 2592000 },{SPLITS => ['1','2','a','b']}

提示：NAME=>'Toutiao' 列族為 Toutiao ；VERSIONS=>1 版本號為1 ；是否開啟block cache緩存，默認開啟。；
BLOOMFILTER=>'ROW' 布隆過濾器，優化HBase的隨機讀取性能，可選值NONE|ROW|ROWCOL，默認為NONE，該參數可以單獨對某個列簇啟用。COMPRESSION=>'SNAPPY' 壓縮；過期時間 TTL => 2592000 為30天
{SPLITS => ['1','2','a','b']} 分區；一般采用hash + partition的方式預分配region，比如示例中rowkey首先使用md5 hash，然后再按照首字母partition為4份，就可以預分配4個region。

插入數據
put 'NewsClickFeedback', '1', 'Toutiao:name', 'zhangsan'
put 'NewsClickFeedback', '01', 'Toutiao:name', 'lisi'
put 'NewsClickFeedback', '100', 'Toutiao:name', 'wangwu'
put 'NewsClickFeedback', '4', 'Toutiao:name', 'liuliu'

IN_MEMORY
數據是否常駐內存，默認為false。HBase為頻繁訪問的數據提供了一個緩存區域，緩存區域一般存儲數據量小、訪問頻繁的數據，常見場景為元數據存儲。默認情況，該緩存區域大小等于Jvm Heapsize 0.2 0.25 ，假如Jvm Heapsize = 70G，存儲區域的大小約等于3.2G。需要注意的是HBase Meta元數據信息存儲在這塊區域，如果業務數據設置為true而且太大會導致Meta數據被置換出去，導致整個集群性能降低，所以在設置該參數時需要格外小心。
//
IN_MEMORY表示常駐內存，用戶如果在列族設置該參數為true，表示該列族對應的數據會常駐內存，一般建議如果是業務元數據，可以設置為常駐內存，另外，hbase:meta數據是常駐內存的。至于hbase:meta能不能執行split，本人在實際環境實際執行命令:split ‘hbase:meta’，結果還是一個region，并沒有出現多個region，目前還是認為hbase:meta不能執行split。
HBase BlockCache系列 – 走進BlockCache http://hbasefly.com/2016/04/08/hbase-blockcache-1/ 在此鏈接中提到了IN_MEMORY=true
//而in-memory區表示數據可以常駐內存，一般用來存放訪問頻繁、數據量小的數據，比如元數據，用戶也可以在建表的時候通過設置列族屬性IN-MEMORY= true將此列族放入in-memory區。

blocksize
HFile會被切分為多個大小相等的block塊，每個block的大小可以在創建表列簇的時候通過參數blocksize ＝> ‘65535’進行指定，默認為64k，大號的Block有利于順序Scan，小號Block利于隨機查詢，因而需要權衡。
//如果業務請求以Get請求為主，可以考慮將塊大小設置較小；如果以Scan請求為主，可以將塊大小調大；默認的64K塊大小是在Scan和Get之間取得的一個平衡

參考鏈接為：HBase － 建表語句解析 http://hbasefly.com/2016/03/23/hbase_create_table/
HBase(八): 表結構設計優化：https://www.cnblogs.com/tgzhu/archive/2016/09/11/5862299.html