【51CTO.com原創稿件】 Apache HBase 是 Hadoop 的大數據存儲數據庫，一個分布式、可伸縮的大數據存儲，是依賴 Hadoop。

[[398652]]

圖片來自 Pexels

HBase 該技術來源于 Fay Chang 所撰寫的 Google 論文“Bigtable：一個結構化數據的分布式存儲系統”。

就像 Bigtable 利用了 Google 文件系統(File System)所提供的分布式數據存儲一樣，HBase 在 Hadoop 之上提供了類似于 Bigtable 的能力。

BATJ 公司為什么用 HBase 能存儲海量的數據?

• 因為 HBase 是在 HDFS 的基礎之上構建的，HDFS 是分布式文件系統。
• Hbase 設計上屬于列式存儲，在存儲上將業務的數據按照水平分割的模式來劃分，因此在查詢與插入的時候比較聚焦。
• HBase 不同于一般的關系數據庫，它是一個適合于非結構化數據存儲的數據庫，特別是 HBase 基于列的而不是基于行的模式存儲

為什么要用 HBase

①分布式存儲引擎分類

分布式存儲引擎大概分類如下：

• 分布式搜索(Elasticsearch)
• 分布式文件系統(HDFS)
• 分布式消息隊列(Kafka)
• 緩存數據庫(Redis)
• 非關系型分布式數據庫(Hbase\Mongodb\Cloudant)
• 等等...

②存儲引擎的存儲方式

存儲引擎的存儲方式如下：

• Redis 有 AOF 和 RDB
• Elasticsearch 會把數據寫到 translog 然后結合 FileSystemCache 將數據刷到磁盤中
• Kafka 本身就是將數據順序寫到磁盤....

這些中間件都能夠實現持久化(比如 HDFS 和 MySQL 我們本身就用來存儲數據的)，那用 HBase 干啥呢?

③各種存儲引擎優缺點

HDFS 可以保存海量數據，容錯性高，適合批處理，適合保存大量數據，可以流式數據訪問，對于服務器的要求也不高，但是他也有一些不足如，不適合低延時數據訪問。

比如毫秒級的存儲數據，是做不到的，也沒辦法高效的對大量小文件進行保存處理，而且一個文件只能有一個線程寫入，不允許多個線程同時寫入，也不支持文件的隨機修改。

MySQL 是我們日常中用的比較多的關系型數據庫了，但是大家都知道 MySQL，他是單機的。

單機 MySQL 他最大的容量，完全取決于服務器的硬盤容量的大小。其最致命的弱點就是當有大量數據需要存儲時，MySQL 很難扛得住。

Elasticsearch 大家都知道他是一個分布式搜索引擎，在搜索效率上還是比較快的。

因為 Elasticsearch 基于分布式所以理論上也是可以保存大量的數據的，我們也可以根據索引來取出來，那這就是我們心目中最完美的存儲方式了嗎?

不，他不是，因為如果我們存儲的數據沒有經常需要查詢的需求，其實放到 Elasticsearch 就是一種浪費，因為數據在寫入 Elasticsearch 時需要進行分詞，從而大量消耗資源，造成沒必要的浪費。

Redis 是近幾年最常用的緩存數據庫，讀與寫的操作都在內存中進行，其速度響應非常快，AOF/RDB 保存的相關數據全會加載到我們機器的內存中，從而導致 Redis 并不適合保存大量的數據，畢竟內存還是相對有限。

Kafka 在我們項目工作中主要用來處理消息的解耦于異步削峰，當數據到達 Kafka，此時就會將數據持久化到服務器硬盤中，且很方便的擴展因為他是分布式的，按照這個邏輯 Kafka 是可以存儲大量數據。

但是 Kafka 持久化了的數據，最常見的用法就是直接重新設置 offset 進行操作。

④Hbase 的使用場景

Hbase 適合需對數據進行隨機讀操作或者隨機寫操作、大數據上高并發操作，比如每秒對 PB 級數據進行上千次操作以及讀寫訪問均是非常簡單的操作。

淘寶指數是 Hbase 在淘寶的一個典型應用。交易歷史紀錄查詢很適合用 Hbase 作為底層數據庫。

入門 HBase

①HBase 特性

Hbase 作為一種 NoSQL 數據庫，而這就說明他不是傳統的 RDBMS 數據庫，且 SQL 語句也是不支持的。

對于 Hbase 是一種分布式存儲的數據庫，在技術層面來講，它是屬于分布式存儲，因為缺少很多 RDBMS 數據庫的特性。

那 Hbase 有什么特點呢?如下：

大，他容量巨大，HBase 的單表可以有百億行、百萬列，可以在橫向和縱向兩個維度插入數據，具有很大的彈性。

稀疏性，這主要體現在 Hbase 針對列有著很高的靈活性，比如對于為 NULL 的列中，是不會占用存儲空間的，所以表可以設計的很稀疏。

易擴展，因為前面我也講到過 HBase 是工作在 HDFS 之上的，所以自然是支持分布式表，同時也繼承了 HDFS 的可擴展性。

而且 HBase 的擴展是橫向擴展的，所謂的橫向擴展是指在擴展的時候不需要提高服務器性能，只需要添加服務器到現有的集群即可。

高并發，如果項目使用 Hbase 的架構，那么使用的 PC 都可以很便宜，因此高 IO 也是常事。

而我所說的高并發，主要是他和其他 NoSQL 一樣，Hbase 不支持復雜的 SQL 語句，這就給性能優化帶來更多可能，并且主要是在內存中工作，支持大并發應該是沒問題的。

還有別忘了，HBase 是天然支持分布式的，所以還可以利用集群等方法提高并發量。

高可用，還是因為 HBase 是運行在 HDFS 上的，HDFS 的多副本存儲，類似于 MySQL 主備容災，他可以在岀現故障時自行恢復，同時 HBase 還有更多的策略如：Replication，WAL 等。

面向列，這個與我們常用的 MySQL 等關系型數據庫不同，HBase 是面向列的存儲控制的。

簡單來說就是每個列他都是是單獨存儲的，而且支持直接對列來進行查詢，下面這張圖可以簡單來理解下什么是對列的操作。

從圖上來理解，看下下面的行存儲于列存儲其中行存儲是保存在一塊的，而列存儲中的數據是分割的。

由上圖得知行存儲更適合插入與更新，而查詢操作時需要讀取其中所有的數據，此時 HBase 列存儲則只需要讀取相關列即可，從而可以大幅降低系統 I/O 吞吐量，達到快速讀取的目的。

②什么情況更適合使用 Hbase

首先 Hbase 不是萬能的，他也有不適合的場景，有哪些不適合場景呢?

這主要也是根據其特點來說的，首先一點就是數據量要大，如果你的數據只有區區幾百萬條或者更少的數據量，那么關系型數據庫可能更適合你。

因為數據量不大的話，根本體現不出 HBase 的優勢，反而會成為累贅，因為有大量的機器空閑，浪費資源。

再一個就是你對于列查詢的使用不是那么高，且你也不需要輔助索引，靜態類型的列等 HBase 的特性，在現有項目中使用關系型數據庫已經可以滿足其需求，則你完全沒必要為了技術而去使用。

如果非要使用對于以往的項目你還需要重新去設計重構等，帶來不必要的麻煩。

最后雖然 Hbase 在單機環境也能運行，但是最好請在開發環境的時候使用。

③HBase 的 Key-Value

HBase 其實就與 Redis 一樣是 Key-Value 的數據庫，那在 HBase 里邊，Key 是什么?Value 是什么?

首先 KeyValue 的概念設計源自一片論文為"The log-structured merge-tree(LSM-Tree)"。

其中的每一行，每一列的數據，都被獨立包裝成特定結構即 KeyValue，而 KeyValue 還包含了很多自我描述信息從而會導致數據膨脹 。

目前市面上所有項目主要數據結構有：

• 結構化數據
• 半結構化數據
• 非結構化數據

由于 HBase 的稀疏性，導致其對于非結構化的數據存儲有著天然的優勢，而在我們日常項目中， 關系型數據也就是結構化數據是經常使用到的 。

由于 HBase 目前只能提供基于 RowKey 的單維度索，在我們日常項目中還是有些吃力。

還需要基于 HBase 添加一些特殊功能，如：

• GeoMesa 時空數據存儲
• JanusGraph 圖數據存儲
• OpenTSDB 時序數據存儲

既然如此，不如專業的事情交給專業的的去做，既然 MySQL，Oracle，MSSQL 這些關系型數據庫這么擅長處理結構化數據，那就讓他們來處理好了。

他們既然不擅長處理海量非結構化數據，那就上 HBase，所以我的理解 HBase 不是萬能的，他只是相對于傳統關系型數據庫的一種補充。

④HBase 架構

HBase 架構如上圖：

• Zookeeper，主要作用是分布式協調。
• RegionServer，作為數據節點，用于存儲數據，也會把自己的信息寫到 ZooKeeper 中。
• HDFS，是在這里主要作為 HBase 的基礎，是一個 分布式文件系統，為 HBase 提供服務。
• Master，主要負責管理所有的 RegionServer，管理所有的 Region 到 RegionServer 的分配，且自身也可以作為一個 RegionServer 提供服務。

其大概流程就是：

• client 請求到 Zookeeper。
• Zookeeper 返回 HRegionServer 地址給 client。
• 當 client 獲取到 Zookeeper 返回的地址就去請求 HRegionServer。
• HRegionServer 讀寫數據后再返回給 client。

⑤HMaster 大作用

看上面的流程我好像沒有提到 HMaster，那 HMaster 是不是沒啥用?那他主要是做什么的呢?

其實他的作用是不能被忽略的有：

• 負責 Region server 分布式管理與負載均衡
• 為 Region server 分配 region
• 在 HRegion 分裂后，負責新 HRegion 的分配
• 將 HDFS 上的垃圾文件回收
• 處理 schema 更新請求

由此可以看來 HMaster 相當于指揮家，統籌大局，非常重要!

RowKey 的設計

RowKey 在查詢和保存方面有著很重要的作用，HBase 中如果設計好一個 RowKey 將會影響到其中數據的分布，與我們的查詢速度。

由此得知設計好一個優秀的 RowKey 是非常重要的，那么這么重要的 RowKey 我們如何來設計呢?

首先要遵從以下幾個原則：

長度原則：最短越好，最短越好，最短越好，重要的事情說三遍，最大不能超過 64K。如果太長主要影響有兩點，

首先特別影響 HFile 的存儲效果。其次 MemStore 將緩存部分數據到內存，如果 RowKey 字段過長，內存的有效利用率就會降低，系統不能緩存更多的數據，這樣會降低檢索效率。

總結：保存慢，查詢慢!

唯一原則：這個應該很好理解，RowKey 存儲結構是 Key-Value 形式，跟 Java 中的 Map 一樣，如果向同一個 Map 保存相同的 Key 的值，后保存的值會覆蓋掉之前保存的值。

排序原則：HBase 會把 RowKey 按照 ASCII 進行自然有序排序，所以反過來我們在設計 RowKey 的時候可以根據這個特點來設計完美的 RowKey，好好的利用這個特性就是排序原則。

散列原則：如果 RowKey 按照時間戳的方式遞增，不要將時間放在二進制碼的前面，建議將 RowKey 的高位作為散列字段，由程序隨機生成，低位放時間字段。

這樣將提高數據均衡分布在每個 RegionServer，以實現負載均衡的幾率。

如果沒有散列字段，首字段直接是時間信息，所有的數據都會集中在一個 RegionServer 上。

這樣在數據檢索的時候負載會集中在個別的 RegionServer 上，造成熱點問題，會降低查詢效率。

①根據 RowKey 模糊查詢

接下來直接上戰場，首先我們根據業務場景需求，肯定還是需要進行在上 T 數據中查詢部分數據的，那就是通過 RowKey 的方式進行模糊查詢。

hbase shell #首先登錄hbase 
list #查詢系統中所有數據庫表 
scan 'tablename',{STARTROW=>'rowkey1',STOPROW=>'rowkey2'} 

②根據 RowKey 范圍查詢

這里演示的是時間范圍查詢，TIMERANGE 中的值為時間戳。

scan ‘tablename’,{TIMERANGE=>[1325654785652,1436524854295]} 

更多操作下次我在給大家出一篇關于 HBase 使用的相關文章進行詳細講解。

HBase 調優

①讀性能優化

HBase 服務端優化：

• 讀請求是否均衡?
• BlockCache 設置是否合理?
• 數據本地率是不是很低?
• HFile 文件是否太多?
• Compaction 是否影響太大?

HBase 客戶端優化：

• scan 緩存是否設置合理?
• get 是否使用批量請求?
• 離線批量讀取請求是否設置禁止緩存?
• 請求是否可以顯示指定列簇或者列?

HBase 列簇優化：

• 布隆過濾器是否設置?

②寫性能優化

HBase 服務端優化：

• Region 是否太少?
• 寫入請求是否均衡?

HBase 客戶端優化：

• 是否可以使用 Bulkload 方案寫入?
• 是否需要寫入 WAL?
• WAL 是否需要同步寫入?
• Put 是否可以同步批量提交?
• Put 是否可以異步批量提交?
• 寫入 Key Value 數據是否太大?

大家可以帶著以上問題去對自己的 HBase 逐個優化。

參考資料：

• http://hbase.apache.org/

作者：劉永繼

簡介：中國科學院大學博士，中國科學院信息工程所，主要從事大數據可視化，虛擬現實與數字孿生技術研究;精通 Java，Python 等主流的技術架構，擅長從架構的角度思考及解決問題。

編輯：陶家龍

征稿：有投稿、尋求報道意向技術人請添加小編微信 gordonlonglong 

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】