本篇內(nèi)容介紹了“HBase入門問題有哪些”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！
一些常見的HBase新手問題
·什么樣的數(shù)據(jù)適合用HBase來(lái)存儲(chǔ)?
行由看似”雜亂無(wú)章”的列組成，行與行之間也無(wú)須遵循一致的定義，而這種定義恰好符合半結(jié)構(gòu)化數(shù)據(jù)或非結(jié)構(gòu)化數(shù)據(jù)的特點(diǎn)。本文所要講述的HBase，就屬于該派系的一個(gè)典型代表。這些”雜亂無(wú)章”的列所構(gòu)成的多行數(shù)據(jù)，被稱之為一個(gè)”稀疏矩陣”，而上圖中的每一個(gè)”黑塊塊”，在HBase中稱之為一個(gè)KeyValue。
Apache HBase官方給出了這樣的定義：
Apache HBase? is the hadoop database, a distributed , scalable , big data store .
即：Apache HBase是基于Hadoop構(gòu)建的一個(gè) 分布式 的、 可伸縮 的 海量數(shù)據(jù)存儲(chǔ)系統(tǒng) 。
HBase常被用來(lái)存放一些結(jié)構(gòu)簡(jiǎn)單，但數(shù)據(jù)量非常大的數(shù)據(jù)(通常在TB級(jí)別以上)，如歷史訂單記錄，日志數(shù)據(jù)，監(jiān)控Metris數(shù)據(jù)等等，HBase提供了簡(jiǎn)單的基于Key值的快速查詢能力。
HBase在國(guó)內(nèi)市場(chǎng)已經(jīng)取得了非常廣泛的應(yīng)用，在搜索引擎中，也可以看出來(lái)，HBase在國(guó)內(nèi)呈現(xiàn)出了逐年上升的勢(shì)態(tài)：
(需要說(shuō)明的一點(diǎn)：HBase中的每一次commit，都已經(jīng)過社區(qū)Commiter成員嚴(yán)格的Review，在commit之前，一個(gè)Patch可能已經(jīng)被修改了幾十個(gè)版本)
令人欣喜的是，國(guó)內(nèi)的開發(fā)者也積極參與到了HBase社區(qū)貢獻(xiàn)中，而且被社區(qū)接納了多名PMC以及Committer成員。
本文將以 一條數(shù)據(jù)在HBase中的“旅程” 為線索，介紹HBase的核心概念與流程，幾乎每一部分都可以展開成一篇獨(dú)立的長(zhǎng)文，但本文旨在讓讀者能夠快速的了解HBase的架構(gòu)輪廓，所以很多特性/流程被被一言帶過，但這些特性在社區(qū)中往往經(jīng)歷了漫長(zhǎng)的開發(fā)過程。至于講什么以及講到什么程度，本文都做了艱難的取舍，在講解的過程中，將會(huì)穿插解答本文開始所提出的針對(duì)初學(xué)者的一些常見問題。
本文適用于HBase新手，而對(duì)于具備一定經(jīng)驗(yàn)的HBase開發(fā)人員，相信本文也可以提供一些有價(jià)值的參考。本文內(nèi)容基于HBase 2.0 beta 2版本，對(duì)比于1.0甚至是更早期的版本，2.0出現(xiàn)了大量變化，下面這些問題的答案與部分關(guān)鍵的變化相關(guān)(新手可以直接跳過這些問題)：
·HBase meta Region在哪里提供服務(wù)?
·HBase是否可以保證單行操作的原子性?
·Region中寫WAL與寫MemStore的順序是怎樣的?
·你是否遇到過Region長(zhǎng)時(shí)間處于RIT的狀態(tài)? 你認(rèn)為舊版本中Assignment Manager的主要問題是什么?
·在面對(duì)Full GC問題時(shí)，你嘗試做過哪些優(yōu)化?
·你是否深究過HBase Compaction帶來(lái)的“寫放大”有多嚴(yán)重?
·HBase的RPC框架存在什么問題?
·導(dǎo)致查詢時(shí)延毛刺的原因有哪些?
本系列文章的 整體行文思路 如下：
·介紹HBase數(shù)據(jù)模型
·基于數(shù)據(jù)模型介紹HBase的適用場(chǎng)景
·快速介紹集群關(guān)鍵角色以及集群部署建議
·示例數(shù)據(jù)介紹
·寫數(shù)據(jù)流程
·讀數(shù)據(jù)流程
·數(shù)據(jù)更新
·負(fù)載均衡機(jī)制
HBase如何存儲(chǔ)小文件數(shù)據(jù)
這些內(nèi)容將會(huì)被拆成幾篇文章。至于集群服務(wù)故障的處理機(jī)制，集群工具，周邊生態(tài)，性能調(diào)優(yōu)以及最佳實(shí)踐等進(jìn)階內(nèi)容，暫不放在本系列文章范疇內(nèi)。
約定
本文范圍內(nèi)針對(duì)一些關(guān)鍵特性/流程，使用了加粗以及加下劃線的方式做了強(qiáng)調(diào)，如” ProcedureV2 “。這些特性往往在本文中僅僅被粗淺提及，后續(xù)計(jì)劃以獨(dú)立的文章來(lái)介紹這些特性/流程。
術(shù)語(yǔ)縮寫 ：對(duì)于一些進(jìn)程/角色名稱，在本文范圍內(nèi)可能通過縮寫形式來(lái)表述：
Region是HBase中負(fù)載均衡的基本單元，當(dāng)一個(gè)Region增長(zhǎng)到一定大小以后，會(huì)自動(dòng)分裂成兩個(gè)。
Column Family
如果將Region看成是一個(gè)表的 橫向切割 ，那么，一個(gè)Region中的數(shù)據(jù)列的 縱向切割 ，稱之為一個(gè) Column Family 。每一個(gè)列，都必須歸屬于一個(gè)Column Family，這個(gè)歸屬關(guān)系是在寫數(shù)據(jù)時(shí)指定的，而不是建表時(shí)預(yù)先定義。
看的出來(lái)，KeyValue是支撐”稀疏矩陣”設(shè)計(jì)的一個(gè)關(guān)鍵點(diǎn)：一些Key相同的任意數(shù)量的獨(dú)立KeyValue就可以構(gòu)成一行數(shù)據(jù)。但這種設(shè)計(jì)帶來(lái)的一個(gè)顯而易見的缺點(diǎn)： 每一個(gè)KeyValue所攜帶的自我描述信息，會(huì)帶來(lái)顯著的數(shù)據(jù)膨脹 。
適用場(chǎng)景
在介紹完了HBase的數(shù)據(jù)模型以后，我們可以回答本文一開始的前兩個(gè)問題：
·什么樣的數(shù)據(jù)適合用HBase來(lái)存儲(chǔ)?
·既然HBase也是一個(gè)數(shù)據(jù)庫(kù)，能否用它將現(xiàn)有系統(tǒng)中昂貴的Oracle替換掉?
HBase的數(shù)據(jù)模型比較簡(jiǎn)單，數(shù)據(jù)按照RowKey排序存放，適合HBase存儲(chǔ)的數(shù)據(jù)，可以簡(jiǎn)單總結(jié)如下：
·以 實(shí)體 為中心的數(shù)據(jù)
·實(shí)體可以包括但不限于如下幾種：
描述這些實(shí)體的，可以有基礎(chǔ)屬性信息、實(shí)體關(guān)系(圖數(shù)據(jù))、所發(fā)生的事件(如交易記錄、車輛軌跡點(diǎn))等等。
·自然人/賬戶/手機(jī)號(hào)/車輛相關(guān)數(shù)據(jù)
·用戶畫像數(shù)據(jù)(含標(biāo)簽類數(shù)據(jù))
·圖數(shù)據(jù)(關(guān)系類數(shù)據(jù))
·以 事件 為中心的數(shù)據(jù)
·監(jiān)控?cái)?shù)據(jù)
·時(shí)序數(shù)據(jù)
·實(shí)時(shí)位置類數(shù)據(jù)
·消息/日志類數(shù)據(jù)
上面所描述的這些數(shù)據(jù)，有的是結(jié)構(gòu)化數(shù)據(jù)，有的是半結(jié)構(gòu)化或非結(jié)構(gòu)化數(shù)據(jù)。HBase的“稀疏矩陣”設(shè)計(jì)，使其應(yīng)對(duì)非結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)時(shí)能夠得心應(yīng)手，但在我們的實(shí)際用戶場(chǎng)景中，結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)依然占據(jù)了比較重的比例。由于HBase僅提供了基于RowKey的單維度索引能力，在應(yīng)對(duì)一些具體的場(chǎng)景時(shí)，依然還需要基于HBase之上構(gòu)建一些專業(yè)的能力，如：
·OpenTSDB 時(shí)序數(shù)據(jù)存儲(chǔ)，提供基于Metrics+時(shí)間+標(biāo)簽的一些組合維度查詢與聚合能力
·GeoMesa 時(shí)空數(shù)據(jù)存儲(chǔ)，提供基于時(shí)間+空間范圍的索引能力
·JanusGraph 圖數(shù)據(jù)存儲(chǔ)，提供基于屬性、關(guān)系的圖索引能力
HBase擅長(zhǎng)于存儲(chǔ)結(jié)構(gòu)簡(jiǎn)單的海量數(shù)據(jù)但索引能力有限，而Oracle等傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)(RDBMS)能夠提供豐富的查詢能力，但卻疲于應(yīng)對(duì)TB級(jí)別的海量數(shù)據(jù)存儲(chǔ)，HBase對(duì)傳統(tǒng)的RDBMS并不是取代關(guān)系，而是一種補(bǔ)充。
HBase與HDFS
我們都知道HBase的數(shù)據(jù)是存儲(chǔ)于HDFS里面的，相信大家也都有這么的認(rèn)知：
·HBase是一個(gè) 分布式數(shù)據(jù)庫(kù) ，HDFS是一個(gè) 分布式文件系統(tǒng)
理解了這一點(diǎn)，我們先來(lái)粗略回答本文已開始提出的其中兩個(gè)問題：
·HBase中的數(shù)據(jù)為何不直接存放于HDFS之上?
HBase中存儲(chǔ)的海量數(shù)據(jù)記錄，通常在幾百Bytes到KB級(jí)別，如果將這些數(shù)據(jù)直接存儲(chǔ)于HDFS之上，會(huì)導(dǎo)致大量的小文件產(chǎn)生，為HDFS的元數(shù)據(jù)管理節(jié)點(diǎn)(NameNode)帶來(lái)沉重的壓力。
·文件能否直接存儲(chǔ)于HBase里面?
如果是幾MB的文件，其實(shí)也可以直接存儲(chǔ)于HBase里面，我們暫且將這類文件稱之為小文件，HBase提供了一個(gè)名為MOB的特性來(lái)應(yīng)對(duì)這類小文件的存儲(chǔ)。但如果是更大的文件，強(qiáng)烈不建議用HBase來(lái)存儲(chǔ)，關(guān)于這里更多的原因，希望你在詳細(xì)讀完本文所有內(nèi)容之后能夠自己解答。
集群角色
關(guān)于集群環(huán)境，你可以使用國(guó)內(nèi)外大數(shù)據(jù)廠商的平臺(tái)，如Cloudera，Hontonworks以及國(guó)內(nèi)的華為，都發(fā)行了自己的企業(yè)版大數(shù)據(jù)平臺(tái)，另外，華為云、阿里云中也均推出了全托管式的HBase服務(wù)。
我們假設(shè)集群環(huán)境已經(jīng)Ready了，先來(lái)看一下集群中的 關(guān)鍵角色 ：
管理節(jié)點(diǎn)獨(dú)立于數(shù)據(jù)節(jié)點(diǎn)部署
如果是基于物理機(jī)部署，每一臺(tái)物理機(jī)節(jié)點(diǎn)上可以設(shè)置幾個(gè)RegionServers/DataNodes來(lái)提升資源使用率。
也可以選擇基于容器來(lái)部署，如在HBaseCon Asia 2017大會(huì)知乎的演講主題中，就提到了知乎基于Kubernetes部署HBase服務(wù)的實(shí)踐。
對(duì)于公有云HBase服務(wù)而言，為了降低總體擁有成本( TCO )，通常選擇” 計(jì)算與存儲(chǔ)物理分離 “的方式，從架構(gòu)上來(lái)說(shuō)，可能導(dǎo)致平均時(shí)延略有下降，但可以借助于共享存儲(chǔ)底層的IO優(yōu)化來(lái)做一些”彌補(bǔ)”。
HBase集群中的RegionServers可以按邏輯劃分為多個(gè)Groups，一個(gè)表可以與一個(gè)指定的Group綁定，可以將RegionServer Group理解成將一個(gè)大的集群劃分成了多個(gè)邏輯子集群，借此可以實(shí)現(xiàn)多租戶間的隔離，這就是HBase中的 RegionServer Group 特性。
示例數(shù)據(jù)
以我們?nèi)粘Ｉ疃际煜さ氖謾C(jī)通話記錄的存儲(chǔ)為例，先簡(jiǎn)單給出示例數(shù)據(jù)的字段定義：
在本文大部分內(nèi)容中所涉及的一條數(shù)據(jù)，是上面加粗的最后一行” MSISDN1 “為” 13400006666 “這行記錄。
在本系列文章的流程圖中，我們將會(huì)使用一個(gè) 紅色的五角星 來(lái)表示該數(shù)據(jù)所在的位置。
寫數(shù)據(jù)之前：建立連接
Login
在啟用了安全特性的前提下，Login階段是為了完成 用戶認(rèn)證 (確定用戶的合法身份)，這是后續(xù)一切 安全訪問控制 的基礎(chǔ)。
當(dāng)前Hadoop/HBase僅支持基于Kerberos的用戶認(rèn)證，ZooKeeper除了Kerberos認(rèn)證，還能支持簡(jiǎn)單的用戶名/密碼認(rèn)證，但都基于靜態(tài)的配置，無(wú)法動(dòng)態(tài)新增用戶。如果要支持其它第三方認(rèn)證，需要對(duì)現(xiàn)有的安全框架做出比較大的改動(dòng)。
創(chuàng)建Connection
Connection可以理解為一個(gè)HBase集群連接的抽象，建議使用ConnectionFactory提供的工具方法來(lái)創(chuàng)建。因?yàn)镠Base當(dāng)前提供了兩種連接模式：同步連接，異步連接，這兩種連接模式下所創(chuàng)建的Connection也是不同的。我們給出ConnectionFactory中關(guān)于獲取這兩種連接的典型方法定義：
預(yù)設(shè)合理的數(shù)據(jù)分片 – Region
分片數(shù)量會(huì)給讀寫吞吐量帶來(lái)直接的影響，因此，建表時(shí)通常建議由用戶主動(dòng)指定劃分 Region分割點(diǎn) ，來(lái)設(shè)定Region的數(shù)量。
HBase中數(shù)據(jù)是按照RowKey的字典順序排列的，為了能夠劃分出合理的Region分割點(diǎn)，需要依據(jù)如下幾點(diǎn)信息：
·Key的組成結(jié)構(gòu)
·Key的數(shù)據(jù)分布預(yù)估
如果不能基于Key的組成結(jié)構(gòu)來(lái)預(yù)估數(shù)據(jù)分布的話，可能會(huì)導(dǎo)致數(shù)據(jù)在Region間的分布不均勻
·讀寫并發(fā)度需求
·依據(jù)讀寫并發(fā)度需求，設(shè)置合理的Region數(shù)量
·為表定義合理的Schema
既然HBase號(hào)稱”schema-less”的數(shù)據(jù)存儲(chǔ)系統(tǒng)，那何來(lái)的是schema? 的確，在數(shù)據(jù)庫(kù)范式的支持上，HBase非常弱，這里的Schema，主要指如下一些信息的設(shè)置：
·NameSpace設(shè)置
·Column Family的數(shù)量
每一個(gè)Column Family中所關(guān)聯(lián)的一些 關(guān)鍵配置 ：
·Compression
HBase當(dāng)前可以支持Snappy，GZ，LZO，LZ4，Bzip2以及ZSTD壓縮算法
·DataBlock Encoding
HBase針對(duì)自身的特殊數(shù)據(jù)模型所做的一種壓縮編碼
·BloomFilter
可用來(lái)協(xié)助快速判斷一條記錄是否存在
·TTL
指定數(shù)據(jù)的過期時(shí)間
·StoragePolicy
指定Column Family的存儲(chǔ)策略，可選配置有：
“ALL_SSD”，”O(jiān)NE_SSD”，”HOT”，”WARM”，”COLD”，”LAZY_PERSIST”
HBase中并不需要預(yù)先設(shè)置Column定義信息，這就是HBase schema-less設(shè)計(jì)的核心。
Client發(fā)送建表請(qǐng)求到Master
建表的請(qǐng)求是通過RPC的方式由Client發(fā)送到Master:
·RPC接口基于Protocol Buffer定義
·建表相關(guān)的描述參數(shù)，也由Protocol Buffer進(jìn)行定義及序列化
Client端側(cè)調(diào)用了Master服務(wù)的什么接口，參數(shù)是什么，這些信息都被通過RPC通信傳輸?shù)組aster側(cè)，Master再依據(jù)這些接口\參數(shù)描述信息決定要執(zhí)行的操作。2.0版本中，HBase目前已經(jīng)支持基于Netty的 異步RPC框架 。
關(guān)于HBase RPC框架
早期的HBase RPC框架，完全借鑒了Hadoop中的實(shí)現(xiàn)，那時(shí)，Netty項(xiàng)目尚不盛行。
Master側(cè)接收到Client側(cè)的建表請(qǐng)求以后，一些主要操作包括：
生成每一個(gè)Region的描述信息對(duì)象HRegionInfo，這些描述信息包括：Region ID, Region名稱，Key范圍，表名稱等信息
生成每一個(gè)Region在HDFS中的文件目錄
將HRegionInfo信息寫入到記錄元數(shù)據(jù)的hbase:meta表中。
說(shuō)明
meta表位于名為”hbase”的namespace中，因此，它的全稱為”hbase:meta”。
但在本系列文章范疇內(nèi)，常將其縮寫為”meta”。
整個(gè)過程中，新表的狀態(tài)也是記錄在hbase:meta表中的，而不用再存儲(chǔ)在ZooKeeper中。
如果建表執(zhí)行了一半，Master進(jìn)程掛掉了，如何處理?這里是由HBase自身提供的一個(gè)名為 Procedure(V2) 的框架來(lái)保障操作的事務(wù)性的，備Master接管服務(wù)以后，將會(huì)繼續(xù)完成整個(gè)建表操作。
一個(gè)被創(chuàng)建成功的表，還可以被執(zhí)行如下操作：
Disable 將所有的Region下線，該表暫停讀寫服務(wù)
Enable 將一個(gè)Disable過的表重新Enable，也就是上線所有的Region來(lái)正常提供讀寫服務(wù)
Alter 更改表或列族的描述信息
Master分配Regions到各個(gè)RegionServers
新創(chuàng)建的所有的Regions，通過 AssignmentManager 將這些Region按照輪詢(Round-Robin)的方式分配到每一個(gè)RegionServer中，具體的分配計(jì)劃是由 LoadBalancer 來(lái)提供的。
AssignmentManager負(fù)責(zé)所有Regions的分配/遷移操作，Master中有一個(gè)定時(shí)運(yùn)行的線程，來(lái)檢查集群中的Regions在各個(gè)RegionServer之間的負(fù)載是否是均衡的，如果不均衡，則通過LoadBalancer生成相應(yīng)的Region遷移計(jì)劃，HBase中支持多種負(fù)載均衡算法，有最簡(jiǎn)單的僅考慮各RegionServer上的Regions數(shù)目的負(fù)載均衡算法，有基于遷移代價(jià)的負(fù)載均衡算法，也有數(shù)據(jù)本地化率優(yōu)先的負(fù)載均衡算法，因?yàn)檫@一部分已經(jīng)提供了插件化機(jī)制，用戶也可以自定義負(fù)載均衡算法。
“HBase入門問題有哪些”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！
重慶分公司
重慶分公司
