在總結spark讀寫hbase的同時，也順便回顧了一下hbase的原理，同樣做個簡單的記錄。事實上，相關的總結網上超級多，寫的已經很到位了。本文一些內容會直接摘取相關參考資料，對原文作者表示感謝。
網際網路的面試一般問的都比較細，尤其是簡歷裡提到過的一些大資料元件，都會問問底層原理，體系結構，有什麼好的設計思想，甚至是原始碼等。所以在能呼叫api實現開發功能之後，也需要花一點時間對元件的原理至少是了解。
我自己覺得學習大資料原理時最麻煩的就是邏輯概念和物理概念的交叉混疊。每一套元件裡都涉及到很多新的專有名詞，很容易就搞混弄亂。學習過程最重要的還是集中注意力，參考多份資料，仔細反覆閱讀，效果會好些。
hbase是hadoop生態圈中的非關係型資料庫，其最大的特點是面向列儲存、可以實現在超大規模資料集上的實時讀寫和隨機訪問，可以說是對hdfs的有益補充。
傳統的行儲存是將完整的資料行儲存在磁碟中，查詢時會讀取該行的所有資料列。但有些應用場景，只需要一小部分資料列，這種方式就很浪費io。
列儲存就是將同乙個資料列的各個值存放在一起，也就是說插入某行資料時，該行的各個資料列的值會存放到不同的地方。好處就是需要某幾列資料時，可以很方便讀取。
hbase同資料庫一樣，也是以表的形式儲存資料。表由行和列構成，若干列可以組成乙個列族(column family)。
基本概念：
從架構上看，hbase由client、zookeeper、hmaster、hregionserver、hregion、store、memstore、storefile、hfile、hlog等構成。
以上是巨集觀上hbase的體系架構，下面就是更細節的資訊，主要是對region的剖析。
hbase基本體系架構就是這樣，從巨集觀上理解：client作為api介面，訪問hbase；master是整個集群的大腦，負責維護regionserver；regionserver管理若干個region，並實現與client的資料通訊；region是邏輯上分布式儲存和負載均衡的最小單元；zookeeper實現對集群的監護和ha。
從微觀上理解region，乙個table會至少有乙個region，隨著資料量的增大，region實現**。region內部由多個store構成，每個store儲存乙個列族。store又由memstore、storefile構成，memstore記憶體寫到一定程度後落磁碟到storefile。
hbase通過**索引結果實現region的定址。我們逆序描述這個設計的思路，hbase的所有資料region元資料被儲存在.meta.表中，但是隨著region增多，顯然.meta.會越大越大，最終也會**成多個region；-root-表實現定位.meta.表的region的位置，儲存.meta.表中所有region的元資料。而且-root-不會**，只有乙個region。zookeeper會記錄-root-表的位置資訊。
我們在正序描述定址過程，client通過zk找到-root-表的位置，通過-root-表查詢到.meta.的位置，再從.meta.查詢使用者region的位置。可以實現最多三次跳轉就可以定位任意乙個region的效果。為了加快訪問速度，.meta.表的所有region全部儲存在記憶體中。客戶端會將查詢過的位置資訊快取起來，且快取不會主動失效。
這部分直接拿來了參考文章的截圖，寫的已經很簡單清晰了。
Hbase原理詳解
各位看官，下面跟著小二一起開始hbase原理的冒險之旅吧，坐穩了，go 先上一張官方 首先指出的乙個錯誤，hlog應該屬於hregionserver的，不應該在hregion中。hbase基本元件說明 client 包含訪問hbase的介面，並維護cache來加快對hbase的訪問，比如region...
Hbase 讀寫 原理
客戶端讀取資訊流程 1 client要讀取資訊，先查詢下client 端的cache中是否存在資料，如果存在，剛直接返回資料。如果不存在，則進入到zookeeper，查詢到裡面的相應資料存在的root表中的位址。2 blockcache 設計用於讀入記憶體頻繁訪問的資料，每個列族都有 3 通過資料存...
Hbase原理與架構
1 client向hregionserver傳送寫請求。2 hregionserver將資料寫到hlog write ahead log 為了資料的持久化和恢復。3 hregionserver將資料寫到記憶體 memstore 4 反饋client寫成功。1 當memstore資料達到閾值 預設是1...