HBase 的底層原理是什么，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。
雅安網(wǎng)站建設公司成都創(chuàng)新互聯(lián)公司,雅安網(wǎng)站設計制作，有大型網(wǎng)站制作公司豐富經驗。已為雅安1000+提供企業(yè)網(wǎng)站建設服務。企業(yè)網(wǎng)站搭建\外貿網(wǎng)站制作要多少錢，請找那個售后服務好的雅安做網(wǎng)站的公司定做！
HBase 是一個分布式的、面向列的開源數(shù)據(jù)庫。建立在 HDFS 之上。Hbase的名字的來源是 Hadoop database，即 Hadoop 數(shù)據(jù)庫。HBase 的計算和存儲能力取決于 Hadoop 集群。
它介于 NOSQL 和 RDBMS 之間，僅能通過主鍵(row key)和主鍵的 range 來檢索數(shù)據(jù)，僅支持單行事務(可通過 Hive 支持來實現(xiàn)多表 join 等復雜操作)。
HBase中表的特點：
大：一個表可以有上十億行，上百萬列
面向列：面向列(族)的存儲和權限控制，列(族)獨立檢索。
稀疏：對于為空(null)的列，并不占用存儲空間，因此，表可以設計的非常稀疏。
HBase系統(tǒng)架構
根據(jù)這幅圖，解釋下HBase中各個組件
包含訪問hbase的接口，Client維護著一些cache來加快對hbase的訪問，比如regione的位置信息.
HBase可以使用內置的Zookeeper，也可以使用外置的，在實際生產環(huán)境，為了保持統(tǒng)一性，一般使用外置Zookeeper。
Zookeeper在HBase中的作用：
保證任何時候，集群中只有一個master
存貯所有Region的尋址入口
實時監(jiān)控Region Server的狀態(tài)，將Region server的上線和下線信息實時通知給Master
為Region server分配region
負責region server的負載均衡
發(fā)現(xiàn)失效的region server并重新分配其上的region
HDFS上的垃圾文件回收
處理schema更新請求
HRegion server維護HMaster分配給它的region，處理對這些region的IO請求
HRegion server負責切分在運行過程中變得過大的region
從圖中可以看到，Client訪問HBase上數(shù)據(jù)的過程并不需要HMaster參與（尋址訪問Zookeeper和HRegion server，數(shù)據(jù)讀寫訪問HRegione server）
HMaster僅僅維護者table和HRegion的元數(shù)據(jù)信息，負載很低。
HBase 整體結構
Table 中的所有行都按照 Row Key 的字典序排列。
Table 在行的方向上分割為多個 HRegion。
HRegion按大小分割的(默認10G)，每個表一開始只有一 個HRegion，隨著數(shù)據(jù)不斷插入表，HRegion不斷增大，當增大到一個閥值的時候，HRegion就會等分會兩個新的HRegion。當Table 中的行不斷增多，就會有越來越多的 HRegion。
HRegion 是 HBase 中分布式存儲和負載均衡的最小單元。最小單元就表示不同的 HRegion 可以分布在不同的 HRegion Server 上。但一個 HRegion 是不會拆分到多個 Server 上的。
HRegion 雖然是負載均衡的最小單元，但并不是物理存儲的最小單元。
事實上，HRegion 由一個或者多個 Store 組成，每個 Store 保存一個 Column Family。
每個 Strore 又由一個 MemStore 和0至多個 StoreFile 組成。如上圖。
StoreFile以HFile格式保存在HDFS上。
HFile的格式為：
HFile 具體結構
開始是兩個固定長度的數(shù)值，分別表示Key的長度和Value的長度。緊接著是Key，開始是固定長度的數(shù)值，表示RowKey的長度，緊接著是 RowKey，然后是固定長度的數(shù)值，表示Family的長度，然后是Family，接著是Qualifier，然后是兩個固定長度的數(shù)值，表示Time Stamp和Key Type（Put/Delete）。Value部分沒有這么復雜的結構，就是純粹的二進制數(shù)據(jù)了。
HFile分為六個部分：
Data Block 段–保存表中的數(shù)據(jù)，這部分可以被壓縮.
Meta Block 段 (可選的)–保存用戶自定義的kv對，可以被壓縮。
File Info 段–Hfile的元信息，不被壓縮，用戶也可以在這一部分添加自己的元信息。
Data Block Index 段–Data Block的索引。每條索引的key是被索引的block的第一條記錄的key。
Meta Block Index段 (可選的)–Meta Block的索引。
Trailer–這一段是定長的。保存了每一段的偏移量，讀取一個HFile時，會首先讀取Trailer，Trailer保存了每個段的起始位置(段的Magic Number用來做安全check)，然后，DataBlock Index會被讀取到內存中，這樣，當檢索某個key時，不需要掃描整個HFile，而只需從內存中找到key所在的block，通過一次磁盤io將整個 block讀取到內存中，再找到需要的key。DataBlock Index采用LRU機制淘汰。
HFile的Data Block，Meta Block通常采用壓縮方式存儲，壓縮之后可以大大減少網(wǎng)絡IO和磁盤IO，隨之而來的開銷當然是需要花費cpu進行壓縮和解壓縮。
目前HFile的壓縮支持兩種方式：Gzip，Lzo。
一個 HRegion 由多個 Store 組成，每個 Store 包含一個列族的所有數(shù)據(jù) Store 包括位于內存的 Memstore 和位于硬盤的 StoreFile。
寫操作先寫入 Memstore，當 Memstore 中的數(shù)據(jù)量達到某個閾值，HRegionServer 啟動 FlashCache 進程寫入 StoreFile，每次寫入形成單獨一個 StoreFile
當 StoreFile 大小超過一定閾值后，會把當前的 HRegion 分割成兩個，并由 HMaster 分配給相應的 HRegion 服務器，實現(xiàn)負載均衡
客戶端檢索數(shù)據(jù)時，先在memstore找，找不到再找storefile。
WAL 意為Write ahead log，類似 MySQL 中的 binlog,用來 做災難恢復時用，Hlog記錄數(shù)據(jù)的所有變更,一旦數(shù)據(jù)修改，就可以從log中進行恢復。
每個Region Server維護一個Hlog,而不是每個Region一個。這樣不同region(來自不同table)的日志會混在一起，這樣做的目的是不斷追加單個文件相對于同時寫多個文件而言，可以減少磁盤尋址次數(shù)，因此可以提高對table的寫性能。帶來的麻煩是，如果一臺region server下線，為了恢復其上的region，需要將region server上的log進行拆分，然后分發(fā)到其它region server上進行恢復。
HLog文件就是一個普通的Hadoop Sequence File：
HLog Sequence File 的Key是HLogKey對象，HLogKey中記錄了寫入數(shù)據(jù)的歸屬信息，除了table和region名字外，同時還包括 sequence number和timestamp，timestamp是”寫入時間”，sequence number的起始值為0，或者是最近一次存入文件系統(tǒng)中sequence number。
HLog Sequece File的Value是HBase的KeyValue對象，即對應HFile中的KeyValue，可參見上文描述。
HRegionServer保存著meta表以及表數(shù)據(jù)，要訪問表數(shù)據(jù)，首先Client先去訪問zookeeper，從zookeeper里面獲取meta表所在的位置信息，即找到這個meta表在哪個HRegionServer上保存著。
接著Client通過剛才獲取到的HRegionServer的IP來訪問Meta表所在的HRegionServer，從而讀取到Meta，進而獲取到Meta表中存放的元數(shù)據(jù)。
Client通過元數(shù)據(jù)中存儲的信息，訪問對應的HRegionServer，然后掃描所在HRegionServer的Memstore和Storefile來查詢數(shù)據(jù)。
最后HRegionServer把查詢到的數(shù)據(jù)響應給Client。
查看meta表信息
hbase(main):011:0> scan 'hbase:meta'
Client也是先訪問zookeeper，找到Meta表，并獲取Meta表元數(shù)據(jù)。
確定當前將要寫入的數(shù)據(jù)所對應的HRegion和HRegionServer服務器。
Client向該HRegionServer服務器發(fā)起寫入數(shù)據(jù)請求，然后HRegionServer收到請求并響應。
Client先把數(shù)據(jù)寫入到HLog，以防止數(shù)據(jù)丟失。
然后將數(shù)據(jù)寫入到Memstore。
如果HLog和Memstore均寫入成功，則這條數(shù)據(jù)寫入成功
如果Memstore達到閾值，會把Memstore中的數(shù)據(jù)flush到Storefile中。
當Storefile越來越多，會觸發(fā)Compact合并操作，把過多的Storefile合并成一個大的Storefile。
當Storefile越來越大，Region也會越來越大，達到閾值后，會觸發(fā)Split操作，將Region一分為二。
細節(jié)描述：
HBase使用MemStore和StoreFile存儲對表的更新。
數(shù)據(jù)在更新時首先寫入Log(WAL log)和內存(MemStore)中，MemStore中的數(shù)據(jù)是排序的，當MemStore累計到一定閾值時，就會創(chuàng)建一個新的MemStore，并且將老的MemStore添加到flush隊列，由單獨的線程flush到磁盤上，成為一個StoreFile。于此同時，系統(tǒng)會在zookeeper中記錄一個redo point，表示這個時刻之前的變更已經持久化了。
當系統(tǒng)出現(xiàn)意外時，可能導致內存(MemStore)中的數(shù)據(jù)丟失，此時使用Log(WAL log)來恢復checkpoint之后的數(shù)據(jù)。
StoreFile是只讀的，一旦創(chuàng)建后就不可以再修改。因此HBase的更新其實是不斷追加的操作。當一個Store中的StoreFile達到一定的閾值后，就會進行一次合并(minor_compact, major_compact),將對同一個key的修改合并到一起，形成一個大的StoreFile，當StoreFile的大小達到一定閾值后，又會對 StoreFile進行split，等分為兩個StoreFile。
由于對表的更新是不斷追加的，compact時，需要訪問Store中全部的 StoreFile和MemStore，將他們按row key進行合并，由于StoreFile和MemStore都是經過排序的，并且StoreFile帶有內存中索引，合并的過程還是比較快。
任何時刻，一個HRegion只能分配給一個HRegion Server。HMaster記錄了當前有哪些可用的HRegion Server。以及當前哪些HRegion分配給了哪些HRegion Server，哪些HRegion還沒有分配。當需要分配的新的HRegion，并且有一個HRegion Server上有可用空間時，HMaster就給這個HRegion Server發(fā)送一個裝載請求，把HRegion分配給這個HRegion Server。HRegion Server得到請求后，就開始對此HRegion提供服務。
HMaster使用zookeeper來跟蹤HRegion Server狀態(tài)。當某個HRegion Server啟動時，會首先在zookeeper上的server目錄下建立代表自己的znode。由于HMaster訂閱了server目錄上的變更消息，當server目錄下的文件出現(xiàn)新增或刪除操作時，HMaster可以得到來自zookeeper的實時通知。因此一旦HRegion Server上線，HMaster能馬上得到消息。
當HRegion Server下線時，它和zookeeper的會話斷開，zookeeper而自動釋放代表這臺server的文件上的獨占鎖。HMaster就可以確定：
HRegion Server和zookeeper之間的網(wǎng)絡斷開了。
HRegion Server掛了。
無論哪種情況，HRegion Server都無法繼續(xù)為它的HRegion提供服務了，此時HMaster會刪除server目錄下代表這臺HRegion Server的znode數(shù)據(jù)，并將這臺HRegion Server的HRegion分配給其它還活著的節(jié)點。
master啟動進行以下步驟:
從zookeeper上獲取唯一一個代表active master的鎖，用來阻止其它HMaster成為master。
掃描zookeeper上的server父節(jié)點，獲得當前可用的HRegion Server列表。
和每個HRegion Server通信，獲得當前已分配的HRegion和HRegion Server的對應關系。
掃描.META.region的集合，計算得到當前還未分配的HRegion，將他們放入待分配HRegion列表。
由于HMaster只維護表和region的元數(shù)據(jù)，而不參與表數(shù)據(jù)IO的過程，HMaster下線僅導致所有元數(shù)據(jù)的修改被凍結(無法創(chuàng)建刪除表，無法修改表的schema，無法進行HRegion的負載均衡，無法處理HRegion 上下線，無法進行HRegion的合并，唯一例外的是HRegion的split可以正常進行，因為只有HRegion Server參與)，表的數(shù)據(jù)讀寫還可以正常進行。因此HMaster下線短時間內對整個HBase集群沒有影響。
從上線過程可以看到，HMaster保存的信息全是可以冗余信息（都可以從系統(tǒng)其它地方收集到或者計算出來）
因此，一般HBase集群中總是有一個HMaster在提供服務，還有一個以上的‘HMaster’在等待時機搶占它的位置。
1.（hbase.regionserver.global.memstore.size）默認;堆大小的40%
regionServer的全局memstore的大小，超過該大小會觸發(fā)flush到磁盤的操作,默認是堆大小的40%,而且regionserver級別的flush會阻塞客戶端讀寫
2.（hbase.hregion.memstore.flush.size）默認：128M
單個region里memstore的緩存大小，超過那么整個HRegion就會flush,
3.（hbase.regionserver.optionalcacheflushinterval）默認：1h
內存中的文件在自動刷新之前能夠存活的最長時間
4.（hbase.regionserver.global.memstore.size.lower.limit）默認：堆大小 * 0.4 * 0.95
有時候集群的“寫負載”非常高，寫入量一直超過flush的量，這時，我們就希望memstore不要超過一定的安全設置。在這種情況下，寫操作就要被阻塞一直到memstore恢復到一個“可管理”的大小, 這個大小就是默認值是堆大小 * 0.4 * 0.95，也就是當regionserver級別的flush操作發(fā)送后,會阻塞客戶端寫,一直阻塞到整個regionserver級別的memstore的大小為 堆大小 * 0.4 *0.95為止
5.（hbase.hregion.preclose.flush.size）默認為：5M
當一個 region 中的 memstore 的大小大于這個值的時候，我們又觸發(fā)了region的 close時，會先運行“pre-flush”操作，清理這個需要關閉的memstore，然后 將這個 region 下線。當一個 region 下線了，我們無法再進行任何寫操作。 如果一個 memstore 很大的時候，flush 操作會消耗很多時間。"pre-flush">
6.（hbase.hstore.compactionThreshold）默認：超過3個
一個store里面允許存的hfile的個數(shù)，超過這個個數(shù)會被寫到新的一個hfile里面 也即是每個region的每個列族對應的memstore在flush為hfile的時候，默認情況下當超過3個hfile的時候就會對這些文件進行合并重寫為一個新文件，設置個數(shù)越大可以減少觸發(fā)合并的時間，但是每次合并的時間就會越長
把小的storeFile文件合并成大的HFile文件。
清理過期的數(shù)據(jù)，包括刪除的數(shù)據(jù)
將數(shù)據(jù)的版本號保存為1個。
看完上述內容，你們掌握HBase 的底層原理是什么的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！
重慶分公司
重慶分公司
