1. 程式人生 > >HBase學習之路 (一)HBase基礎介紹

HBase學習之路 (一)HBase基礎介紹

產生背景

自 1970 年以來,關係資料庫用於資料儲存和維護有關問題的解決方案。大資料的出現後, 好多公司實現處理大資料並從中受益,並開始選擇像 Hadoop 的解決方案。Hadoop 使用分 布式檔案系統,用於儲存大資料,並使用 MapReduce 來處理。Hadoop 擅長於儲存各種格式 的龐大的資料,任意的格式甚至非結構化的處理。

Hadoop 的限制

Hadoop 只能執行批量處理,並且只以順序方式訪問資料。這意味著必須搜尋整個資料集, 即使是最簡單的搜尋工作。 當處理結果在另一個龐大的資料集,也是按順序處理一個巨大的資料集。在這一點上,一個 新的解決方案,需要訪問資料中的任何點(隨機訪問)單元。

Hadoop 隨機存取資料庫

應用程式,如 HBase,Cassandra,CouchDB,Dynamo 和 MongoDB 都是一些儲存大量資料和 以隨機方式訪問資料的資料庫。

總結:

(1)海量資料量儲存成為瓶頸,單臺機器無法負載大量資料

(2)單臺機器 IO 讀寫請求成為海量資料儲存時候高併發大規模請求的瓶頸

(3)隨著資料規模越來越大,大量業務場景開始考慮資料儲存橫向水平擴充套件,使得儲存服 務可以增加/刪除,而目前的關係型資料庫更專注於一臺機器

回到頂部

HBase簡介

HBase 是 BigTable 的開源(原始碼使用 Java 編寫)版本。是 Apache Hadoop 的資料庫,是建 立在 HDFS 之上,被設計用來提供高可靠性、高效能、列儲存、可伸縮、多版本的 NoSQL 的分散式資料儲存系統,實現對大型資料的實時、隨機的讀寫訪問。

HBase 依賴於 HDFS 做底層的資料儲存,BigTable 依賴 Google GFS 做資料儲存

HBase 依賴於 MapReduce 做資料計算,BigTable 依賴 Google MapReduce 做資料計算

HBase 依賴於 ZooKeeper 做服務協調,BigTable 依賴 Google Chubby 做服務協調

NoSQL = NO SQL

NoSQL = Not Only SQL:會有一些把 NoSQL 資料的原生查詢語句封裝成 SQL,比如 HBase 就有 Phoenix 工具

關係型資料庫 和 非關係型資料庫的典型代表

NoSQL:hbase, redis, mongodb

RDBMS:mysql,oracle,sql server,db2

HBase 這個 NoSQL 資料庫的要點

① 它介於 NoSQL 和 RDBMS 之間,僅能通過主鍵(rowkey)和主鍵的 range 來檢索資料

② HBase 查詢資料功能很簡單,不支援 join 等複雜操作

③ 不支援複雜的事務,只支援行級事務(可通過 hive 支援來實現多表 join 等複雜操作)。

④ HBase 中支援的資料型別:byte[](底層所有資料的儲存都是位元組陣列)

⑤ 主要用來儲存結構化和半結構化的鬆散資料。

結構化、半結構化和非結構化

結構化:資料結構欄位含義確定,清晰,典型的如資料庫中的表結構

半結構化:具有一定結構,但語義不夠確定,典型的如 HTML 網頁,有些欄位是確定的(title), 有些不確定(table)

非結構化:雜亂無章的資料,很難按照一個概念去進行抽取,無規律性

與 Hadoop 一樣,HBase 目標主要依靠橫向擴充套件,通過不斷增加廉價的商用伺服器,來增加 計算和儲存能力。

HBase 中的特點

1、:一個表可以有上十億行,上百萬列

2、面向列:面向列(族)的儲存和許可權控制,列(簇)獨立檢索。

3、稀疏:對於為空(null)的列,並不佔用儲存空間,因此,表可以設計的非常稀疏。

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

回到頂部

 HBase表結構邏輯檢視

初次接觸HBase,可能看到以下描述會懵:“基於列儲存”,“稀疏MAP”,“RowKey”,“ColumnFamily”。

其實沒那麼高深,我們需要分兩步來理解HBase, 就能夠理解為什麼HBase能夠“快速地”“分散式地”處理“大量資料”了。

  1.記憶體結構

  2.檔案儲存結構

 名詞概念

加入我們有如下一張表

Rowkey的概念

Rowkey的概念和mysql中的主鍵是完全一樣的,Hbase使用Rowkey來唯一的區分某一行的資料。

由於Hbase只支援3中查詢方式:

1、基於Rowkey的單行查詢

2、基於Rowkey的範圍掃描

3、全表掃描

因此,Rowkey對Hbase的效能影響非常大,Rowkey的設計就顯得尤為的重要。設計的時候要兼顧基於Rowkey的單行查詢也要鍵入Rowkey的範圍掃描。具體Rowkey要如何設計後續會整理相關的文章做進一步的描述。這裡大家只要有一個概念就是Rowkey的設計極為重要。

rowkey 行鍵可以是任意字串(最大長度是 64KB,實際應用中長度一般為 10-100bytes),最好是 16。在 HBase 內部,rowkey 儲存為位元組陣列。HBase 會對錶中的資料按照 rowkey 排序 (字典順序)

Column的概念

列,可理解成MySQL列。

ColumnFamily的概念

列族, HBase引入的概念。

Hbase通過列族劃分資料的儲存,列族下面可以包含任意多的列,實現靈活的資料存取。就像是家族的概念,我們知道一個家族是由於很多個的家庭組成的。列族也類似,列族是由一個一個的列組成(任意多)。

Hbase表的建立的時候就必須指定列族。就像關係型資料庫建立的時候必須指定具體的列是一樣的。

Hbase的列族不是越多越好,官方推薦的是列族最好小於或者等於3。我們使用的場景一般是1個列族。

TimeStamp的概念

TimeStamp對Hbase來說至關重要,因為它是實現Hbase多版本的關鍵。在Hbase中使用不同的timestame來標識相同rowkey行對應的不通版本的資料。

HBase 中通過 rowkey 和 columns 確定的為一個儲存單元稱為 cell。每個 cell 都儲存著同一份 資料的多個版本。版本通過時間戳來索引。時間戳的型別是 64 位整型。時間戳可以由 hbase(在資料寫入時

自動)賦值,此時時間戳是精確到毫秒的當前系統時間。時間戳也可以由 客戶顯式賦值。如果應用程式要避免資料版本衝突,就必須自己生成具有唯一性的時間戳。 每個 cell 中,不同版本的資料按照時間

倒序排序,即最新的資料排在最前面。

為了避免資料存在過多版本造成的的管理 (包括存貯和索引)負擔,hbase 提供了兩種資料版 本回收方式:  儲存資料的最後 n 個版本  儲存最近一段時間內的版本(設定資料的生命週期 TTL)。使用者可以針對每個列簇進行設定。

單元格(Cell)

由{rowkey, column( = + ), version} 唯一確定的單元。 Cell 中的資料是沒有型別的,全部是位元組碼形式存貯。