Hbase在生態系統中的位置
Hbase存儲的邏輯視圖
Hbase的存儲格式
Hbase寫數據流程
Hbase快速響應數據
Hbase在生態系統中的位置
HBase位於結構化存儲層，Hadoop HDFS為HBase提供了高可靠性的底層存儲支持，Hadoop MapReduce為HBase提供了高性能的計算能力，Zookeeper為HBase提供了穩定服務和failover機制。
Hbase存儲的邏輯視圖
1）行鍵(RowKey)
-- 行鍵是字節數組, 任何字符串都可以作為行鍵；
-- 表中的行根據行鍵進行排序，數據按照Row key的字節序(byte order)排序存儲；
-- 所有對表的訪問都要通過行鍵 （單個RowKey訪問，或RowKey范圍訪問，或全表掃描) （二級索引）
2）列族（ColumnFamily）
-- CF必須在表定義時給出
-- 每個CF可以有一個或多個列成員(ColumnQualifier)，列成員不需要在表定義時給出，新的列族成員可以隨后按需、動態加入
-- 數據按CF分開存儲，HBase所謂的列式存儲就是根據CF分開存儲（每個CF對應一個Store），這種設計非常適合於數據分析的情形
3）時間戳（TimeStamp）
-- 每個Cell可能又多個版本，它們之間用時間戳區分
4）單元格（Cell）
-- Cell 由行鍵，列族:限定符，時間戳唯一決定，數據全部以字節碼形式存儲
5）區域(Region）
-- HBase自動把表水平（按Row）划分成多個區域(region)，每個region會保存一個表里面某段連續的數據；
-- 每個表一開始只有一個region，隨着數據不斷插入表，region不斷增大，當增大到一個閥值的時候，region就會等分會兩個新的region；
-- 當table中的行不斷增多，就會有越來越多的region。這樣一張完整的表被保存在多個Region 上。
-- HRegion是HBase中分布式存儲和負載均衡的最小單元（默認256M）。最小單元表示不同的HRegion可以分布在不同的HRegionServer上。但一個HRegion不會拆分到多個server上。
特點：
無模式：每行都有一個可排序的主鍵和任意多的列，列可以根據需要動態的增加，同一張表中不同的行可以有截然不同的列；
面向列：面向列（族）的存儲和權限控制，列（族）獨立檢索；
稀疏：空（null）列並不占用存儲空間，表可以設計的非常稀疏；
Hbase的存儲格式
HBase中的每張表都通過行鍵按照一定的范圍被分割成多個子表（HRegion），默認一個HRegion超過256M就要被分割成兩個，由HRegionServer管理，管理哪些HRegion由HMaster分配。
HRegionServer存取一個子表時，會創建一個HRegion對象，然后對表的每個列族(Column Family)創建一個Store實例，每個Store都會有0個或多個StoreFile與之對應，每個StoreFile都會對應一個HFile， HFile就是實際的存儲文件。因此，一個HRegion有多少個列族就有多少個Store。另外，每個HRegion還擁有一個MemStore實例。memStore存儲在內存中，StoreFile存儲在HDFS上。
Region雖然是分布式存儲的最小單元，但並不是存儲的最小單元。Region由一個或者多個Store組成，每個store保存一個columns family；每個Store又由一個memStore和0至多個StoreFile組成，StoreFile包含HFile；memStore存儲在內存中，StoreFile存儲在HDFS上。
HBase是基於BigTable的面向列的分布式存儲系統，其存儲設計是基於Memtable / SSTable設計的，主要分為兩部分，一部分為內存中的MemStore (Memtable)，另外一部分為磁盤(這里是HDFS)上的HFile (SSTable)。還有就是存儲WAL的log，主要實現類為HLog.
本質上MemStore就是一個內存里放着一個保存KEY/VALUE的MAP，當MemStore（默認64MB）寫滿之后，會開始刷磁盤操作。
HFile結構：
Data Block：保存表中的數據，這部分可以被壓縮
Meta Block：（可選）保存用戶自定義的kv對，可以被壓縮。
File Info ：Hfile的meta元信息，不被壓縮，定長。
Data Block Index ：Data Block的索引。每個Data塊的起始點。
Meta Block Index：（可選的）Meta Block的索引，Meta塊的起始點。
Trailer： 定長。保存了每一段的偏移量，讀取一個HFile時，會首先讀取Trailer，Trailer有指針指向其他數據塊的起始點，保存了每個段的起始位置(段的Magic Number用來做安全check)，然后，DataBlock Index會被讀取到內存中，這樣，當檢索某個key時，不需要掃描整個HFile，而只需從內存中找到key所在的block，通過一次磁盤io將整個block讀取到內存中，再找到需要的key。DataBlock Index采用LRU機制淘汰。
HFile的Data Block，Meta Block通常采用壓縮方式存儲。Data Block是HBase I/O的基本單元，為了提高效率，HRegionServer中有基於LRU的Block Cache機制。每個Data塊的大小可以在創建一個Table的時候通過參數指定，大號的Block有利於順序Scan，小號Block利於隨機查詢。每個Data塊除了開頭的Magic以外就是一個個KeyValue對拼接而成, Magic內容就是一些隨機數字，目的是防止數據損壞。
HFile中的Key-Value結構
HFile中的每個Key-Value對就是一個簡單的byte數組。但這個byte數組包含了很多項信息，並含有固定的結構。（有點類似數據流）
開始是兩個長度固定的數值，分別表示Key的長度和Value的長度。緊接着是Key，開始是固定長度的數值，表示RowKey的長度，緊接着是RowKey，然后是固定長度的數值，表示Family的長度，然后是Family（列族），接着是Qualifier（小列），然后是兩個固定長度的數值，表示Time Stamp和Key Type（Put/Delete）。Value部分則相對簡單，是純粹的二進制數據。
HBase 為每個值維護了多級索引，即：<key, column family, column name（qualifer）, timestamp>
Hbase寫數據流程
a) Client發起了一個HTable.put(Put)請求給HRegionServer
b) HRegionServer會將請求匹配到某個具體的HRegion上面
c) 決定是否寫WAL log。WAL log文件是一個標准的Hadoop SequenceFile，文件中存儲了HLogKey，這些Keys包含了和實際數據對應的序列號，主要用於崩潰恢復。
d) Put數據保存到MemStore中，同時檢查MemStore狀態，如果滿了，則觸發Flush to Disk請求。
e) HRegionServer處理Flush to Disk的請求，將數據寫成HFile文件並存到HDFS上，並且存儲最后寫入的數據序列號，這樣就可以知道哪些數據已經存入了永久存儲的HDFS中。
由於不同的列族會共享region，所以有可能出現，一個列族已經有1000萬行，而另外一個才100行。當一個要求region分割的時候，會導致100行的列會同樣分布到多個region中。所以，一般建議不要設置多個列族。
Hbase快速響應數據
hbase上的數據是以storefile(HFile)二進制流的形式存儲在HDFS上block塊中；但是HDFS並不知道的hbase存的是什么，它只把存儲文件是為二進制文件，也就是說，hbase的存儲數據對於HDFS文件系統是透明的。
HBase HRegion servers集群中的所有的region的數據在服務器啟動時都是被打開的，並且在內沖初始化一些memstore，相應的這就在一定程度上加快系統響應；而Hadoop中的block中的數據文件默認是關閉的，只有在需要的時候才打開，處理完數據后就關閉，這在一定程度上就增加了響應時間。
從根本上說，HBase能提供實時計算服務主要原因是由其架構和底層的數據結構決定的，即由LSM-Tree + HTable(region分區) + Cache決定——客戶端可以直接定位到要查數據所在的HRegion server服務器，然后直接在服務器的一個region上查找要匹配的數據，並且這些數據部分是經過cache緩存的。
Client訪問用戶數據之前需要首先訪問zookeeper，然后訪問-ROOT-表，接着訪問.META.表，最后才能找到用戶數據的位置去訪問，中間需要多次網絡操作，不過client端會做cache緩存。
1、Client會通過內部緩存的相關的-ROOT-中的信息和.META.中的信息直接連接與請求數據匹配的HRegion server；
2、然后直接定位到該服務器上與客戶請求對應的region，客戶請求首先會查詢該region在內存中的緩存——memstore(memstore是是一個按key排序的樹形結構的緩沖區)；
3、如果在memstore中查到結果則直接將結果返回給client；
4、在memstore中沒有查到匹配的數據，接下來會讀已持久化的storefile文件中的數據。storefile也是按key排序的樹形結構的文件——並且是特別為范圍查詢或block查詢優化過的，；另外hbase讀取磁盤文件是按其基本I/O單元(即 hbase block)讀數據的。具體就是過程就是：
如果在BlockCache中能查到要造的數據則這屆返回結果，否則就讀去相應的storefile文件中讀取一block的數據，如果還沒有讀到要查的數據，就將該數據block放到HRegion Server的blockcache中，然后接着讀下一block塊兒的數據，一直到這樣循環的block數據直到找到要請求的數據並返回結果；如果將該region中的數據都沒有查到要找的數據，最后接直接返回null，表示沒有找的匹配的數據。當然blockcache會在其大小大於一的閥值（heapsize * hfile.block.cache.size * 0.85）后啟動基於LRU算法的淘汰機制，將最老最不常用的block刪除。
Hbase容錯和恢復
該機制用於數據的容錯和恢復：
每個HRegionServer中都有一個HLog對象，HLog是一個實現Write Ahead Log的類，在每次用戶操作寫入MemStore的同時，也會寫一份數據到HLog文件中（HLog文件格式見后續），HLog文件定期會滾動出新的，並刪除舊的文件（已持久化到StoreFile中的數據）。當HRegionServer意外終止后，HMaster會通過Zookeeper感知到，HMaster首先會處理遺留的 HLog文件，將其中不同Region的Log數據進行拆分，分別放到相應region的目錄下，然后再將失效的region重新分配，領取 到這些region的HRegionServer在Load Region的過程中，會發現有歷史HLog需要處理，因此會Replay HLog中的數據到MemStore中，然后flush到StoreFiles，完成數據恢復。
HBase容錯性
Master容錯：Zookeeper重新選擇一個新的Master
*無Master過程中，數據讀取仍照常進行；
*無master過程中，region切分、負載均衡等無法進行；
RegionServer容錯：定時向Zookeeper匯報心跳，如果一旦時間內未出現心跳，Master將該RegionServer上的Region重新分配到其他RegionServer上，失效服務器上“預寫”日志由主服務器進行分割並派送給新的RegionServer
Zookeeper容錯：Zookeeper是一個可靠地服務，一般配置3或5個Zookeeper實例