Hbase 是一個分布式的、面向列的開來源資料庫，其實現是建立在google 的bigTable 理論之上，並基於hadoop HDFS檔案系統。 Hbase不同於一般的關係型資料庫(RDBMS)。是一種適用於非結構化資料存放區的資料庫，且Hbase是基於列的資料庫。 下面的內容基於我們已經安裝好hadoop、hbase。 一、hbase shell 介紹 hbase shell是使用者和hbase 互動的介面之一，當然還可以通過其它方式比如java api等 下表列出了 hbase 基本命令操作：
| 操作 |
命令運算式 |
注意
|
| 建立表 |
create 'table_name, 'family1','family2','familyN' |
|
| 添加記錄 |
put 'table_name', 'rowkey', 'family:column', 'value' |
|
| 查看記錄 |
get 'table_name', 'rowkey' |
查詢單條記錄，也是hbase 最常用的命令 |
| 查看錶中的記錄總數 |
count 'table_name' |
這個命令並不快，且目前沒有找到更快的方式統計行數 |
| 刪除記錄 |
delete 'table_name' ,'rowkey','family_name:column'
deleteall 'table_name','rowkey' |
第一種方式刪除一條記錄單列的資料
第二種方式刪除整條記錄 |
|
| 刪除一張表 |
1、disable 'table_name' |
|
| 2、drop 'table_name' |
| 查看所有記錄 |
scan "table_name" ,{LIMIT=>10} |
LIMIT=>10 只返回10條記錄，否則將全部展示 |
利用上面基礎命令可以完成基本的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 支援Regex，並列出當前匹配的表的如下： 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
