如何解析Hbase原理以及基本運行方式和優(yōu)化，針對這個問題，這篇文章詳細介紹了相對應(yīng)的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

10年積累的成都做網(wǎng)站、成都網(wǎng)站設(shè)計經(jīng)驗，可以快速應(yīng)對客戶對網(wǎng)站的新想法和需求。提供各種問題對應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認識你，你也不認識我。但先網(wǎng)站制作后付款的網(wǎng)站建設(shè)流程，更有寧江免費網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

HBase是一個構(gòu)建在HDFS上的分布式列存儲系統(tǒng)；
HBase是基于Google BigTable模型開發(fā)的，典型的key/value系統(tǒng)；
HBase是Apache Hadoop生態(tài)系統(tǒng)中的重要一員，主要用于海量非結(jié)構(gòu)化數(shù)據(jù)存儲；
從邏輯上講，HBase將數(shù)據(jù)按照表、行和列進行存儲。
與hadoop一樣，Hbase目標(biāo)主要依靠橫向擴展，通過不斷增加廉價的商用服務(wù)器，來增加計算和存儲能力

:總結(jié)一點，都知道Hbase是一個基于HDFS的列數(shù)據(jù)庫對不對！

Hbase的特征：

1. BIGTABLE：所謂的大表，一個表可以有數(shù)十億行，和百萬個列。

2. 面向列：面向列（族）的存儲和權(quán)限控制，列（族）獨立檢索

3. 稀疏：空（null）列并不占用存儲空間，表可以設(shè)計的非常稀疏；

4. 數(shù)據(jù)多版本：每個單元中的數(shù)據(jù)可以有多個版本，默認情況下版本號自動分配，是單元格插入時的時間戳；（所以說，Hbase中沒有修改這一個概念，如果修改就是增加數(shù)據(jù)，只不過時間戳變了。查詢出來的數(shù)據(jù)也就變了。）

5. 數(shù)據(jù)類型單一：Hbase中的數(shù)據(jù)都是字符串，沒有類型。

注：針對字符串 我需要解釋一下：最適合使用Hbase存儲的數(shù)據(jù)是非常稀疏的數(shù)據(jù)（非結(jié)構(gòu)化或者半結(jié)構(gòu)化的數(shù)據(jù)）。Hbase之所以擅長存儲這類數(shù)據(jù)，是因為Hbase是column-oriented列導(dǎo)向的存儲機制，而我們熟知的RDBMS都是row- oriented行導(dǎo)向的存儲機制

結(jié)構(gòu)化數(shù)據(jù)：結(jié)構(gòu)化信息，我們通常接觸的數(shù)據(jù)庫所管理的信息，包括生產(chǎn)、業(yè)務(wù)、交易、客戶信息等方面的記錄

非結(jié)構(gòu)化數(shù)據(jù)：非結(jié)構(gòu)化數(shù)據(jù),包括所有格式的辦公文檔、文本、圖片、XML、HTML、各類報表、圖像和音頻/視頻信息等等

分析：在許多大型像奇藝，搜狐，騰訊視頻 優(yōu)酷視頻。他們的資源可能大部分是非結(jié)構(gòu)化數(shù)據(jù)。

Hbase存儲模型：

1. HBase的基本元素:

2. 表、行、列、單元格： 表的基本要素

3. 鍵：一般是指行的鍵，即唯一標(biāo)識某行的元素。表中的行，可以根據(jù)鍵進行排序，而對表的訪問，也通過鍵。

4. 列族：所有列族成員擁有相同的前綴，某列族的成員，需要預(yù)先定義，但也可以直接進行追加。

5. 列族成員會一起放進存儲器。而HBase面向列的存儲，是面向列族的數(shù)據(jù)存儲，數(shù)據(jù)存儲與調(diào)優(yōu)都在這個層次，HBase表與RDBMS中表類似，行是排序的，客戶端可以把列添加到列族中去。

6. 單元格cell： 單元格中存放的是不可分割的字節(jié)數(shù)組。并且每個單元格擁有版本信息。HBase的是按版本信息倒序排列。

7. 區(qū)域region：將表水平劃分，是HBase集群分布數(shù)據(jù)的最小單位。在線的所有區(qū)域就構(gòu)成了表的內(nèi)容。

    

8.  

Hbase的存儲原理：

自動分區(qū)：（跟hadoopHDFS很相似）

1. Hbase中一個表被劃分了很多個Region，它可以動態(tài)擴展，保證整個系統(tǒng)的負載均衡。

2. 讓一個Region達了上限的時候，就會自動拆分二個相等的Region。（原理就是Hbase中的split和compaction）

3. 每個Region由一個RegionServer管理，一個RegionServer可以管理多個Region。

4. RgionServer管理100-1000個region比較合適。 Region的大小一般在1-20GB

表設(shè)計優(yōu)化：

HBase 是一個高可靠性、高性能、面向列、可伸縮的分布式數(shù)據(jù)庫，但是當(dāng)并發(fā)量過高或者已有數(shù)據(jù)量很大時，讀寫性能會下降。我們可以采用如下方式逐步提升 HBase 的檢索速度。

預(yù)先分區(qū)

默認情況下，在創(chuàng)建 HBase 表的時候會自動創(chuàng)建一個 Region 分區(qū)，當(dāng)導(dǎo)入數(shù)據(jù)的時候，所有的HBase 客戶端都向這一個 Region 寫數(shù)據(jù)，直到這個 Region 足夠大了才進行切分。一種可以加快批量寫入速度的方法是通過預(yù)先創(chuàng)建一些空的 Regions，這樣當(dāng)數(shù)據(jù)寫入 HBase 時，會按照Region 分區(qū)情況，在集群內(nèi)做數(shù)據(jù)的負載均衡。

Rowkey 優(yōu)化

HBase 中 Rowkey 是按照字典序存儲，因此，設(shè)計 Rowkey 時，要充分利用排序特點，將經(jīng)常一起讀取的數(shù)據(jù)存儲到一塊，將最近可能會被訪問的數(shù)據(jù)放在一塊。

此外，Rowkey 若是遞增的生成，建議不要使用正序直接寫入 Rowkey，而是采用 reverse 的方式反轉(zhuǎn) Rowkey，使得 Rowkey 大致均衡分布，這樣設(shè)計有個好處是能將 RegionServer 的負載均衡，否則容易產(chǎn)生所有新數(shù)據(jù)都在一個 RegionServer 上堆積的現(xiàn)象，這一點還可以結(jié)合 table的預(yù)切分一起設(shè)計。

減少ColumnFamily 數(shù)量

不要在一張表里定義太多的 ColumnFamily。目前 Hbase 并不能很好的處理超過 2~3 個 ColumnFamily 的表。因為某個 ColumnFamily 在 flush 的時候，它鄰近的 ColumnFamily 也會因關(guān)聯(lián)效應(yīng)被觸發(fā) flush，最終導(dǎo)致系統(tǒng)產(chǎn)生更多的 I/O。

緩存策略 (setCaching)

創(chuàng)建表的時候，可以通過 HColumnDescriptor.setInMemory(true) 將表放到 RegionServer 的緩存中，保證在讀取的時候被 cache 命中。

設(shè)置存儲生命期

創(chuàng)建表的時候，可以通過 HColumnDescriptor.setTimeToLive(int timeToLive) 設(shè)置表中數(shù)據(jù)的存儲生命期，過期數(shù)據(jù)將自動被刪除。

硬盤配置

每臺 RegionServer 管理 10~1000 個 Regions，每個 Region 在 1~2G，則每臺 Server 最少要10G，最大要 1000*2G=2TB，考慮 3 備份，則要 6TB。方案一是用 3 塊 2TB 硬盤，二是用 12塊 500G 硬盤，帶寬足夠時，后者能提供更大的吞吐率，更細粒度的冗余備份，更快速的單盤故障恢復(fù)。

分配合適的內(nèi)存給 RegionServer 服務(wù)

在不影響其他服務(wù)的情況下，越大越好。例如在 HBase 的 conf 目錄下的 hbase-env.sh 的最后添加 export HBASE_REGIONSERVER_OPTS="-Xmx16000m $HBASE_REGIONSERVER_OPTS”

其中 16000m 為分配給 RegionServer 的內(nèi)存大小。

寫數(shù)據(jù)的備份數(shù)

備份數(shù)與讀性能成正比，與寫性能成反比，且備份數(shù)影響高可用性。有兩種配置方式，一種是將hdfs-site.xml 拷貝到 hbase 的 conf 目錄下，然后在其中添加或修改配置項 dfs.replication 的值為要設(shè)置的備份數(shù)，這種修改對所有的 HBase 用戶表都生效，另外一種方式，是改寫 HBase 代碼，讓 HBase 支持針對列族設(shè)置備份數(shù)，在創(chuàng)建表時，設(shè)置列族備份數(shù)，默認為 3，此種備份數(shù)只對設(shè)置的列族生效。

WAL（預(yù)寫日志）

可設(shè)置開關(guān)，表示 HBase 在寫數(shù)據(jù)前用不用先寫日志，默認是打開，關(guān)掉會提高性能，但是如果系統(tǒng)出現(xiàn)故障 (負責(zé)插入的 RegionServer 掛掉)，數(shù)據(jù)可能會丟失。配置 WAL 在調(diào)用 Java API寫入時，設(shè)置 Put 實例的 WAL，調(diào)用 Put.setWriteToWAL(boolean)。

批量寫

HBase 的 Put 支持單條插入，也支持批量插入，一般來說批量寫更快，節(jié)省來回的網(wǎng)絡(luò)開銷。在客戶端調(diào)用 Java API 時，先將批量的 Put 放入一個 Put 列表，然后調(diào)用 HTable 的 Put(Put 列表) 函數(shù)來批量寫。

客戶端一次從服務(wù)器拉取的數(shù)量

通過配置一次拉去的較大的數(shù)據(jù)量可以減少客戶端獲取數(shù)據(jù)的時間，但是它會占用客戶端內(nèi)存。有三個地方可進行配置：

1）在 HBase 的 conf 配置文件中進行配置 hbase.client.scanner.caching；

2）通過調(diào)用 HTable.setScannerCaching(int scannerCaching) 進行配置；

3）通過調(diào)用 Scan.setCaching(int caching) 進行配置。三者的優(yōu)先級越來越高。

RegionServer 的請求處理 IO 線程數(shù)

較少的 IO 線程適用于處理單次請求內(nèi)存消耗較高的 Big Put 場景 (大容量單次 Put 或設(shè)置了較大cache 的 Scan，均屬于 Big Put) 或 ReigonServer 的內(nèi)存比較緊張的場景。

較多的 IO 線程，適用于單次請求內(nèi)存消耗低，TPS 要求 (每秒事務(wù)處理量 (TransactionPerSecond)) 非常高的場景。設(shè)置該值的時候，以監(jiān)控內(nèi)存為主要參考。

在 hbase-site.xml 配置文件中配置項為 hbase.regionserver.handler.count。

Region 大小設(shè)置

配置項為 hbase.hregion.max.filesize，所屬配置文件為 hbase-site.xml.，默認大小 256M。

在當(dāng)前 ReigonServer 上單個 Reigon 的最大存儲空間，單個 Region 超過該值時，這個 Region會被自動 split 成更小的 Region。小 Region 對 split 和 compaction 友好，因為拆分 Region 或compact 小 Region 里的 StoreFile 速度很快，內(nèi)存占用低。缺點是 split 和 compaction 會很頻繁，特別是數(shù)量較多的小 Region 不停地 split, compaction，會導(dǎo)致集群響應(yīng)時間波動很大，Region 數(shù)量太多不僅給管理上帶來麻煩，甚至?xí)l(fā)一些 Hbase 的 bug。一般 512M 以下的都算小 Region。大 Region 則不太適合經(jīng)常 split 和 compaction，因為做一次 compact 和 split 會產(chǎn)生較長時間的停頓，對應(yīng)用的讀寫性能沖擊非常大。

此外，大 Region 意味著較大的 StoreFile，compaction 時對內(nèi)存也是一個挑戰(zhàn)。如果你的應(yīng)用場景中，某個時間點的訪問量較低，那么在此時做 compact 和 split，既能順利完成 split 和 compaction，又能保證絕大多數(shù)時間平穩(wěn)的讀寫性能。compaction 是無法避免的，split 可以從自動調(diào)整為手動。只要通過將這個參數(shù)值調(diào)大到某個很難達到的值，比如 100G，就可以間接禁用自動 split(RegionServer 不會對未到達 100G 的 Region 做 split)。再配合 RegionSplitter 這個工具，在需要 split 時，手動 split。手動 split 在靈活性和穩(wěn)定性上比起自動 split 要高很多，而且管理成本增加不多，比較推薦 online 實時系統(tǒng)使用。內(nèi)存方面，小 Region 在設(shè)置 memstore 的大小值上比較靈活，大 Region 則過大過小都不行，過大會導(dǎo)致 flush 時 app 的 IO wait 增高，過小則因 StoreFile 過多影響讀性能。

關(guān)于如何解析Hbase原理以及基本運行方式和優(yōu)化問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關(guān)知識。