[TOC] 下面幾個shell 命令在hbase操作中可以起到很到的作用，且主要體現在建表的過程中，看下面幾個create 屬性 # BLOOMFILTER 默認是NONE 是否使用布隆過慮及使用何種方式 布隆過濾可以每列族單獨啟用。 使用 HColumnDescriptor.setBloomFilterType(NONE | ROW | ROWCOL) 對列族單獨啟用布隆。 * Default = ROW 對行進行布隆過濾。 * 對 ROW，行鍵的哈希在每次插入行時將被添加到布隆。 * 對 ROWCOL，行鍵 + 列族 + 列族修飾的哈希將在每次插入行時添加到布隆 使用方法: create 'table',{BLOOMFILTER =>'ROW'} **啟用布隆過濾可以節省讀磁盤過程，可以有助于降低讀取延遲 ** # VERSIONS 默認是1 這個參數的意思是數據保留1個 版本，如果我們認為我們的數據沒有這么大的必要保留這么多，隨時都在更新，而老版本的數據對我們毫無價值，那將此參數設為1 能節約2/3的空間 使用方法: `create 'table',{VERSIONS=>'2'}` 附：`MIN_VERSIONS => '0'`是說在compact操作執行之后，至少要保留的版本 # COMPRESSION 默認值是NONE 即不使用壓縮 這個參數意思是該列族是否采用壓縮，采用什么壓縮算法 使用方法: create 'table',{NAME=>'info',COMPRESSION=>'SNAPPY'} 建議采用SNAPPY壓縮算法 HBase中，在Snappy發布之前（Google 2011年對外發布Snappy），采用的LZO算法，目標是達到盡可能快的壓縮和解壓速度，同時減少對CPU的消耗； 在Snappy發布之后，建議采用Snappy算法（參考《HBase: The Definitive Guide》），具體可以根據實際情況對LZO和Snappy做過更詳細的對比測試后再做選擇。  如果建表之初沒有壓縮，后來想要加入壓縮算法，可以通過alter修改schema # alter 使用方法： 如 修改壓縮算法 ~~~ disable 'table' alter 'table',{NAME=>'info',COMPRESSION=>'snappy'} enable 'table' ~~~ 但是需要執行`major_compact 'table'` 命令之后 才會做實際的操作。 # TTL 默認是 2147483647 即:Integer.MAX_VALUE 值大概是68年 這個參數是說明該列族數據的存活時間，單位是s 這個參數可以根據具體的需求對數據設定存活時間，超過存過時間的數據將在表中不在顯示，待下次major compact的時候再徹底刪除數據 注意的是TTL設定之后 `MIN_VERSIONS=>'0'` 這樣設置之后，TTL時間戳過期后，將全部徹底刪除該family下所有的數據，如果MIN_VERSIONS 不等于0那將保留最新的MIN_VERSIONS個版本的數據，其它的全部刪除，比如MIN_VERSIONS=>'1' 屆時將保留一個最新版本的數據，其它版本的數據將不再保存。 # describe 'table' 這個命令查看了create table 的各項參數或者是默認值 `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)? 并給出確認提示 ~~~ # drop_all 這個命令和disable_all的使用方式是一樣的 # hbase 表預分區----手動分區 默認情況下，在創建HBase表的時候會自動創建一個region分區，當導入數據的時候，所有的HBase客戶端都向這一個region寫數據，直到這個region足夠大了才進行切分。**一種可以加快批量寫入速度的方法是通過預先創建一些空的regions**，這樣當數據寫入HBase時，會按照region分區情況，在集群內做數據的負載均衡。 命令方式: ~~~ create 't1', 'f1', {NUMREGIONS => 15, SPLITALGO => 'HexStringSplit'} ~~~ 也可以使用api的方式: ~~~ bin/hbase org.apache.hadoop.hbase.util.RegionSplitter test_table HexStringSplit -c 10 -f info ~~~ 參數： ~~~ test_table是表名 HexStringSplit 是split 方式 -c 是分10個region -f 是family ~~~ 可在UI上查看結果，如圖：  這樣就可以將表預先分為15個區，減少數據達到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的方式，并將檢測如果達到這個值，再手動分配region** # 行鍵設計 表結構設計 1. 列族數量的設定 以用戶信息為例，可以將必須的基本信息存放在一個列族，而一些附加的額外信息可以放在另一列族； 2. 行鍵的設計 語音詳單： ~~~ 13877889988-20150625 13877889988-20150625 13877889988-20150626 13877889988-20150626 13877889989 13877889989 13877889989 ~~~ ----將需要批量查詢的數據盡可能連續存放 CMS系統----多條件查詢 盡可能將查詢條件關鍵詞拼裝到rowkey中，查詢頻率最高的條件盡量往前靠 ~~~ 20150230-zhangsan-category… 20150230-lisi-category… ~~~ (每一個條件的值長度不同，可以通過做定長映射來提高效率) 參考：《hbase 實戰》----詳細講述了facebook /GIS等系統的表結構設計