什麼是HBase？

 HBase 介紹

 

  1、什麼是HBase？

1.HBase – Hadoop Database，是一個高可靠性、高性能、面向列、可伸縮、實時讀寫的分佈式數據庫 

2. HBASE是Google Bigtable的開源實現，可是也有不少不一樣之處。好比：Google Bigtable使用GFS做爲其文件存儲系統，HBASE利用Hadoop HDFS做爲其文件存儲系統；Google運行MAPREDUCE來處理Bigtable中的海量數據，HBASE一樣利用Hadoop MapReduce來處理HBASE中的海量數據；Google Bigtable利用Chubby做爲協同服務，HBASE利用Zookeeper做爲協同服務。

3.HBase是一個分佈式存儲、數據庫引擎，能夠支持千萬的QPS、PB級別的存儲，這些都已經在生產環境驗證，而且在廣大的公司已經驗證。特別是阿里（淘寶、天貓、螞蟻金服）、小米米聊、小米雲、小米推送服務）、京東、滴滴內部都有數千、上萬臺的HBase集羣。Hbase PMC。阿里1個。 Hbase Committer。阿里4個，小米4個。 2016年雙11，HBase承載訪問量達到了上百GB/秒(寫入)與上百GB/秒(讀取)，至關於全國人民一秒收發一條短信，在業務記錄、安全風控、實時計算、日誌監控、消息聊天等多個場景發揮重要價值。

   2、哪些是HBase的特色？

1.存儲數據量大：一個表能夠有上億行，上百萬列。

2.面向列：面向列表（簇）的存儲和權限控制，列（簇）獨立檢索。

3.稀疏：對於爲空（NULL）的列，並不佔用存儲空間，所以，表能夠設計的很是稀疏。

4.無模式：每一行都有一個能夠排序的主鍵和任意多的列，列能夠根據須要動態增長，同一張表中不一樣的行能夠有大相徑庭的列。

5.數據多版本：每一個單元中的數據能夠有多個版本，默認狀況下，版本號自動分配，版本號就是單元格插入時的時間戳。

6.數據類型單一：HBase中的數據都是字符串，沒有類型。

   3、HBase與傳統數據庫的比較

    MySQL：關係型數據庫，主要面向OLTP（面向交易的處理過程），支持事務，支持二級索引，支持sql，支持主從、支持存儲引擎）。

HBase：基於HDFS，支持海量數據讀寫（尤爲是寫），支持上億行、上百萬列的，面向列的分佈式NoSql數據庫。自然分佈式，主從架構，不支持事務，不支持二級索引，不支持sql, 不支持條件查詢和Order by等查詢。

1.數據存儲方式

MySQL中要提早定義表結構，也就是說表共有多少列（屬性）須要提早定義好，而且同時須要定義好每一個列所佔用的存儲空間。數據以行爲單位組織在一塊兒的，假如某一行的某一列沒有數據，也須要佔用存儲空間。

HBase則是以列爲單位存儲數據，每一列就是一個key-value，HBase的表列（屬性）不用提早定義，並且列能夠動態擴展，好比人員信息表中須要添加一個新的「address」字段，MySQL須要提早alter表，HBase的話直接插入便可。

2. 數據類型：

HBase只有簡單的字符類型，它只保存字符串。而關係數據庫有豐富的類型和存儲方式。

3. 數據操做：

HBase只有很簡單的插入、查詢、刪除、清空等操做，表和表之間是分離的沒有複雜的表和表之間的關係，而傳統數據庫一般有各式各樣的函數和鏈接操做。  

  4.超大數據量

        當數據量愈來愈大，RDBMS數據庫撐不住了，就出現了讀寫分離策略，經過一個Master專門負責寫操做，多個Slave負責讀操做，服務器成本倍增。隨着壓力增長，Master撐不住了，這時就要分庫了，把關聯不大的數據分開部署，一些join查詢不能用了，須要藉助中間層。隨着數據量的進一步增長，一個表的記錄愈來愈大，查詢就變得很慢，因而又得搞分表，好比按ID取模分紅多個表以減小單個表的記錄數。經歷過這些事的人都知道過程是多麼的折騰。採用HBase就簡單了，只須要加機器便可，HBase會自動水平切分擴展，跟Hadoop的無縫集成保障了其數據可靠性（HDFS）和海量數據分析的高性能（MapReduce）。

4、HBase基本術語的理解

     1.Row Key:能夠當作表中每條記錄的主鍵，方便快速查找。

2.Column family：擁有一個名稱，包含一個或多個相關的列稱爲列族。

3.Column：屬於某一個Column family，包含在某一列中。

4.Cell：經過Row Key、Column family和Column 能夠定位到該cell。

5.Version number：cell 中存放了多個版本的內容，每一個row key 惟一，默認系統時間戳

 

5、HBase的體系架構都有哪幾部分？

 

 

 

 

 

 

 

1.Client：使用HBase RPC機制與HMaster和HRegionServer進行通訊

Client與HMaster進行管理類操做

Client與HRegionServer進行數據讀寫類操做也能夠看作是整個HBase集羣的入口

 

2.Master：主要負責Table和Region的管理工做：

管理用戶對錶的增刪改查操做

管理HRegionServer的負載均衡，調整Region分佈

Region Split後，負責新Region的分佈

在HRegionServer停機後，負責失效HRegionServer上Region遷移。

3.Zookeeper：維護HBase集羣，Master與RegionServers啓動時會向Zookeeper註冊。集羣內能夠有多個Master，可是ZK保證只有一個對外提供服務，其餘作Stand by，出現宕機有相應的選舉機制選出新Master

4.Region Server：對於一個RegionServer而言，其包括了多個Region。RegionServer的做用是維護Master分配給他的region，以及實現讀寫IO操做。Client經過ZK尋址，最終也是直接鏈接RegionServer實現讀取數據。

5.Region：table在行的方向上分隔爲多個region，不一樣的region能夠分別在不一樣的Region Server上。隨着數據不斷插入表，region不斷增大，當region的某個列族達到一個閾值時就會分紅兩個新的region。

對Region的解析：

(1)Store：每個region由一個或多個store組成，一個store存放一個列族，若是有幾個ColumnFamily，也就有幾個Store。一個Store由一個memStore和0或者 多個StoreFile組成。HBase以store的大小來判斷是否須要切分region。

(2)MemStore：存放在內存中，保存修改的數據。當memStore的大小達到一個閥值（默認128MB）時，memStore會被flush到StoreFile。

(3)StoreFile：MemStore快照後存儲在StoreFile中，其底層是以HFile的格式保存。

(4)HFile：HFile是Hadoop的二進制格式文件，就是按照必定的結構存儲信息。

(5)HLog(WAL log)：WAL意爲write ahead log，用來作災難恢復使用。每一個RegionServer中都會有一個HLog的實例，會將RegionServer的全部更新操做記錄在HLog中，一旦regionServer宕機，就能夠從log中進行恢復。

HBase基本體系架構從宏觀上理解：Client做爲API接口，訪問HBase；Master是整個集羣的大腦，負責維護RegionServer；RegionServer管理若干個Region，並實現與Client的數據通訊；Region是邏輯上分佈式存儲和負載均衡的最小單元；Zookeeper實現對集羣的監護和HA。

從微觀上理解Region，一個table會至少有一個Region，隨着數據量的增大，Region實現分裂。Region內部由多個Store構成，每一個Store存儲一個列族。Store又由MemStore、StoreFile構成，MemStore內存寫到必定程度後落磁盤到StoreFile。

讀流程

 

1) Client訪問Zookeeper，查找-ROOT-表，獲取.META.表信息；

2) 從.META.表查找，獲取存放目標數據的Region信息，從而找到對應的RegionServer；

3) 經過RegionServer獲取須要查找的數據；

4) RegionServer的內存分爲MemStore和BlockCache兩部分，MemStore主要用於寫數據，BlockCache主要用於讀數據。讀請求先到MemStore中查數據，查不到就到BlockCache中查，再查不到就會到StoreFile上讀，並把讀的結果放入BlockCache。

尋址過程：client—>Zookeeper—>ROOT表—>.META. 表—>RegionServer—>Region—>client