1. 程式人生 > >hbase數據原理及基本架構

hbase數據原理及基本架構

write 隨著 結構 hbase 用戶 自動分配 zookeepe 切分 分布

hbase是一個構建在hdfs上的分布式列存儲系統;

hbase是apache hadoop生態系統中的重要一員,主要用於海量結構化數據存儲

從邏輯上講,hbase將數據按照表、行和列進行存儲

hbase表特點:
  1.大:一個表可以有數十億行,上百萬列;

  2.無模式:每行都有一個可排序的主鍵和任意多的列,列可以根據需要動態的增加,同一張表中不同的行可以有截然不同的列;

  3.面向列:面向列(族)的存儲和權限控制,列(族)獨立檢索;

  4.稀疏:對於空(null)的列,並不占用存儲空間,表可以設計的非常稀疏;

  5.數據多版本:每個單元中的數據可以有多個版本,默認情況下版本號自動分配,是單元格插入時的時間戳;

  6.數據類型單一:hbase中的數據都是字符串,沒有類型

hbase與hdfs的對比:
  1.兩者都具有良好的容錯性和擴展性,都可以擴展到成百上千個節點。

  2.hdfs適合批處理場景,不支持數據隨機查找,不適合增量數據處理,不支持數據更新。

行存儲與列存儲:
  傳統行式數據庫:

    1.數據是按行存儲的

    2.沒有索引的查詢使用大量I/O

    3.建立索引和物化視圖需要花費大量時間和資源

    4.面向查詢的需求,數據庫必須被大量膨脹才能滿足性能要求

  列式數據庫:

    1.數據是按列存儲-每一列單獨存放

    2.數據即是索引

    3.指訪問查詢涉及的列-大量降低系統I/O

    4.每一列由一個線索來處理-查詢的並發處理

    5.數據類型一致,數據特征相似-高效壓縮

第二:hbase數據模型
hbase是基於Google BigTable模型開發的,典型的key/value系統
技術分享圖片
第一:hbase介紹
hbase是一個構建在hdfs上的分布式列存儲系統;

hbase是apache hadoop生態系統中的重要一員,主要用於海量結構化數據存儲

從邏輯上講,hbase將數據按照表、行和列進行存儲

hbase表特點:
  1.大:一個表可以有數十億行,上百萬列;

  2.無模式:每行都有一個可排序的主鍵和任意多的列,列可以根據需要動態的增加,同一張表中不同的行可以有截然不同的列;

  3.面向列:面向列(族)的存儲和權限控制,列(族)獨立檢索;

  4.稀疏:對於空(null)的列,並不占用存儲空間,表可以設計的非常稀疏;

  5.數據多版本:每個單元中的數據可以有多個版本,默認情況下版本號自動分配,是單元格插入時的時間戳;

  6.數據類型單一:hbase中的數據都是字符串,沒有類型

hbase與hdfs的對比:
  1.兩者都具有良好的容錯性和擴展性,都可以擴展到成百上千個節點。

  2.hdfs適合批處理場景,不支持數據隨機查找,不適合增量數據處理,不支持數據更新。

行存儲與列存儲:
  傳統行式數據庫:

    1.數據是按行存儲的

    2.沒有索引的查詢使用大量I/O

    3.建立索引和物化視圖需要花費大量時間和資源

    4.面向查詢的需求,數據庫必須被大量膨脹才能滿足性能要求

  列式數據庫:

    1.數據是按列存儲-每一列單獨存放

    2.數據即是索引

    3.指訪問查詢涉及的列-大量降低系統I/O

    4.每一列由一個線索來處理-查詢的並發處理

    5.數據類型一致,數據特征相似-高效壓縮

第二:hbase數據模型
hbase是基於Google BigTable模型開發的,典型的key/value系統

第三:hbase物理模型
每個column family存儲在HDFS上的一個單獨文件中;

Key和Version number在每個column family中均有一份

空值不被保存

eg:
技術分享圖片
info Column Family:
技術分享圖片
roles Column Family
技術分享圖片
數據物理存儲:
1.Table中所有的行都按照row key的字典序列排列;

2.Table在行的方向上被分割為多個Region;
技術分享圖片
3.Region按照大小分割的,每個表開始只有一個region,隨著數據的增多,region不斷的增大,當增大到一個閥值的時候,region就會等分成兩個新的region,之後會有越來越多的region;
技術分享圖片
4.Region是Hbase中分布式存儲和負載均衡的最小單元,不同的region分布在不同RegionServer上;
技術分享圖片
5.Region雖然是分布式存儲的最小單元,但並不是存儲的最小單元。

  1)Region是由一個或者多個Store組成,每個store保存一個columns family;

  2)每個Store又由一個memStore和0或多個StoreFile組成

  3)memStore存儲在內存中,StoreFile存儲在HDFS上。
技術分享圖片
第四:hbase基礎架構
Hbase架構:

在分布式的生產環境中,HBase 需要運行在 HDFS 之上,以 HDFS 作為其基礎的存儲設施。在 HBase 的集群中主要由 Master 和 Region Server 組成,以及 Zookeeper
技術分享圖片
Hbase相關的組件:
Clinet:

  包含訪問Hbase的接口,並維護cache來加快對Hbase的訪問。

zookeeper:

  保證任何時候,集群中只有一個master

  存儲所有Region的尋址入口

  實時監控Region Server的上線或者下線信息,並實時通知給Master

  存儲HBase的schema和table元數據

  zookeeper作用:

    HBase依賴zk;

    默認情況下Hbase管理zk實例,eg:啟動或者停止zk

    Master與RegionServers啟動時會向zk註冊

    Zookeeper的引入使得Master不在是單點故障

Master:

  為Region Server分配region

  負責Region Server的負載均衡

  發現失效的Region Server並重新分配他上面的region

  管理用戶對table的增刪改查操作

Region Server:

  維護region,處理對這些region的IO請求

  負責切分在運行過程中變得過大的region

-ROOT-表與-META-表:
-ROOT-表:

  包含-META-表所在的region列表,該表只會有一個Region;

  zookeeper中記錄了-ROOT-表的位置

-META-表:

  包含所有的用戶空間region列表,以及RegionServer的服務器地址
技術分享圖片
詳解:

1.HBase的所有Region元數據被存儲在.META.表中,隨著Region的增多,.META.表中的數據也會增大,並分裂成多個新的Region。為了定位.META.表中各個Region的位置,把.META.表中所有Region的元數據保存在-ROOT-表中,最後由Zookeeper記錄-ROOT-表的位置信息。所有客戶端訪問用戶數據前,需要首先訪問Zookeeper獲得-ROOT-的位置,然後訪問-ROOT-表獲得.META.表的位置,最後根據.META.表中的信息確定用戶數據存放的位置,如上圖所示。

2.-ROOT-表永遠不會被分割,它只有一個Region,這樣可以保證最多只需要三次跳轉就可以定位任意一個Region。為了加快訪問速度,.META.表的所有Region全部保存在內存中。客戶端會將查詢過的位置信息緩存起來,且緩存不會主動失效。如果客戶端根據緩存信息還訪問不到數據,則詢問相關.META.表的Region服務器,試圖獲取數據的位置,如果還是失敗,則詢問-ROOT-表相關的.META.表在哪裏。最後,如果前面的信息全部失效,則通過ZooKeeper重新定位Region的信息。所以如果客戶端上的緩存全部是失效,則需要進行6次網絡來回,才能定位到正確的Region。

高可用
Write-Ahead-Log(WAL)保障數據高可用
技術分享圖片
理解高可用首先:必須理解下HLog的作用,HBase中的Hlog機制是WAL的一種實現,而WAL是事務機制中常見的一致性的實現方式。每個RegionServer中都會有一個HLog的實例,RegionServer會將更新操作(put,delete等),先記錄到WAL(也就是HLog中),然後再將其寫入到Store的MemStore,最終Memstore達到一定的閥值後,在寫入到HFile中,這樣就保證了HBase的寫的可靠性,若沒有WAL,當RegionServer掛掉的時候,MemStore還沒有寫到HFile的數據,或者說StoreFile沒有保存的時候,數據會丟失。(說到這裏或許有人會問,假如HFile本身丟失了怎麽辦,這是由HDFS來保證的。在HDFS中的數據默認會有3份)

HFile是由很多個數據塊(Block)組成,並且有一個固定的結尾塊,其中的數據塊是由一個Header和多個Key-Value的鍵值對組成,在結尾的數據塊中包含了數據相關的索引信息,系統也是通過結尾的索引信息找到HFile中的數據。
組件的高可用
Master容錯:Zookeeper重新選擇一個新的Master

  無Master過程中,數據讀取任然照常進行

  無Master過程中,region切分、負載均衡等無法進行

RegionServer容錯:

  定時向Zookeeper匯報心跳,如果一旦一段時間內未出現心跳,Master將該RegionServer上的Region重新分配到其他的RegionServer上;

  失效的服務器上“預寫”日誌由主服務器進行分割並派送給新的RegionServer上

zookeeper容錯:zookeeper是一個可靠的服務

  一般是3到5個zookeeper實例

讀寫流程
  寫操作:
    1)client通過zookeeper的調度,向regionserver發出寫數據的請求,在Region中寫數據

    2)數據首先記錄在HLog中,然後再將其寫入到Store的MemStore,直到MemStore達到預定閥值

    3)MemStore中的數據被Flush成一個StoreFile

    4)隨著StoreFile文件的不斷增多,當其數據增長到一定閥值後,觸發Compact合並操作,將多個StoreFile合並成一個StoreFile,同時進行版本合並和數據刪除

    5)StoreFiles通過不斷的Compact合並操作,逐步形成越來越大的StoreFile

    6)單個StoreFile大小超過一定閥值後,觸發Split操作,把當前Region Split成2個新的Region,父Region會下線,新Split出的2個子Region會被HMaster分配到相應的RegionServer上,使原先1個Region的壓力得以分流到2個Region上面

  通過上述的寫流程可以發現,HBase更新、刪除等操作都是在後續Compact歷程中進行的,使得用戶的寫操作只要進入內存就可以立刻返回,實現可HBase I/0的高性能。

  讀操作:
    1)client訪問zk,查找-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

hbase數據原理及基本架構