為什么BATJ公司要用HBase？
原創(chuàng)【51CTO.com原創(chuàng)稿件】 Apache HBase 是 Hadoop 的大數(shù)據(jù)存儲數(shù)據(jù)庫，一個分布式、可伸縮的大數(shù)據(jù)存儲，是依賴 Hadoop。
圖片來自 Pexels
HBase 該技術(shù)來源于 Fay Chang 所撰寫的 Google 論文“Bigtable：一個結(jié)構(gòu)化數(shù)據(jù)的分布式存儲系統(tǒng)”。
就像 Bigtable 利用了 Google 文件系統(tǒng)(File System)所提供的分布式數(shù)據(jù)存儲一樣，HBase 在 Hadoop 之上提供了類似于 Bigtable 的能力。
BATJ 公司為什么用 HBase 能存儲海量的數(shù)據(jù)?
- 因為 HBase 是在 HDFS 的基礎(chǔ)之上構(gòu)建的，HDFS 是分布式文件系統(tǒng)。
- Hbase 設(shè)計上屬于列式存儲，在存儲上將業(yè)務(wù)的數(shù)據(jù)按照水平分割的模式來劃分，因此在查詢與插入的時候比較聚焦。
- HBase 不同于一般的關(guān)系數(shù)據(jù)庫，它是一個適合于非結(jié)構(gòu)化數(shù)據(jù)存儲的數(shù)據(jù)庫，特別是 HBase 基于列的而不是基于行的模式存儲
為什么要用 HBase
①分布式存儲引擎分類
分布式存儲引擎大概分類如下：
- 分布式搜索(Elasticsearch)
- 分布式文件系統(tǒng)(HDFS)
- 分布式消息隊列(Kafka)
- 緩存數(shù)據(jù)庫(Redis)
- 非關(guān)系型分布式數(shù)據(jù)庫(Hbase\Mongodb\Cloudant)
- 等等...
②存儲引擎的存儲方式
存儲引擎的存儲方式如下：
- Redis 有 AOF 和 RDB
- Elasticsearch 會把數(shù)據(jù)寫到 translog 然后結(jié)合 FileSystemCache 將數(shù)據(jù)刷到磁盤中
- Kafka 本身就是將數(shù)據(jù)順序?qū)懙酱疟P....
這些中間件都能夠?qū)崿F(xiàn)持久化(比如 HDFS 和 MySQL 我們本身就用來存儲數(shù)據(jù)的)，那用 HBase 干啥呢?
③各種存儲引擎優(yōu)缺點
HDFS 可以保存海量數(shù)據(jù)，容錯性高，適合批處理，適合保存大量數(shù)據(jù)，可以流式數(shù)據(jù)訪問，對于服務(wù)器的要求也不高，但是他也有一些不足如，不適合低延時數(shù)據(jù)訪問。
比如毫秒級的存儲數(shù)據(jù)，是做不到的，也沒辦法高效的對大量小文件進行保存處理，而且一個文件只能有一個線程寫入，不允許多個線程同時寫入，也不支持文件的隨機修改。
MySQL 是我們?nèi)粘Ｖ杏玫谋容^多的關(guān)系型數(shù)據(jù)庫了，但是大家都知道 MySQL，他是單機的。
單機 MySQL 他最大的容量，完全取決于服務(wù)器的硬盤容量的大小。其最致命的弱點就是當(dāng)有大量數(shù)據(jù)需要存儲時，MySQL 很難扛得住。
Elasticsearch 大家都知道他是一個分布式搜索引擎，在搜索效率上還是比較快的。
因為 Elasticsearch 基于分布式所以理論上也是可以保存大量的數(shù)據(jù)的，我們也可以根據(jù)索引來取出來，那這就是我們心目中最完美的存儲方式了嗎?
不，他不是，因為如果我們存儲的數(shù)據(jù)沒有經(jīng)常需要查詢的需求，其實放到 Elasticsearch 就是一種浪費，因為數(shù)據(jù)在寫入 Elasticsearch 時需要進行分詞，從而大量消耗資源，造成沒必要的浪費。
Redis 是近幾年最常用的緩存數(shù)據(jù)庫，讀與寫的操作都在內(nèi)存中進行，其速度響應(yīng)非常快，AOF/RDB 保存的相關(guān)數(shù)據(jù)全會加載到我們機器的內(nèi)存中，從而導(dǎo)致 Redis 并不適合保存大量的數(shù)據(jù)，畢竟內(nèi)存還是相對有限。
Kafka 在我們項目工作中主要用來處理消息的解耦于異步削峰，當(dāng)數(shù)據(jù)到達 Kafka，此時就會將數(shù)據(jù)持久化到服務(wù)器硬盤中，且很方便的擴展因為他是分布式的，按照這個邏輯 Kafka 是可以存儲大量數(shù)據(jù)。
但是 Kafka 持久化了的數(shù)據(jù)，最常見的用法就是直接重新設(shè)置 offset 進行操作。
④Hbase 的使用場景
Hbase 適合需對數(shù)據(jù)進行隨機讀操作或者隨機寫操作、大數(shù)據(jù)上高并發(fā)操作，比如每秒對 PB 級數(shù)據(jù)進行上千次操作以及讀寫訪問均是非常簡單的操作。
淘寶指數(shù)是 Hbase 在淘寶的一個典型應(yīng)用。交易歷史紀錄查詢很適合用 Hbase 作為底層數(shù)據(jù)庫。
入門 HBase
①HBase 特性
Hbase 作為一種 NoSQL 數(shù)據(jù)庫，而這就說明他不是傳統(tǒng)的 RDBMS 數(shù)據(jù)庫，且 SQL 語句也是不支持的。
對于 Hbase 是一種分布式存儲的數(shù)據(jù)庫，在技術(shù)層面來講，它是屬于分布式存儲，因為缺少很多 RDBMS 數(shù)據(jù)庫的特性。
那 Hbase 有什么特點呢?如下：
大，他容量巨大，HBase 的單表可以有百億行、百萬列，可以在橫向和縱向兩個維度插入數(shù)據(jù)，具有很大的彈性。
稀疏性，這主要體現(xiàn)在 Hbase 針對列有著很高的靈活性，比如對于為 NULL 的列中，是不會占用存儲空間的，所以表可以設(shè)計的很稀疏。
易擴展，因為前面我也講到過 HBase 是工作在 HDFS 之上的，所以自然是支持分布式表，同時也繼承了 HDFS 的可擴展性。
而且 HBase 的擴展是橫向擴展的，所謂的橫向擴展是指在擴展的時候不需要提高服務(wù)器性能，只需要添加服務(wù)器到現(xiàn)有的集群即可。
高并發(fā)，如果項目使用 Hbase 的架構(gòu)，那么使用的 PC 都可以很便宜，因此高 IO 也是常事。
而我所說的高并發(fā)，主要是他和其他 NoSQL 一樣，Hbase 不支持復(fù)雜的 SQL 語句，這就給性能優(yōu)化帶來更多可能，并且主要是在內(nèi)存中工作，支持大并發(fā)應(yīng)該是沒問題的。
還有別忘了，HBase 是天然支持分布式的，所以還可以利用集群等方法提高并發(fā)量。
高可用，還是因為 HBase 是運行在 HDFS 上的，HDFS 的多副本存儲，類似于 MySQL 主備容災(zāi)，他可以在岀現(xiàn)故障時自行恢復(fù)，同時 HBase 還有更多的策略如：Replication，WAL 等。
面向列，這個與我們常用的 MySQL 等關(guān)系型數(shù)據(jù)庫不同，HBase 是面向列的存儲控制的。
簡單來說就是每個列他都是是單獨存儲的，而且支持直接對列來進行查詢，下面這張圖可以簡單來理解下什么是對列的操作。
從圖上來理解，看下下面的行存儲于列存儲其中行存儲是保存在一塊的，而列存儲中的數(shù)據(jù)是分割的。
由上圖得知行存儲更適合插入與更新，而查詢操作時需要讀取其中所有的數(shù)據(jù)，此時 HBase 列存儲則只需要讀取相關(guān)列即可，從而可以大幅降低系統(tǒng) I/O 吞吐量，達到快速讀取的目的。
②什么情況更適合使用 Hbase
首先 Hbase 不是萬能的，他也有不適合的場景，有哪些不適合場景呢?
這主要也是根據(jù)其特點來說的，首先一點就是數(shù)據(jù)量要大，如果你的數(shù)據(jù)只有區(qū)區(qū)幾百萬條或者更少的數(shù)據(jù)量，那么關(guān)系型數(shù)據(jù)庫可能更適合你。
因為數(shù)據(jù)量不大的話，根本體現(xiàn)不出 HBase 的優(yōu)勢，反而會成為累贅，因為有大量的機器空閑，浪費資源。
再一個就是你對于列查詢的使用不是那么高，且你也不需要輔助索引，靜態(tài)類型的列等 HBase 的特性，在現(xiàn)有項目中使用關(guān)系型數(shù)據(jù)庫已經(jīng)可以滿足其需求，則你完全沒必要為了技術(shù)而去使用。
如果非要使用對于以往的項目你還需要重新去設(shè)計重構(gòu)等，帶來不必要的麻煩。
最后雖然 Hbase 在單機環(huán)境也能運行，但是最好請在開發(fā)環(huán)境的時候使用。
③HBase 的 Key-Value
HBase 其實就與 Redis 一樣是 Key-Value 的數(shù)據(jù)庫，那在 HBase 里邊，Key 是什么?Value 是什么?
首先 KeyValue 的概念設(shè)計源自一片論文為"The log-structured merge-tree(LSM-Tree)"。
其中的每一行，每一列的數(shù)據(jù)，都被獨立包裝成特定結(jié)構(gòu)即 KeyValue，而 KeyValue 還包含了很多自我描述信息從而會導(dǎo)致數(shù)據(jù)膨脹 。
目前市面上所有項目主要數(shù)據(jù)結(jié)構(gòu)有：
- 結(jié)構(gòu)化數(shù)據(jù)
- 半結(jié)構(gòu)化數(shù)據(jù)
- 非結(jié)構(gòu)化數(shù)據(jù)
由于 HBase 的稀疏性，導(dǎo)致其對于非結(jié)構(gòu)化的數(shù)據(jù)存儲有著天然的優(yōu)勢，而在我們?nèi)粘ｍ椖恐校?關(guān)系型數(shù)據(jù)也就是結(jié)構(gòu)化數(shù)據(jù)是經(jīng)常使用到的 。
由于 HBase 目前只能提供基于 RowKey 的單維度索，在我們?nèi)粘ｍ椖恐羞€是有些吃力。
還需要基于 HBase 添加一些特殊功能，如：
- GeoMesa 時空數(shù)據(jù)存儲
- JanusGraph 圖數(shù)據(jù)存儲
- OpenTSDB 時序數(shù)據(jù)存儲
既然如此，不如專業(yè)的事情交給專業(yè)的的去做，既然 MySQL，Oracle，MSSQL 這些關(guān)系型數(shù)據(jù)庫這么擅長處理結(jié)構(gòu)化數(shù)據(jù)，那就讓他們來處理好了。
他們既然不擅長處理海量非結(jié)構(gòu)化數(shù)據(jù)，那就上 HBase，所以我的理解 HBase 不是萬能的，他只是相對于傳統(tǒng)關(guān)系型數(shù)據(jù)庫的一種補充。
④HBase 架構(gòu)
HBase 架構(gòu)如上圖：
- Zookeeper，主要作用是分布式協(xié)調(diào)。
- RegionServer，作為數(shù)據(jù)節(jié)點，用于存儲數(shù)據(jù)，也會把自己的信息寫到 ZooKeeper 中。
- HDFS，是在這里主要作為 HBase 的基礎(chǔ)，是一個 分布式文件系統(tǒng)，為 HBase 提供服務(wù)。
- Master，主要負責(zé)管理所有的 RegionServer，管理所有的 Region 到 RegionServer 的分配，且自身也可以作為一個 RegionServer 提供服務(wù)。
其大概流程就是：
- client 請求到 Zookeeper。
- Zookeeper 返回 HRegionServer 地址給 client。
- 當(dāng) client 獲取到 Zookeeper 返回的地址就去請求 HRegionServer。
- HRegionServer 讀寫數(shù)據(jù)后再返回給 client。
⑤HMaster 大作用
看上面的流程我好像沒有提到 HMaster，那 HMaster 是不是沒啥用?那他主要是做什么的呢?
其實他的作用是不能被忽略的有：
- 負責(zé) Region server 分布式管理與負載均衡
- 為 Region server 分配 region
- 在 HRegion 分裂后，負責(zé)新 HRegion 的分配
- 將 HDFS 上的垃圾文件回收
- 處理 schema 更新請求
由此可以看來 HMaster 相當(dāng)于指揮家，統(tǒng)籌大局，非常重要!
RowKey 的設(shè)計
RowKey 在查詢和保存方面有著很重要的作用，HBase 中如果設(shè)計好一個 RowKey 將會影響到其中數(shù)據(jù)的分布，與我們的查詢速度。
由此得知設(shè)計好一個優(yōu)秀的 RowKey 是非常重要的，那么這么重要的 RowKey 我們?nèi)绾蝸碓O(shè)計呢?
首先要遵從以下幾個原則：
長度原則：最短越好，最短越好，最短越好，重要的事情說三遍，最大不能超過 64K。如果太長主要影響有兩點，
首先特別影響 HFile 的存儲效果。其次 MemStore 將緩存部分數(shù)據(jù)到內(nèi)存，如果 RowKey 字段過長，內(nèi)存的有效利用率就會降低，系統(tǒng)不能緩存更多的數(shù)據(jù)，這樣會降低檢索效率。
總結(jié)：保存慢，查詢慢!
唯一原則：這個應(yīng)該很好理解，RowKey 存儲結(jié)構(gòu)是 Key-Value 形式，跟 Java 中的 Map 一樣，如果向同一個 Map 保存相同的 Key 的值，后保存的值會覆蓋掉之前保存的值。
排序原則：HBase 會把 RowKey 按照 ASCII 進行自然有序排序，所以反過來我們在設(shè)計 RowKey 的時候可以根據(jù)這個特點來設(shè)計完美的 RowKey，好好的利用這個特性就是排序原則。
散列原則：如果 RowKey 按照時間戳的方式遞增，不要將時間放在二進制碼的前面，建議將 RowKey 的高位作為散列字段，由程序隨機生成，低位放時間字段。
這樣將提高數(shù)據(jù)均衡分布在每個 RegionServer，以實現(xiàn)負載均衡的幾率。
如果沒有散列字段，首字段直接是時間信息，所有的數(shù)據(jù)都會集中在一個 RegionServer 上。
這樣在數(shù)據(jù)檢索的時候負載會集中在個別的 RegionServer 上，造成熱點問題，會降低查詢效率。
①根據(jù) RowKey 模糊查詢
接下來直接上戰(zhàn)場，首先我們根據(jù)業(yè)務(wù)場景需求，肯定還是需要進行在上 T 數(shù)據(jù)中查詢部分數(shù)據(jù)的，那就是通過 RowKey 的方式進行模糊查詢。
- hbase shell #首先登錄hbase
- list #查詢系統(tǒng)中所有數(shù)據(jù)庫表
- scan 'tablename',{STARTROW=>'rowkey1',STOPROW=>'rowkey2'}
②根據(jù) RowKey 范圍查詢
這里演示的是時間范圍查詢，TIMERANGE 中的值為時間戳。
- scan ‘tablename’,{TIMERANGE=>[1325654785652,1436524854295]}
更多操作下次我在給大家出一篇關(guān)于 HBase 使用的相關(guān)文章進行詳細講解。
HBase 調(diào)優(yōu)
①讀性能優(yōu)化
HBase 服務(wù)端優(yōu)化：
- 讀請求是否均衡?
- BlockCache 設(shè)置是否合理?
- 數(shù)據(jù)本地率是不是很低?
- HFile 文件是否太多?
- Compaction 是否影響太大?
HBase 客戶端優(yōu)化：
- scan 緩存是否設(shè)置合理?
- get 是否使用批量請求?
- 離線批量讀取請求是否設(shè)置禁止緩存?
- 請求是否可以顯示指定列簇或者列?
HBase 列簇優(yōu)化：
- 布隆過濾器是否設(shè)置?
②寫性能優(yōu)化
HBase 服務(wù)端優(yōu)化：
- Region 是否太少?
- 寫入請求是否均衡?
HBase 客戶端優(yōu)化：
- 是否可以使用 Bulkload 方案寫入?
- 是否需要寫入 WAL?
- WAL 是否需要同步寫入?
- Put 是否可以同步批量提交?
- Put 是否可以異步批量提交?
- 寫入 Key Value 數(shù)據(jù)是否太大?
大家可以帶著以上問題去對自己的 HBase 逐個優(yōu)化。
參考資料：
- http://hbase.apache.org/
作者：劉永繼
簡介：中國科學(xué)院大學(xué)博士，中國科學(xué)院信息工程所，主要從事大數(shù)據(jù)可視化，虛擬現(xiàn)實與數(shù)字孿生技術(shù)研究;精通 Java，Python 等主流的技術(shù)架構(gòu)，擅長從架構(gòu)的角度思考及解決問題。
編輯：陶家龍
征稿：有投稿、尋求報道意向技術(shù)人請?zhí)砑有【幬⑿?gordonlonglong
【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】
