hbase(來自hadoop database)是乙個很好的bigtable的實現，能夠儲存上百億行和百萬列的資料，是乙個高可靠性、高效能、面向列、可伸縮的分布式儲存系統。
hbase的基本架構組成如下：
hbase使用zookeeper作為協調服務，每個時刻只有乙個hmaster在執行，hmaster來負責維護表和元資料（包括region），而不負責具體的資料讀寫。這樣一旦hmaster失效，導致所有的元資料無法被修改，region切分、負載均衡等無法進行；但還可以進行正常的資料讀寫，提供服務；一旦zookeeper感知不到hmaster,就會選舉出乙個新的hmaster,這樣解決了單點故障的問題。
一 個 hbase例項包括多個hregionserver,hregionserver內部管理了一系列hregion物件，每個hregion對應了table中的乙個region，hregion中由多個hstore組成。每個hstore對應了table中的乙個column family的儲存，可以看出每個column family其實就是乙個集中的儲存單元，因此最好將具備共同io特性的column放在乙個column family中，這樣最高效。
每個table包含多個region，每個region裡面包含乙個memstore(記憶體)和多個storefile（hdfs檔案）
hbase寫資料的典型流程是：
1) 、client發起了乙個htable.put(put)請求給hregionserver
2) 、hregionserver會將請求定位到某個具體的hregion上面
3) 、決定是否寫wal log。wal(write ahead log)檔案是乙個標準的hadoop sequencefile，檔案中儲存了hlogkey，這些keys包含了和實際資料對應的序列號，主要用於崩潰恢復。在每次使用者操作寫入memstore的同時，也會寫乙份資料到hlog檔案中，hlog檔案定期會滾動出新的，並刪除舊的檔案（已持久化到storefile中的資料）
4)、put資料儲存到memstore中，同時檢查memstore狀態，如果滿了，則觸發flush to disk請求。
5) hregionserver處理flush to disk的請求，將資料寫成hfile檔案並存到hdfs上，並且儲存最後寫入的資料序列號，這樣就可以知道哪些資料已經存入了永久儲存的hdfs中。
當hregionserver意外終止後，hmaster會通過zookeeper感知到，hmaster首先會處理遺留的 hlog檔案，將其中不同region的log資料進行拆分，分別放到相應region的目錄下，然後再將失效的region重新分配，領取 到這些region的hregionserver在load region的過程中，會發現有歷史hlog需要處理，因此會replay hlog中的資料到memstore中，然後flush到storefiles，完成資料恢復。
hbase讀資料的典型流程是：
1、client會通過內部快取的相關的-root-中的資訊和.meta.中的資訊直接連線與請求資料匹配的hregionserver；
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裡面有幾個基本的概念：
rowkey,column family,timestamp,cell，網上有很多介紹，不說了。
關於安裝和使用，前面已經說過了。
這裡說說hbase的設計的時候的幾個注意的地方：
1.雖然hbase表號稱可容納百萬列，在實際應用中，請盡量構建「高而瘦」(即行記錄很多，列較少)的表，同時需要對列的數量進行測試，以避免過度影響讀寫效能。
2.預設情況下，在建立hbase表的時候會自動建立乙個region分割槽，當匯入資料的時候，所有的hbase客戶端都向這乙個region寫資料，直到這個region足夠大了才進行切分。一種可以加快批量寫入速度的方法是通過預先建立一些空的regions，這樣當資料寫入hbase時，會按照region分割槽情況，在集群內做資料的負載均衡。
3.不要在一張表裡定義太多的 column family 。目前hbase並不能很好的處理超過2~3個column family的表。因為某個column family在flush的時候，它鄰近的column family也會因關聯效應被觸發flush，最終導致系統產生更多的i/o。所以， 根據官方的建議，乙個 hbase 表中建立乙個列族即可。
4.列族的名稱不宜過長
5.合理運用快取
6.合理進行壓縮
7,設定ttl，如果你在同一單元上有多個時間版本，早於設定ttl的版本會被刪除。
8,使用時間版本，hbase在預設情況下每個單元維護三個時間版本。這個屬性是可以設定的。如果你只需要乙個版本，推薦你在設定表時只維護乙個版本。這樣系統就不會保留更新單元的多個時間版本。
HBase資料儲存
hbase的資料檔案都儲存在hdfs上，格式主要有兩種 hfile hbase中keyvalue資料的儲存格式，hfile是hadoop的二進位制檔案，實際上storefile就是對hfile做了輕量級的包裝，即storefile底層就是hfile hlog file hbase中wal write...
Hadoop資料儲存 Hbase
大家都知道hadoop是乙個資料庫，其實說的的就是hbase。它和我們平常理解的關係型資料庫有什麼區別呢？1.它是nosql的，它沒有sql的介面，有自己的一套api。通過以上描述，我們分析一下hbase的特點 1 儲存海量資料 pb 2 高吞吐 每秒每個節點上千次寫 3 適合處理稀疏資料 半結構化...
大資料儲存HBase
這兩天要寫乙個方案，某單位想建乙個中心資料庫，匯聚各業務系統資料，以及各種網上抓取的預報資料。我設想是用hbase。主要考慮點是 1 開源 2 支援海量資料 該單位的資料量增長按規劃還是很大的，大約每天20gb 關係型資料庫就不考慮了。rdbms本質上是單機系統，拿mysql來說吧，主從複製，讀寫分...