網(wǎng)易視頻云：HBase最佳實(shí)踐列族設(shè)計(jì)優(yōu)化.docx

網(wǎng)易視頻云：HBase最佳實(shí)踐列族設(shè)計(jì)優(yōu)化隨著大數(shù)據(jù)的越來越普及，HBase也變得越來越流行。會(huì)用HBase現(xiàn)在已經(jīng)變的并不困難，然而，怎么把它用的更好卻并不簡單。那怎么定義用的好呢？很簡單，在保證系統(tǒng)穩(wěn)定性、可用性的基礎(chǔ)上能夠用最少的系統(tǒng)資源（CPU,IO等）獲得最好的性能（吞吐量，讀寫延遲）就是用的好。HBase是一個(gè)龐大的體系，涉及到很多方面，很多因素都會(huì)影響到系統(tǒng)性能和系統(tǒng)資源使用率，根據(jù)場景對(duì)這些配置進(jìn)行優(yōu)化會(huì)很大程度上提升系統(tǒng)的性能。筆者總結(jié)至少有如下幾個(gè)方面：HDFS相關(guān)配置優(yōu)化，HBase服務(wù)器端優(yōu)化（GC優(yōu)化、Compaction優(yōu)化、硬件配置優(yōu)化），列族設(shè)計(jì)優(yōu)化，客戶端優(yōu)化等，其中客戶端優(yōu)化在前面已經(jīng)通過超時(shí)機(jī)制、重試機(jī)制講過，后面筆者會(huì)繼續(xù)分別介紹其他三個(gè)優(yōu)化重點(diǎn)。本節(jié)重點(diǎn)介紹列族設(shè)計(jì)優(yōu)化，HBase中基本屬性都是以列族為單位進(jìn)行設(shè)置的，如下示例，用戶創(chuàng)建了一張稱為 NewsClickFeedback的表，表中只有一個(gè)列族Toutiao，緊接著的屬性都是對(duì)此列族進(jìn)行的設(shè)置。這些屬性基本都會(huì)或多或少地影響該表的讀寫性能，但有些屬性用戶只需要理解其意義就知道如何設(shè)置，而有些屬性卻需要根據(jù)場景、根據(jù)業(yè)務(wù)來設(shè)置，比如BLOCKSIZE屬性在不同場景下應(yīng)該如何設(shè)置？還有COMPRESSION屬性和DATA_BLOCK_ENCODING屬性，兩者都可以提供壓縮功能，那到底應(yīng)該選擇哪個(gè)，還是兩個(gè)都需要進(jìn)行設(shè)置？本文就重點(diǎn)介紹這三個(gè)屬性的設(shè)計(jì)原則。BlockSize設(shè)置塊大小是HBase的一個(gè)重要配置選項(xiàng)，默認(rèn)塊大小為64M。對(duì)于不同的業(yè)務(wù)數(shù)據(jù)，塊大小的合理設(shè)置對(duì)讀寫性能有很大的影響。而對(duì)塊大小的調(diào)整，主要取決于兩點(diǎn)：1. 用戶平均讀取數(shù)據(jù)的大小。理論上講，如果用戶平均讀取數(shù)據(jù)的大小較小，建議將塊大小設(shè)置較小，這樣可以使得內(nèi)存可以緩存更多block，讀性能自然會(huì)更好。相反，建議將塊大小設(shè)置較大。為了更好說明上述原理，筆者使用YCSB做了一個(gè)測試，分別在Get、Scan兩種場景下測試不同BlockSize大?。?6K，64K，128K）對(duì)性能的影響。測試結(jié)果分別如下面兩圖：隨著BlockSize的增大，系統(tǒng)隨機(jī)讀的吞吐量不斷降低，延遲不斷增大。64K大小比16K大小的吞吐量大約降低13%，延遲增大13%。同樣的，128K大小比64K大小的吞吐量降低約22%，延遲增大27%。因此，對(duì)于以隨機(jī)讀為主的業(yè)務(wù)，可以適當(dāng)調(diào)低BlockSize的大小，以獲得更好的讀性能。隨著BlockSize增大，scan的吞吐量逐漸增大，延遲不斷降低。64K大小BlockSize比16K大小的吞吐量增加了33%，延遲降低了24%；128K大小比64K大小吞吐量增加了7%，延遲降低了7%；因此，對(duì)于以scan為主的業(yè)務(wù)，可以適當(dāng)增大BlockSize的大小，以獲得更好的讀性能?？梢姡绻麡I(yè)務(wù)請求以Get請求為主，可以考慮將塊大小設(shè)置較小；如果以Scan請求為主，可以將塊大小調(diào)大；默認(rèn)的64M塊大小是在Scan和Get之間取得的一個(gè)平衡。2. 數(shù)據(jù)平均鍵值對(duì)規(guī)模?？梢允褂肏File命令查看平均鍵值對(duì)規(guī)模，如下：從上面輸出的信息可以看出，該HFile的平均鍵值對(duì)規(guī)模為62B + 93B = 155B，相對(duì)較小，在這種情況下可以適當(dāng)將塊大小調(diào)?。ɡ?2KB）。這樣可以使得一個(gè)block內(nèi)不會(huì)有太多kv，kv太多會(huì)增大塊內(nèi)尋址的延遲時(shí)間，因?yàn)镠Base在讀數(shù)據(jù)時(shí)，一個(gè)block內(nèi)部的查找是順序查找。注意：默認(rèn)塊大小適用于多種數(shù)據(jù)使用模式，調(diào)整塊大小是比較高級(jí)的操作。配置錯(cuò)誤將對(duì)性能產(chǎn)生負(fù)面影響。因此建議在調(diào)整之后進(jìn)行測試，根據(jù)測試結(jié)果決定是否可以線上使用。數(shù)據(jù)編碼/壓縮Compress/DeCompress數(shù)據(jù)壓縮是HBase提供的另一個(gè)特性，HBase在寫入數(shù)據(jù)塊到HDFS之前會(huì)首先對(duì)數(shù)據(jù)塊進(jìn)行壓縮，再落盤，從而可以減少磁盤空間使用量。而在讀數(shù)據(jù)的時(shí)候首先從HDFS中加載出block塊之后進(jìn)行解壓縮，然后再緩存到BlockCache，最后返回給用戶。寫路徑和讀路徑分別如下：結(jié)合上圖，來看看數(shù)據(jù)壓縮對(duì)資源使用情況以及讀寫性能的影響：（1） 資源使用情況：壓縮最直接、最重要的作用即是減少數(shù)據(jù)硬盤容量，理論上snappy壓縮率可以達(dá)到5:1，但是根據(jù)測試數(shù)據(jù)不同，壓縮率可能并沒有理論上理想；壓縮/解壓縮無疑需要大量計(jì)算，需要大量CPU資源；根據(jù)讀路徑來看，數(shù)據(jù)讀取到緩存之前block塊會(huì)先被解壓，緩存到內(nèi)存中的block是解壓后的，因此和不壓縮情況相比，內(nèi)存前后基本沒有任何影響。（2） 讀寫性能：因?yàn)閿?shù)據(jù)寫入是先將kv數(shù)據(jù)值寫到緩存，最后再統(tǒng)一flush的硬盤，而壓縮是在flush這個(gè)階段執(zhí)行的，因此會(huì)影響flush的操作，對(duì)寫性能本身并不會(huì)有太大影響；而數(shù)據(jù)讀取如果是從HDFS中讀取的話，首先需要解壓縮，因此理論上讀性能會(huì)有所下降；如果數(shù)據(jù)是從緩存中讀取，因?yàn)榫彺嬷械腷lock塊已經(jīng)是解壓后的，因此性能不會(huì)有任何影響；一般情況下大多數(shù)讀都是熱點(diǎn)讀，緩存讀占大部分比例，壓縮并不會(huì)對(duì)讀有太大影響。可見，壓縮特性就是使用CPU資源換取磁盤空間資源，對(duì)讀寫性能并不會(huì)有太大影響。HBase目前提供了三種常用的壓縮方式：GZip | LZO | Snappy，下面表格是官方分別從壓縮率，編解碼速率三個(gè)方面對(duì)其進(jìn)行對(duì)比：綜合來看，Snappy的壓縮率最低，但是編解碼速率最高，對(duì)CPU的消耗也最小，目前一般建議使用Snappy。Encode/Decode除了數(shù)據(jù)壓縮之外，HBase還提供了數(shù)據(jù)編碼功能。和壓縮一樣，數(shù)據(jù)在落盤之前首先會(huì)對(duì)KV數(shù)據(jù)進(jìn)行編碼；但又和壓縮不同，數(shù)據(jù)塊在緩存前并沒有執(zhí)行解碼，因此即使后續(xù)命中緩存的查詢也是編碼的數(shù)據(jù)塊，需要解碼后才能獲取到具體的KV數(shù)據(jù)。寫路徑和讀路徑分別如下：同樣，來看看數(shù)據(jù)壓縮對(duì)資源使用情況以及讀寫性能的影響：（1） 資源使用情況：和壓縮一樣，編碼最直接、最重要的作用也是減少數(shù)據(jù)硬盤容量，但是數(shù)據(jù)壓縮率一般沒有數(shù)據(jù)壓縮的壓縮率高，理論上只有5:2；編碼/解碼一般也需要大量計(jì)算，需要大量CPU資源；根據(jù)讀路徑來看，數(shù)據(jù)讀取到緩存之前block塊并沒有被解碼，緩存到內(nèi)存中的block是編碼后的，因此和不編碼情況相比，相同數(shù)據(jù)block快占用內(nèi)存更少，即內(nèi)存利用率更高。（2） 讀寫性能：和數(shù)據(jù)壓縮相同，數(shù)據(jù)編碼也是在數(shù)據(jù)flush到hdfs階段執(zhí)行的，因此并不會(huì)直接影響寫入過程；前面講到，數(shù)據(jù)塊是以編碼形式緩存到blockcache中的，因此同樣大小的blockcache可以緩存更多的數(shù)據(jù)塊，這有利于讀性能。另一方面，用戶從緩存中加載出來數(shù)據(jù)塊之后并不能直接獲取KV，而需要先解碼，這卻不利于讀性能?？梢姡瑪?shù)據(jù)編碼在內(nèi)存充足的情況下會(huì)降低讀性能，而在內(nèi)存不足的情況下需要經(jīng)過測試才能得出具體結(jié)論。HBase目前提供了四種常用的編碼方式：Prefix | Diff | Fast_Diff | Prefix_Tree。下圖是Prefix_Tree編碼算法作者做的一個(gè)測試結(jié)果：可見，prefix_tree壓縮算法在不同的block size下性能都比較穩(wěn)定，而另外兩種壓縮算法的查找性能會(huì)隨著blocksize直線下降。對(duì)于我們默認(rèn)的64K的block大小，性能相差40+倍。另外，阿里天梧大牛之前在一篇博文里面做過測試證明了PREFIX_TREE算法的優(yōu)越性，見HBase-0.96中新BlockEncoding算法-PREFIX_TREE壓縮的初步探究及測試，因此一般建議使用PREFIX_TREE編碼壓縮。選擇哪一個(gè)？Why？綜上上面分析，數(shù)據(jù)壓縮和數(shù)據(jù)編碼使命基本相同：消耗CPU資源壓縮數(shù)據(jù)大小，可以認(rèn)為是一種時(shí)間換空間的做法。但，同時(shí)開啟兩個(gè)功能會(huì)不會(huì)更好？如果只需要開啟一個(gè)，優(yōu)先選擇哪一個(gè)？為了更加深刻地認(rèn)識(shí)數(shù)據(jù)壓縮編碼，回答上面兩個(gè)問題，本人在測試環(huán)境使用YCSB做了一個(gè)簡單的測試，分別在四種場景下（無壓縮無編碼、僅壓縮、僅編碼、既壓縮既編碼）對(duì)隨機(jī)讀以及掃描讀的操作延時(shí)、CPU使用率以及對(duì)應(yīng)的壓縮率進(jìn)行了測試。測試條件：數(shù)據(jù)：6000w條記錄，一個(gè)列族，每個(gè)列族10個(gè)列，單條記錄總共1K大??；硬件：單RegionServer，3G BlockCache，CPU：32Intel(R)Xeon(R)CPUE5-2650v22.60GHz測試結(jié)果：結(jié)果分析：1. 數(shù)據(jù)壓縮率并沒有理論上0.2那么高，只有0.7左右，這和數(shù)據(jù)結(jié)構(gòu)有關(guān)系。其中壓縮、編碼、壓縮+編碼三種方式的壓縮率基本相當(dāng)。2. 隨機(jī)讀場景：和默認(rèn)配置相比，snappy壓縮在性能上沒有提升，CPU開銷卻上升了38%；prefix_tree性能上沒有提升，CPU利用率也基本相當(dāng)；snappy+prefix_tree性能沒有提升，CPU開銷上升了38%。3. 區(qū)間掃描場景：和默認(rèn)配置相比，snappy壓縮在性能上略有10%的提升，但是CPU開銷卻上升了23%；prefix_tree性能上略有4%左右的下降，但是CPU開銷也下降了5%； snappy+prefix_tree在性能上基本沒有提升，CPU開銷卻上升了23%；設(shè)計(jì)原則：1. 在任何場景下開啟prefix_tree編碼都是安全的2. 在任何場景下都不要同時(shí)開啟snappy壓縮和prefix_tree編碼3. 通常情況下snappy壓縮并不能比prefix_tree編碼獲得更好的優(yōu)化結(jié)果，如果需要使用snappy需要針對(duì)業(yè)務(wù)數(shù)據(jù)進(jìn)行實(shí)際測試到此為止，