一條數(shù)據(jù)的HBase之旅，簡(jiǎn)明HBase入門教程-開篇

開篇

開篇

用慣了Oracle/MySQL的同學(xué)們，心目中的數(shù)據(jù)表，應(yīng)該是長(zhǎng)成這樣的：

這種表結(jié)構(gòu)規(guī)整，每一行都有固定的列構(gòu)成，因此，非常適合結(jié)構(gòu)化數(shù)據(jù)的存儲(chǔ)。但在NoSQL領(lǐng)域，數(shù)據(jù)表的模樣卻往往換成了另外一種"畫風(fēng)"：

行由看似"雜亂無(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是基于Hadoop構(gòu)建的一個(gè)分布式的、可伸縮的海量數(shù)據(jù)存儲(chǔ)系統(tǒng)。

HBase常被用來(lái)存放一些海量的(通常在TB級(jí)別以上)結(jié)構(gòu)比較簡(jiǎn)單的數(shù)據(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)：

從Apache HBase所關(guān)聯(lián)的github項(xiàng)目的commits統(tǒng)計(jì)信息來(lái)看，也可以看出來(lái)該項(xiàng)目非常活躍：

(需要說(shuō)明的一點(diǎn)：HBase中的每一次commit，都已經(jīng)過(guò)社區(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)輪廓，所以很多特性/流程被被一言帶過(guò)，但這些特性在社區(qū)中往往經(jīng)歷了漫長(zhǎng)的開發(fā)過(guò)程。至于講什么以及講到什么程度，本文都做了艱難的取舍，在講解的過(guò)程中，將會(huì)穿插解答本文開始所提出的針對(duì)初學(xué)者的一些常見問(wèn)題。

本文適用于HBase新手，而對(duì)于具備一定經(jīng)驗(yàn)的HBase開發(fā)人員，相信本文也可以提供一些有價(jià)值的參考。本文內(nèi)容基于HBase 2.0 beta 2版本，對(duì)比于1.0甚至是更早期的版本，2.0出現(xiàn)了大量變化，下面這些問(wèn)題的答案將揭示部分關(guān)鍵的變化（新手可以直接跳過(guò)這些問(wèn)題）：

HBase meta Region在哪里提供服務(wù)？

HBase是否可以保證單行操作的原子性？

Region中寫WAL與寫MemStore的順序是怎樣的？

你是否遇到過(guò)Region長(zhǎng)時(shí)間處于RIT的狀態(tài)？ 你認(rèn)為舊版本中Assignment Manager的主要問(wèn)題是什么？

在面對(duì)Full GC問(wèn)題時(shí)，你嘗試做過(guò)哪些優(yōu)化？

你是否深究過(guò)HBase Compaction帶來(lái)的“寫放大”有多嚴(yán)重？

HBase的RPC框架存在什么問(wèn)題？

導(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)。

約定

1. 本文范圍內(nèi)針對(duì)一些關(guān)鍵特性/流程，使用了加粗以及加下劃線的方式做了強(qiáng)調(diào)，如"ProcedureV2"。這些特性往往在本文中僅僅被粗淺提及，后續(xù)計(jì)劃以獨(dú)立的文章來(lái)介紹這些特性/流程。

2. 術(shù)語(yǔ)縮寫：對(duì)于一些進(jìn)程/角色名稱，在本文范圍內(nèi)可能通過(guò)縮寫形式來(lái)表述：

數(shù)據(jù)模型

RowKey

用來(lái)表示唯一一行記錄的主鍵，HBase的數(shù)據(jù)是按照RowKey的字典順序進(jìn)行全局排序的，所有的查詢都只能依賴于這一個(gè)排序維度。

通過(guò)下面一個(gè)例子來(lái)說(shuō)明一下"字典排序"的原理：

RowKey列表{"abc", "a", "bdf", "cdf", "def"}按字典排序后的結(jié)果為{"a", "abc", "bdf", "cdf", "defg"}

也就是說(shuō)，當(dāng)兩個(gè)RowKey進(jìn)行排序時(shí)，先對(duì)比兩個(gè)RowKey的第一個(gè)字節(jié)，如果相同，則對(duì)比第二個(gè)字節(jié)，依次類推...如果在對(duì)比到第M個(gè)字節(jié)時(shí)，已經(jīng)超出了其中一個(gè)RowKey的字節(jié)長(zhǎng)度，那么，短的RowKey要被排在另外一個(gè)RowKey的前面。

稀疏矩陣

參考了Bigtable，HBase中一個(gè)表的數(shù)據(jù)是按照稀疏矩陣的方式組織的，"開篇"部分給出了一張關(guān)于HBase數(shù)據(jù)表的抽象圖，我們?cè)俳Y(jié)合下表來(lái)加深大家關(guān)于"稀疏矩陣"的印象：

看的出來(lái)：每一行中，列的組成都是靈活的，行與行之間并不需要遵循相同的列定義， 也就是HBase數(shù)據(jù)表"schema-less"的特點(diǎn)。

Region

區(qū)別于Cassandra/DynamoDB的"Hash分區(qū)"設(shè)計(jì)，HBase中采用了"Range分區(qū)"，將Key的完整區(qū)間切割成一個(gè)個(gè)的"Key Range" ，每一個(gè)"Key Range"稱之為一個(gè)Region。

也可以這么理解：將HBase中擁有數(shù)億行的一個(gè)大表，橫向切割成一個(gè)個(gè)"子表"，這一個(gè)個(gè)"子表"就是Region：

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ù)先定義。

KeyValue

KeyValue的設(shè)計(jì)不是源自Bigtable，而是要追溯至論文"The log-structured merge-tree(LSM-Tree)"。每一行中的每一列數(shù)據(jù)，都被包裝成獨(dú)立的擁有特定結(jié)構(gòu)的KeyValue，KeyValue中包含了豐富的自我描述信息:

看的出來(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è)問(wèn)題：

什么樣的數(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)知：

理解了這一點(diǎn)，我們先來(lái)粗略回答本文已開始提出的其中兩個(gè)問(wèn)題：

集群角色

我們假設(shè)集群環(huán)境已經(jīng)Ready了，先來(lái)看一下集群中的關(guān)鍵角色：

相信大部分人對(duì)這些角色都已經(jīng)有了一定程度的了解，我們快速的介紹一下各個(gè)角色在集群中的主要職責(zé)：

ZooKeeper

在一個(gè)擁有多個(gè)節(jié)點(diǎn)的分布式系統(tǒng)中，假設(shè)，只能有一個(gè)節(jié)點(diǎn)是主節(jié)點(diǎn)，如何快速的選舉出一個(gè)主節(jié)點(diǎn)而且讓所有的節(jié)點(diǎn)都認(rèn)可這個(gè)主節(jié)點(diǎn)？這就是HBase集群中存在的一個(gè)最基礎(chǔ)命題。

利用ZooKeeper就可以非常簡(jiǎn)單的實(shí)現(xiàn)這類"仲裁"需求，ZooKeeper還提供了基礎(chǔ)的事件通知機(jī)制，所有的數(shù)據(jù)都以 ZNode的形式存在，它也稱得上是一個(gè)"微型數(shù)據(jù)庫(kù)"。

NameNode

HDFS作為一個(gè)分布式文件系統(tǒng)，自然需要文件目錄樹的元數(shù)據(jù)信息，另外，在HDFS中每一個(gè)文件都是按照Block存儲(chǔ)的，文件與Block的關(guān)聯(lián)也通過(guò)元數(shù)據(jù)信息來(lái)描述。NameNode提供了這些元數(shù)據(jù)信息的存儲(chǔ)。

DataNode

HDFS的數(shù)據(jù)存放節(jié)點(diǎn)。

RegionServer

HBase的數(shù)據(jù)服務(wù)節(jié)點(diǎn)。

Master

HBase的管理節(jié)點(diǎn)，通常在一個(gè)集群中設(shè)置一個(gè)主Master，一個(gè)備Master，主備角色的"仲裁"由ZooKeeper實(shí)現(xiàn)。 Master主要職責(zé)：

①負(fù)責(zé)管理所有的RegionServer。

②建表/修改表/刪除表等DDL操作請(qǐng)求的服務(wù)端執(zhí)行主體。

③管理所有的數(shù)據(jù)分片(Region)到RegionServer的分配。

④如果一個(gè)RegionServer宕機(jī)或進(jìn)程故障，由Master負(fù)責(zé)將它原來(lái)所負(fù)責(zé)的Regions轉(zhuǎn)移到其它的RegionServer上繼續(xù)提供服務(wù)。

⑤Master自身也可以作為一個(gè)RegionServer提供服務(wù)，該能力是可配置的。

集群部署建議

如果基于物理機(jī)/虛擬機(jī)部署，通常建議：

1. RegionServer與DataNode聯(lián)合部署，RegionServer與DataNode按1:1比例設(shè)置。

這種部署的優(yōu)勢(shì)在于，RegionServer中的數(shù)據(jù)文件可以存儲(chǔ)一個(gè)副本于本機(jī)的DataNode節(jié)點(diǎn)中，從而在讀取時(shí)可以利用HDFS中的"短路徑讀取(Short Circuit)"來(lái)繞過(guò)網(wǎng)絡(luò)請(qǐng)求，降低讀取時(shí)延。

2. 管理節(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)粘Ｉ疃际煜さ?**的存儲(chǔ)為例，先簡(jiǎn)單給出示例數(shù)據(jù)的字段定義：

如上定義與電信領(lǐng)域的通話記錄字段定義相去甚遠(yuǎn)，本文力求簡(jiǎn)潔，僅給出了最簡(jiǎn)單的示例。如下是"虛構(gòu)"的樣例數(shù)據(jù)：

在本文大部分內(nèi)容中所涉及的一條數(shù)據(jù)，是上面加粗的最后一行"MSISDN1"為"13400006666"這行記錄。

在本系列文章的流程圖中，我們將會(huì)使用一個(gè)紅色的五角星來(lái)表示該數(shù)據(jù)所在的位置。

寫數(shù)據(jù)之前：創(chuàng)建連接

Login

在啟用了安全特性的前提下，Login階段是為了完成用戶認(rèn)證(確定用戶的合法身份)，這是后續(xù)一切安全訪問(wèn)控制的基礎(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)于獲取這兩種連接的典型方法定義：

Connection中主要維護(hù)著兩類共享的資源：

線程池

Socket連接

這些資源都是在真正使用的時(shí)候才會(huì)被創(chuàng)建，因此，此時(shí)的連接還只是一個(gè)"虛擬連接"。

寫數(shù)據(jù)之前：創(chuàng)建數(shù)據(jù)表

DDL操作的抽象接口 - Admin

Admin定義了常規(guī)的DDL接口，列舉幾個(gè)典型的接口：

預(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è)置：

1.?NameSpace設(shè)置

2. Column Family的數(shù)量

3. 每一個(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ù)的過(guò)期時(shí)間

⑤ StoragePolicy

指定Column Family的存儲(chǔ)策略，可選項(xiàng)有："ALL_SSD"，"ONE_SSD"，"HOT"，"WARM"，"COLD"，"LAZY_PERSIST"

HBase中并不需要預(yù)先設(shè)置Column定義信息，這就是HBase schema less設(shè)計(jì)的核心。

Client發(fā)送建表請(qǐng)求到Master

建表的請(qǐng)求是通過(guò)RPC的方式由Client發(fā)送到Master:

RPC接口基于Protocol Buffer定義

建表相關(guān)的描述參數(shù)，也由Protocol Buffer進(jìn)行定義及序列化

Client端側(cè)調(diào)用了Master服務(wù)的什么接口，參數(shù)是什么，這些信息都被通過(guò)RPC通信傳輸?shù)組aster側(cè)，Master再依據(jù)這些接口\參數(shù)描述信息決定要執(zhí)行的操作。2.0版本中，HBase目前已經(jīng)支持基于Netty的異步RPC框架。

Master側(cè)接收到Client側(cè)的建表請(qǐng)求以后，一些主要操作包括：

1. 生成每一個(gè)Region的描述信息對(duì)象HRegionInfo，這些描述信息包括：Region ID, Region名稱，Key范圍，表名稱等信息。

2. 生成每一個(gè)Region在HDFS中的文件目錄。

3. 將HRegionInfo信息寫入到記錄元數(shù)據(jù)的hbase:meta表中。

整個(gè)過(guò)程中，新表的狀態(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過(guò)的表重新Enable，也就是上線所有的Region來(lái)正常提供讀寫服務(wù)

Alter? 更改表或列族的描述信息

Master分配Regions

新創(chuàng)建的所有的Regions，通過(guò)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ù)載是否是均衡的，如果不均衡，則通過(guò)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ù)載均衡算法。

總結(jié)

本文主要介紹了如下內(nèi)容：

1. HBase項(xiàng)目概述，呈現(xiàn)了HBase社區(qū)的活躍度以及搜索引擎熱度等信息

2. HBase數(shù)據(jù)模型部分，講到了RowKey，稀疏矩陣，Region，Column Family，KeyValue等概念

3. 基于HBase的數(shù)據(jù)模型，介紹了HBase的適合場(chǎng)景（以實(shí)體/事件為中心的簡(jiǎn)單結(jié)構(gòu)的數(shù)據(jù)）

4. 介紹了HBase與HDFS的關(guān)系

5. 介紹了集群的關(guān)鍵角色：ZooKeeper, Master, RegionServer，NameNode, DataNode

6. 集群部署建議

7. 給出了一些示例數(shù)據(jù)

8. 寫數(shù)據(jù)之前的準(zhǔn)備工作：建立集群連接，建表（建表時(shí)應(yīng)該定義合理的Schema以及設(shè)置合理的Region數(shù)量），建表由Master處理，新創(chuàng)建的Regions由Region AssignmentManager負(fù)責(zé)分配到各個(gè)RegionServer。

下一篇文章將正式開始介紹寫數(shù)據(jù)的流程。

致謝

感謝Apache HBase PMC成員Ted Yu，李鈺，張鐸對(duì)本文中與2.0版本相關(guān)特性/流程描述內(nèi)容方面的Review，感謝王瓊、向宏偉以及陳土炎等幾位同學(xué)給本文內(nèi)容方面提出的寶貴意見。感謝畢美杰為本文提供的漂亮的封面圖片：）

本文轉(zhuǎn)載自微信公眾號(hào)【NoSql漫談】。

NoSQL數(shù)據(jù)庫(kù)

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。