HBase 詳細概述

HBase簡介

HBase的發展史

2006年末由PowerSet 的Chad Walters和Jim Kellerman 發起，2008年成爲Apache Hadoop的一個子項目。現已做爲產品在多家企業被使用，如：

1. WorldLingo
2. Streamy.com
3. OpenPlaces
4. Yahoo!
5. Adobe
6. 淘寶
7. Facebook
8. Twitter
9. Trend Micro

Hbase是什麼

HBase是一種構建在HDFS之上的分佈式、面向列的存儲系統。在須要實時讀寫、隨機訪問超大規模數據集時，可使用HBase。

儘管已經有許多數據存儲和訪問的策略和實現方法，但事實上大多數解決方案，特別是一些關係類型的，在構建時並無考慮超大規模和分佈式的特色。許多商家經過複製和分區的方法來擴充數據庫使其突破單個節點的界限，但這些功能一般都是過後增長的，安裝和維護都和複雜。同時，也會影響RDBMS的特定功能，例如聯接、複雜的查詢、觸發器、視圖和外鍵約束這些操做在大型的RDBMS上的代價至關高，甚至根本沒法實現。

HBase從另外一個角度處理伸縮性問題。它經過線性方式從下到上增長節點來進行擴展。HBase不是關係型數據庫，也不支持SQL，可是它有本身的特長，這是RDBMS不能處理的，HBase巧妙地將大而稀疏的表放在商用的服務器集羣上。

HBase 是Google Bigtable 的開源實現，與Google Bigtable 利用GFS做爲其文件存儲系統相似， HBase 利用Hadoop HDFS 做爲其文件存儲系統；Google 運行MapReduce 來處理Bigtable中的海量數據， HBase 一樣利用Hadoop MapReduce來處理HBase中的海量數據；Google Bigtable 利用Chubby做爲協同服務， HBase 利用Zookeeper做爲對應。

HBase的特色

1. 大：一個表能夠有上億行，上百萬列。
2. 面向列：面向列表（簇）的存儲和權限控制，列（簇）獨立檢索。
3. 稀疏：對於爲空（NULL）的列，並不佔用存儲空間，所以，表能夠設計的很是稀疏。
4. 無模式：每一行都有一個能夠排序的主鍵和任意多的列，列能夠根據須要動態增長，同一張表中不一樣的行能夠有大相徑庭的列。
5. 數據多版本：每一個單元中的數據能夠有多個版本，默認狀況下，版本號自動分配，版本號就是單元格插入時的時間戳。
6. 數據類型單一：HBase中的數據都是字符串，沒有類型。

HBase的高併發和實時處理數據

Hadoop是一個高容錯、高延時的分佈式文件系統和高併發的批處理系統，不適用於提供實時計算；HBase是能夠提供實時計算的分佈式數據庫，數據被保存在HDFS分佈式文件系統上，由HDFS保證期高容錯性，可是再生產環境中，HBase是如何基於hadoop提供實時性呢？ HBase上的數據是以StoreFile(HFile)二進制流的形式存儲在HDFS上block塊兒中；可是HDFS並不知道的hbase存的是什麼，它只把存儲文件是爲二進制文件，也就是說，hbase的存儲數據對於HDFS文件系統是透明的。下面是HBase文件在HDFS上的存儲示意圖。

HBase HRegion servers集羣中的全部的region的數據在服務器啓動時都是被打開的，而且在內衝初始化一些memstore，相應的這就在必定程度上加快系統響 應；而Hadoop中的block中的數據文件默認是關閉的，只有在須要的時候纔打開，處理完數據後就關閉，這在必定程度上就增長了響應時間。

從根本上說，HBase能提供實時計算服務主要緣由是由其架構和底層的數據結構決定的，即由LSM-Tree + HTable(region分區) + Cache決定——客戶端能夠直接定位到要查數據所在的HRegion server服務器，而後直接在服務器的一個region上查找要匹配的數據，而且這些數據部分是通過cache緩存的。具體查詢流程以下圖所示：

具體數據訪問流程以下：

1. Client會經過內部緩存的相關的-ROOT-中的信息和.META.中的信息直接鏈接與請求數據匹配的HRegion server；
2. 而後直接定位到該服務器上與客戶請求對應的Region，客戶請求首先會查詢該Region在內存中的緩存——Memstore(Memstore是一個按key排序的樹形結構的緩衝區)；
3. 若是在Memstore中查到結果則直接將結果返回給Client；
4. 在Memstore中沒有查到匹配的數據，接下來會讀已持久化的StoreFile文件中的數據。前面的章節已經講過，StoreFile也是按 key排序的樹形結構的文件——而且是特別爲範圍查詢或block查詢優化過的，；另外HBase讀取磁盤文件是按其基本I/O單元(即 HBase Block)讀數據的。

具體就是過程就是：

若是在BlockCache中能查到要造的數據則這屆返回結果，不然就讀去相應的StoreFile文件中讀取一block的數據，若是尚未讀到要查的 數據，就將該數據block放到HRegion Server的blockcache中，而後接着讀下一block塊兒的數據，一直到這樣循環的block數據直到找到要請求的數據並返回結果；若是將該 Region中的數據都沒有查到要找的數據，最後接直接返回null，表示沒有找的匹配的數據。固然blockcache會在其大小大於一的閥值（heapsize * hfile.block.cache.size * 0.85）後啓動基於LRU算法的淘汰機制，將最老最不經常使用的block刪除。

HBase數據模型

HBase 以表的形式存儲數據。表由行和列組成。列劃分爲若干個列族（row family），以下圖所示。

HBase的邏輯數據模型：

HBase的物理數據模型（實際存儲的數據模型）：

邏輯數據模型中空白cell在物理上是不存儲的，由於根本沒有必要存儲，所以若一個請求爲要獲取t8時間的contents:html，他的結果就是空。類似的，若請求爲獲取t9時間的anchor:my.look.ca，結果也是空。可是，若是不指明時間，將會返回最新時間的行，每一個最新的都會返回

Row Key

與 NoSQL 數據庫同樣，Row Key 是用來檢索記錄的主鍵。訪問 HBase table 中的行，只有三種方式：

1)經過單個 Row Key 訪問。

2)經過 Row Key 的 range 全表掃描。

3)Row Key 可使任意字符串（最大長度是64KB，實際應用中長度通常爲 10 ~ 100bytes），在HBase 內部，Row Key 保存爲字節數組。

在存儲時，數據按照* Row Key 的字典序（byte order）排序存儲*。設計 Key 時，要充分排序存儲這個特性，將常常一塊兒讀取的行存儲到一塊兒（位置相關性）。

注意 字典序對 int 排序的結果是 1，10,100,11,12,13,14,15,16,17,18,19,20,21，…， 9，91,92,93,94,95,96,97,98,99。要保存整形的天然序，Row Key 必須用 0 進行左填充。

行的一次讀寫是原子操做（不論一次讀寫多少列）。這個設計決策可以使用戶很容易理解程序在對同一個行進行併發更新操做時的行爲。

列族

HBase 表中的每一個列都歸屬於某個列族。列族是表的 Schema 的一部分（而列不是），必須在使用表以前定義。列名都以列族做爲前綴，例如 courses:history、courses:math 都屬於 courses 這個列族。

訪問控制、磁盤和內存的使用統計都是在列族層面進行的。在實際應用中，列族上的控制權限能幫助咱們管理不一樣類型的應用， 例如，容許一些應用能夠添加新的基本數據、一些應用能夠讀取基本數據並建立繼承的列族、 
一些應用則只容許瀏覽數據（甚至可能由於隱私的緣由不能瀏覽全部數據）。

時間戳

HBase 中經過 Row 和 Columns 肯定的一個存儲單元稱爲 Cell。每一個 Cell 都保存着同一份數據的多個版本。 版本經過時間戳來索引，時間戳的類型是 64 位整型。時間戳能夠由HBase（在數據寫入時自動）賦值， 
此時時間戳是精確到毫秒的當前系統時間。時間戳也 能夠由客戶顯示賦值。若是應用程序要避免數據版本衝突，就必須本身生成具備惟一性的時間戳。每一個 Cell 中，不一樣版本的數據按照時間倒序排序，即最新的數據排在最前面。

爲了不數據存在過多版本形成的管理（包括存儲和索引）負擔，HBase 提供了兩種數據版本回收方式。 一是保存數據的最後 n 個版本，二是保存最近一段時間內的版本（好比最近七天）。用戶能夠針對每一個列族進行設置。

Cell

Cell 是由 {row key，column(=< family> + < label>)，version} 惟一肯定的單元。Cell 中的數據是沒有類型的，所有是字節碼形式存儲。

HBase物理存儲

Table 在行的方向上分割爲多個HRegion，每一個HRegion分散在不一樣的RegionServer中。

每一個HRegion由多個Store構成，每一個Store由一個memStore和0或多個StoreFile組成，每一個Store保存一個Columns Family

 

HBase系統架構

HBase架構圖以下：

從HBase的架構圖上能夠看出，HBase中的組件包括Client、Zookeeper、HMaster、HRegionServer、HRegion、Store、MemStore、StoreFile、HFile、HLog等，接下來介紹他們的做用。

HBase中的每張表都經過行鍵按照必定的範圍被分割成多個子表（HRegion），默認一個HRegion超過256M就要被分割成兩個，這個過程由HRegionServer管理，而HRegion的分配由HMaster管理。

Client

包含訪問HBase的接口，並維護cache來加快對HBase的訪問。

Zookeeper的做用

HBase依賴Zookeeper，默認狀況下HBase管理Zookeeper實例(啓動或關閉Zookeeper),Master與RegionServers啓動時會向Zookeeper註冊。

Zookeeper的做用：

• 保證任什麼時候候，集羣中只有一個master
• 存儲全部Region的尋址入口
• 實時監控Region server的上線和下線信息。並實時通知給master
• 存儲HBase的schema和table元數據

HMaster的做用

1. 爲Region server分配region
2. 負責Region server的負載均衡
3. 發現失效的Region server並從新分配其上的region。
4. HDFS上的垃圾文件回收。
5. 處理schema更新請求。

HRegionServer的做用

1. 維護master分配給他的region，處理對這些region的io請求。
2. 負責切分正在運行過程當中變的過大的region。

注意：client訪問hbase上的數據時不須要master的參與，由於數據尋址訪問zookeeper和region server，而數據讀寫訪問region server。master僅僅維護table和region的元數據信息，而table的元數據信息保存在zookeeper上，所以master負載很低。

HRegion

table在行的方向上分隔爲多個Region。Region是HBase中分佈式存儲和負載均衡的最小單元，即不一樣的region能夠分別在不一樣的Region Server上，但同一個Region是不會拆分到多個server上。

Region按大小分隔，每一個表通常是隻有一個region。隨着數據不斷插入表，region不斷增大，當region的某個列族達到一個閾值（默認256M）時就會分紅兩個新的region。

每一個region由如下信息標識：

1. < 表名,startRowkey,建立時間>
2. 由目錄表(-ROOT-和.META.)記錄該region的endRowkey

Region被分配給哪一個Region Server是徹底動態的，因此須要機制來定位Region具體在哪一個region server。 
下面咱們來看看Region是如何被定位的。

HRegion定位

1. 經過zk裏的文件/hbase/rs獲得-ROOT-表的位置。-ROOT-表只有一個region。
2. 經過-ROOT-表查找.META.表的第一個表中相應的region的位置。其實-ROOT-表是.META.表的第一個region；.META.表中的每個region 
   在-ROOT-表中都是一行記錄。
3. 經過.META.表找到所要的用戶表region的位置。用戶表中的每一個region在.META.表中都是一行記錄。

-ROOT-表永遠不會被分隔爲多個region，保證了最多須要三次跳轉，就能定位到任意的region。client會將查詢的位置 信息保存緩存起來，緩存不會主動失效，所以若是client上的緩存所有失效，則須要進行6次網絡來回，才能定位到正確的region，其中三次用來發現 緩存失效，另外三次用來獲取位置信息。

提示：

-ROOT-表：表包含.META.表所在的region列表，該表只有一個Region;Zookeeper中記錄了-ROOT-表的location

.META.表：表包含全部的用戶空間region列表，以及Region Server的服務器地址

Store

每個region由一個或多個store組成，至少是一個store，hbase會把一塊兒訪問的數據放在一個store裏面，即爲每一個 ColumnFamily建一個store，若是有幾個ColumnFamily，也就有幾個Store。一個Store由一個memStore和0或者 多個StoreFile組成。 HBase以store的大小來判斷是否須要切分region

MemStore

memStore 是放在內存裏的。保存修改的數據即keyValues。當memStore的大小達到一個閥值（默認64MB）時，memStore會被flush到文 件，即生成一個快照。目前hbase 會有一個線程來負責memStore的flush操做。

StoreFile

memStore內存中的數據寫到文件後就是StoreFile，StoreFile底層是以HFile的格式保存。

HLog

HLog(WAL log)：WAL意爲write ahead log，用來作災難恢復使用，HLog記錄數據的全部變動，一旦region server 宕機，就能夠從log中進行恢復。

HLog文件就是一個普通的Hadoop Sequence File， Sequence File的value是key時HLogKey對象，其中記錄了寫入數據的歸屬信息，除了table和region名字外，還同時包括sequence number和timestamp，timestamp是寫入時間，sequence number的起始值爲0，或者是最近一次存入文件系統中的sequence number。 Sequence File的value是HBase的KeyValue對象，即對應HFile中的KeyValue。

LogFlusher

前面提到，數據以KeyValue形式到達HRegionServer，將寫入WAL以後，寫入一個SequenceFile。看過去沒問題，可是由於數 據流在寫入文件系統時，常常會緩存以提升性能。這樣，有些本覺得在日誌文件中的數據實際在內存中。 
這裏，咱們提供了一個LogFlusher的類。它調用 HLog.optionalSync(),後者根據 hbase.regionserver.optionallogflushinterval (默認是10秒)，按期調用Hlog.sync()。另外，HLog.doWrite()也會根據 
hbase.regionserver.flushlogentries (默認100秒)按期調用Hlog.sync()。Sync() 自己調用HLog.Writer.sync()，它由SequenceFileLogWriter實現。

LogRoller

Log的大小經過$HBASE_HOME/conf/hbase-site.xml 的 hbase.regionserver.logroll.period 限制，默認是一個小時。因此每60分鐘，會打開一個新的log文件。長此以往，會有一大堆的文件須要維護。首先，LogRoller調用 HLog.rollWriter()，定時滾動日誌，以後，利用HLog.cleanOldLogs()能夠清除舊的日誌。它首先取得存儲文件中的最大的 sequence number，以後檢查是否存在一個log全部的條目的「sequence number」均低於這個值，若是存在，將刪除這個log。 每一個region server維護一個HLog，而不是每個region一個，這樣不一樣region（來自不一樣的table）的日誌會混在一塊兒，這樣作的目的是不斷追加 單個文件相對於同時寫多個文件而言，能夠減小磁盤尋址次數，所以能夠提升table的寫性能。帶來麻煩的時，若是一個region server下線，爲了恢復其上的region，須要將region server上的log進行拆分，而後分發到其餘region server上進行恢復。

HBase工做流程

目前爲止，相信你已經瞭解了HBase組件的使用和做用，但你可能還不太清楚上面說起的這些HBase組件間是如何運做的，下面咱們來看看HBase的工做流程

Client

首先當一個請求產生時，HBase Client使用RPC(遠程過程調用)機制與HMaster和HRegionServer進行通訊，對於管理類操做，Client與HMaster進行RPC;對於數據讀寫操做，Client與HRegionServer進行RPC。

Zookeeper

HBase Client使用RPC(遠程過程調用)機制與HMaster和HRegionServer進行通訊，但如何尋址呢？因爲Zookeeper中存儲了-ROOT-表的地址和HMaster的地址，因此須要先到Zookeeper上進行尋址。

HRegionServer也會把本身以Ephemeral方式註冊到Zookeeper中，使HMaster能夠隨時感知到各個HRegionServer的健康狀態。此外，Zookeeper也避免了HMaster的單點故障。

HMaster

當用戶須要進行Table和Region的管理工做時，就須要和HMaster進行通訊。HBase中能夠啓動多個HMaster,經過Zookeeper的Master Eletion機制保證總有一個Master運行。

1. 管理用戶對Table的增刪改查操做
2. 管理HRegionServer的負載均衡，調整Region的分佈
3. 在Region Split後，負責新Region的分配
4. 在HRegionServer停機後，負責失效HRegionServer上的Regions遷移

HRegionServer

當用戶須要對數據進行讀寫操做時，須要訪問HRegionServer。HRegionServer存取一個子表時，會建立一個HRegion對象，而後對錶的每一個列族建立一個Store實例，每一個Store都會有一個 MemStore和0個或多個StoreFile與之對應，每一個StoreFile都會對應一個HFile， HFile就是實際的存儲文件。所以，一個HRegion有多少個列族就有多少個Store。 一個HRegionServer會有多個HRegion和一個HLog。

當HStore存儲是HBase的核心了，其中由兩部分組成：MemStore和StoreFiles。 MemStore是Sorted Memory Buffer,用戶 
寫入數據首先 會放在MemStore,當MemStore滿了之後會Flush成一個 StoreFile（實際存儲在HDHS上的是HFile），當StoreFile文件數量增加到必定閥值，就會觸發Compact合併操做，並將多個StoreFile合併成一個StoreFile，合併過程當中會進行版本合併和數據刪除，所以能夠看出HBase其實只有增長數據，全部的更新和刪除操做都是在後續的compact過程當中進行的，這使得用戶的 讀寫操做只要進入內存中就能夠當即返回，保證了HBase I/O的高性能。

下面以一個具體數據Put的流程，讓咱們加深對HBase工做流程的認識。

HBase Put流程

下面是put流程的時序圖：

客戶端：

1. 客戶端發起Put寫請求，講put寫入writeBuffer，若是是批量提交，寫滿緩存後自動提交
2. 根據rowkey將put吩咐給不一樣regionserver

服務端：

1. RegionServer將put按rowkey分給不一樣的region
2. Region首先把數據寫入wal
3. wal寫入成功後，把數據寫入memstore
4. Memstore寫完後，檢查memstore大小是否達到flush閥值
5. 若是達到flush閥值，將memstore寫入HDFS，生成HFile文件

HBase Compact &&Split

當StoreFile文件數量增加到必定閥值，就會觸發Compact合併操做，並將多個StoreFile合併成一個StoreFile，當這個StoreFile大小超過必定閥值後，會觸發Split操做，同時把當前Region Split成2個Region,這是舊的Region會下線，新Split出的2個Region會被HMaster分配到相應的HregionServer上，使得原先1個Region的壓力得以分散到2個Region上。

以下圖四個Storefile文件（從memstore文件通過flush而獲得，默認64M的storefile文件）通過Compact合併成一個大的256M storefile文件，當設定的Region閥值爲128M時，就會Split爲兩個128M的Storefile文件，而後HMaster再把這兩個storefile文件分配到不停地Regionserver上。

HFile

HBase中全部的數據文件都存儲在Hadoop HDFS上，主要包括兩種文件類型：

• Hfile:HBase中KeyValue數據的存儲格式，HFile是Hadoop的 二進制格式文件，實際上StoreFile就是對Hfile作了輕量級包裝，即StoreFile底層就是HFile
• HLog File:HBase中WAL(write ahead log)的存儲格式，物理上是Hadoop的Sequence File

HFile的存儲格式以下：

HFile文件是不定長的，長度固定的只有其中的兩塊：Trailer和FileInfo。

Trailer中有指針指向其餘數據塊的起始點，FileInfo記錄了文件的一些meta信息。 Data Block是hbase io的基本單元，爲了提升效率，HRegionServer中有基於LRU的block cache機制。 
每一個Data塊的大小能夠在建立一個Table的時候經過參數指定（默認塊大小64KB），大號的Block有利於順序Scan，小號的 Block利於隨機查詢。 
每一個Data塊除了開頭的Magic之外就是一個個KeyValue對拼接而成，Magic內容就是一些隨機數字，目的是防止數 據損壞，結構以下。

 

上圖可知，開始是兩個固定長度的數值，分別表示key的長度和alue的長度。緊接着是Key,開始是固定長度的數值，表示RowKey的長度，緊接着是RowKey，而後是固定長度的數值，表示Family的長度，而後是Family,接着是Qualifier，而後是兩個固定長度的數值，表示Time Stamp和Key Type(Put/Delete)。Value部分沒有那麼複雜的結構，就是純粹的二進制數據。

HBase的三維有序（即字典順序）存儲

Hfile是HBase中KeyValue數據的存儲格式。從上面的 HBase物理數據模型中能夠看出，HBase是面向列表（簇）的存儲。每一個Cell由 {row key，column(=< family> + < label>)，version} 惟一肯定的單元，他們組合在一塊兒就是一個KeyValue。根據上述描述，這個KeyValue中的key就是{row key，column(=< family> + < label>)，version} ，而value就是cell中的值。

HBase的三維有序存儲中的三維是指：rowkey（行主鍵），column key(columnFamily+< label>)，timestamp(時間戳或者版本號)三部分組成的三維有序存儲。

• rowkey

rowkey是行的主鍵，它是以字典順序排序的。因此 rowkey的設計是相當重要的，關係到你應用層的查詢效率。咱們在根據rowkey範圍查詢的時候，咱們通常是知道startRowkey，若是咱們經過scan只傳startRowKey ： d開頭的，那麼查詢的是全部比d大的都查了，而咱們只須要d開頭的數據，那就要經過endRowKey來限制。咱們能夠經過設定endRowKey爲：d 開頭，後面的根據你的rowkey組合來設定，通常是加比startKey大一位。

• column key

column key是第二維，數據按rowkey字典排序後，若是rowkey相同，則是根據column key來排序的，也是按字典排序。 
咱們在設計table的時候要學會利用這一點。好比咱們的收件箱。咱們有時候須要按主題排序，那咱們就能夠把主題這設置爲咱們的column key，即設計爲columnFamily+主題.,這樣的設計。

• timestamp

timestamp 時間戳，是第三維，這是個按降序排序的，即最新的數據排在最前面。這個就沒有什麼說的了。網上其餘的博客也提到比較多。

HLog Replay

根據以上的敘述，咱們已經瞭解了關於HStore的基本原理，但咱們還必需要了解一下HLog的功能，由於上述的HStore在系統正常工做的前提下是沒問題的，可是在分佈式 系統環境中，沒法避免系統出錯或者宕機，由於一旦HRegionServer意外退出，MemStore中的內存數據將會丟失，這就須要引入HLog。每一個HRegionServer中都有一個HLog對象，HLog是一個實現Write Ahead Log的類，在每一次用戶操做寫入MemStore的同時，也會寫一份數據到HLog文件中，HLog文件按期(當文件已持久化到StoreFile中的數據)會滾出新的，而且刪除舊的文件。當HRegionServer意外終止 後，HMaster會經過Zookeeper感知到，HMaster首先會處理遺留的Hlog文件，將其中不一樣Region的Log數據進行拆分，分別放到相應Region的目錄下，而後再將失效的Region從新分配，領取到這些Region的Regionserver在Load Region的過程當中，會發現歷史HLog須要處理，所以Replay HLog中的數據到MemStore中，而後flush到StoreFiles,完成數據恢復。

HLog存儲格式

WAL(Write Ahead Log):RegionServer在處理插入和刪除過程當中，用來記錄操做內容的日誌，只有日誌寫入成功，纔會通知客戶端操做成功。

上圖中是HLog文件的結構，其實HLog文件就是一個普通的Hadoop Sequence File，Sequence File的Key是HLogKey對象，HLogKey中記錄了寫入數據的歸屬信息，除了table和Region名字外，同時還包括sequence number和timestamp,timestamp是」寫入時間」，sequence number 的起始值爲0，或者是最近一次存入文件系統中的sequence number。

HLog Sequence File 的Value是HBase的KeyValue對象昂，即對應HFile中的KeyValue。

HBase的高可用

當出現上圖三種狀況的高可用策略：

1. HDFS機架識別策略：當數據文件損壞時，會找相同機架上備份的數據文件，若是相同機架上的數據文件也損壞會找不一樣機架備份數據文件。
2. HBase的Region快速恢復：當節點損壞時，節點上的丟失region,會在其餘節點上均勻快速恢復。
3. Master節點的HA機制：Master爲一主多備。當Master主節點宕機後，剩下的備節點經過選舉，產生主節點。

HBase性能和優化

影響HBase性能的因素

上圖中，從HDFS如下都屬於HBase的支撐系統。

從構成集羣機器的底層硬件到把硬件和操做系統(尤爲是文件系統)，JVM,HDFS鏈接起來的網絡之間的全部部件都會影響到HBase的性能。HBase系統的狀態也會影響到HBase的系統。例如，在集羣中執行合併的時候或者Memstore刷寫的時候與什麼都沒有作的時候相比，其性能表現是不一樣的。應用系統的性能還取決於它和HBase的交互方式，因此模式設計和其餘環節同樣起到了必不可少的做用。

在評判HBase性能時，全部這些因素都有影響；在優化集羣時，須要查看全部這些因素。

優化HBase支撐系統

(1)硬件選擇

總的原則是，根據業務狀況和集羣規模大小選擇合理的硬件。

(2)網絡配置

基於當前階段硬件的典型分佈式系統都會受到網絡的限制，HBase也不例外。在節點和機架頂置交換機之間建議採用10Gb以太網交換機。千萬不要過於滿額配置地使用網絡，不然在高負載時，會影響HBase應用系統的性能。

(3)操做系統

通常狀況下，只要使用Hadoop和HBase，操做系統一般選擇Linux。能夠選擇Red Hat Enterprise Linux，CentOS，也能夠選擇成功部署過的其餘操做系統。

(4)本地文件系統

本地Linux文件系統在HBase集羣體系裏起到了重要做用，而且嚴重影響到HBase的性能。雖然EXT4是推薦使用的本地文件系統，但沒有大規模使用，相反EXT3和XFS已經在生產系統裏獲得成功使用，建議使用EXT3和XFS做爲本地文件系統。

(5)HDFS

根據業務訪問特色優化

根據業務訪問特色，將Hbase的工做負載大體分爲如下四類：

(1)隨機讀密集型

對於隨機讀密集型工做負載，高效利用緩存和更好地索引會給HBase系統帶來更高的性能。

(2)順序讀密集型

對於順序讀密集型工做負載，讀緩存不會帶來太多好處；除非順序讀的規模很小而且限定在一個特定的行鍵範圍內，不然極可能使用緩存會比不使用緩存須要更頻繁地訪問硬盤。

(3)寫密集型

寫密集型工做負載的優化方法須要有別於讀密集型負載。緩存再也不起到重要做用。寫操做老是進入MemStore，而後被刷寫生成新的Hfile，之後再被合併。得到更好寫性能的辦法是不要太頻繁刷寫、合併或者拆分，由於在這段時間裏IO壓力上升，系統會變慢。

(4)混合型

對於徹底混合型工做負載，優化方法會變得複雜些。優化時，須要混合調整多個參數來獲得一個最優的組合。

其它角度來優化HBase性能

(1)JVM垃圾回收優化

(2)本地memstore分配緩存優化

(3)Region拆分優化

(4**)Region合併優化**

(5)Region預先加載優化

(6)負載均衡優化

(7)啓用壓縮

(8)GZIP、snappy、lzo，推薦snappy,壓縮比稍差於lzo；可是壓縮速度高於lzo,而且與lzo有差很少的 解壓縮速度。

（9）進行預分區，從而避免自動split，提升hbase響應速度

（10）避免出現region熱點現象，啓動按照table級別進行balance

HBase常見的調優參數

HBase shell訪問

HBase Shell 提供了大多數的 HBase 命令, 經過 HBase Shell 用戶能夠方便地建立、刪除及修改表, 還能夠向表中添加數據、列出表中的相關信息等。

在啓動 HBase 以後,用戶能夠經過下面的命令進入 HBase Shell 之中,命令以下所示:

1 [hadoop@CDHNode1 ~]$hbase shell

輸入 help 能夠看到命令分組。（注意命令都是小寫，有大小寫的區分）

部分命令

下邊分組舉例 Shell 的各類操做。

general操做

查詢 HBase 服務器狀態 status。

查詢hbase版本 version

ddl操做

一、 建立一個表

create ‘table1’, ‘tab1_id’, ‘tab1_add’, ‘tab1_info’

二、 列出全部的表

三、 得到表的描述

describe 「table1」

四、 刪除一個列族 disable alter enable 注意刪除前，須要先把表disable

disable ‘table1’

alter ‘table1’, {NAME=>’tab1_add’, METHOD=>’delete’}

enable ‘table1’

五、 查看錶是否存在 
exists ‘table2’

六、 判斷表是否爲‘enable’

is_enabled ‘table1’

七、 刪除一個表

disable ‘table1’

drop ‘table1’

dml操做

一、 插入幾條記錄

put ‘member’, ‘scutshuxue’, ‘info:age’, ‘24’

put ‘member’, ‘scutshuxue’, ‘info:birthday’, ‘1987-06-17’

put ‘member’, ‘scutshuxue’, ‘info:company’, ‘alibaba’

put ‘member’, ‘scutshuxue’, ‘address:contry’, ‘china’

put ‘member’, ‘scutshuxue’, ‘address:province’, ‘zhejiang’

put ‘member’, ‘scutshuxue’, ‘address:city’, ‘hangzhou’

put命令比較簡單，只有這一種用法： 
hbase> put ‘t1′, ‘r1′, ‘c1′, ‘value’, ts1

t1指表名，r1指行鍵名，c1指列名，value指單元格值。ts1指時間戳，通常都省略掉了。

二、 全表掃描 scan

三、 得到數據 get

1) 得到一行的全部數據

2) 得到某行，某列族的全部數據

3) 得到某行，某列族，某列的全部數據

四、 更新一條記錄 put（把scutshuxue年齡改成99）

put ‘member’, ‘scutshuxue’, ‘info:age’, 99

五、 刪除 delete、 deleteall

1) 刪除行’scutshuxue’, 列族爲‘info’ 中age的值

delete ‘member’, ‘scutshuxue’, ‘info:age’

2) 刪除整行

deleteall ‘member’, ‘scutshuxue’

六、 查詢表中有多少行

count ‘member’

七、 給‘xiaoming’這個id增長’info:age’字段，並使用counter實現遞增

incr ‘member’, ‘xiaoming’, ‘info:age’

八、 將整個表清空

truncate ‘member’

能夠看出，HBase 是經過先對錶執行 disable，而後再執行 drop 操做後重建表來實現 truncate 的功能的。