1.Rowkey是什么

可以理解為關(guān)系型數(shù)據(jù)庫(kù)MySQL Oracle的主鍵,用于標(biāo)識(shí)唯一的行。
完全是由用戶指定的一串不重復(fù)的字符串。
HBase中的數(shù)據(jù)永遠(yuǎn)是根據(jù)Rowkey的字典排序來(lái)排序的。

網(wǎng)站設(shè)計(jì)、成都網(wǎng)站建設(shè),成都做網(wǎng)站公司-創(chuàng)新互聯(lián)已向上千多家企業(yè)提供了,網(wǎng)站設(shè)計(jì),網(wǎng)站制作,網(wǎng)絡(luò)營(yíng)銷(xiāo)等服務(wù)!設(shè)計(jì)與技術(shù)結(jié)合,多年網(wǎng)站推廣經(jīng)驗(yàn),合理的價(jià)格為您打造企業(yè)品質(zhì)網(wǎng)站。

2.Rowkey的作用

讀寫(xiě)數(shù)據(jù)時(shí) 通過(guò) RowKey 找到 對(duì)應(yīng) 的 Region，例如需要查找一條數(shù)據(jù)肯定需要知道他的RowKey ，寫(xiě)數(shù)據(jù)的時(shí)候也要根據(jù)RowKey 來(lái)寫(xiě)。
MemStore中的數(shù)據(jù)按Rowkey字典順序排序，寫(xiě)數(shù)據(jù)的時(shí)候會(huì)先將數(shù)據(jù)放到MemStore也就是內(nèi)存，內(nèi)存中的數(shù)據(jù)是按照Rowkey字典順序排序的。
HFile中的數(shù)據(jù)按RowKey字典順序排序，內(nèi)存中的數(shù)據(jù)最后也會(huì)持久化到磁盤(pán)中，磁盤(pán)的數(shù)據(jù)HFile也是按RowKey字典順序排序。

3.RowKey對(duì)查詢的影響

例：RowKey由uid+phone+name組成

1.可以很好的支持的場(chǎng)景

• uid=111 AND phone = 123 AND name = abc

• uid=111 AND phone = 123

• uid=111 AND phone = 12?

• uid=111

  這種場(chǎng)景下我們都指定了uid部分,也就是RowKey的第一部分,第一種查詢的RowKey是完整的格式,所以查詢效率是最好的,后邊的三個(gè)雖然沒(méi)有指定完整RowKey,但是查詢的支持度也還不錯(cuò).

2.難支持的場(chǎng)景

• phone = 123 AND name = abc

• phone = 123

• name = abc

  這種場(chǎng)景下并沒(méi)有指定RowKey的第一部分uid,只通過(guò)phone跟name去做查詢,也就是不指定先導(dǎo)部分,那么這種場(chǎng)景會(huì)導(dǎo)致HBase的查詢的時(shí)候去進(jìn)行全表掃描,降低了查詢效率.

4.RowKey對(duì)Region劃分影響

HBase表的數(shù)據(jù)是按照RowKey來(lái)分散到不同的Region,不合理的RowKey設(shè)計(jì)會(huì)導(dǎo)致熱點(diǎn)問(wèn)題,熱點(diǎn)問(wèn)題是大量的Client直接訪問(wèn)集群的一個(gè)或極少數(shù)個(gè)節(jié)點(diǎn),而集群中的其他節(jié)點(diǎn)卻處于相對(duì)空閑的狀態(tài),從而影響對(duì)HBase表的讀寫(xiě)性能.

5.RowKey的設(shè)計(jì)技巧

1.Salting(加鹽)

Salting的原理是將固定長(zhǎng)度的隨機(jī)數(shù)放在行鍵的起始處,具體就是給 rowkey 分配一個(gè)隨機(jī)前綴 以使得它和之前排序不同。分配的前綴種類(lèi)數(shù)量應(yīng)該和你想使數(shù)據(jù)分散到不同的 region 的數(shù)量一致。 如果你有一些 熱點(diǎn) rowkey 反復(fù)出現(xiàn)在其他分布均勻的 rwokey 中，加鹽是很有用的。

例:假如你有下列 rowkey，你表中每一個(gè) region 對(duì)應(yīng)字母表中每一個(gè)字母。 以 ‘a(chǎn)’ 開(kāi)頭是同一個(gè)region, 'b’開(kāi)頭的是同一個(gè)region。在表中，所有以 'f’開(kāi)頭的都在同一個(gè) region， 它們的 rowkey 像下面這樣：

foo0001 a-foo0001

foo0002 ===>    b-foo0002

foo0003 c-foo0003

foo0004 d-foo0004

假如你需要將上面這個(gè) region 分散到 4個(gè) region。你可以用4個(gè)不同的鹽：‘a(chǎn)’, ‘b’, ‘c’, ‘d’.在這個(gè)方案下，每一個(gè)字母前綴都會(huì)在不同的 region 中。加鹽之后，就像上邊的例子.

所以，你可以向4個(gè)不同的 region 寫(xiě)，理論上說(shuō)，如果所有人都向同一個(gè)region 寫(xiě)的話，你將擁有之前4倍的吞吐量。

優(yōu)缺點(diǎn):由于前綴是隨機(jī)生成的,因此想要按照字典順序找到這些行,則需要做更多的工作,從這個(gè)角度上看,salting增加了寫(xiě)操作的吞吐量,卻也增加了讀操作的開(kāi)銷(xiāo).

2.Hashing

Hashing 的原理是計(jì)算 RowKey 的 hash 值，然后取 hash 的部分字符串和原來(lái)的 RowKey 進(jìn)行拼接。這里說(shuō)的 hash 包含 MD5、sha1、sha256或sha512等算法,并不是僅限于Java的Hash值計(jì)算。

例:比如我們有如下的 RowKey：

                foo0001                 95f18cfoo0001

                foo0002     ===>        6ccc20foo0002

                foo0003                 b61d00foo0003

                foo0004                 1a7475foo0004

我們使用 md5 計(jì)算這些 RowKey 的 hash 值，然后取前 6 位和原來(lái)的 RowKey 拼接得到新的 RowKey,如上

優(yōu)缺點(diǎn)：可以一定程度打散整個(gè)數(shù)據(jù)集，但是不利于 Scan；比如我們使用 md5 算法，來(lái)計(jì)算Rowkey的md5值，然后截取前幾位的字符串。
常見(jiàn)用法:subString(MD5(設(shè)備ID), 0, x) + 設(shè)備ID，其中x一般取5或6。

3.Reversing(反轉(zhuǎn))

Reversing 的原理是反轉(zhuǎn)一段固定長(zhǎng)度或者全部的鍵。

例:比如我們有以下 URL ，并作為 RowKey：

                flink.iteblog.com                           moc.golbeti.knilf
                www.iteblog.com          ===>               moc.golbeti.www
                carbondata.iteblog.com                      moc.golbeti.atadnobrac
                def.iteblog.com                             moc.golbeti.fed

這些 URL 其實(shí)屬于同一個(gè)域名，但是由于前面不一樣，導(dǎo)致數(shù)據(jù)不在一起存放。我們可以對(duì)其進(jìn)行反轉(zhuǎn),如上,經(jīng)過(guò)這個(gè)之后，前綴就相同了,這些 URL 的數(shù)據(jù)就可以放一起了。

優(yōu)缺點(diǎn):有效的打亂了行鍵,但是卻犧牲了行排序的屬性.

6.RowKey的長(zhǎng)度

RowKey 可以是任意的字符串，最大長(zhǎng)度64KB（因?yàn)?Rowlength 占2字節(jié)）。建議越短越好，原因如下：

• 數(shù)據(jù)的持久化文件HFile中是按照KeyValue存儲(chǔ)的，如果rowkey過(guò)長(zhǎng)，比如超過(guò)100字節(jié)，1000w行數(shù)據(jù)，光rowkey就要占用100*1000w=10億個(gè)字節(jié)，將近1G數(shù)據(jù)，這樣會(huì)極大影響HFile的存儲(chǔ)效率；
• MemStore將緩存部分?jǐn)?shù)據(jù)到內(nèi)存，如果rowkey字段過(guò)長(zhǎng)，內(nèi)存的有效利用率就會(huì)降低，系統(tǒng)不能緩存更多的數(shù)據(jù)，這樣會(huì)降低檢索效率；
• 目前操作系統(tǒng)都是64位系統(tǒng)，內(nèi)存8字節(jié)對(duì)齊，控制在16個(gè)字節(jié)，8字節(jié)的整數(shù)倍利用了操作系統(tǒng)的最佳特性。

7.設(shè)計(jì)案例剖析

1.交易類(lèi)表 Rowkey 設(shè)計(jì)

• 查詢某個(gè)賣(mài)家某段時(shí)間內(nèi)的交易記錄
  sellerId + timestamp + orderId

• 查詢某個(gè)買(mǎi)家某段時(shí)間內(nèi)的交易記錄
  buyerId + timestamp ＋orderId

• 根據(jù)訂單號(hào)查詢
  orderNo

如果某個(gè)商家賣(mài)了很多商品，按第一種方式,就有可能會(huì)有大量RowKey前綴相同的數(shù)據(jù)在相同的Region上,造成熱點(diǎn)問(wèn)題,可以如下設(shè)計(jì) Rowkey 實(shí)現(xiàn)快速搜索 salt + sellerId + timestamp 其中，salt 是隨機(jī)數(shù)。

我們?cè)谠瓉?lái)的結(jié)構(gòu)之前進(jìn)行了一步加鹽salt操作,例如加上一個(gè)隨機(jī)數(shù),這樣就可以把這些數(shù)據(jù)分散到不同的Region上去了.    

可以支持的場(chǎng)景：

• 全表 Scan,因?yàn)檫M(jìn)行了加鹽操作,數(shù)據(jù)分散到了不同的Region上,Scan的時(shí)候就會(huì)去不同的Region上去Scan,這樣就提升高并發(fā),也就提升檢索效率.
• 按照 sellerId 查詢
• 按照 sellerId + timestamp 查詢

2.金融風(fēng)控 Rowkey 設(shè)計(jì)

查詢某個(gè)用戶的用戶畫(huà)像數(shù)據(jù)

prefix + uid

prefix + idcard

prefix + tele

其中前綴的生成 prefix = substr(md5(uid),0 ,x)， x 取 5-6。uid、idcard以及 tele 分別表示用戶唯一標(biāo)識(shí)符、×××、手機(jī)號(hào)碼。

3.車(chē)聯(lián)網(wǎng) Rowkey 設(shè)計(jì)

• 查詢某輛車(chē)在某個(gè)時(shí)間范圍的數(shù)據(jù),例如發(fā)動(dòng)機(jī)數(shù)據(jù)
  carId + timestamp

• 某批次的車(chē)太多，造成熱點(diǎn)
  prefix + carId + timestamp

其中 prefix = substr(md5(uid),0 ,x)

4.倒序時(shí)間戳(時(shí)間倒排)

查詢用戶最新的操作記錄或者查詢用戶某段時(shí)間的操作記錄，RowKey 設(shè)計(jì)如下：
uid + Long.Max_Value - timestamp

支持的場(chǎng)景

• 查詢用戶最新的操作記錄
  Scan [uid] startRow [uid][00000000000] stopRow [uid][uid][Long.Max_Value - timestamp]

  這樣就能查出比如說(shuō)最近100條數(shù)據(jù)

• 查詢用戶某段時(shí)間的操作記錄
  Scan [uid] startRow [uid][Long.Max_Value - startTime] stopRow uid [uid][Long.Max_Value - endTime]

5.二級(jí)索引

例:有一張HBase表結(jié)構(gòu)及數(shù)據(jù)如下

問(wèn):如何查找phone=13111111111的用戶?

遇到這種需求的時(shí)候,HBase的設(shè)計(jì)肯定是滿足不了的,這時(shí)候就要引入二級(jí)索引,將phone當(dāng)做RowKey,uid/name當(dāng)做列名構(gòu)建二級(jí)索引.

如果不依賴第三方組建的話,可以自己編碼實(shí)現(xiàn)二級(jí)索引,同時(shí)也可以通過(guò)Phoenix或者Solr創(chuàng)建二級(jí)索引.

SQL+OLTP ==> Phonenix

全文檢索+二級(jí)索引 ==> Solr/ES