Hbase常識及適合場景

當我們對於數據結構字段不夠確定或雜亂無章很難按一個概念去進行抽取的數據適合用使用什麼數據庫?答案是什麼,如果我們使用的傳統數據庫,肯定留有多餘的字段,10個不行,20個,但是這個嚴重影響了質量。並且如果面對大數據庫,pt級別的數據,這種浪費更是嚴重的,那麼我們該使用是什麼數據庫?hbase數個不錯的選擇,那麼我們對於hbase還存在下列問題:


1.Column Family代表什麼?
2.HBase通過row和column確定一份數據,這份數據的值可能有多個版本,爲什麼會存在多個版本?
3.查詢的時候會顯示那個版本?
4.它們的存儲類型是什麼?
5.tableName是什麼類型?
6.RowKey 和 ColumnName是什麼類型?
7.Timestamp 是什麼類型?

8.value 是什麼類型?

帶着以上幾個問題去讀下面內容:


引言

團隊中使用Hbase的項目多了起來,對於業務人員而言,通常並不需要從頭搭建、維護一套HBase的集羣環境,對於其架構細節也不一定要深刻理解(交由HBase集羣維護團隊負責),迫切需要的是快速理解基本技術來解決業務問題。最近在XX項目輪崗過程中,嘗試着從業務人員視角去看HBase,將一些過程記錄下來,期望對快速瞭解HBase、掌握相關技術來開展工作的業務人員有點幫助。我覺得作爲一個初次接觸HBase的業務開發測試人員,他需要迫切掌握的至少包含以下幾點:
深入理解HTable,掌握如何結合業務設計高性能的HTable

掌握與HBase的交互,反正是離不開數據的增刪改查,通過HBase Shell命令及Java Api都是需要的

掌握如何用MapReduce分析HBase裏的數據,HBase裏的數據總要分析的,用MapReduce是其中一種方式

掌握如何測試HBase MapReduce,總不能光寫不管正確性吧,debug是需要的吧,看看如何在本機單測debug吧



本系列將圍繞以上幾點展開,篇幅較長,如果是HBase初學者建議邊讀邊練,對於HBase比較熟練的,可以選讀下,比如關注下HBase的MapReduce及其測試方法。

從一個示例說起

傳統的關係型數據庫想必大家都不陌生,我們將以一個簡單的例子來說明使用RDBMS和HBase各自的解決方式及優缺點。
以博文爲例,RDBMS的表設計如下:


 

爲了方便理解,我們以一些數據示例下

 

上面的例子,我們用HBase可以按以下方式設計

 

同樣爲了方便理解,我們以一些數據示例下,同時用紅色標出了一些關鍵概念,後面會解釋

 


HTable一些基本概念

Row key


行主鍵, HBase不支持條件查詢和Order by等查詢,讀取記錄只能按Row key(及其range)或全表掃描,因此Row key需要根據業務來設計以利用其存儲排序特性(Table按Row key字典序排序如1,10,100,11,2)提高性能。

Column Family(列族)

在表創建時聲明,每個Column Family爲一個存儲單元。在上例中設計了一個HBase表blog,該表有兩個列族:article和author。

Column(列)

HBase的每個列都屬於一個列族,以列族名爲前綴,如列article:title和article:content屬於article列族,author:name和author:nickname屬於author列族。
Column不用創建表時定義即可以動態新增,同一Column Family的Columns會羣聚在一個存儲單元上,並依Column key排序,因此設計時應將具有相同I/O特性的Column設計在一個Column Family上以提高性能。同時這裏需要注意的是:這個列是可以增加和刪除的,這和我們的傳統數據庫很大的區別。所以他適合非結構化數據。

Timestamp

HBase通過row和column確定一份數據,這份數據的值可能有多個版本,不同版本的值按照時間倒序排序,即最新的數據排在最前面,查詢時默認返回最新版本。如上例中row key=1的author:nickname值有兩個版本,分別爲1317180070811對應的“一葉渡江”和1317180718830對應的“yedu”(對應到實際業務可以理解爲在某時刻修改了nickname爲yedu,但舊值仍然存在)。Timestamp默認爲系統當前時間(精確到毫秒),也可以在寫入數據時指定該值。
Value

每個值通過4個鍵唯一索引,tableName+RowKey+ColumnKey+Timestamp=>value,例如上例中{tableName=’blog’,RowKey=’1’,ColumnName=’author:nickname’,Timestamp=’ 1317180718830’}索引到的唯一值是“yedu”。

存儲類型

TableName 是字符串
RowKey 和 ColumnName 是二進制值(Java 類型 byte[])
Timestamp 是一個 64 位整數(Java 類型 long)
value 是一個字節數組(Java類型 byte[])。


存儲結構

可以簡單的將HTable的存儲結構理解爲

 

即HTable按Row key自動排序,每個Row包含任意數量個Columns,Columns之間按Column key自動排序,每個Column包含任意數量個Values。理解該存儲結構將有助於查詢結果的迭代。

話說什麼情況需要HBase

半結構化或非結構化數據

對於數據結構字段不夠確定或雜亂無章很難按一個概念去進行抽取的數據適合用HBase。以上面的例子爲例,當業務發展需要存儲author的email,phone,address信息時RDBMS需要停機維護,而HBase支持動態增加.


記錄非常稀疏

RDBMS的行有多少列是固定的,爲null的列浪費了存儲空間。而如上文提到的,HBase爲null的Column不會被存儲,這樣既節省了空間又提高了讀性能。


多版本數據

如上文提到的根據Row key和Column key定位到的Value可以有任意數量的版本值,因此對於需要存儲變動歷史記錄的數據,用HBase就非常方便了。比如上例中的author的Address是會變動的,業務上一般只需要最新的值,但有時可能需要查詢到歷史值。


大數據

當數據量越來越大,RDBMS數據庫撐不住了,就出現了讀寫分離策略,通過一個Master專門負責寫操作,多個Slave負責讀操作,服務器成本倍增。隨着壓力增加,Master撐不住了,這時就要分庫了,把關聯不大的數據分開部署,一些join查詢不能用了,需要藉助中間層。隨着數據量的進一步增加,一個表的記錄越來越大,查詢就變得很慢,於是又得搞分表,比如按ID取模分成多個表以減少單個表的記錄數。經歷過這些事的人都知道過程是多麼的折騰。採用HBase就簡單了,只需要加機器即可,HBase會自動水平切分擴展,跟Hadoop的無縫集成保障了其數據可靠性(HDFS)和海量數據分析的高性能(MapReduce)。


**************************

轉自:做一個愛分享的人

**************************

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章