1. 程式人生 > >如何使用HBase?大資料儲存的兩個實戰場景

如何使用HBase?大資料儲存的兩個實戰場景

現如今各種資料儲存方案層出不窮,本文僅僅是結合兩個實戰場景就基於HBase的大資料儲存做了簡單的分析,並對HBase的原理做了簡單的闡述。如何使用好HBase,甚至於如何選擇一個最優的資料儲存方案,還需要我們根據場景需要具體分析和設計

HBase是一個高可靠性、高效能、面向列、可伸縮的分散式儲存系統,適用於結構化的儲存,底層依賴於Hadoop的HDFS,利用HBase技術可在廉價PCServer上搭建起大規模結構化儲存叢集。因此HBase被廣泛使用在大資料儲存的解決方案中。

為何使用HBase

HBase的優點:

- 列可以動態增加,並且列為空就不儲存資料,節省儲存空間。

- Hbase自動切分資料,使得資料儲存自動具有水平scalability。

- Hbase可以提供高併發讀寫操作的支援。

HBase的缺點:

- 不能支援條件查詢,只支援按照Row key來查詢。

- HBase並不適合傳統的事物處理程式或關聯分析,不支援複雜查詢,一定程度上限制了它的使用,但是用它做資料儲存的優勢也同樣非常明顯。

因為HBase儲存的是鬆散的資料,所以如果你的應用程式中,資料表每一行的結構是有差別的,那麼可以考慮使用HBase。因為HBase的列可以動態增加,並且列為空就不儲存資料,所以如果你需要經常追加欄位,且大部分欄位是NULL值的,那可以考慮HBase。因為HBase可以根據Rowkey提供高效的查詢,所以如果你的資料(包括元資料、訊息、二進位制資料等)都有著同一個主鍵,或者你需要通過鍵來訪問和修改資料,使用HBase是一個很好地選擇。

如何使用HBase

場景一:賣家操作日誌

賣家操作日誌,顧名思義是用來記錄商家操作的系統,從而可以保證商家可以精確查詢自己的各種操作。京東有幾十萬的商家時時刻刻的進行著各種操作,因此賣家操作日誌的特點是:資料量大、實時性強、增多查少。

圖1

圖2

我們在做賣家操作日誌初期,將所有的操作日誌存放在ES中,操作日誌的資料量是非常大的,但尷尬的是我們當時所能申請到的ES資源有限。當把大量的資料儲存到有限的ES叢集中時便導致了效能的下降。在這種情況下,我們選擇了只在ES叢集中儲存最近三個月的資料,對其提供靈活的查詢,而長期的資料儲存使用HBase來進行。這樣的話我們便可以實現對近期操作靈活展現,對長期資料也有精確備份。

場景二:京麥訊息日誌的儲存

京麥訊息日誌的儲存是屬於京麥筋斗雲系統(用於打造京麥訊息生態系統閉環)不可或缺的一部分。其中包含訊息的全鏈路追蹤以及訊息的統計分析。京麥訊息每天都會有幾千萬的訊息量,如何對訊息進行追蹤和統計便成為了一個至關重要的問題。訊息追蹤要求實時性、多維度精確查詢,因此我們選擇將最近一週的訊息日誌儲存在ES。統計分析要求我們有足夠多的資料,因此我們在將資料儲存在ES中的同時也儲存在HBase中一份。最終再定期將HBase中的資料匯入到京東的資料集市中,這樣我們便可以很方便的對京麥訊息進行統計分析。

HBase的資料結構

要使用HBase我們首先要了解HBase的資料結構:

HBase會儲存系列的行記錄,行記錄有三個基本型別的定義:Row Key、Time Stamp、Column Family。

Row Key

與NoSQL資料庫一樣,Row Key是用來檢索記錄的主鍵。訪問HBase table中的行,只有三種方式:

通過單個Row Key訪問。

通過Row Key的range全表掃描。

Row Key可以是任意字串(最大長度是64KB,實際應用中長度一般為 10 ~ 100bytes),在HBase內部,Row Key儲存為位元組陣列。

在儲存時,資料按照Row Key的字典序(byte order)排序儲存。設計Key時,要充分排序儲存這個特性,將經常一起讀取的行儲存到一起(位置相關性)。

Column Family

HBase表中每個列都必須屬於某個列族,列族必須作為表模式定義的一部分預先給出(有點像關係型資料庫中的列名,定義完一般情況下就不會再去修改);

列名以列族作為字首,每個列族都可以有多個列成員。新的列族成員(也就是列)可以隨後按需,動態加入。

Hbase把同一列族裡面的資料儲存在同一目錄下,由幾個檔案儲存。

Time Stamp

在HBase每個cell儲存單元對同一份資料有多個版本,根據唯一的時間戳來區分每個版本之間的差異,不同版本的資料按照時間倒序排序,最新的資料版本排在最前面。

簡述HBase的架構原理

1. HBase的模組

Master

HBase Master用於協調多個Region Server,偵測各個Region Server之間的狀態,並平衡Region Server之間的負載。HBase Master還有一個職責就是負責分配Region給Region Server。HBase允許多個Master 節點共存,但是這需要Zookeeper的幫助。不過當多個Master節點共存時,只有一個Master是提供服務的,其他的Master節點處於待命的狀態。當正在工作的Master節點宕機時,其他的Master則會接管 HBase 的叢集。

Region Server

對於一個Region Server而言,其包括了多個Region。Region Server的作用只是管理表格,以及實現讀寫操作。Client 直接連線Region Server,並通訊獲取HBase中的資料。對於Region而言,則是真實存放HBase資料的地方,也就說Region是HBase可用性和分散式的基本單位。如果當一個表格很大,並由多個CF組成時,那麼表的資料將存放在多個Region之間,並且在每個Region中會關聯多個儲存的單元(Store)。

Zookeeper

對於HBase而言,Zookeeper的作用是至關重要的。首先Zookeeper是作為HBase Master的HA解決方案。也就是說,是Zookeeper保證了至少有一個HBase Master處於執行狀態。並且Zookeeper負責Region和Region Server的註冊。其實Zookeeper發展到目前為止,已經成為了分散式大資料框架中容錯性的標準框架。不光是HBase,幾乎所有的分散式大資料相關的開源框架,都依賴於Zookeeper實現HA。

2. HBase的原理

首先我們需要知道HBase的叢集是通過Zookeeper來進行機器之前的協調,也就是說HBase Master與Region Server之間的關係是依賴Zookeeper來維護。當一個Client需要訪問HBase叢集時,Client需要先和Zookeeper來通訊,然後才會找到對應的Region Server。每一個 Region Server管理著很多個Region。對於HBase來說,Region是HBase並行化的基本單元。因此,資料也都儲存在Region中。

這裡我們需要特別注意,每一個Region都只儲存一個Column Family的資料,並且是該CF中的一段(按Row 的區間分成多個Region)。Region所能儲存的資料大小是有上限的,當達到該上限時(Threshold),Region會進行分裂,資料也會分裂到多個Region中,這樣便可以提高資料的並行化,以及提高資料的容量。

每個Region包含著多個Store物件。每個Store包含一個MemStore,和一個或多個HFile。MemStore便是資料在記憶體中的實體,並且一般都是有序的。當資料向Region寫入的時候,會先寫入MemStore。當MemStore中的資料需要向底層檔案系統傾倒(Dump)時(例如MemStore中的資料體積到達MemStore配置的最大值),Store便會建立StoreFile,而StoreFile就是對HFile一層封裝。所以MemStore中的資料會最終寫入到HFile中,也就是磁碟IO。由於HBase底層依靠HDFS,因此HFile都儲存在HDFS之中。這便是整個HBase工作的原理簡述。

使用HBase時應注意的問題

基於Hbase的系統設計與開發中,需要考慮的因素不同於關係型資料庫,Hbase模式本身很簡單,但賦予你更多調整的空間,有一些模式寫效能很好,但讀取資料時表現不好,或者正好相反,類似傳統資料庫基於正規化的OR建模,在實際專案中考慮Hbase設計模式是,我們需要從以下幾方面內容著手:

• 這個表應該有多少個列簇

• 列簇使用什麼資料

• 每個列簇應有多少個列

• 列名應該是什麼,儘管列名不必在建表時定義,但是讀寫資料時是需要的

• 單元應該存放什麼資料

• 每個單元儲存什麼時間版本

• 行健結構是什麼,應該包括什麼資訊

總結

現如今各種資料儲存方案層出不窮,本文僅僅是結合兩個實戰場景就基於HBase的大資料儲存做了簡單的分析,並對HBase的原理做了簡單的闡述。如何使用好HBase,甚至於如何選擇一個最優的資料儲存方案,還需要我們根據場景需要具體分析和設計

各位對大資料感興趣的我在這裡為大家介紹一個大資料學習交流群,有關大資料的基礎與專案實戰的學習資料都是有的哦,感興趣的可以加群:615997810,