1、關於delete marker的問題。(p24)
hbase的delete命令，並不是真的刪除了文件，而是設置一個標記（delete marker）。用戶在檢索數據的時候，會過濾掉這些標示的數據。
HBase的刪除標記有三種：
1. version delete marker 刪除指定version的某個qualifier對應的value
2. column delete marker 刪除某個qualifier的所有version的數據
3. family delete marker 刪除column family 下所有qualifier對應的所有version的數據
還可以再column和family delete marker上打上時間戳，這時，只有小於這個時間戳的version纔會被影響到。
HBase允許進行基於時間的查詢從而得到指定時間段的歷史數據。查詢時間T的數據即查詢[0,T+1)的數據。這樣就帶來了一個潛在的問題。當一個delete marker被set上，所有被它影響到的數據都不再可見。如果你在時間T put了一個qualifier爲C的數據，接着在T+X的時間點刪除這個qualifier，此時查詢[0,T+1)時間段的數據將不會返回qualifier爲C的這個KV對。
HBASE-4536 https://issues.apache.org/jira/browse/HBASE-4536解決了這個問題，可以通過在shell裏建表時加上 KEEP_DELETED_CELLS=>true或在java client上調用時加上HColumnDescriptor.setKeepDeletedCells(true)。這樣，被刪除的數據在基於時間的歷史數據查詢中依然可見(當然要保證delete marker的時間戳不在歷史查詢的時間範圍內)。就剛纔的例子來說，加上這個支持後，查詢[0,T+1)時間段的數據將會返回C，而查詢[0,T+X+1)時間段的數據將不會返回C，因爲在該時間點，C也已經被刪除了。
2、關於HBase的壓縮的兩種方法
當由內存將文件flush到硬盤上時，會創建很多的hfile文件，對這些hfile文件需要壓縮，包含minor compactions and major compactions
minor壓縮，是將多個小的文件合併成大的文件，執行n路合併。
major壓縮，是指將一個column family的文件都存儲爲一個大文件，同時他還掃描刪除標示，或者過期的版本信息。
此處有LSM-tree的引子，等到[p316]也的時候仔細研究下。
3、Hbase有三個主要的部件組成。
- Client
- Master Server
- RegisonServer
- Cilent
- 包含訪問hbase的接口，client維護着一些cache來加快對hbase的訪問，比如regione的位置信息。
- MasterServer
- 爲Region server分配region
- 負責region server的負載均衡
- 發現失效的region server並重新分配其上的region
- GFS上的垃圾文件回收
- 處理schema更新請求
- Region Server
- Region server維護Master分配給它的region，處理對這些region的IO請求
- Region server負責切分在運行過程中變得過大的region
- Zookeeper
- 保證任何時候，集羣中只有一個master
- 存貯所有Region的尋址入口。
- 實時監控Region Server的狀態，將Region server的上線和下線信息實時通知給Master
- 存儲Hbase的schema,包括有哪些table，每個table有哪些column family