2019/2/20 星期三
hbase分佈式存儲機制（工作原理詳解）
hbase集羣中每個組件的作用
Hmaster ：
1 爲Region server 分配region
2 負責region server 的負載均衡
3 發現失效的region server 並重新分配其上的region
4 GFS 上的垃圾文件回收
5 處理schema（模式） 更新請求 //可以通俗的理解爲管理用戶對錶的增刪改成操作
regionserver
1 Region server 維護Master 分配給它的region，處理對這些region 的IO 請求
2 Region server 負責切分在運行過程中變得過大的region //真正管理表實際數據的
3 regionsever 負責響應用戶的IO請求，並且向hdfs中讀寫數據
//可以看到，client 訪問hbase 上數據的過程並不需要master 參與
（尋址訪問zookeeper 和regionserver，數據讀寫訪問regione server），master 僅僅維護者table 和region 的元數據信息，所有負載很低。
提示：一般的regionserver和hdfs中的datanode並置，datanode存儲有regionserver正在管理的數據，hbase的數據最終都是存儲在hdfs上。
Zookeeper
1 保證任何時候，集羣中只有一個master
2 存貯所有Region 的尋址入口。
3 實時監控Region Server 的狀態，將Region server 的上線和下線信息實時通知給Master
4 存儲Hbase 的schema（模式）,包括有哪些table，每個table 有哪些column family
Client
1 包含訪問hbase 的接口，client 維護着一些cache 來加快對hbase 的訪問，比如regione 的位置信息。
//客戶端直接與regionserver聯繫的
hbase分佈式存儲機制詳解
1 已經提到過，Table 中的所有行都按照row key 的字典序排列。
2 Table 在行的方向上分割爲多個region。
3 region 按大小分割的，每個表一開始只有一個region，隨着數據不斷插入表，region 不斷增大，當增大到一個閥值的時，region 就會等分會兩個新的region。當table 中的行不斷增多，就會有越來越多的region。
4 region 是Hbase 中分佈式存儲和負載均衡的最小單元。最小單元就表示不同的region 可以分佈在不同的HRegion server 上。但一個region 是不會拆分到多個server 上的。
5、當regionserver上的region的數據量增長到一個閾值的時候會分裂，然後繼續增長分裂。（推薦每一個regionserver管理1000個region）
再到細節中，一個region中的數據最終存儲到hdfs上去的時候，會採用什麼樣子的機制呢？
6、Region 雖然是分佈式存儲的最小單元，但並不是存儲的最小單元。事實上，Region 由一個或者多個Store 組成，每個store 保存一個columns family（列族）。每個Strore 又由一個memStore 和0 至多個StoreFile 組成。如圖：StoreFile 以HFile 格式保存在HDFS 上。
//region中的一個列族就是一個物理的存儲單位，所有2個不同的列族是絕對不可能存放在同一個文件中的。
7、每個Strore 又由一個memStore 和0 至多個StoreFile 組成。memstore是共享的，相當於整個store的內存緩存，如果客戶端去讀數據的時候，如果命中到哪裏就會優先從memstore中拿或者寫數據。如果memstore中沒有我們要取的數據的話，接下來纔會到storefile中去找。memstore可以理解爲一個緩存的機制。如果是寫數據的時候，會先向memstore中去寫，然後過段時間纔會把memstore刷成storefile（這其實就是region flush：寫數據的時候先寫到memstore中，過段時間再flush成storefile storefile會轉化成hfile 最終存儲到hdfs上）//StoreFile 以HFile 格式保存在HDFS 上。
8、當有多個storefile超過我們設定的閾值的時候，會出現compactition（壓縮）操作。將允許操作將所有的storefile文件作爲一個storefile重新寫入（每次memstore刷新寫入一個storefile）你可以指定更大數量延壓縮，但壓縮將運行更長時間，在壓縮期間，更新將無法刷新到磁盤。長時間的壓縮需要足夠的內存，再以壓縮的持續時間內記錄所有更新，如太大，壓縮期間，客戶端會超時。
9、在hfile端也會出現壓縮的情況：hbase會自動拾取一些較小的hfile，並將它們寫入一些較大的hFile中，這個過程叫minor compacition ：minor compacatition通過重寫操作，利用合併排序將較小的文件轉化爲較大數量卻數量較少的文件中。
提示：在有些資料中會單獨的提到blockcache是讀操作的緩存，他保存了內存中經常被讀的一些信息。memstore是寫操作的緩存，
我們把他們理解成一樣的，作用爲緩存就可以了。不必深究。
HFile 的格式爲：
Trailer 部分的格式:
HFile 分爲六個部分：
1、Data Block 段–保存表中的數據，這部分可以被壓縮
2、Meta Block 段(可選的)–保存用戶自定義的kv 對，可以被壓縮。
3、File Info 段–Hfile 的元信息，不被壓縮，用戶也可以在這一部分添加自己的元信息。
4、Data Block Index 段–Data Block 的索引。每條索引的key 是被索引的block 的第一條記錄的key。
5、Meta Block Index 段(可選的)–Meta Block 的索引。
6、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 進行壓縮和解壓縮。
目標Hfile 的壓縮支持兩種方式：Gzip，Lzo。
Memstore 與storefile
一個region 由多個store 組成，每個store 包含一個列族的所有數據 Store 包括位於把內存的memstore 和位於硬盤的storefile
寫操作先寫入memstore,當memstore 中的數據量達到某個閾值，regionserver 啓動flashcache進程寫入storefile,每次寫入形成單獨一個storefile。
當storefile 大小超過一定閾值後，會把當前的region 分割成兩個，並由Hmaster 分配奧相應的region 服務器，實現負載均衡
客戶端檢索數據時，先在memstore 找，找不到再找storefile
HLog(WAL log)
WAL 意爲Write ahead log(http://en.wikipedia.org/wiki/Write-ahead_logging)，類似mysql 中的binlog,用來做災難恢復只用，Hlog 記錄數據的所有變更,一旦數據修改，就可以從log 中進行恢復。
每個Region Server 維護一個Hlog,而不是每個Region 一個。這樣不同region(來自不同table)的日誌會混在一起，這樣做的目的是不斷追加單個文件相對於同時寫多個文件而言，可以減少磁盤尋址次數，因此可以提高對table 的寫性能。帶來的麻煩是，如果一臺region server下線，爲了恢復其上的region，需要將region server 上的log 進行拆分，然後分發到其它regionserver 上進行恢復
HLog 文件就是一個普通的Hadoop Sequence File，Sequence File 的Key 是HLogKey 對象，HLogKey 中記錄了寫入數據的歸屬信息，除了table 和region 名字外，同時還包括sequence number 和timestamp，timestamp 是”寫入時間”，sequence number 的起始值爲0，或者是最近一次存入文件系統中sequence number。HLog Sequece File 的Value 是HBase 的KeyValue對象，即對應HFile 中的KeyValue，可參見上文描述。
詳細解釋hbase的讀寫過程
讀寫過程
上面提到，hbase 使用MemStore 和StoreFile 存儲對錶的更新。
1、數據在更新（寫）時首先寫入Log(WAL log)和內存(MemStore)中，MemStore 中的數據是排序的，當MemStore 累計到一定閾值時，就會創建一個新的MemStore，並且將老的MemStore 添加到flush 隊列，由單獨的線程flush 到磁盤上，成爲一個StoreFile。
2、於此同時，系統會在zookeeper 中記錄一個redo point，表示這個時刻之前的變更已經持久化了。(minor compact)
3、當系統出現意外時，可能導致內存(MemStore)中的數據丟失，此時使用Log(WAL log)來恢復checkpoint 之後的數據。
4、前面提到過StoreFile 是隻讀的，一旦創建後就不可以再修改。因此Hbase 的更新其實是不斷追加的操作。
5、當一個Store 中的StoreFile 達到一定的閾值後，就會進行一次合併(major compact),將對同一個key 的修改合併到一起，形成一個大的StoreFile，當StoreFile 的大小達到一定閾值後，又會對StoreFile 進行split，等分爲兩個StoreFile。
6、由於對錶的更新是不斷追加的，處理讀請求時，需要訪問Store 中全部的StoreFile 和MemStore，將他們的按照row key 進行合併，由於StoreFile 和MemStore 都是經過排序的，並且StoreFile 帶有內存中索引，合併的過程還是比較快。
寫請求處理過程小結
1 client 向region server 提交寫請求
2 region server 找到目標region
3 region 檢查數據是否與schema 一致
4 如果客戶端沒有指定版本，則獲取當前系統時間作爲數據版本
5 將更新寫入WAL log
6 將更新寫入Memstore
7 判斷Memstore 的是否需要flush 爲Store 文件。
Region 管理機制
(1) region 分配
任何時刻，一個region 只能分配給一個region server。master 記錄了當前有哪些可用的region server。以及當前哪些region 分配給了哪些region server，哪些region 還沒有分配。當存在未分配的region，並且有一個region server上有可用空間時，master 就給這個region server 發送一個裝載請求，把region分配給這個region server。region server 得到請求後，就開始對此region
提供服務。
(2) region server 上線
master 使用zookeeper 來跟蹤region server 狀態。當某個region server 啓動時，會首先在zookeeper 上的server 目錄下建立代表自己的文件，並獲得該文件的獨佔鎖。由於master 訂閱了server 目錄上的變更消息，當server 目錄下的文件出現新增或刪除操作時，master 可以得到來自zookeeper 的實時通知。因此一旦region server 上線，master 能馬上得到消息。
(3)region server 下線
當region server 下線時，它和zookeeper 的會話斷開，zookeeper 而自動釋放代表這臺server 的文件上的獨佔鎖。而master 不斷輪詢server 目錄下文件的鎖狀態。如果master 發現某個region server 丟失了它自己的獨佔鎖，(或者master 連續幾次和region server 通信都無法成功),master 就是嘗試去獲取代表這個region server 的讀寫鎖，一旦獲取成功，就可以確定：
1 region server 和zookeeper 之間的網絡斷開了。
2 region server 掛了。
的某其中一種情況發生了，無論哪種情況，region server 都無法繼續爲它的region提供服務了，此時master 會刪除server 目錄下代表這臺region server 的文件，並將這臺region server 的region 分配給其它還活着的同志。
如果網絡短暫出現問題導致region server 丟失了它的鎖，那麼region server重新連接到zookeeper 之後，只要代表它的文件還在，它就會不斷嘗試獲取這個文件上的鎖，一旦獲取到了，就可以繼續提供服務。
HMaster 工作機制
（1）Hmaster 上線
master 啓動進行以下步驟:
1 從zookeeper 上獲取唯一一個代碼master 的鎖，用來阻止其它master 成爲master。
2 掃描zookeeper 上的server 目錄，獲得當前可用的region server 列表。
3 和2 中的每個region server 通信，獲得當前已分配的region 和region server的對應關係。
4 掃描.META.region 的集合，計算得到當前還未分配的region，將他們放入待分配region 列表。
（2）master 下線
由於master 只維護表和region 的元數據，而不參與表數據IO 的過程，master下線僅導致所有元數據的修改被凍結(無法創建刪除表，無法修改表的schema（模式），無法進行region 的負載均衡，無法處理region 上下線，無法進行region 的合併，唯一例外的是region 的split 可以正常進行，因爲只有region server 參與)，表的數據讀寫還可以正常進行。因此master 下線短時間內對整個hbase集羣沒有影響。從上線過程可以看到，master 保存的信息全是可以冗餘信息（都可以從系統其它地方收集到或者計算出來），因此，一般hbase 集羣中總是有一個master 在提供服務，還有一個以上的’master’在等待時機搶佔它的位置。