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

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