HBase 介紹
一、什么是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/秒(讀取)，相當於全國人民一秒收發一條短信，在業務記錄、安全風控、實時計算、日志監控、消息聊天等多個場景發揮重要價值。
二、哪些是HBase的特點？
1.存儲數據量大：一個表可以有上億行，上百萬列。
2.面向列：面向列表（簇）的存儲和權限控制，列（簇）獨立檢索。
3.稀疏：對於為空（NULL）的列，並不占用存儲空間，因此，表可以設計的非常稀疏。
4.無模式：每一行都有一個可以排序的主鍵和任意多的列，列可以根據需要動態增加，同一張表中不同的行可以有截然不同的列。
5.數據多版本：每個單元中的數據可以有多個版本，默認情況下，版本號自動分配，版本號就是單元格插入時的時間戳。
6.數據類型單一：HBase中的數據都是字符串，沒有類型。
三、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）。
四、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 唯一，默認系統時間戳
五、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