hbase 學習(十四)Facebook針對hbase的優化方案分析

使用hbase的目的是爲了海量數據的隨機讀寫,可是在實際使用中卻發現針對隨機讀的優化和gc是一個很大的問題,並且hbase的數據是存儲在Hdfs,而Hdfs是面向流失數據訪問進行設計的,就不免帶來效率的降低。下面介紹一下Facebook Message系統在HBase online storage場景下的一個案例(《Apache Hadoop Goes Realtime at Facebook》, SIGMOD 2011),最近他們在存儲領域頂級會議FAST2014上發表了一篇論文《Analysis of HDFS Under HBase: A Facebook Messages Case Study》分析了他們在使用HBase中遇到的一些問題和解決方案。該論文首先講了Facebook的分析方法包括tracing/analysis/simulation,FM系統的架構和文件與數據構成等,接下來開始分析FM系統在性能方面的一些問題,並提出瞭解決方案。 
FM系統的主要讀寫I/O負載 數據庫

 

Figure 2描述了每一層的I/O構成,解釋了在FM系統對外請求中讀佔主導,可是因爲logging/compaction/replication/caching致使寫被嚴重放大。apache

  • HBase的設計是分層結構的,依次是DB邏輯層、FS邏輯層、底層系統邏輯層。DB邏輯層提供的對外使用的接口主要操做是put()和get()請求,這兩個操做的數據都要寫到HDFS上,其中讀寫比99/1(Figure 2中第一條)。緩存

  • 因爲DB邏輯層內部爲了保證數據的持久性會作logging,爲了讀取的高效率會作compaction,並且這兩個操做都是寫佔主導的,因此把這兩個操做(overheads)加上以後讀寫比爲79/21(Figure 2中第二條)。網絡

  • 至關於調用put()操做向HBase寫入的數據都是寫入了兩份:一份寫入內存Memstore而後flush到HFile/HDFS,另外一份經過logging直接寫HLog/HDFS。Memstore中積累必定量的數據纔會寫HFile,這使得壓縮比會比較高,而寫HLog要求實時append record致使壓縮比(HBASE-8155)相對較低,致使寫被放大4倍以上。    Compaction操做就是讀取小的HFile到內存merge-sorting成大的HFile而後輸出,加速HBase讀操做。Compaction操做致使寫被放大17倍以上,說明每部分數據平均被重複讀寫了17次,因此對於內容不變的大附件是不適合存儲在HBase中的。因爲讀操做在FM業務中佔主要比例,因此加速讀操做對業務很是有幫助,因此compaction策略會比較激進。 
    HBase的數據reliable是靠HDFS層保證的,即HDFS的三備份策略。那麼也就是上述對HDFS的寫操做都會被轉化成三倍的local file I/O和兩倍的網絡I/O。這樣使得在本地磁盤I/O中衡量讀寫比變成了55/45。架構

  • 然而因爲對本地磁盤的讀操做請求的數據會被本地OS的cache緩存,那麼真正的讀操做是因爲cache miss引發的讀操做的I/O量,這樣使得讀寫比變成了36/64,寫被進一步放大。    另外Figure 3從I/O數據傳輸中真正業務需求的數據大小來看各個層次、各個操做引發的I/O變化。除了上面說的,還發現了整個系統最終存儲在磁盤上有大量的cold data(佔2/3),因此須要支持hot/cold數據分開存儲。app

 

總的來講,HBase stack的logging/compaction/replication/caching會放大寫I/O,致使業務邏輯上讀爲主導的HBase系統在地層實際磁盤I/O中寫佔據了主導。 
FM系統的主要文件類型和大小 
分佈式

FM系統的幾種文件類型如Table 2所示,這個是純業務的邏輯描述。在HBase的每一個RegionServer上的每一個column family對應一個或者多個HFile文件。FM系統中有8個column family,因爲每一個column family存儲的數據的類型和大小不同,使得每一個column family的讀寫比是不同的。並且不多數據是讀寫都會請求的,因此cache all writes可能做用不大(Figure 4)。 
oop

 

對於每一個column family的文件,90%是小於15M的。可是少許的特別大的文件會拉高column family的平均文件大小。例如MessageMeta這個column family的平均文件大小是293M。從這些文件的生命週期來看,大部分FM的數據存儲在large,long-lived files,然而大部分文件倒是small, short-lived。這對HDFS的NameNode提出了很大的挑戰,由於HDFS設計的初衷是爲了存儲少許、大文件準備的,全部的文件的元數據是存儲在NameNode的內存中的,還有有NameNode federation。 
FM系統的主要I/O訪問類型下面從temporal locality, spatial locality, sequentiality的角度來看。 
73.7%的數據只被讀取了一次,可是1.1%的數據被讀取了至少64次。也就是說只有少部分的數據被重複讀取了。可是從觸發I/O的角度,只有19%的讀操做讀取的是隻被讀取一次的數據,而大部分I/O是讀取那些熱數據。 
在HDFS這一層,FM讀取數據沒有表現出sequentiality,也就是說明high-bandwidth, high-latency的機械磁盤不是服務讀請求的理想存儲介質。並且對數據的讀取也沒有表現出spatial locality,也就是說I/O預讀取也沒啥做用。 
解決方案1. Flash/SSD做爲cache使用。 
性能

下面就考慮怎麼架構可以加速這個系統了。目前Facebook的HBase系統每一個Node掛15塊100MB/s帶寬、10ms尋址時間的磁盤。Figure 9代表:a)增長磁盤塊數有點用;b)增長磁盤帶寬沒啥大用;c)下降尋址時間很是有用。 
因爲少部分一樣的數據會被常常讀取,因此一個大的cache可以把80%左右的讀取操做攔截而不用觸發磁盤I/O,並且只有這少部分的hot data須要被cache。那麼拿什麼樣的存儲介質作cache呢?Figure 11說明若是拿足夠大的Flash作二級緩存,cache命中率會明顯提升,同時cache命中率跟內存大小關係並不大。 
注:關於拿Flash/SSD作cache,能夠參考HBase BucketBlockCache(HBASE-7404
優化

咱們知道你們比較關心Flash/SSD壽命的問題,在內存和Flash中shuffling數據可以使得最熱的數據被交換到內存中,從而提高讀性能,可是會下降Flash的壽命,可是隨着技術的發展這個問題帶來的影響可能愈來愈小。 
說完加速讀的cache,接着討論了Flash做爲寫buffer是否會帶來性能上的提高。因爲HDFS寫操做只要數據被DataNode成功接收到內存中就保證了持久性(由於三臺DataNode同時存儲,因此認爲從DataNode的內存flush到磁盤的操做不會三個DataNode都失敗),因此拿Flash作寫buffer不會提升性能。雖然加寫buffer會使後臺的compaction操做下降他與前臺服務的I/O爭用,可是會增長很大複雜度,因此仍是不用了。最後他們給出告終論就是拿Flash作寫buffer沒用。 
而後他們還計算了,在這個存儲棧中加入Flash作二級緩存不但能提高性能達3倍之多,並且只須要增長5%的成本,比加內存性價比高不少。 
2.分層架構的缺點和改進方案 

 

如Figure 16所示,通常分佈式數據庫系統分爲三個層次:db layer/replication layer/local layer。這種分層架構的最大優勢是簡潔清晰,每層各司其職。例如db layer只須要處理DB相關的邏輯,底層的存儲認爲是available和reliable的。 
HBase是圖中a)的架構,數據的冗餘replication由HDFS來負責。可是這個帶來一個問題就是例如compaction操做會讀取多個三備份的小文件到內存merge-sorting成一個三備份的大文件,這個操做只能在其中的一個RS/DN上完成,那麼從其餘RS/DN上的數據讀寫都會帶來網絡傳輸I/O。 
圖中b)的架構就是把replication層放到了DB層的上面,Facebook舉的例子是Salus,不過我對這個東西不太熟悉。我認爲Cassandra就是這個架構的。這個架構的缺點就是DB層須要處理底層文件系統的問題,還要保證和其餘節點的DB層協調一致,太複雜了。 
圖中c)的架構是在a的基礎上的一種改進,Spark使用的就是這個架構。HBase的compaction操做就能夠簡化成join和sort這樣兩個RDD變換。 

Figure 17展現了local compaction的原理,原來的網絡I/O的一半轉化成了本地磁盤讀I/O,並且能夠利用讀cache加速。咱們都知道在數據密集型計算系統中網絡交換機的I/O瓶頸很是大,例如MapReduce Job中Data Shuffle操做就是最耗時的操做,須要強大的網絡I/O帶寬。加州大學聖迭戈分校(UCSD)微軟亞洲研究院(MSRA)都曾經設計專門的數據中心網絡拓撲來優化網絡I/O負載,相關研究成果在計算機網絡頂級會議SIGCOMM上發表了多篇論文,可是因爲其對網絡路由器的改動傷筋動骨,最後都沒有成功推廣開來。 

 

Figure 19展現了combined logging的原理。如今HBase的多個RS會向同一個DataNode發送寫log請求,而目前DataNode端會把來自這三個RS的log分別寫到不一樣的文件/塊中,會致使該DataNode磁盤seek操做較多(再也不是磁盤順序I/O,而是隨機I/O)。Combined logging就是把來自不一樣RS的log寫到同一個文件中,這樣就把DataNode的隨機I/O轉化成了順序I/O。

相關文章
相關標籤/搜索