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

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
3. 在-ROOT-表中都是一行記錄。
4. 通過.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的支撐系統。

從構成集群機器的底層硬件到把硬件和操作系統

在評判HBase性能時，所有這些因素都有影響；在優化集群時，需要查看所有這些因素。

優化HBase支撐系統

(1)硬件選擇

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

(2)網絡配置

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

(3)操作系統

一般情況下，只要使用Hadoop和HBase，操作系統通常選擇Linux

(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 之中,命令如下所示:

[hadoop@CDHNode1 ~]$hbase shell
1

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

部分命令

下邊分組舉例 Shell 的各種操作。

general操作

查詢 HBase 服務器狀態 status。

查詢hbase版本 version

ddl操作

1、 創建一個表

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

2、 列出所有的表

3、 獲得表的描述

describe “table1”

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

disable ‘table1’

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

enable ‘table1’

5、 查看錶是否存在

exists ‘table2’

6、 判斷表是否為‘enable’

is_enabled ‘table1’

7、 刪除一個表

disable ‘table1’

drop ‘table1’

dml操作

1、 插入幾條記錄

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指時間戳，一般都省略掉了。

2、 全表掃描 scan

3、 獲得數據 get

1) 獲得一行的所有數據

2) 獲得某行，某列族的所有數據

3) 獲得某行，某列族，某列的所有數據

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

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

5、 刪除 delete、 deleteall

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

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

2) 刪除整行

deleteall ‘member’, ‘scutshuxue’

6、 查詢表中有多少行

count ‘member’

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

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

8、 將整個表清空

truncate ‘member’

可以看出，HBase 是通過先對錶執行 disable，然後再執行 drop 操作後重建表來實現 truncate 的功能的。

以上是學習HBase後，整理的HBase概述，如有錯誤，請指正！

【1】想了解大數據知識，可以關注我下方評論轉發後，私信“資料”。

【2】部分資料有時間限制，抓緊時間吧！

感謝大家支持！

閱讀更多 大數據程序 的文章

關鍵字: HDFS 全都 數據結構