Hbase的初步認識
整篇文章是在學習了多篇其他作者的文章的一個結合,若有冒犯侵權,還請及時告知,但也是我對於Hbase的心得體會,如果有理解錯誤的地方也還請大家指點,那麼下面我們就步入正文
Hbase
BigTable是什麼
在正式瞭解Hbase之前,我們先簡單的瞭解一下BigTable
百度百科給出的答案是:BigTable是Google設計的分散式資料儲存系統,用來處理海量的資料的一種非關係型的資料庫。BigTable是非關係型資料庫,是一個稀疏的、分散式的、持久化儲存的多維度排序Map。Bigtable的設計目的是快速且可靠地處理PB級別的資料,並且能夠部署到上千臺機器上。
BigTable資料模型
BigTable不是關係型資料庫,但是卻沿用了很多關係型資料庫的術語,像table(表)、row(行)、column(列)等。這容易讓讀者誤入歧途,將其與關係型資料庫的概念對應起來,從而難以理解。
本質上說,BigTable是一個鍵值(key-value)對映。按作者的說法,Bigtable是一個稀疏的,分散式的,持久化的,多維的排序對映。
BigTable的鍵有三維,分別是 行鍵(row key)、列鍵(column key)和時間戳(timestamp)
簡單理解,BigTable儲存的結構類似key-value (但並不是key-value),key稱為RowKey,value可以分多列(Column)儲存多個Value,相關的Column(一般資料型別相同)被聚為列簇(ColumnFamily),Value可以儲存多個版本,每個版本有Timestamp標識
可以總結為如下關係:
(RowKey,ColumnFamily:Column,Timestamp) → Value
類似如下表格:
BigTable的特點
1、適合大規模海量資料,PB級資料;
2、分散式、併發資料處理,效率極高;
3、易於擴充套件,支援動態伸縮;
4、適用於廉價裝置;
5、適合於讀操作,不適合寫操作。
6、不適用於傳統關係型資料庫;
Hbase是什麼
HBase:是一個分散式的、面向列的開源資料庫,該技術來源於 Fay Chang 所撰寫的Google論文“Bigtable:一個結構化資料的分散式儲存系統”。就像Bigtable利用了Google檔案系統(File System)所提供的分散式資料儲存一樣,HBase在Hadoop之上提供了類似於Bigtable
Hbase資料模型
Hbase是NoSQL資料庫的一種,但儘管如此,它也使用著一些關係型資料庫的術語
Table:Hbase的表由多個行組成
RowKey:代表著一行,這一行可以有一個或多個的列。通過row key來定位資料。是最重要的資料模型,當插入資料的時候,資料會按照row key進行排序,插入到合適的位置。
Column Family:先說一下列簇,方便後面說列。它在使用表前就必須被定義好,多個列可以有相同的列簇,例如:language:chinese和language:english都屬於language這個列簇
Column:代表著具體的哪一列,可以不用提前定義
Column Qualifier:列的唯一標識
Cell:Cell是由row,column family,column qualifier包含時間戳與值組成的,一般表達某個值的版本。cell中 的資料是沒有型別的,全部是位元組碼形式存貯。
Timestamp:Hbase中通過rowkey和columns確定的為一個存貯單元稱為cell。每個 cell都儲存 著同一份資料的多個版本。版本通過時間戳來索引。時間戳的型別是 64位整型。時間戳可以由HBASE(在資料寫入時自動 )賦值。預設的時間戳是你寫入資料的那一刻,但是你也可以在寫入資料的時候指定不同的時間戳
總結一下:
假設表中每一行代表著某個使用者和所有他所關注的其它使用者,那麼使用者ID就是Row Key,而每一個列標識(Column Qualifier)就是這個使用者所關注的其他使用者在列族裡的序號,單元資料(Cell)就是這個使用者所關注的其他使用者的使用者ID,然後有相同關係的其他關注者就可以放在同一列簇(Column Family),如:列簇分為男生和女生(當然這個例子可能不太好)
補充幾點:
1.Hbase在儲存資料的時候,有兩個SortedMap,首先按照rowkey進行字典排序,然後再對Column進行字典排序。
2.Hbase和RDBMS不一樣,沒有那麼多的資料型別,只有一個字串
3.看過官方檔案的話就會發現,Hbase支援四種操作:Get、Put、Scan、Delete
4.HBase的所有資料模型操作均按排序順序返回資料。首先是按行,然後是ColumnFamily,然後是列限定符,最後是時間戳(按相反順序排序,因此首先返回最新記錄)
5.Hbase並不能像RDBMS一樣支援join,但不代表Hbase不能做到,具體策略官方檔案有提及
Hbase架構體系
Hbase內部的基本組成
Hbase的整體主要由zookeeper,Hmaster,HRegionServer,Hdfs檔案系統組成。由這四部分共同完成資料的讀取與寫入。
Hbase的資料儲存方式
hbase有個很重要的特性,就是可以存取海量資料,而且是通過分散式叢集的方式, 當資料量越來越多的時候通過增加叢集主機的數量就可以將資料分散到不同的主機上,這是傳統的資料庫很難實現的
如上圖,不同的範圍的資料劃分到不同的Region,而不同的HRegion會被放在不同的主機上,當查詢資料的時候,只要根據RowKey先找到資料在那個範圍的HRegion中,就可以直接去那個HRegion中找到資料,所以查詢效率會比傳統的資料庫快很多。 當然隨著資料不斷增多,Region也會不斷的增多(對錶的劃分增多),而RegionServer也是多個,不同的Region由多個不同的RegionServer管理著。
Hbase的讀寫資料的基本流程
寫資料
客戶端傳送請求,找到請求需要的Region的RegionServer,RegionServer會先將請求寫入到Hlog,防止資料丟失,很多系統都是這樣操作的,寫入完成後才會將請求寫入到對應的Region中
我們再說一下,是如何從Region寫入到hdfs中的,Region中有多個Store(每個Store代表著一個Table中的Column Family),而資料在哪個Column Family 就傳入那個Store,其流程:RegionServer會先寫入到Region的MemStore中(此時就會返回寫入成功,但Hfile檔案還並未建立),當MemStore的資料達到一定大小時,就會Flush,然後被寫入到StoreFile中,StoreFile又會被序列化成Hfile,最後通過hdfs的api傳入到hdfs
讀資料
讀資料和寫資料我們都要知道是如何查詢到我們要的資料儲存的Region是在哪個RegionServer上,首先我們通過Zookeeper查詢到-root-的位置(-root-只有一個,本質也是一個Region,存放的是不同範圍的RowKey去哪個RegionServer的.Meta.中找),之後再去請求.Meta.得到Table和RowKey,然後在去請求在哪個Region上,最後拿到想要的資料,一共是請求了四次(不過某版本之後去掉了-root-)
HMaster
最後來說一下一直沒有提到的HMaster,當一個Region中的資料達到一定程度,HMaster就會對其進行合併資料,清理其中的冗餘資料,清理後的資料大小小於256M,還有一個呢,就是HRegion Split,最開始的時候,一個Table只有一個HRegion,隨著資料寫入的增加使HRegion到達一定的大小,就需要Split成兩個HRegion,這個大小由hbase.hregion.max.filesize指定,其過程就是由HMaster完成的。 當split時,兩個新的HRegion會在同一個HRegionServer中建立,它們各自包含父HRegion一半的資料,當Split完成後,父HRegion會下線,而新的兩個子HRegion會向HMaster註冊上線,處於負載均衡的考慮,這兩個新的HRegion可能會被HMaster分配到其他的HRegionServer中。 當HRegionServer宕機之後,HMaster可以讀取Hlog,將資料在傳送給其他RegionServer進行資料恢復。並修改.Meta.
總結一下:
Hmaster: 在Region Split後,負責新Region的分配; 新機器加入時,管理HRegion Server的負載均衡,調整Region分佈 在HRegion Server宕機後,負責失效HRegion Server 上的Regions遷移。
Region Server: Region Server維護Master分配給它的region,處理對這些Region的IO請求 HRegion Server管理了很多Table的分割槽,也就是Region。
Zookeeper: ZooKeeper為HBase叢集提供協調服務,它管理著HMaster和HRegionServer的狀態(available/alive等),並且會在它們宕機時通知給HMaster Zookeeper中管理著hbase的元資料,例如-root-的位置所在。
hdfs: 資料檔案的存放處。由於其本身的分散式儲存機制,所以資料檔案很安全。 hadoop的datanode最好和region在同一主機上,方便讀取資料。儘量避免網路資料傳輸。