1.1-1.3 HBase入門

1、HBASE入門

部分參考連接：http://www.javashuo.com/article/p-ctgbupvo-ey.html

一、簡介

HBase – Hadoop Database，是一個高可靠性、高性能、面向列、可伸縮的分佈式存儲系統，利用HBase技術可在廉價PC Server上搭建起大規模結構化存儲集羣。

HBase是Google BigTable的開源實現，與Google BigTable利用GFS做爲其文件存儲系統相似，HBase利用Hadoop HDFS做爲其文件存儲系統；
Google運行MapReduce來處理BigTable中的海量數據，HBase一樣利用Hadoop MapReduce來處理HBase中的海量數據；
Google BigTable利用Chubby做爲協同服務，HBase利用Zookeeper做爲協同服務。

官網版本：http://archive.apache.org/dist/hbase/

CDH版本(穩定,推薦)：http://archive.cloudera.com/cdh5/


##
HBase的用途：
    海量數據存儲
    準實時查詢

HBase的應用場景及特色：
    交通
    金融
    電商
    移動（電話信息）等

 

二、HBASE的特色

HBase的特色：
一、
容量大
HBase單表能夠有上百億行、百萬列，數據矩陣橫向和縱向兩個維度所支持的數據量級都很是具備彈性。 


2.、面向列
HBase是面向列的存儲和權限控制，並支持獨立檢索。列式存儲，其數據在表中是按照某列存儲的，這樣在查詢只須要少數幾個字段的時候，
能大大減小讀取的數據量。


多版本
HBase每個列的數據存儲有多個Version（version）。

稀疏性
爲空的列並不佔用存儲空間，表能夠設計的很是稀疏。

擴展性
底層依賴於HDFS

高可靠性
WAL機制保證了數據寫入時不會因集羣異常而致使寫入數據丟失：Replication機制保證了在集羣出現嚴重的問題時，數據不會發生丟失或損壞。
並且HBase底層使用HDFS，HDFS自己也有備份。


三、高性能
底層的LSM數據結構和Rowkey有序排列等架構上的獨特設計，使得HBase具備很是高的寫入性能。region切分、主鍵索引和緩存機制使得HBase在
海量數據下具有必定的隨機讀取性能，該性能針對Rowkey的查詢可以達到毫秒級別。

 

 

2、HBASE架構體系

一、

HBase中的每一張表就是所謂的BigTable。BigTable會存儲一系列的行記錄，行記錄有三個基本類型的定義：
   RowKey：
            是行在BigTable中的惟一標識。

   TimeStamp：
            是每一次數據操做對應關聯的時間戳，能夠看做SVN的版本。

   Columns family列簇：
            定義爲<family>:<label>，經過這兩部分能夠指定惟一的數據的存儲列，family的定義和修改須要對HBase進行相似於DB的DDL操做，
            而label，不須要定義直接可使用，這也爲動態定製列提供了一種手段。family另外一個做用體如今物理存儲優化讀寫操做上，同family
            的數據物理上保存的會比較接近，所以在業務設計的過程當中能夠利用這個特性。



##
RowKey
與NoSQL數據庫同樣，rowkey是用來檢索記錄的主鍵。訪問HBase Table中的行，只有三種方式：
經過單個rowkey訪問；

經過rowkey的range；

全表掃描
          rowkey行鍵能夠任意字符串（最大長度64KB，實際應用中長度通常爲10-100bytes），在HBase內部RowKey保存爲字節數組。
          存儲時，數據按照RowKey的字典序（byte order）排序存儲，設計key時，要充分了解這個特性，將常常一塊兒讀取的行存放在一塊兒。
          須要注意的是：行的一次讀寫是原子操做（不論一次讀寫多少列）
 
        列簇
            HBase表中的每一個列，都歸屬於某個列簇，列簇是表的schema的一部分（而列不是），必須在使用表以前定義。列名都以列簇做爲前綴。例如：
            courses:history,  courses:math 都屬於 courses 這個列簇。
            訪問控制，磁盤和內存的使用統計都是在列簇層面進行的。
            實際應用中，列簇上的控制權限能幫助咱們管理不一樣類型的應用：咱們容許一些應用能夠添加新的基本數據、
            一些應用能夠讀取基本數據並建立繼承的列簇、一些應用則只容許瀏覽數據（設置可能由於隱私的緣由不能瀏覽全部數據）。

        時間戳
            HBase中經過row和columns肯定的爲一個存儲單元稱爲cell。每一個cell都保存着同一份數據的多個版本。版本經過時間戳來索引。
            時間戳的類型是64位整型。時間戳能夠由HBase在寫入時自動賦值，此時時間戳是精確到毫秒的當前系統時間。時間戳也能夠由客戶顯示賦值。
            若是應用程序要避免數據版本衝突，就必須本身生成具備惟一性的時間戳。每一個cell中在不一樣版本的數據按照時間倒序排序，即最新的數據排在最前面。
            爲了不數據存在過多的版本形成的管理負擔，HBase提供了兩種數據版本回收方式。一是保存數據的最後n個版本，二是保存最近一段時間內的版本
          （好比最近七天）。用戶能夠針對每一個列簇進行設置。
            
        Cell
            由{row key, columnFamily, version} 惟一肯定的單元。cell中的數據是沒有類型的，所有是字節碼形式存儲。

 

二、HBASE存儲架構

Table在行的方向上分割爲多個HRegion，每一個HRegion分散在不一樣的RegionServer中。

 

每一個HRegion由多個Store構成，每一個Store由一個MemStore和0或多個StoreFile組成，每一個Store保存一個Columns Family

StoreFile以HFile格式存儲在HDFS中。

 

從HBase的架構圖上能夠看出，HBase中的存儲包括HMaster、HRegionSever、HRegion、HLog、Store、MemStore、StoreFile、HFile等，如下是HBase存儲架構圖：
 

HBase中的每張表都經過鍵按照必定的範圍被分割成多個子表（HRegion），默認一個HRegion超過256M就要被分割成兩個，這個過程由HRegionServer管理，
而HRegion的分配由HMaster管理。
 
HMaster的做用：
    爲HRegionServer分配HRegion；
    負責HRegionServer的負載均衡；
    發現失效的HRegionServer並從新分配；
    HDFS上的垃圾文件回收；
    處理Schema更新請求；
 
HRegionServer的做用：
    維護HMaster分配給它的HRegion，處理對這些HRegion的IO請求；
    負責切分正在運行過程當中變得過大的HRegion；
 
能夠看到，Client訪問HBase上的數據並不須要HMaster參與，尋址訪問ZooKeeper和HRegionServer，數據讀寫訪問HRegionServer，
HMaster僅僅維護Table和Region的元數據信息，Table的元數據信息保存在ZooKeeper上，負載很低。HRegionServer存取一個子表時，
會建立一個HRegion對象，而後對錶的每一個列簇建立一個Store對象，每一個Store都會有一個MemStore和0或多個StoreFile與之對應，
每一個StoreFile都會對應一個HFile，HFile就是實際的存儲文件。所以，一個HRegion有多少列簇就有多少個Store。
 一個HRegionServer會有多個HRegion和一個HLog。
 
HRegion
Table在行的方向上分割爲多個HRegion，HRegion是HBase中分佈式存儲和負載均衡的最小單元，即不一樣的HRegion能夠分別在不一樣的HRegionServer上，
但同一個HRegion是不會拆分到多個HRegionServer上的。HRegion按大小分割，每一個表通常只有一個HRegion，隨着數據不斷插入表，HRegion不斷增大，
當HRegion的某個列簇達到一個閥值（默認256M）時就會分紅兩個新的HRegion。
 
一、<表名，StartRowKey, 建立時間>
二、由目錄表(-ROOT-和.META.)記錄該Region的EndRowKey
 
HRegion定位：HRegion被分配給哪一個HRegionServer是徹底動態的，因此須要機制來定位HRegion具體在哪一個HRegionServer，HBase使用三層結構來定位HRegion：
        一、經過zk裏的文件/hbase/rs獲得-ROOT-表的位置。-ROOT-表只有一個region。
        二、經過-ROOT-表查找.META.表的第一個表中相應的HRegion位置。其實-ROOT-表是.META.表的第一個region；
             .META.表中的每個Region在-ROOT-表中都是一行記錄。
        三、經過.META.表找到所要的用戶表HRegion的位置。用戶表的每一個HRegion在.META.表中都是一行記錄。
 
        -ROOT-表永遠不會被分隔爲多個HRegion，保證了最多須要三次跳轉，就能定位到任意的region。Client會將查詢的位置信息保存緩存起來，緩存不會主動失效，
        所以若是Client上的緩存所有失效，則須要進行6次網絡來回，才能定位到正確的HRegion，其中三次用來發現緩存失效，另外三次用來獲取位置信息。
 
Store
        每個HRegion由一個或多個Store組成，至少是一個Store，HBase會把一塊兒訪問的數據放在一個Store裏面，即爲每一個ColumnFamily建一個Store，
        若是有幾個ColumnFamily，也就有幾個Store。一個Store由一個MemStore和0或者多個StoreFile組成。 HBase以Store的大小來判斷是否須要切分HRegion。
 
 
MemStore
        MemStore 是放在內存裏的，保存修改的數據即keyValues。當MemStore的大小達到一個閥值（默認64MB）時，MemStore會被Flush到文件，
        即生成一個快照。目前HBase會有一個線程來負責MemStore的Flush操做。
 
　　
StoreFile
　    MemStore內存中的數據寫到文件後就是StoreFile，StoreFile底層是以HFile的格式保存。

 

HFile
　　 HBase中KeyValue數據的存儲格式，是Hadoop的二進制格式文件。 首先HFile文件是不定長的，長度固定的只有其中的兩塊：Trailer和FileInfo。
        Trailer中有指針指向其餘數據塊的起始點，FileInfo記錄了文件的一些meta信息。Data Block是HBase IO的基本單元，爲了提升效率，
        HRegionServer中有基於LRU的Block Cache機制。每一個Data塊的大小能夠在建立一個Table的時候經過參數指定（默認塊大小64KB），
        大號的Block有利於順序Scan，小號的Block利於隨機查詢。每一個Data塊除了開頭的Magic之外就是一個個KeyValue對拼接而成，
        Magic內容就是一些隨機數字，目的是防止數據損壞，結構以下。

 

HFile結構圖以下：

Data Block段用來保存表中的數據，這部分能夠被壓縮。 Meta Block段（可選的）用來保存用戶自定義的kv段，能夠被壓縮。 FileInfo段用來保存HFile的元信息，不能被壓縮，用戶也能夠在這一部分添加本身的元信息。 

Data Block Index段（可選的）用來保存Meta Blcok的索引。 Trailer這一段是定長的。保存了每一段的偏移量，讀取一個HFile時，會首先讀取Trailer，Trailer保存了每一個段的起始位置(段的Magic Number用來作安全check)，

而後，DataBlock Index會被讀取到內存中，這樣，當檢索某個key時，不須要掃描整個HFile，而只需從內存中找到key所在的block，經過一次磁盤io將整個 block讀取到內存中，再找到須要的key。DataBlock Index採用LRU機制淘汰。 

HFile的Data Block，Meta Block一般採用壓縮方式存儲，壓縮以後能夠大大減小網絡IO和磁盤IO，隨之而來的開銷固然是須要花費cpu進行壓縮和解壓縮。（備註： DataBlock Index的缺陷。 a) 佔用過多內存　b) 啓動加載時間緩慢）

 

HLog 
　　HLog(WAL log)：WAL意爲write ahead log，用來作災難恢復使用，HLog記錄數據的全部變動，一旦region server 宕機，就能夠從log中進行恢復。 
 
LogFlusher 
　　按期的將緩存中信息寫入到日誌文件中 
 
LogRoller　 
　 　對日誌文件進行管理維護