****什么是Hbase****
Hbase是一種基于HDFS的分布式數(shù)據(jù)庫(kù)
支持海量的數(shù)據(jù)的存儲(chǔ)，千億、萬(wàn)億級(jí)別
表存儲(chǔ)比較稀疏，Schema十分靈活
支持?jǐn)?shù)據(jù)的多版本
列式存儲(chǔ)
主鍵索引，低延遲的隨機(jī)查詢
擴(kuò)展性與生俱來(lái)
HBase的基本概念和架構(gòu)：
HMaster：Hbase的管理協(xié)調(diào)進(jìn)程，用于Schema的管理，管理對(duì)Table的增、刪、改、查操作，調(diào)整Region的分布，Region進(jìn)行分裂的時(shí)候負(fù)責(zé)新的Region的分配。
RegionServer：Hbase的數(shù)據(jù)節(jié)點(diǎn)進(jìn)程，主要是負(fù)責(zé)響應(yīng)用戶的I/O請(qǐng)求。
Zookeeper在這里主要起命名和通知的功能，Zk主要負(fù)責(zé)多HMaster的選舉,存貯部分元數(shù)據(jù)、實(shí)時(shí)監(jiān)控RegionServer，宕機(jī)之后迅速進(jìn)行Region的轉(zhuǎn)移、保證集群中只有一個(gè)HMaster。
數(shù)據(jù)存儲(chǔ)：
HRegion 是RegionServer內(nèi)部維護(hù)的一個(gè)對(duì)象，是一個(gè)Table的一個(gè)子集，一個(gè)Region和一個(gè)表一一對(duì)。
HLOG是Hbase的WAL（Write-Ahead Logging）機(jī)制的一個(gè)實(shí)現(xiàn)，通過(guò)預(yù)寫日志，來(lái)避免節(jié)點(diǎn)宕機(jī)帶來(lái)的數(shù)據(jù)丟失的問(wèn)題，當(dāng)寫入HLOG成功，此時(shí)此節(jié)點(diǎn)宕機(jī)，HMaster控制Region轉(zhuǎn)移到其他節(jié)點(diǎn)后，在Region上線的過(guò)程中會(huì)將HLOG上的數(shù)據(jù)重新寫入，保證可靠性。
MemStore：數(shù)據(jù)寫入時(shí)先進(jìn)行MemStore的寫入，當(dāng)MemStore寫滿之后進(jìn)行Flush，將數(shù)據(jù)FLush成一個(gè)HRegion。這樣就保證了高吞吐，同時(shí)數(shù)據(jù)寫入內(nèi)存后，請(qǐng)求即返回，響應(yīng)速度十分快。
Store是Region的子集，一個(gè)Store對(duì)應(yīng)著Hbase的一個(gè)列族，所以Hbase的列族是分開(kāi)存儲(chǔ)的，通常將經(jīng)常放在一個(gè)查詢的數(shù)據(jù)放在一個(gè)列族中，同時(shí)官方不建議用多列族，原因是會(huì)導(dǎo)致數(shù)據(jù)不均勻的問(wèn)題。
StoreFile對(duì)應(yīng)著Hbase的底層存儲(chǔ)—HFile,HFile是Hbase的底層存儲(chǔ)，所有數(shù)據(jù)以固定的數(shù)據(jù)格式存儲(chǔ)在HDFS的特定目錄下，會(huì)定期的Split和Compact。
Table的層級(jí)和在HDFS上的存儲(chǔ)：
表在HDFS上的存儲(chǔ)
表的層級(jí)關(guān)系：
表結(jié)構(gòu)：
邏輯視圖：
?
Hfile里是怎么存儲(chǔ)的：
數(shù)據(jù)膨脹：
從上面的圖我們可以看見(jiàn)，數(shù)據(jù)的基本格式為：rowkey：timestamp:columm_family:coloum:value.
邏輯上的一行數(shù)據(jù)被拆成了兩行數(shù)據(jù)進(jìn)行存儲(chǔ)，同時(shí)存儲(chǔ)的數(shù)據(jù)大大的膨脹了主要是冗余了rowkey timestamp 和coloumFamily字段，通常數(shù)據(jù)會(huì)膨脹2倍以上，具體大小視具體的數(shù)據(jù)。
更小的單元
Cell
Cell的概念是在Hbase0.96之后出現(xiàn)的，用來(lái)表征一行數(shù)據(jù),Cell的前身是KeyValue，Cell的格式如下：
? {row, column, version}
Version：
Version使用來(lái)標(biāo)識(shí)數(shù)據(jù)版本的概念，Hbase支持多版本的機(jī)制，同一份數(shù)據(jù)具有多個(gè)版本，這樣可以追蹤到一條數(shù)據(jù)的上一個(gè)版本的信息，Hbase中的Cell是按照Version倒序排列的，所以第一個(gè)讀取到的一定是最新版本的數(shù)據(jù)。
Hbase 默認(rèn)的版本數(shù)為1，過(guò)量的Version數(shù)據(jù)將在Compact的過(guò)程中被刪除，官方的建議是Version最大數(shù)最好不要超過(guò)100，因?yàn)檫@樣會(huì)很大程度上消耗存儲(chǔ)空間。
TTL( Time To Live)
TTL是一個(gè)標(biāo)識(shí)一個(gè)數(shù)據(jù)的生命周期，對(duì)一個(gè)列族設(shè)定TTL之后，在到達(dá)TTL的時(shí)間時(shí)，數(shù)據(jù)會(huì)自動(dòng)刪除，盡管設(shè)置了Version，到達(dá)了TTL之后數(shù)據(jù)仍然會(huì)被刪除：
Hbase的存儲(chǔ)模型：
LSM思想：
LSM的基本思想是將修改的數(shù)據(jù)保存在內(nèi)存，達(dá)到一定數(shù)量后在將修改的數(shù)據(jù)批量寫入磁盤，在寫入的過(guò)程中與之前已經(jīng)存在的數(shù)據(jù)做合并。同B樹(shù)存儲(chǔ)模型一樣，LSM存儲(chǔ)模型也支持增、刪、讀、改以及順序掃描操作。LSM模型利用批量寫入解決了隨機(jī)寫入的問(wèn)題，雖然犧牲了部分讀的性能，但是大大提高了寫的性能.
因?yàn)樾?shù)先寫到內(nèi)存中，為了防止內(nèi)存數(shù)據(jù)丟失，寫內(nèi)存的同時(shí)需要暫時(shí)持久化到磁盤，對(duì)應(yīng)了HBase的MemStore和HLog
MemStore上的樹(shù)達(dá)到一定大小之后，需要flush到HRegion磁盤中（一般是Hadoop DataNode），這樣MemStore就變成了DataNode上的磁盤文件StoreFile，定期HRegionServer對(duì)DataNode的數(shù)據(jù)做merge操作，徹底刪除無(wú)效空間，多棵小樹(shù)在這個(gè)時(shí)機(jī)合并成大樹(shù)，來(lái)增強(qiáng)讀性能。
MemStore的Flush過(guò)程：
? 在Hbase的寫入過(guò)程中，首先追加到HLOG上，來(lái)保證數(shù)據(jù)的可靠性，隨后append到MemStore上，當(dāng)MemStore寫滿了之后會(huì)進(jìn)行Flush過(guò)程，F(xiàn)lush過(guò)程中Hbase會(huì)開(kāi)啟一個(gè)新的MemStore接收新的寫入，F(xiàn)lush會(huì)產(chǎn)生一個(gè)新的HFile到HDFS上，當(dāng)Hfile數(shù)量和大小達(dá)到一定程度時(shí)，已經(jīng)大大的影響到了查詢性能，隨后會(huì)進(jìn)行Compact操作。
Compact過(guò)程：
隨著MemStore的不斷Flush，在HDFS上會(huì)形成越來(lái)越多的小文件，文件數(shù)量過(guò)多會(huì)大大的降低查詢效率，Compact過(guò)程會(huì)盡可能的將它們合并成規(guī)模更少但是更大的文件
合并過(guò)程又分為minor compact和major的compact。
minor compact：主要是將小于一定閾值的文件合并成更大的文件。
major compact：主要是將所有的文件都合并成一個(gè)文件。
文件合并之后會(huì)大大的提高查詢效率，但是由于合并過(guò)程中會(huì)讀取全量的數(shù)據(jù)，這樣會(huì)大量的占用磁盤的IO，導(dǎo)致查詢效率大幅下降，甚至不可用。
Split過(guò)程：
? 當(dāng)一個(gè)Region的大小達(dá)到一定程度的時(shí)候，會(huì)進(jìn)行Region的Split過(guò)程，Split過(guò)程中Region會(huì)進(jìn)行下線操作，此時(shí)不響應(yīng)任何請(qǐng)求，直到Split過(guò)程結(jié)束。多列族且數(shù)據(jù)不均勻的情況會(huì)導(dǎo)致，大列族觸發(fā)了Split，盡管小列族的數(shù)據(jù)很小，但是依然會(huì)進(jìn)行split導(dǎo)致數(shù)據(jù)不均，同時(shí)大列族的flush會(huì)帶動(dòng)小列族的flush，導(dǎo)致反復(fù)的IO，十分影響效率，久而久之會(huì)嚴(yán)重的影響Scan查詢效率。
Hbase對(duì)查詢的優(yōu)化：
Server端緩存——BlockCache
一個(gè)Hbase的查詢請(qǐng)求首先會(huì)先到Memstore中查數(shù)據(jù)，查不到就到BlockCache中查，再查不到就會(huì)到磁盤上讀,BlockCache采用LRU機(jī)制，這樣相當(dāng)于對(duì)常用數(shù)據(jù)進(jìn)行緩存，提高查詢效率，但是在進(jìn)行Scan的時(shí)候盡量避免使用cache，因?yàn)檫@樣會(huì)大大的降低查詢效率，例如MapReduce在做全表Scan的時(shí)候一定要關(guān)閉cache。
多File的選擇——Bloom Filter
? Hbase在HDFS上存儲(chǔ)可能會(huì)有多個(gè)文件，在沒(méi)有合并的情況下，各個(gè)File之間Rowkey索引可能互有交集，查詢時(shí)最壞情況下要遍歷全部文件，這樣就大大的降低了查詢效率，Hbase提供了Bloom Filter來(lái)實(shí)現(xiàn)快速的定位目標(biāo)記錄所在的文件。
? Bloom Filter可以保守的確定一條數(shù)據(jù)在不在一個(gè)集合中，如果Bloom Filter認(rèn)為一條數(shù)據(jù)在一個(gè)文件中，但事實(shí)上不一定在。但是Bloom Filter認(rèn)為不在那么該數(shù)據(jù)一定不在。
? Bloom Filter的原理使用一個(gè)十分大的二進(jìn)制數(shù)組將File中的所有數(shù)據(jù)進(jìn)行多種Hash算法hash到這個(gè)二進(jìn)制數(shù)組上。當(dāng)查詢到來(lái)時(shí)，對(duì)查詢進(jìn)行同樣的Hash處理，該結(jié)果在該File中,那么就判斷該數(shù)據(jù)在這個(gè)集合中，但是由于Hash沖突的存在，這種判斷的正確性不能100%保證，但是也能幫我們擋住大量的請(qǐng)求了。
MapReduce對(duì)Hbase的支持：
Hbase是Hadoop生態(tài)系統(tǒng)中很重要的一員，所以Hbase和MapReduce的契合度十分高，Mapreduce為Hbase提供了抽象度很高的Api，能快速的對(duì)Hbase中的數(shù)據(jù)進(jìn)行計(jì)算。
Mapredece中提供了TableMapReduceUtil來(lái)支持讀取和寫入Hbase兩種場(chǎng)景：
在Map函數(shù)中繼承下TableMapper:
實(shí)現(xiàn)Reduce函數(shù)：
此處有坑! 在Hbase作為Mapreduce為輸入的時(shí)候，Scan需要關(guān)閉blockCache 否則容易拖垮集群。
雖然這種是比較常用的mapreduce方式，但是，它的性能十分不好，數(shù)據(jù)吞吐量比較大的時(shí)候會(huì)給Hbase造成十分大的負(fù)載。
另一種加載機(jī)制：BulkLoad和HFileInputFormat
為了避免大量數(shù)據(jù)批量涌入造成Hbase Region進(jìn)行頻繁的compact和Split 造成短暫性不可用的問(wèn)題。 Hbase提供了一種批量寫入到Hbase底層存儲(chǔ)的機(jī)制——bulkLoad。
bulkLoad是通過(guò)直接寫底層Hbase存儲(chǔ)的機(jī)制避開(kāi)了整個(gè)Hbase的寫入流程，從而避免Region的Compact和Split。
為什么選擇bulkLoad：
處理流程：
流程圖
應(yīng)用場(chǎng)景：
對(duì)于直接讀取Hbase底層Hfile，官方?jīng)]有提供方法，不過(guò)可以通過(guò)自定義HfileInputFormat實(shí)現(xiàn)，但是這里面存在的問(wèn)題是，對(duì)于還在內(nèi)存中的數(shù)據(jù)通過(guò)這種方式查詢不到（不知道現(xiàn)在有沒(méi)有解決）。
“詬病”——熱點(diǎn)問(wèn)題
在初次寫入或者rowkey分布不均勻的情況下，容易導(dǎo)致集群負(fù)載不一致，查詢和寫入速度變慢。
rowkey被設(shè)計(jì)為順序，或分布比較集中的情況。順序的rowkey雖然能為scan帶來(lái)比較高的性能，但是會(huì)在寫入時(shí)帶來(lái)寫人熱點(diǎn)的問(wèn)題。
? 初次寫入問(wèn)題則是第一次寫入時(shí)默認(rèn)只有一個(gè)region，那么如果第一次有大量數(shù)據(jù)寫入，會(huì)導(dǎo)致Region會(huì)很快的進(jìn)行compact和Split，會(huì)短暫的導(dǎo)致數(shù)據(jù)不可用，進(jìn)而阻塞寫操作。
解決：合理設(shè)置rowkey（主要針對(duì)寫入熱點(diǎn)問(wèn)題，同時(shí)實(shí)時(shí)寫入數(shù)據(jù)）：
對(duì)rowkey進(jìn)行hash或MD5
翻轉(zhuǎn)倒序
避免順序時(shí)間或者時(shí)間戳
加鹽（salting）
局限性：雖然做了salting 但是還是不能把數(shù)據(jù)準(zhǔn)確的分到不同的region上
預(yù)分區(qū)：
預(yù)分區(qū)是在建表的時(shí)候根據(jù)預(yù)先設(shè)計(jì)的Rowkey，預(yù)先進(jìn)行rowkey的劃分。這樣可以解決數(shù)據(jù)初始寫入壓力大的問(wèn)題。
局限：隨著數(shù)據(jù)量的增加，還是會(huì)產(chǎn)生，compact、split的，region短暫性下線的問(wèn)題。
終極大招bulkload：
bulkload巧妙的避開(kāi)了Hbase Api的寫入，所以不會(huì)產(chǎn)生Compact和Split的問(wèn)題。同mapreduce配合使用，系統(tǒng)吞吐量十分大。
局限：只能做離線的數(shù)據(jù)導(dǎo)入，不支持實(shí)時(shí)寫入，一般場(chǎng)景為離線非實(shí)時(shí)的場(chǎng)景。
以上均為自己總結(jié)的，作為自己的備忘錄，希望大家看到錯(cuò)誤之處，幫忙指出，共同學(xué)習(xí)，謝謝。
