1.Hbase 的基本介紹
- HBase 時建立在hdfs之上的數據庫
- 不支持join等SQL事務等繁雜的操作
- 支持的數類型：byte[]
- 依靠橫向擴展，一個表可以有上十億行，上百萬列
- 面向列族存儲和權限控制
- 對於空（null）的列，並不佔用存儲空間，是一個稀疏表
2.HBASE的使用場景 （12個字）
- 海量數據
- 精確查詢
- 快速返回
3.Hbase 和hadoop之間的關係
HDFS:
- 海量數據儲存，適合一次掃描大量數據
- 適合一次寫入，多出讀取
- 不適合頻繁修改數據
Hbase
- 適合一詞掃描少量數據
- 合適多次寫入多次讀取
- 支持數據更新
- 支持刪除數據
4.Hbase 與Rdbms 的關係
RDBMS：
- 支持SQL查詢
- 支持事務
- 支持join
hbase:
- 不支持SQL查詢
- 不支持事務
- 不支持join
5.HBase 詳細架構
Client：
訪問數據的入口，包含訪問hbase的API接口,維護着一些cache來加快對hbase的訪問
Zookeeper：
1.zookeeper的選舉機制保證任何時候，集羣中只有一個master
2.實時監控Region Server的狀態，將Region server的上線和下線信息實時通知給Master
3.存儲Hbase的schema
4.存貯所有Region的尋址入口
Master：
1.爲Region server分配region
2.負責region server的負載均衡
3.發現失效的region server並重新分配其上的region
4.處理schema（元數據）更新請求
說明：Hmaster短時間下線，hbase集羣依然可用，長時間不行。
Region server：
1.Region server維護Master分配給它的region，處理對這些region的IO請求
2.Region server負責切分在運行過程中變得過大的region
6. Row Key
最大長度是 64KB，完全可以自行設計。Hbase會對錶中的數據按照rowkey排序（字典序）
7.列族Column Family
列族是表的schema的一部分，而列不是。（schema包含表名和列族）
每個列都所屬於某一個列族。一個列族可以包含多個列。一個列族與列的關係是一對多。
8.時間戳
標記一個數據的不同版本，時間戳可以由hbase(在數據寫入時自動 )賦值，hbase支持工程師自己定義時間戳。每個 cell中，不同版本的數據按照時間倒序排序
9.hbase本身提供數據回收機制
1．保存數據的最後n個版本
2．保存最近一段時間內的版本
10. Cell
存儲數據的最小單位，由{row key, column( = + ), version} 唯一確定的單元確定一個精確的數據
11.VersionNum
數據的版本號，默認值爲系統時間戳。
12. hbase物理存儲
1.一個regionserver內部可以有多個region,這多個region可能來自多個表或一個表。一個region只能屬於一個 regionserver.
2.一個regionserver只有一個HLog
3.一個region裏面可以有多個store
4.一個store裏面只有一個memstore
13.rtegion的切分
region按大小分割的(默認10G)。每個表一開始只有一個region，隨着數據的增加，一個region逐漸變大，達到 10G，進行分裂，等分成兩個region.
14. Memstore與storefile
一個region由多個store組成，每個store包含一個列族的所有數據 Store包括位於內存的memstore和位於硬盤的 storefile
客戶端檢索數據時，先在memstore找，找不到再找storefile
15.HLog(WAL log)
每個Region Server維護一個Hlog,而不是每個Region一個.
Hlog的切分機制
1.當數據寫入hlog以後，hbase發生異常。關閉當前的hlog文件
2.當日志的大小達到HDFS數據塊的0.95倍的時候，關閉當前日誌，生成新的日誌
3.每隔一小時生成一個新的日誌文件
16.讀請求過程
meta表是hbase系統自帶的一個表。裏面存儲了hbase用戶表的元信息。
元信息爲meta表內記錄一行數據是用戶表一個region的start key 到endkey的範圍。
meta表存儲在regionserver裏。 具體存儲在哪個regionserver裏？zookeeper知道。
過程:
1.客戶端到zookeeper詢問meta表在哪
2.客戶端到meta所在的節點（regionserver）讀取meta表的數據
3.客戶端找到region 獲取region和regionserver的對應關係，直接到regionserver讀取region數據
17.HBase的特徵
1.海量存儲:Hbase適合存儲PB級別的海量數據，在幾十到百毫秒內返回數據。
2.列式存儲:這裏的列式存儲其實說的是列族存儲列族理論上可以很多，但實際上建議不要超過6個
3.極易擴展:處理能力（RegionServer）的擴展，是基於存儲的擴展（HDFS）
4.高併發:這裏說的高併發，主要是在併發的情況下，Hbase的單個IO延遲下降並不多
5.稀疏:在列數據爲空的情況下，是不會佔用存儲空間的。
18. 寫請求過程
1.Client先訪問zookeeper，找到Meta表，並獲取Meta表元數據。確定當前將要寫入的數據所對應的HRegion和 HRegionServer服務器。
2.Client向該HRegionServer服務器發起寫入數據請求。
3.Client先把數據寫入到HLog，以防止數據丟失，然後將數據寫入到Memstore。
4.Memstore達到閾值，會把Memstore中的數據flush到Storefile中
5.當Storefile越來越多，達到一定數量時，會觸發Compact合併操作，將多個小文件合併成一個大文件。
6.Storefile越來越大，Region也會越來越大，達到閾值後，會觸發Split操作，變成兩個文件。
說明：hbasez 支持數據修改（僞修改），實際上是相同rowkey數據的添加。hbase只顯示最後一次的添加
19. region的分配過程
前提：一個region只能分配給一個region server
1.master記錄了當前有哪些可用的region server。以及當前哪些region分配給了哪些region server，哪些region還沒有分配。
2.當需要分配的新的region，並且有一個region server上有可用空間時，master就給這個region server發送一個裝載請求，把region分配給這個region server。
3.region server得到請求後，就開始對此region提供服務。
20. region server上線
前提：master使用zookeeper來跟蹤region server狀態。
1.當某個region server啓動時，首先在zookeeper上的/hbase/rs目錄下建立代表自己的znode。
2.master訂閱了/hbase/rs目錄上的變更消息，當/hbase/rs目錄下的文件出現新增或刪除操作時，master可以得到來自zookeeper的實時通知。因此一旦region server上線，master能馬上得到消息
21.region server下線
前提：master使用zookeeper來跟蹤region server狀態。
1.當region server下線時，它和zookeeper的會話斷開。
2.zookeeper而自動釋放代表這臺server的文件上的獨佔鎖（znode）
3.zookeeper將變化發送給master
4.master 將掛掉的region server的region分配給其它還活着的regionserver
22.Hmaster的上線
前提：hbase集羣中可以設置多個Hmaster，真正對外提供服務的只有一個
1.從zookeeper上獲取唯一 一個代表active master的鎖，用來阻止其它master成爲真正的master。
2.掃描zookeeper上的/hbase/rs節點，獲得當前可用的region server列表。
3.master和每個region server通信，獲得當前已分配的region和region server的對應關係。 4.master掃描.META.表，計算得到當前還未分配的region，將他們放入待分配region列表。
23.Hmaster下線後的影響
master只維護表和region的元數據，不參與表數據IO的過程，所以master下線短時間內對整個hbase集羣沒有影響。表的數據讀寫還可以正常進行。
無法創建刪除表，無法修改表的schema，無法進行region的負載均衡，無法處理region 上下線，無法進行region的 合併（region的split可以正常進行） 當hmaster下線後，啓動Zookeeper的選舉機制，選出新的Hmaster,新的Hmaster上線，執行上線流程。
24.flush機制
全局的memstore的flush機制默認爲堆總大小（多個memstore 多個region）的40%，超過該大小會觸發flush到磁盤的操作，會阻塞客戶端讀寫，flush將所有的memstore全部flush.
單個的memstore默認爲數據達到128M或1h或者數據爲堆大小 0.95倍將會flush. memstore默認將會先提前flush 5M.(先flush一小部分，等後面數據達到閾值在flush後 面的數據) 這樣會比一次flush效率高
hbase不建議配置過多列族：過多的列族會消耗大量的內存，同時數據在flush時消耗磁盤IO. 一個regionserver續寫操作可用堆內存的80%，讀取佔用40% ，寫入佔用40%。這兩個參數直接影響hbase讀寫性能。
25.compact機制
默認3個小的storeFile文件達到三個，合併成大的Storefile文件。
26.split機制
默認一個HFile達到10Gb的時候就會進行切分
27.hbase預分區的優點
1.增加數據讀寫效率:數據分佈在多臺regionserver節點
2.負載均衡，防止數據傾斜:當數據時離散的發送時，預分區可以解決數據傾斜
3.方便集羣調度region: 分佈在多個節點便於調度
4.優化Map數量
28.rowKey的獲取方式
1.通過rowkey直接查找
2.通過startkey endkey 範圍查找
3.全表掃描
29.rowkey散列原則
建議將rowkey的高位(左邊)作爲散列字段， 低位（右邊）放時間字段，這樣將提高數據均衡分佈在每個 RegionServer，以實現負載均衡的機率。
若不按照此原則：
讓時間戳作爲高位，數據將按照時間的順序進行存儲會引發熱點問題
30.rowkey散列原則
建議將rowkey的高位(左邊)作爲散列字段， 低位（右邊）放時間字段，這樣將提高數據均衡分佈在每個 RegionServer，以實現負載均衡的機率。
若不按照此原則：
讓時間戳作爲高位，數據將按照時間的順序進行存儲會引發熱點問題
31.什麼是熱點問題
當有一點時間業務數據爆炸增長時，這個階段的數據將存儲在少數的節點上。
32.如何解決熱點問題
原則：將分散的數據，放在rowkey的高位
1.哈希（隨機數）:將哈希值放在高位
2.反轉:反轉固定長度或者數字格式的數據（時間戳反轉、手機號反轉，訂單號反轉）
3.加鹽:本質時是加隨機數，並且放在高位。
